Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 5 Dec 2005 14:39:12 -0800

David McGrew asked me to comment on the appended message re hash
functions in IKE.

My view is that there is no need to RUSH into upgrading SHA-1 in
IKEv1 or v2. The only place where the recent attacks have a direct
relevance is in public key certificates. Other uses of hashes in IKE
(which include PRF, MAC, ephemeral signatures, and the randomness
extraction functionality referred to by David's mail) would have some
benefit from a hash function upgrade but nothing truly urgent. None of
these uses are based on collision resistance in some essential way.
Of course, new attacks, in particular on the pseudo-random properties of
secretly-keyed HMAC, could be found in the future (or maybe even in the
present), but such attacks to be of real significance will not be merely
collision attacks.

On the other hand it is imperative that a transition to stronger hash
functions be planned now and executed asap. First, we do not know how fast
attacks will improve and reach the point of being relevant even for uses
such as in IKE. Second, such a transition is needed across all
cryptographic applications and certainly across ietf standards.
Last, there are no performance issues with the hash functions used in
IKE. These operations are all quite insiginificant in comparison to public
key (signatures and Diffie-Hellman) operations, so a slower hash function
should not be a consideration against upgrading (this may be different in
the case of ipsec that uses HMAC to MAC millions of packets).

As for certificates, where collision attacks may be of real significance,
this is not IKE-specific. In that front, planning a transition is even
more significant (and I would not count on the lack of explicit practical
attacks on real-world certificates).

Hugo

On Fri, 2 Dec 2005, David McGrew wrote:

>  Hi Michael,
>
>  On Dec 2, 2005, at 7:35 AM, Michael Richardson wrote:
>
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  >>>>>> "David" == David McGrew <[email-masked]> writes:
>  >>>>>>
>  >   David> I think that it's worth suggesting that implementors
>  > move to
>  >   David> a SHA-256 based PRF for IKE.
>  >
>  > I don't think you understand the attacks very well if you suggest
>  > that.
>  > The PRF is about sifting bits.  The inputs to it are fixed in length
>  > (for a given situation) consists of pieces from both parties, which
>  > are
>  > both public (nonces and cookies), as well as private (result of DH).
>  > The output of it is never made public.  There is nothing for an
>  > attacker to get onto.
>  > As far as I understand things, unless someone figures out a way to
>  > break MD5 such that knowing one input to the function means that you
>  > know the entire output, the use of hashes for PRFs is not imperiled.
>
>  Sure, and HMAC-SHA1 is believed to be secure regardless of the
>  collision results against SHA1, and it is HMAC that's used in the PRF.
>
>  My comments were in part motivated by the desire to use a Diffie-
>  Hellman method that's provably secure.I believe that that collision
>  resistance of the IKE KDF hash is needed for such a proof.The
>  analysis of the key derivation used in IKE that I have in mind is in
>  Dodis, Gennaro, HÂstad, Krawczyk, and Rabin, "Randomness Extraction
>  and Key Derivation Using the CBC, Cascade and HMAC Modes", Advances
>  in Cryptology ñ CRYPTO 2004, online at http://theory.lcs.mit.edu/
>  ~yevgen/ps/hmac.ps.The IKE implications are mentioned in the 2nd to
>  last par. of Section 1.2, and the HMAC results are in the subsection
>  "The Extraction Properties of HMAC".I'll check with Hugo to verify
>  my interpretation here.
>
>  The point that I wanted to make is that "it is best to migrate
>  towards crypto methods that have less unproven assumptions", not
>  "there is a lurking flaw and we all need to implement something new
>  right away".I agree with your gist, that as far as we know, there
>  are no security problems with using IKE relying on an HMAC-SHA1 PRF.
>
>  >
>  > The reason that I say this is because getting the right inputs and
>  > outputs to the PRF is often very difficult. An error hereis usually
>  > made consistently, so an implementation will interoperate with itself,
>  > and it is often hard to get to details of the input/output of the PRF
>  > out of many implementations (in debug mode), so it is very hard to
>  > figure out what is occuring wrong.
>  >
>  > i.e. this is among the hardest piece to test.
>
>  Yes, and unfortunately KDFs in general seem to have been designed
>  without algorithm agility in mind.
>
>  David
>  >
>
>

_______________________________________________
saag mailing list
[email-masked]
http://jis.mit.edu/mailman/listinfo/saag

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Dec 2005 12:51:32 -0800

Greetings again. Thank you for all the response on the -00 draft. I 
have significantly revised it, and the -01 is available from 
<http://www.ietf.org/internet-drafts/draft-hoffman-ike-ipsec-hash-use-01.txt>.

In this draft, Section 5 is all new, and it would be grand if folks 
could read it carefully. In it, I try to glean the basics from Eric 
and Steve's paper and come to conclusions about what should be done. 
I may have missed important parts (for that matter, so might they), 
and others might have different conclusions from what I got.

Please let the lists know what you think.

--Paul Hoffman, Director
--VPN Consortium