Subject: [MSEC] RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt "HMAC-authent i cat ed Diffie-Hellman for MIKEY"

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Tue, 5 Mar 2002 10:34:20 +0100

Fredik,

I've inlined my response and comments below.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 47713
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Fredrik Lindholm (ERA) [mailto:[email-masked]] 
Sent:	Thursday, February 28, 2002 1:31 PM
To:	Euchner Martin  ICN M SR 3; [email-masked]
Cc:	Fredrik Lindholm (ERA)
Subject:	RE:FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt
"HMAC-authenti cat ed Diffie-Hellman for MIKEY"

Hi,

Some comments on the proposal. I had an off-line 
discussion with Martin, a few weeks ago. Some of these 
comments were raised then as well. 

The primary intention of DHHMAC is not to depend on a PKI 
(or the use of certificates). By introducing pre-shared 
keys, a PKI will of course not be needed. However, I 
personally don't see that MIKEY requires a PKI which is 
stated in DHHMAC (it is only stated that a PKI may be 
needed for scalability). There are no requirements in 
MIKEY that the public-keys must be distributed in a 
specific way. Of course, I see a few very obvious ways 
to distribute the public keys:

meu> There is nothing wrong with using a PKI of course and I would not want
to raise the impression that I dislike PKI at all. It should be obvious that
PKI is probably one of the very few security infrastructures which support
full, global scalability. If secure group communication has such
requirements then PKI is the only viable solution, shared keys would not
work then.

However, this comes at a tremendous price: availability of a PKI
infrastructure, certificate enrolement and certificate distribution
mechanisms, revocation mechanisms, certificate management and other tasks.
Each of those tasks is already complex and involves quite some effort in
terms of implementation. This is among the reasons, why PKI applications and
support in systems is still low today and might continue to be so.

However, my understanding of the MIKEY scenario is, that there is also a
case for small sized groups. Such small sized groups would not need the full
flexibility as global large scale groups. They should not require
availability of a PKI. And for simplicity, dependency on PKI and certificate
management standards should also be minimized. This is the sub-case where
the password and shared secret has its strengths and where the symmetric
shared secret or the DH-HMAC have their applicability statement (may be this
should be made more clear in the drafts).

Remember how easy it is to subscribe with a password or to provision and
securely distribute a password/shared secret? This is the most widely
deployed technique in so many systems. Nearly no implementation overhead is
necessary for this (a phone call, a snail mail envelope, an SSL web link
etc) is just sufficient for this.

I should clarify the dependency on PKI and reword this in my draft.

1) using a "full-fledge" PKI solution (with well defined 
distribution channels)

meu> This is good for the public-key distribution and DH-SIGN methods. As
far as real-time certificate validation and revocation is feasible (how
should this actually be done???) and if available, I do not see meaningful
usage for the symmetric key distribution nor the DH-HMAC either.

2) using self-signed certificates (which will lead to 
different requirements on the distribution)

meu:> This is a valid method how to use the public-key based key
distribution without availability of a full-fledged PKI. However, it
requires implementation of PKI-based protocols and methods such a
certificates, RSA X.509 digital signatures etc. And such protocols are
non-trivial to implement interoperable.

3) ignore certificates and share the public-keys in whatever 
way you like (e.g. manually inserting the key in the user 
key database like a pre-shared key). The implication of this 
would be that the public keys would be just like pre-shared 
keys. In MIKEY, it is not specified how the user key database 
is built up (as this is viewed as implementation specific), 
e.g. if it is built only on certificates or if it may 
contain "hard coded" public keys. 

Meu:> Right, the configuration is an implementation issue. Let me just say,
that many system configuration and management systems can easily handle
shared keys and passwords but are will have trouble when it comes to
configuring certificates and private/public key pairs.

Another comment concerns the scenarios addressed. The DHHMAC 
will not work for some of these scenarios it will only work 
in a one-to-one scenario, not in small-size groups as stated. 

