Subject: [MSEC] Last minute edits in draft-ietf-msec-mikey-dhhmac-11.txt

From: "Euchner, Martin" <[email-masked]>
Date: Mon, 27 Feb 2006 09:37:17 +0100

Dear MSECers,

Following the call of the SAAG Security Area Directorate and the general
advice giving by the MSEC WG chair, I've investigated the situation on
the security of hash functions in the context of MIKEY-DHHMAC.
I've added some new text to the MIKEY-DHHMAC security consideration
section where I provide considerations on the security of HMAC-SHA1 in
the context of DHHMAC and the formerly reported attacks on hash
functions.

In particular; let me propose the following new paragraph to be added to
the end of section 5.5 "Residual risk":

HMAC-SHA1 is a key security mechanism within DHHMAC upon which the
overall security of MIKEY DHHMAC depends.  MIKEY DHHMAC uses HMAC-SHA1
in combination with the classic Diffie-Hellman key agreement scheme.
HMAC-SHA1 is a keyed one-way hash function that involves a secret in its
computation.  DHHMAC applies HMAC-SHA1 for protection of the MIKEY
payload.  Likewise, the pseudo-random function PRF within MIKEY [3] uses
the HMAC-SHA1 mechanism as a key derivation function.
While certain attacks have been reported against SHA1 and MD5 (see
[38]), with current knowledge (see [38], [39]), no collision attacks
have been reported against the HMAC-SHA1 security mechanism.
It is believed that MIKEY DHHMAC should be considered secure enough for
the time being. Thus, there is no need to change the underlying security
mechanism within the MIKEY DHHMAC protocol.
<<<

Further, I've added the following two related references to the section
8.2 "Informative References":
[38] P. Hoffman, B. Schneier; "Attacks on Cryptographic Hashes in
Internet Protocols"; RFC 4270; IETF, November 2005.

[39] S.M. Bellovin, E.K. Rescorla: "Deploying a New Hash Algorithm",
October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
<<<

I've also added a reference to MIKEY-RSA-r by replacing the reference
[15] (which is duplicate with [9] and has become RFC 4086 in the
meantime) with
[15] D. Ignjatic, L. Dondeti et al: "An additional mode of key
distribution
in MIKEY: MIKEY-RSA-R", Internet Draft, Work in Progress,
draft-ietf-msec-mikey-rsa-r-02, IETF, January 2006.
<<<

Further, I've added reference to the MIKEY-ECC draft
[40] A. Milne et al: "ECC Algorithms For MIKEY", Internet Draft, Work in
Progress, draft-ietf-msec-mikey-ecc-00, IETF, June 2005.
<<<
and by replacing the former statement in section 5.5 >>>Note, that an
elliptic-curve Diffie-Hellman variant of MIKEY remains for further
study.<<< by the new statement
Note, that elliptic-curve variants of MIKEY are defined in [40].
<<<

There are a few other, very minor typos and editorial corrections that
I've made to the -11 version since, which should not be worth mentioning
here.

Please let me know, if these proposed editorial changes are ok, and if
not how the new text should be modified. (No feedback means acceptance).

FYI: draft-ietf-msec-mikey-dhhmac-11.txt is IESG approved and is
currently sitting in the RFC editors queue and is waiting there for
publication. However, DHHMAC is stuck from progress due to various
dependencies of other referenced normative draft RFC documents which are
yet to enter the RFC editor's queue.

With kind regards

Martin Euchner.
---------------------------------------------------------------------
| Dipl.-Inf.                     
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| COM GCM PS 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: [email-masked]
[mailto:[email-masked]] On Behalf Of Lakshminath
Dondeti
Sent: Donnerstag, 17. November 2005 02:40
To: [email-masked]
Cc: canetti
Subject: [MSEC] SHA-1 replacement analyses for MSEC protocols

At the SAAG meeting, Russ directed all SEC area WGs to analyze the 
protocols they are working (worked) on and plan for SHA-1 
replacement.  Here are the directives (1) and (2):

"1.Do the Bellovin-Rescorla analysis before IETF 65 for each protocol 
in the WG"
"2.Start standards work for transition to SHA-256, but remember 
another transition is coming, so plan for it"

MSEC has the following documents/protocols to analyze:

GSAKMP
GDOI
MSEC-signatures
MIKEY related
TESLA

Did I miss any?

Our first request to everyone is to read the Belloving-Rescorla paper 
(the relevant NIST and SAAG presentations materials should help as 
well).  Feel free to discuss the analysis method and your review of 
that paper with other MSEC contributors.

References:
http://www.cs.columbia.edu/~smb/papers/new-hash.pdf
http://www.csrc.nist.gov/pki/HashWorkshop/2005/Oct31_Presentations/Bello
vin_new-hash.pdf
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64

(search for SAAG meeting materials)

Next, if you are interested in analyzing any of the MSEC documents or 
protocols, please contact Ran and me.  Some of you have already done 
so; thanks.

We need to start work on this ASAP as we need to finish this work 
before the March IETF meeting,  **February 27, 2006 would be the -00-
deadline

We'll post the protocol analysis assignments :-) toward the end of 
next week.  (Please hurry and volunteer).

thanks and regards,
Lakshminath

for
Ran & Lakshminath

PS:  Current document authors MUST do the analysis as part of their 
next document revision.  Thanks.

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

---

From: David McGrew <[email-masked]>
Date: Mon, 27 Feb 2006 03:43:53 -0800

Martin,

> have been reported against the HMAC-SHA1 security mechanism.

here is a nit: in the above you should probably strike the word  
"collision", since HMAC is most likely used just as a MAC and a PRF.   
You might also want to cite the recent work http://eprint.iacr.org/ 
2006/043 as evidence that HMAC can be a good PRF even when the  
underlying hash is not collision resistant.

David