Review of draft-ietf-msec-mikey-applicability-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



$Id: draft-ietf-msec-mikey-applicability-07-rev.txt,v 1.3 2008/02/12
12:53:27 ekr Exp $

OVERVIEW
MIKEY [RFC3830] is a key exchange protocol intended for use with SIP
and SRTP. Like many such protocols, it's really a framework and it's
accumulated a baffling array of methods/modes over the years (e.g.,
DH, RSA, RSA-R, shared key, etc...) This document provides an overview
level description of the various modes and the scenarios in which they
are usable.


GENERAL COMMENTS
This document needs significant revision before it is ready for
publication.

- Given that this is an applicability document, it really needs
 some summary tables of what is applicable when. I have provided
 mine in this review.

- It's a little hard to understand how this document is supposed
 to be used. One gets the impression that it's supposed to be
 self-contained, but it's pretty hard to understand the
 ladder diagrams and descriptions of the modes without reference
 to 3830. If this document is intended to be self-contained,
 then a higher level of abstraction and more introduction is needed.

- A lot of the assessments made here seem more like opinions and
 qualitative judgements than facts. For instance:

  The two MIKEY modes, which only
  require one message to be transported (Section 3.1 and Section 3.2),
  work nicely in early media situations, as both, sender and receiver

 This is semi-editorial, but I would stick to factual assertions.

- The document needs a thorough review for writing quality and
 a copy-edit. I found numerous editorial errors.

- All of S 3 would benefit by breaking out the advantages and
 disadvantages into some kind of list, rather than just
 having a freeform paragraph.


SPECIFIC COMMENTS
S 2.
This terminology dump is really hard to map to the rest of the
text. It's fine to have a glossary, but you also need to
introduce the terms in context in the main text (see general
comments above).

S 3.

  The focus of the following subsections lies on the key distribution
  methods as well as the discussion about advantages and disadvantages
  of the different schemes.  Note that the MIKEY key distribution
  schemes rely on loosely synchronized clocks.  A secure network clock
  synchronization protocol should realize this.  RFC3830 recommends the
  ISO time synchronization protocol [ISO_sec_time].  The format applied
  to the timestamps submitted in the MIKEY have to match the NTP format
  described in [RFC1305].  In other cases, such as of a SIP endpoint,
  clock synchronization by deriving time from a trusted outbound proxy
  may be appropriate.

What happens if the clocks aren't synchronized


  o  Provision of Perfect Forward Secrecy (PFS): Describes the support
     of PFS, which is, according to RFC4949 [RFC4949] the the property

s/the the/the/


  o  Key generation involvement: Describes if both or just one of the
     participants are actively involved in key generation.  The option
     to involve both parties in the key generation is interesting to
     avoid that one communication partner generates (intentionally or
     unintentionally) weak keys.

The situation is rather more complicated than this. There are three
properties that you at least potentially want to be able to
ensure:

1. That each side can guarantee that keys are fresh (thus preventing
  replay attack).
2. That a problem in either side's PRNG doesn't result in compromise
  of the protocol.
3. That neither side can force the generation of weak keys or keys
  from some restricted subspace.

The first property can be assured simply by both sides contributing
public entropy.

The second property can only be assured by requiring attack on key
pairs generated from *both* sides in order to recover the traffic
keys. Note that DH does not provide this property, since only one
key pair need be attacked. The classic argument here is that *static*
DH provides more protection here because the sides can use a single
good PRNG to generate their DH shares and then can have weak PRNGs.
But AFAICT, MIKEY doesn't use static DH, but rather ephemeral DH,
ewhere this argument does not apply.

The third property is basically impossible to achieve with RSA and
difficult even with DH. Since a malicious peer can basically provide
their keys to some third party via a side channel, this isn't very
interesting anyway.

