Subject: RE: [MSEC] DH mode in MIKEY

From: "Fredrik Lindholm (EAB)" <[email-masked]>
Date: Wed, 25 Jun 2003 13:57:28 +0200

To wrap up the discussion, from the mails we have seen, 
it seems as there is support for the DH-mode. The fact that 
H.323 uses MIKEY with DH in its specs gives also an extra 
motivation to keep the DH-mode. We would therefore like to 
suggest that our initial recommendation is followed, i.e. 
to keep the DH mode, but
- better clarify the difference between the DH mode and the other 
  modes in the document, and
- make the DH mode optional to implement. 

Fredrik 

> -----Original Message-----
> From: Steffen Fries [mailto:[email-masked]]
> Sent: den 18 juni 2003 15:38
> To: [email-masked]; Ran Canetti
> Subject: Re: [MSEC] DH mode in MIKEY
> 
> 
> Hi Ran,
> 
> I made some inline comments.
> 
> (a)If we're already having an upstream message, then why not have a
> > three-message protocol that is based on nonces rather than 
> timestamps?
> > (nonces are easier to deal with, and they are not susceptible to
> > "clock rewinding attacks").
> In multimedia sytems there are protocols used that just feature 
> a two message exchange between the sender and the receiver. 
> Here MIKEY can be applied. One example is the usage of Fast 
> Start in H.323. Here only the SETUP message and the appropriate 
> response message are sent. A three way protocol would add an 
> extra message to Fast Start, which is not desired. Furthermore, 
> MIKEY has already been considered by the ITU-T for usage in 
> H.323 in combination with SRTP in Draft H.235 Annex G. 
> Again, in multimedia environments MIKEY is intended to be 
> incorporated into (existing) VoIP protocols using only a full 
> handshake rather than be used standalone.
> Moreover, DH is useful in this case to have e.g. PFS (see also 
> point c below). 
> 
> (b) If we're already having a nonce-based
> > DH exchange, then why not use an off-the-shelf protocol such as
> > TLS/SSH/IKE etc., rather than doing things from scratch? (for
> > instance, if we use IKEv2, we get a four message exchange that is
> > already protectign against DOS, is relatively well analyzed, etc.) 
> MIKEY is defined in a way that it may be integrated into 
> existing protocols as a key management container. This is for 
> instance the case for SIP and H.323. Because of the few 
> messages needed by MIKEY for key management and security policy 
> negotiation it integrates nicely in protocols only using a full 
> handshake to establish a session between two parties. Other key 
> management approaches like the ones you mentioned require more 
> messages to be exchanged.
> 
> (c)
> > MIKEY is directed at media and multimedia straming. Is PFS an
> > important concern for such scenarios? is it worth the extra
> > complexity?
> MIKEY may be used in VoIP environments to provide means for 
> media data protection. PFS may not be necessary in every case 
> but PFS is a security property, which cannot be achieved in any 
> other way. If this is worth the extra effort may be a scenario 
> specific question. Nvertheless, PFS provides additional 
> security, with the ensurance that the security may not be 
> compromised in a backwards way. 
> You might compare this additional security functionality with 
> somebody who encrypts files on his PC despite the fact that the 
> PC is protected against unauthorized access.
> 
> Steffen
> 
> 
> 
> 
> 
> _______________________________________________
> msec mailing list
> [email-masked]
> http://www.pairlist.net/mailman/listinfo/msec
> 

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: canetti <[email-masked]>
Date: Thu, 26 Jun 2003 18:27:07 -0400 (EDT)

Frederik, Steffan,

Yes, I tend to agree with your reading of the situation. The reasoning
below sounds convincing enough to me, and no other objection was made on
the list.

So, Frederik, I sounds like you should go ahead and submit
a revised version that keeps the DH mode as optional, and clarifies its
role and rationale.

Thanks,

Ran