Subject: [MSEC] DH mode in MIKEY

From: "Elisabetta Carrara (EAB)" <[email-masked]>
Date: Wed, 4 Jun 2003 16:28:46 +0200

Hi,

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 
  (<draft-ietf-msec-mikey-dhhmac-01.txt>).
- 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: "Fredrik Lindholm" <[email-masked]>
Date: Fri, 13 Jun 2003 01:10:36 +0200

FYI (mail from Martin Euchner),

Ran, Thomas, it seems like there are mails that do not turn up in the msec
mail
archives. I have received one mail from Martin and one mail from Mark which
does not appear in the archives, though they are addressed to the group.

Cheers,
Fredrik

----- Original Message ----- 
From: "Euchner Martin" <[email-masked]>
To: "'Elisabetta Carrara (EAB)'" <[email-masked]>;
<[email-masked]>; "Euchner Martin" <[email-masked]>
Cc: "Fredrik Lindholm (EAB)" <[email-masked]>; "Karl
Norrman (EAB)" <[email-masked]>; "Mats Naslund (EAB)"
<[email-masked]>; "Jari Arkko (LMF)"
<[email-masked]>
Sent: Thursday, June 12, 2003 10:08 AM
Subject: RE: [MSEC] DH mode in MIKEY

> Dear all,
> It is true that MIKEY features 3 key management protocol variants (key
distribution with symmetric shared secrets, signed key distribution with
RSA, and signed key agreement with the DH protocol).
>
> In the following I want to provide good arguments (also in support of the
editor) why I believe the DH protocols are necessary for MIKEY and thus to
keep DH within MIKEY.
>
> 1. DH provides an important security property "perfect forward secrecy"
(PFS). None of the other MIKEY protocols is able to provide this security
property and thus none of the other MIKEY protocols is able to substitute
the DH-PFS property in that regard.
>
>
> 2. It is exactly this crucial and nice PFS property of DH that made the DH
protocol a core key management function in various other key management
protocols including IKE (v1, v2), TLS, SecSH and many, many more.
>
> 3. DH protocol is a generic technique not only applicable to groups of
prime or of characteristic 2. This is because of the fundamental
mathematical assumption that the discrete logarithm problem is also a very
hard one in general groups. This enables DH to be deployed also for GF(p)*,
sub groups and for groups upon elliptic curves. RSA does not allow such
generalization as the core mathematical problem is a different one (large
integer factorization).
>
> 4. While RSA asymmetric keys tend to become increasingly lengthy (1536 bit
and higher) and thus very computational intensive. Elliptic-curve DH (ECDH)
allows to cut-down key lengths substantially (say 170 bit and higher) while
maintaining at least the security level and providing even significant
performance benefits in practice. Moreover, it is believed that elliptic
curve techniques provide much better protection against side channel attacks
due to the inherent redundancy in the projective coordinates. For all this,
one may view elliptic-curve-based DH as being more "future-proof" than RSA.
>
> 5. Due to the fact the both entities (sender and receiver) contribute to
the generation of the DH key, malicious cheating or using weak random
generators of either side may be leveraged. One may view this as an
additional distributed security measure increasing security robustness over
the case where all the security depends just on the proper implementation of
a single entity.
>
> 6. DH has proven feasible in praxis over many years and in many cases.
MIKEY should thus inherit the security properties of DH such as PFS but also
other beneficial properties of DH; e.g., like implementation ease.
>
> 7. The MIKEY key management protocol suite is optimized for the purpose of
multimedia applications with real-time constraints. In particular, all MIKEY
key management protocols terminate in at most one round-trip; making MIKEY
perfectly suitable for integration into the two-way signaling handshake of
SIP/SDP offer/answer or H.245 fast start.
>
> 8. MIKEY is able not only to agree or deliver new key material with this
handshake, but also to negotiate a security policy with security
capabilities and crypto algorithms as part of this handshake. No other key
management protocol (IKE, TLS, SecSH) is able to accomplish this task in at
most a single round trip. No wonder, none of those key management protocols
for "data applications" ever had any real-time requirements in their design,
why should they fulfil it? Therefore, IPSEC, TLS, or other lengthy key
management protocols just cannot meet the specific time constraints of a
multimedia key management protocol for real-time MM applications.
>
> 9. MIKEY is a rather generic MM-key management protocol with many
potential applications. Let me report in my capacity as Q.G/16 Rapporteur,
that ITU-T SG16 has figured out a use case (or call it applicability profile
of MIKEY) in the H.323-multimedia environment; this is described within
draft H.235 Annex G " Usage of the Secure Real Time Transport Protocol
(SRTP) in conjunction with the MIKEY Key Management Protocol within H.235".
This fairly stable draft specifies several deployments of MIKEY key
management protocols including also DH-SIGN and DH-HMAC. For this reason,
the MIKEY DH variants do have true applicability statements and this should
underline the need of DH in MIKEY.
>
> 10. Perhaps it should be better clarified in the MIKEY ID, that MIKEY is
not supposed to be yet another alternative to general key management
protocols. Rather, MIKEY is applicable just for the purpose of a multimedia
applications with according key management needs.
>
> 11. The question of timestamps and quasi synchronized time came up a
couple of times in the discussion. While it may be difficult to argue about
the general, abstract case, at least in H.235 Annex G enabled environments,
the constraint of timestamps does not put a big burden; similar thoughts
might hold for SIP too.
>
> 12. Avoiding timestamps in key management protocols and using nonces etc.
would immediately add another half-round trip at least and thereby would
break the "at-most one roundtrip" constraint given by the MM applications
like SIP or H.323. However, in practice usage of time servers is not that
out-of scope, as it might appear at first sight. Many environments have
already such time servers available and thus such facilities could be used
too.
>
> 13. It is true that DH as MIKEY defines it, is just applicable for a group
of size 2 (i.e., plain P2P communication). There is no straight-forward
generalization known that naturally extends DH key-agreement to true groups
with several members that would fit into the basic MIKEY handshake protocol
flow. Still, although DH is poor in terms of group-support, the simple,
degenerated 2-entity group still plays a major and important role in
practice.
>
> 14. Recognizing that DH plays a special role within MIKEY (in particular
in terms of group-support), one may in fact consider making the DH variants
of MIKEY an option. This may assist to describe more easily a unified
group-key management approach of MIKEY.
>
>
> As a conclusion, I should say that I see clear value-add in having the
MIKEY-DH variants around.
>
>
> With kind regards
>
> Martin Euchner.
> -----------------------------------------------------------------------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 62366
> | ICN M SR 3                     mailto:[email-masked]
> |                                mailto:[email-masked]
> | Hofmannstr. 51                 Intranet:
http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany
> -----------------------------------------------------------------------
>
>  -----Original Message-----
> From: Elisabetta Carrara (EAB) [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2003 4:29 PM
> To: [email-masked]'
> Cc: Fredrik Lindholm (EAB); Karl Norrman (EAB); Mats Naslund (EAB); Jari
Arkko (LMF)
> Subject: [MSEC] DH mode in MIKEY
>
> Hi,
>