MEU:> The DH-HMAC addresses exactly the same scenario as the symmetric-key
distribution variant: peer-to-peer such as in simple-one-to-many (MIKEY-00
section 9.1) or in small-sized groups (MIKEY-00 section 9.2). Thus, I do not
see a case where DH-HMAC would not work.
Obviously, DH-HMAC (and symmetric key distribution too) does not solve the
general, much harder problem of truly scalable group-key management. Both
variants address just a very specific sub-case.

A comment concerning the HMAC. The HMAC in DHHMAC may be used 
with either SHA-1 or a truncated SHA-1. Using HMAC with a 
truncated hash, rather than truncated HMAC with full hash, is 
highly non-standard. In particular, what are the security 
effects of truncating the 'inner' hash in the HMAC? It seems 
that, e.g., under heuristic assumptions on the keying and the 
use of the padding strings in HMAC, the collision probability 
(hence also forgery probability), appears to increase by a 
factor of two.

meu:> The truncated HMAC serves the purpose of reduced bandwidth. The
computation procedure is according to RFC2104 and is applied in IPSEC as
described in RFC 2404 "The Use of HMAC-SHA-1-96 within ESP and AH":
>> HMAC-SHA-1-96 produces a 160-bit authenticator value.  This 160-bit value
can be truncated as described in RFC2104.<<

Thus, the (outer) truncated HMAC of 96 bits is conveyed in the DH-HMAC
message; there is no truncation on the inner parts of the HMAC function.

While I could agree that truncated HMAC increases the collision probability
the general assumption and belief is that this would not significantly lower
the security, there might even be increased security gains by truncation as
pointed out below and as stated in section 5 of RFC 2104:

>> A well-known practice with message authentication codes is to
   truncate the output of the MAC and output only part of the bits
   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
   analytical advantages of truncating the output of hash-based MAC
   functions. The results in this area are not absolute as for the
   overall security advantages of truncation. It has advantages (less
   information on the hash result available to an attacker) and
   disadvantages (less bits to predict for the attacker).  Applications
   of HMAC can choose to truncate the output of HMAC by outputting the t
   leftmost bits of the HMAC computation for some parameter t (namely,
   the computation is carried in the normal way as defined in section 2
   above but the end result is truncated to t bits). We recommend that
   the output length t be not less than half the length of the hash
   output (to match the birthday attack bound) and not less than 80 bits
   (a suitable lower bound on the number of bits that need to be
   predicted by an attacker).  We propose denoting a realization of HMAC
   that uses a hash function H with t bits of output as HMAC-H-t. For
   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
   and with the output truncated to 80 bits.  (If the parameter t is not
   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
   hash are output.)<<

As such, the truncated HMAC is offered as an option in DH-HMAC in the case
where bandwidth is of concern and the security provided is acceptable.

So my personal opinion is that the DHHMAC will solve a problem 
that already can be solved by MIKEY. By using the HMAC instead 
of signatures will of course decrease the overall computational 
workload. However, due to the DH computations needed, I don't 
think a new method can be motivated from an efficiency point 
of view either.

MEU:> In some sense DH-HMAC addresses the same problem as the other MIKEY
key management schemes (see above). It is also true, that DH-HMAC provides a
simple solution for that key management problem with
- fair, mutual key agreement
- provisions perfect forward secrecy
- without any dependency on a PKI or need to implement public-key based
standards
- sound performance and reduced bandwidth (in particular with the truncated
HMAC)
- simple and straight-forward master key provisioning possible.

To summarize, none of the other 3 MIKEY methods is able to provide these
beneficial properties altogether. This is sufficient motivation for DH-HMAC
as an additional key management method in MIKEY. Let me conclude, that each
of the four key management variants has its subtle strength and weaknesses,
and no single method alone is able to subsume all the features and strengths
of the other methods.

Best Regards,
Fredrik