So, this paragraph needs a total rewrite to more clearly indicate
what you're trying to achieve.

  If MIKEY is used for SRTP [RFC3711] bootstrapping, it also uses the
  SSRC to associate security policies with actual sessions.  The SSRC
  identifies the synchronization source.  The value is chosen randomly,
  with the intent that no two synchronization sources within the same
  SRTP session will have the same SSRC.  Although the probability of
  multiple sources choosing the same identifier is low, all (S)RTP
  implementations must be prepared to detect and resolve collisions.
  Nevertheless in multimedia communication scenarios supporting forking
  (see Section 5.2), collisions may occur leading to so-called two-time
  pads, i.e., the same key is used for media streams to different
  destinations.  Note that two time pads may also occur for media

You need to elaborate on this more. If two-time pads are actually a
possibility with MIKEY, that's a really serious flaw,
since TTP leads to almost complete compromise of the plaintext.
Worse yet, GCM is known to be very brittle in the face of
any keying material reuse.


S 3.2.
Is there some plausible, scalable, mechanism whereby the initiator
would get the responder's public key?


S 3.3.
  dependent on the certificate used.  Besides the use of X.509v3
  certificates it is mandatory to support the Diffie-Hellmann group
  "OAKLEY5" [RFC2412].

This requires some more elaboration. What if you want to use
another DH group?

  The advantages of this approach are a fair,
  mutual key agreement (both parties provide to the key),
  perfect forward secrecy, and the absence of the need to fetch a certificate
  in advance as needed for the MIKEY-RSA method depicted above.

See above comments about key generation involvement. Also, PFS
is only provided if you require that both sides generate fresh
keys for each exchange. Is that required in MIKEY?


S 3.5.

  standards.  Moreover, this scheme has a sound performance and reduced
  bandwidth requirements and provides a simple and straightforward
  master key provisioning.  Lack of support for group keying is a
  disadvantage.

This all looks suspiciously like opinion. Sound performance and reduced
bandwidth requirements as compared to what? Simple and straightforward
compared to what? I mean, this requires manually established keys, right?


S 3.6.
I'm not sure why SAML is being discussed here, if there aren't
any drafts. Given its status, if it is to be discussed, maybe in
S 4, where you discuss the work in progress.


S 3.7.
  key delivery scheme.  Note that the Initiator can contribute to the
  key material since the key is derived from through CSB-ID and RAND
  payloads in unicast use cases.

So, this is a good example of confusion about contributing to the
key material, since this is public entropy, bnot private entropy.

  This mode is also useful in multicast
  scenarios where multiple clients are contacting a known server and
  are downloading the key.  Responder workload is significantly reduced
  in these scenarios compared to MIKEY in public key mode.  This is due
  to the fact that the asymmetric encryption requires less effort
  compared to the decryption using the private key.

Well, it's reduced by a factor of about two, right? OTOH, responder
workload is increased by the same factor.


S 4.1.
This isn't really a comment on this document, but what's the
rationale for adding ECIES and ECMQV?


S 5.
  While MIKEY and its extensions provide plenty of choice in terms of
  modes of operation an implementation may choose to simplify its
  behavior.

Plenty? That seems like opinion again. There are certainly a lot of
modes, but plenty is a question of whether some set of them
meet the requirements for which they are designed.


  Responder in public key mode.  If envelope keys are cached it can
  then also choose to do re-keying in shared key mode.  In general,

How would you know if envelope keys were cached?


  communication takes place.  An implementation that does not support
  shared key mode can mimic behavior of a peer that does but lacks the
  shared key.  Similarly, if a peer chooses not to operate in the
  public key mode it may reject the certificate of the Initiator.  The
  same applies to peers that choose to operate in one of the DH modes
  exclusively.

I don't understand what this graf is trying to say.


  Forward MIKEY modes, were the initiator provides the key material,
  like public key or shared key mode when used in SIP/SDP may lead to
  complications in some calls scenarios, for example forking scenarios
  were key derivation material gets distributed to multiple parties.

