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

["Fries, Steffen" <[e-mail]>]

Hi Eric,

thanks for the review feedback. We will incoprorate your suggestions and
comments and provide an updated version. I put some comments inline.

Ciao
	Steffen

> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]] 
> Sent: Tuesday, February 12, 2008 7:28 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Review of draft-ietf-msec-mikey-applicability-07
> 
> $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.
Thanks for the proposed tables. They are certainly a good way to
summarize the results.

> - 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.
The document is not thought to be self-contained. It is rather an
additional source of information how to use MIKEY in terms of the
applicability of the different modes, which exist also in addition to
the ones defined in RFC3830. 

> - 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.
We already received and incorporated editorial changes from the GEN-ART
review.

> - 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.
Agreed, we will incorporate such a list.

> 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
According to RFC3830 the replay handling may not work, depending on the
cache size. We will put an explanation here.

> 
> 
>   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.
MIKEY states that the parameter must be "randomly/pseudo-randomly and
secretly chosen". 
What you say is that when using static DH it would be more or less
required to have a good PRNG for the initial generation. If this is not
given you end up having the same problem as with ephemeral DH. 
We will rewrite the part to state more clearly why whe thought about
this property for a comparison.

> 
> 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.
see above

> 
>   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.
The TTP is rather connected with SRTP as with MIKEY. This is outlined in
RFC3711. We will provide a reference here to avoid a misinterpretation.

> 
> 
> S 3.2.
> Is there some plausible, scalable, mechanism whereby the 
> initiator would get the responder's public key?
This is out of scope of MIKEY-RSA. It was seen as a problem, therefore
MIKEY RSA_R was introduced providing an inband certificate provisioning.


> 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?
MIKEY allows for the usage of other DH groups as well, OKALEY5 is just
the mandatory one.

>   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?
MIKEY states "MUST be randomly/pseudo-randomly and secretly chosen". It
is not stated explicitly, that this must be done for every new run.

> 
> 
> 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?
Reworded to:
		Moreover, this scheme has a sound performance and
                   reduced bandwidth requirements compared to
MIKEY-DH-SIGN and provides a simple 
                   and straightforward master key provisioning. The
establishment of shared secrets and 
                   the lack of support for group keying is a
disadvantage.

> 
> 
> 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.
We thought that the general approach is interesting here as it enhances
the MIKEY modes and reduces the dependency on synchronized clocks. The
reason that it is in section 3 is merely because all mode extensions are
in section 3, while all other enhancements are in section 4.

> 
> 
> 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.

If I remember right, the usecase involved mobile clients like phones,
which were expected to have less performance.
> 
> 
> 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.
changed it to variety

> 
> 
>   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?
Not explained in MIKEY, would need to be done 

> 
> 
>   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.
We will rewrite it. This was rather policy related.

> 
> 
>   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?
Not in any case. If the proxy forks to two of your devices sharing the
same 
certificate+priv.key it will work.
> 
> 
>   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.
Agreed

> 
> 
> 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.
We will rephrase it to be specific to MBMS. 

> 
> -Ekr
> 
_______________________________________________
Ietf mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/ietf