Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-hoffman-ikev1-algorithms-00.txt

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 4 Oct 2004 08:54:16 -0700

It would be great if the reason no one has commented on this is 
because it is perfect, but that seems unlikely. On the other hand, if 
this is so uncontroversial (after all, it instantiates what we've 
been talking about for nearly six years), I'm happy to just take it 
to the ADs as-is.

The document can be found at 
<http://www.ietf.org/internet-drafts/draft-hoffman-ikev1-algorithms-00.txt>. 
The meat of the document is:

---------------

2.  Old algorithm requirements

     RFC 2409 has the following MUST-level and SHOULD-level requirements:

     o  DES for encryption MUST be supported
     o  MD5 and SHA-1 for hashing MUST be supported
     o  Diffie-Hellman MODP group 1 (discrete log 768 bits) MUST be
        supported
     o  TripleDES for encryption SHOULD be supported
     o  Tiger for hashing SHOULD be supported
     o  DSA and RSA for authentication with signatures SHOULD be supported
     o  RSA for authentication with encryption SHOULD be supported
     o  Diffie-Hellman MODP group 2 (discrete log 1024 bits) SHOULD be
        supported

     RFC 2409 gives two conflicting requirement levels for Diffie-Hellman
     MODP groups with elliptic curves.  Section 4 of that specification
     says "IKE implementations ...  MAY support ECP and EC2N groups", but
     Sections 6.3 and 6.4 say that MODP groups 3 and 4 for EC2N groups
     SHOULD be supported.

3.  New algorithm requirements

     The new requirements for IKEv1 are:

     o  TripleDES for encryption MUST be supported
     o  SHA-1 for hashing MUST be supported
     o  Diffie-Hellman MODP group 2 (discrete log 1024 bits) MUST be
        supported
     o  RSA for authentication with signatures SHOULD be supported

     The other algorithms that were listed at MUST-level and SHOULD-level
     in RFC 2409 are now MAY-level.  This includes DES for encryption, MD5
     and Tiger for hashing, Diffie-Hellman MODP group 1, Diffie-Hellman
     MODP groups with elliptic curves, DSA for authentication with
     signatures, and RSA for authentication with encryption.  Some of
     these are dropped to MAY due to cryptographic weakness, while others
     are dropped due to lack of any significant deployment and
     interoperability.

     Note that additional algorithms have been developed since the time of
     RFC 2409 that many people consider SHOULD-level or MUST-level.  Most
     notable among these are discrete log MODP groups with longer key
     lengths, AES-128 for encryption, and SHA-256 for hashing.  They are
     not included in this document because doing so would cause this
     document to be an extension to RFC 2409 instead of an update of RFC
     2409.

---------------

Comments are welcome.

--Paul Hoffman, Director
--VPN Consortium

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Oct 2004 11:50:05 +0300

Paul Hoffman / VPNC writes:
> Greetings again. We have talked for over five years about getting rid 
> of 56-bit DES in IKEv1. So, I have (belatedly) written a draft on 
> doing this at the same time as updating the other algorithm MUSTs and 
> SHOULDs. This is a personal draft, not a WG item, but it can be 
> discussed on this list before I turn it into the IESG as a personal 
> submission.
> 
> Comments are appreciated.

The document seems fine. Perhaps add reference to the NIST
announcement of documenting the removal of DES or so might be good
idea. Also adding "authentication via pre-shareed keys" to both
sections 2 and 3 would be good, so all the requirements are there. Now
that is the only one that is left out, as it is not changing. 

I would actually like to make AES a next MUST cipher, and I do not see
problem that we refer new documents here. We are still updating
RFC2409 aren't we?

Anyways, this will update the ciphers used in the IKEv1 SA, but it
does not change the ciphers used in the IPsec SAs. If you want to do
that too, you need to update the RFC2407 too.

RFC2407 current lists mandatory algorithms as AH with MD5, AH with
SHA1, ESP with DES and HMAC-MD5, ESP with NULL cipher.

The RFC2406 also lists mandatory algorithms for ESP, i.e it lists: DES
in CBC mode, HMAC with MD5, HMAC with SHA-1, NULL authentication
algorithm and NULL encryption algorithm.

And the RFC2402 lists mandatory algorithms for AH, i.e. it lists; HMAC
with MD5 and SHA-1.
-- 
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 5 Oct 2004 11:14:57 -0700

At 11:50 AM +0300 10/5/04, Tero Kivinen wrote:
>The document seems fine.

Thanks!

>  Perhaps add reference to the NIST
>idea.

I'm not so hot on this, because we should also then talk about why 
MD5 is now not as fine as it was a few months ago, and why MODP Group 
1 is not as fine, and so on. If we start doing that, what do I say 
about moving Tiger to "MAY"? Was that because no one implemented it, 
or because no one implemented it because no one was confident in its 
crypto properties? Then there's the question about elliptic curves.

I'd kinda rather leave the crypto reasoning vague unless others here 
really think it is needed for the document.

>  Also adding "authentication via pre-shareed keys" to both

Good point, thanks.

>problem that we refer new documents here. We are still updating

No, that's extending RFC 2409. AES was not listed (for obvious 
historical reasons), so this would be a clear extension.

We *can* extend RFC 2409, of course, but that would mean something 
very different for the process, I think. If we extend it, we probably 
would need to wind in all the extensions that we have created over 
the past six years. Yuck.

>algorithm and NULL encryption algorithm.

Of course. I wanted to be sure we were on the right track with this 
one. Doing the same thing for 2406 and 2407 is trivial if we agree on 
what we are doing here.

>And the RFC2402 lists mandatory algorithms for AH, i.e. it lists; HMAC

But there is no problem with its requirements, is there?

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Oct 2004 11:22:31 +0300

> crypto properties? Then there's the question about elliptic curves.

You can use pointers for those others also. 

> really think it is needed for the document.

Yes, but you can provide pointers for those discussions. I.e. for
cipher change point to the NIST, for MODP groups point to the BCP86 /
RFC3766 and perhaps also to the RFC2409, which said that group 1 was
only for single DES. For Tiger and Elliptic curves, it is quite easy
to say that they haven't been used or even tested really, so no point
of those being SHOULD. 

> the past six years. Yuck.

I do not think we need to take any other changes than what is
required, and we can refer those extensions (AES) by just refering the
rfc defining them.

I still think that it would be "Update" to the RFC2409 if we simply
say that AES (RFC3602) is now MUST to implement cipher. 

> one. Doing the same thing for 2406 and 2407 is trivial if we agree on 

Good. I just wanted to point it out for other people, as most of the
people do not really care what we us in the IKE, everybody is much
more interested in the IPsec algorithms.

> But there is no problem with its requirements, is there?

Probably not. 
-- 
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 8 Oct 2004 09:47:22 -0700

>say that AES (RFC3602) is now MUST to implement cipher.

I'm fine with this as long as this document is only updating the 
crypto stuff, not rolling in everything else we have done to IKEv1 in 
the past six years. Does anyone have any objections to that?

--Paul Hoffman, Director
--VPN Consortium