Subject: Re: [MSEC] DH mode in MIKEY

From: Ran Canetti <[email-masked]>
Date: Tue, 17 Jun 2003 15:10:54 -0400

Elizabetta, Martin, and all,

[Cochair hat off]
TO add some pepper to the discussion, let me present the following points 
questioning the utility of the DH mode in MIKEY. (The points cam up in
several discussions between the authors, the chairs of msec and mmusic,
and the respective ad's. Any thoughts are most welcome.
All the other modes in MIKEY involve a single "downstream"
message. This is great advantage, and in particular it mitigates the
added complexity (and additional security threats) involved in using
timestamps. The DH mode ddoes not enjoy these advantages, since it
requires an upstream message. Thus the following questions arise:
(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").
(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.)
(c) MIKEY is directed at media and multimedia straming. 
Is PFS an important concern for such scenarios? is it worth the extra
complexity?

[Cchair hat on]
We need to get to closure on this issue, in order to move forward with the
mikey draft. So lets put a cap of a week on the dicsussion and try to reach
closure by June 24th.

Ran

> 
> MIKEY has been through AD review (by Russ). One question 
> that was brought up was whether the DH key exchange was 
> needed or not. We decided that such discussion should be 
> brought to the list. 
> 
> Below is a very brief summary of the discussion so far. 
> To avoid a too lengthly discussions, Ran and Thomas will 
> issue a deadline for it.
> 
> A summary of motivations for keeping the DH mode: 
> - it is the only mode giving PFS.
> - Unlike RSA (and essentially all public key methods) DH 
>   can be instantiated VERY efficiently by selecting an 
>   appropriate group, e.g. elliptic curves. 
> - There has been explicit interest for this mode 
>   (&lt;draft-ietf-msec-mikey-dhhmac-01.txt&gt;).
> - While MIKEY was designed to be useful in small groups, 
>   many use cases for DH will only be simple person-to-person 
>   calls (where DH indeed applies).
> 
> Summary of the questioning of the DH mode:
> - Does it make sense to have yet-another DH based exchange 
>   in the IETF, and what added value does this protocol 
>   have over existing ones, e.g. IKE, TLS, SSH? 
> - Without the DH mode, there will be a more unified model 
>   of the key establishment (which would be very helpful for 
>   the understanding of the protocol). 
> - Does it make sense to have a two round, timestamp-based 
>   DH, rather than a 3 round nonce-based one (the benefits 
>   and the need for timestamps in the DH case are not as 
>   strong as in the other modes)? 
> 
> The authors recommendation has been to keep the DH mode, but
> - better clarify the difference between the DH mode and the other 
>   modes in the document
> - make the DH mode optional to implement.
> 
> We would like to hear the opinion of the people in msec.
> 
> Thanks, 
> cheers
> 
> /the authors
>  
> 
> 
> 

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

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 18 Jun 2003 15:37:48 +0200

Hi Ran,

I made some inline comments.

(a)If we're already having an upstream message, then why not have a
> (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