> -----Original Message-----
> From: Euchner Martin ICN M SR 3 [mailto:[email-masked]]
> Sent: den 30 januari 2002 16:57
> To: [email-masked]
> Subject: [MSEC] FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt
> "HMAC-authenticat ed Diffie-Hellman for MIKEY"
> 
> 
> 
> 
> 
> -----Original Message-----
> -From: 	Euchner Martin  ICN M SR 3
> Sent:	Monday, January 28, 2002 10:36 AM
> To:	'Thomas Hardjono'; Euchner Martin  ICN M SR 3
> Subject:	new draft draft-euchner-MIKEY-DHHMAC-00.txt
> "HMAC-authenticated Diffie-Hellman for MIKEY"
> Thomas,
> 
> as indicated at the past IETF MSEC WG meeting, I see reasons 
> for a fourth
> key management protocol variant in MIKEY. Please find attached my
> corresponding Internet Draft with a proposed specification of 
> such a scheme.
> However, before submitting my ID to the IETF secretariat, I 
> would like to
> consult with you how to best handle this issue.
> Please let me hear your advice on whether to make this an 
> MSEC WG draft or
> keep it as an individual draft for the time being? Of course, 
> I appreciate
> any other feedback as well.
> 
>   <<draft-euchner-MIKEY-DHHMAC-00.txt>>
> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Phone: +49 89 722 55790
> | Martin Euchner                 Fax  : +49 89 722 47713
> | Siemens AG
> | ICN M SR 3                     mailto:[email-masked]
> |                                mailto:[email-masked]
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany
> --------------------------------------------------------------
> ---------
> 
> -----Original Message-----
> -From: 	Thomas Hardjono [mailto:[email-masked]]
> Sent:	Monday, January 14, 2002 11:19 PM
> To:	Euchner Martin  ICN M SR 3
> Subject:	RE: [MSEC] Draft of minutes from IETF52 Salt Lake City
> 
> Thanks Martin.
> cheers,
> thomas
> ------
> 
> At 1/14/2002||10:43 AM, you wrote:
>  >Thomas,
>  >
>  >In your meeting report you mentioned the following statement:
>  >
>  >Another person (?) mentioned that he has a fourth key 
> establishment scheme
>  >in mind.  Will write an I-D and post to the mailing list.
>  >
>  >
>  >Actually, it was me myself who made that true statement. 
> Thus, you can
>  >frankly substitute my name there.
>  >
>  >To be honest, I had not yet time to start writing such an 
> ID as desired,
> but
>  >I hope, I will find some time and be productive until the 
> next meeting.
>  >Watch out"
>  >
>  >With kind regards
>  >
>  >Martin Euchner.
>  
> >-------------------------------------------------------------
> ----------
>  >| Dipl.-Inf.                     Phone: +49 89 722 55790
>  >| Martin Euchner                 Fax  : +49 89 722 47713
>  >| Siemens AG
>  >| ICN M SR 3                     
mailto:[email-masked]
 >|                                mailto:[email-masked]
 >| Hofmannstr. 51                 Intranet:
 >http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm
 >| D-81359 Muenchen               Internet: http://www.siemens.de/
 >| __________________
 >| Germany
 >-----------------------------------------------------------------------
 >
 >  -----Original Message-----
 >From:   Thomas Hardjono [mailto:[email-masked]]
 >Sent:   Friday, January 11, 2002 11:42 PM
 >To:     [email-masked]
 >Cc:     [email-masked]
 >Subject:        [MSEC] Draft of minutes from IETF52 Salt Lake City
 >
 >  << File: msec52_minutes-draft1.txt >>
 >Folks,
 >
 >Attached is the draft of the minutes from the MSEC WG meeting
 >at IETF52 in Salt Lake City.
 >
 >My apologies for being late.
 >
 >Please look at it and comment a.s.a.p.  This was my effort at merging
 >the two pieces of the minutes (Thanks to Dennis and Lakshminath for
 >consecutively taking the minutes).
 >
 >If there are no major objections I might try to include it with the slides
 >for submission to the formal IETF52 Proceedings (deadline Jan/14).
 >
 >All the slides are now on the website, and only this minutes-file
 >is missing/late.
 >
 >cheers,
 >
 >thomas
 >------

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

---

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 5 Mar 2002 13:56:39 +0100

Hi Martin!

(only some small comments inline)

> configuring certificates and private/public key pairs.

I still see no difference in sharing a pre-shared key and sharing a 
public key, except the size. But there is a big step if you 
introduce passwords (as these are generally memorable). However, 
if you try to introduce passwords, you will lower the security 
quite drastically in DH-HMAC. The MAC can be used by an attacker 
to verify whether the guessed password is correct. So, I think you 
should point out security implications etc. if you intend to use 
passwords.