s/were/where/*2


  may cause the initiator to drop the session invitation.  Even in the
  case all parties involved have all the prerequisites for interpreting
  the MIKEY message received there is a possible problem with multiple
  responders starting media sessions using the same key.  While the
  SSRCs will be different in most of the cases they are only sixteen
  bits long and there is a high probability of a two-time pad problem.

So, this means that these modes are useless in any case where there
might be forking, right?


  4.  If the Initiator does not expect the receiver to have his
      certificate he may use RSA-R.  Using RSA-R he can provide the
      initiators certificate information in-band to the receiver.
      Moreover, the initiator may also provide a random number which
      can be used by the receiver for key generation.  Thus both
      parties can be involved in the key management.  But as the
      inclusion of the random number cannot be forced by the initiator,
      true PFS cannot be provided.  Note that in this mode, after
      establishing the TGK, it may be used as PSK with other MIKEY
      modes.

The reason that PFS can't be provided here is not that the inclusion
of the random number can't be forced by the initiator, but rather
that the initiator's static RSA key is used.


  6.  If no PSK or certificate is available at the initiators side (and
      likewise at the receivers side) but lower level security (like
      TLS ot IPSec) is in place the user may use the unprotected mode
      of MIKEY.

You need to explain that this is unsafe in any case where there is an
untrusted proxy.


The end of this section needs some charts of which modes provide
which properties and can be used in which settings. This should
look something like this:


                Early    Secure      Retargeting    Redirect   Shared
                Media    Forking                               Key Conf
------------------------------------------------------------------------
PSK  (3.1)         Yes                                           Yes *
RSA  (3.2)         Yes                                           Yes *
DH-SIGN (3.3)              Yes*         Yes             Yes
Unprotected (3.4)  Yes
DH-MAC (3.5)
RSA-R  (3.7)               Yes          Yes             Yes      Yes *


* = with problems
   DH-SIGN with forking + early media has perf issues as
   described in S 5.2, as well as group negotiation issues
   as called out in my review.

   The conferencing modes only work properly with one orientation
   of requester/responder.


                Manual    Needs        PFS    KGI
                 Keys      PKI
----------------------------------------------------
PSK  (3.1)         Yes      No          No     No
RSA  (3.2)         No       Yes         No     No
DH-SIGN (3.3)      No       Yes         Yes    Yes
Unprotected (3.4)  No       No          No     No
DH-MAC (3.5)       Yes      No          Yes    Yes
RSA-R  (3.7)       No       Yes         No     No


KGI == Key generation involvement

It looks to me like (and I recall from previous discussions) that
there is no mode that can be guaranteed to work. That needs to get
called out explicitly.



S 5.1.

  To cope with the early media problem there are further approaches to
  describe security preconditions [RFC5027], i.e., certain
  preconditions need to be met to enable voice data encryption.  One
  example is for instance that a scenario where a provisional response,
  containing the required MIKEY parameter, is sent before encrypted
  media is processed.

This doesn't cope with the early media problem, it just means that
you get no voice instead of voice you can't decrypt. This also
interacts badly with forking (cf. HERFP).



S 5.2.

  MIKEY data.  For asymmetric MIKEY modes, if the sender is aware of
  the forking he may not know in advance to which location the INVITE
  is forked and thus may not use the right receiver certificate to
  encrypt the MIKEY envelope key.  Note, the sender may include several

In what settings would the sender be aware of forking? How does this
work with calls to people you've never claled before? I don't see
how either of these modes actually works right.


  Moreover, depending on the MIKEY mode chosen, a two-time pad may
  occur in dependence of the negotiated key material and the SSRC.  For
  the non Diffie-Hellman modes other than RSA-R, a two-time pad may
  occur when multiple receivers pick the same SSRC.

Again, so this is really bad, right?


S 7.
  was voted in favor of DTLS-SRTP.  Thus, the reader is pointed to the
  appropriate resources for further information.  Note that MIKEY has
  already been deployed and is also targeted for use in 3GPP and MBMS
  applications.

As I understand it, 3GPP intends to use DTLS-SRTP when it's finished,
so you might consider rephrasing this sentence so it doesn't quite
so much give the impression that they will be using MIKEY and
not DTLS-SRTP.

-Ekr
_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]