> variants address just a very specific sub-case.

No, DH-HMAC does not solve the same scenarios as the symmetric-key 
distribution.

Assume we have three parties A, B, and C. A would like 
to invite B and C to a group communication (i.e. they will share 
the same TEK) and where A will choose the group key. 

In the symmetric-key distribution A chooses the PMK key and 
sends this to the both parties. Both B and C will obtain the same 
PMK and can derive the same TEK. No problems.

In the DH-HMAC we will have the following:

A               B               C
      to B
g^x  ------->   
     <-------  g^y
(A and B will use PMK = g^(xy))

g^a  --------------------------->
     <--------------------------- g^b
(A and C will use PMK = g^(ab))

i.e. this will create completely different PMKs 
for the communication between A and B, and A and C.
This is valid for all groups where the number of 
members are equal or greater than 3.

There are solutions of using DH to create group 
keys. But that is not something MIKEY is using.

> described in RFC 2404 "The Use of HMAC-SHA-1-96 within ESP and AH":

Sorry, I must have misunderstood you. I guess this was due to: 
"SHA-1-96 produces a slightly shorter HMAC result where the SHA-1 
result SHALL be truncated to the 96 leftmost bits when represented 
in network byte order". 
I think it would be good to explicitly state that it is not the SHA-1s 
that are truncated, but the result of the final HMAC.  

Cheers,
Fredrik

---

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Tue, 5 Mar 2002 15:19:09 +0100

Fredrik

Again thank for your comments. You may find my response below.

With kind regards

Martin Euchner.

 -----Original Message-----
From: 	Fredrik Lindholm (ERA) [mailto:[email-masked]] 
Sent:	Tuesday, March 05, 2002 1:57 PM
To:	Euchner Martin  ICN M SR 3; [email-masked]
Subject:	RE: FW: new draft draft-euchner-MIKEY-DHHMAC-00.txt
"HMAC-authent i cat ed Diffie-Hellman for MIKEY"

Hi Martin!

Meu:> It is true and well known, that passwords and static shared secrets
introduce a security risk. This was so obvious, that I probably forgot to
mention this in my security considerations section (you see, there is more
to add...). Of course, there are many security issues related just to
password usage and maintenance of shared secrets. You are right, in that
passwords of short lengths but also non-random shared secrets are
susceptible to systematic attacks where an attackers looks at the MAC.

However, MIKEY doesn't say anything about the nature of the shared key such
as whether it stems from a password. As things are at the moment (not having
looked at MIKEY-01 yet), the issue of passwords is outside of MIKEY. I'm not
intending to introduce a password into MIKEY, the password was merely an
example in my argumentation.

But the question is if this is really user-friendly just to work with some
clumsy shared secret bit string rather than a somewhat longer but more
readable pass phrase perhaps? The more I'm thinking on this and am debating
with you on this issue in general, the more I see the need to address the
management, configuration and provisioning issues at least in the security
considerations section in both drafts.
Another issue related to that should be how often to change the shared
secret and how to update it. If our solutions would depend on "real-time"
provisioning, then we somehow missed our goal.

Yet, assuming the shared secret is sufficiently long, random etc, the
systematic guessing and probing attack on the MAC is possible in theory for
the symmetric key distribution and the DH-HMAC variant, but probably
neglectable in practice (this could also be addressed in both security
consideration sections).

A               B               C
      to B
g^x  ------->   
     <-------  g^y

Meu:> Frederick, you are absolutely right here. It was my oversight. Of
course Diffie-Hellman as we use it, works only point-to-point and not
multipoint.

Thus, I should rather say that DH-HMAC works in the same scenario as
DH_SIGN, namely point-to-point. Am I right to consider a sender-receiver
group with two members as a very special case of a small-group?

MEU:> Yes there is a generalized DH scheme with a nice theory, but I doubt
on whether this is a practical scheme (not speaking about real-time at all).

MEU:> Ok, I can clarify this issues in a next version of DH-HMAC.

Cheers,
Fredrik