Subject: Crypto algorithms for IKEv2

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 28 Apr 2003 11:11:58 -0700

Greetings again. At the WG meeting in San Francisco over a month ago, 
the WG agreed that the IKEv2 document should split out the 
cryptographic algorithms into a RFC that can be updated separately 
from the main IKEv2 protocol RFC with which we are almost finished.

I have turned in an Internet Draft on this topic that matches what I 
believe matches the general feeling from the WG based on earlier 
discussion on this mailing list and the lively face-to-face 
discussions in San Francisco. A temporary version of the draft is at 
<http://www.vpnc.org/ietf-ipsec/draft-hoffman-ipsec-algorithms-00-TEMP.txt>; 
as usual, that link will disappear when the draft is officially in 
the Internet Drafts directory.

This document is meant to be a companion to the *next* draft of 
IKEv2. In that draft, Charlie can cleanly excise from his section 
3.3.2 the cryptographic tables labeled "For Transform Type 1", "For 
Transform Type 2", "For Transform Type 3", and "For Transform Type 
4", leaving Transform Type 5, which is not cryptographic. He can also 
remove the MUST, SHOULD, and MAY statements in Appendix B.

The result will be a free-standing document that the IETF can update 
when we want to change the cryptographic requirements for IKEv2. For 
example, there was general agreement in San Francisco that we will 
probably be requiring AES and longer Diffie-Hellman primes in the 
not-distant future, and that fact is reflected in the Internet Draft.

Given that we are trying to finish up IKEv2 in the near future and 
not reopening agreed-to issues, I'm definitely interested to hear if 
anyone thinks that the document has things that the WG didn't agree 
to.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jimmy Zhang" <[email-masked]>
Date: Mon, 28 Apr 2003 17:09:03 -0700

How about TWOFISH ?

Thanks,

Jimmy

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul 
> Hoffman / VPNC
> Sent: Monday, April 28, 2003 11:12 AM
> To: [email-masked]
> Subject: Crypto algorithms for IKEv2
> 
> 

--Paul Hoffman, Director
--VPN Consortium

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 11:15:19 -0400

Editorial comments/questions: 

Where are the ENCR_DES_IV32 and ENCR_RC4 defined?
RFC2401bis? Or?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 11:27:39 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> This document is meant to be a companion to the *next* draft of 
    VPNC> IKEv2. In that draft, Charlie can cleanly excise from his section 
    VPNC> 3.3.2 the cryptographic tables labeled "For Transform Type 1", "For 
    VPNC> Transform Type 2", "For Transform Type 3", and "For Transform Type 
    VPNC> 4", leaving Transform Type 5, which is not cryptographic. He can also 
    VPNC> remove the MUST, SHOULD, and MAY statements in Appendix B.

  Paul, I think that this is a very good way to organize things.  
  I have one additional suggestion, which you may or may not like.

Split this document into two documents:
Document 1 title: Security Algorithms for IKEv2
	 sections 1, 1.3, 2.

Document 2 title: A VPN profile for IKEv2
	 section 3, plus all MANDATORY statements from other sections.

Rational for this:
a)	 This makes Document 1 really the initial IANA registry. 
	 Very simple for IANA to grok.
	 Very simple for implementors to reference as well.

b)	 Document 2 now becomes readable to end-users, to
	 system support people, and even to marketing.

c)	 Your document claims it is for VPN use, so make it so.

d)	 I do not believe that any statements about "MUST" can really
	 be made in isolation of the application area. We have long
	 endless debates about what is "best" because we have differing
	 goals, and therefore different risk/benefit tradeoffs.

e)	 "Note that the suites listed here are for use of IPsec in virtual
	 private networks. Other uses of IKEv2 and IPsec will probably want
	 to define their own suites and give them different names."

This is perfectly fine with me. By naming the document to reflect this, you
open up the floor to having other users define their own needs. 

In the end, a customer will specify a device that is RFC-Document2 compliant
for their VPN use, and things will work. 

It might be that after doing this that Document 1 isn't worth removing from
IKEv2. I don't care one way or another.

One final question is that it might be there there should still be a MUST for
some IKEv2 transforms. This might permit a mobile VoIP phone to be able to
get far enough in negotiation with a VPN-only box to determine that they
share no common phase 2 protocols. I don't know if this is useful.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 29 Apr 2003 09:35:25 -0700

To: IETF-Announce: ;
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-hoffman-ipsec-algorithms-00.txt
Date: Tue, 29 Apr 2003 07:39:59 -0400
Sender: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Security Algorithms for IKEv2
	Author(s)	: P. Hoffman
	Filename	: draft-hoffman-ipsec-algorithms-00.txt
	Pages		: 6
	Date		: 2003-4-28

The IKEv2 protocol [IKEv2] relies on security algorithms to provide
privacy and authentication between the initiator and responder. There
are many such algorithms available, and two IKEv2 systems cannot
interoperate unless they are using the same algorithms. This document
specifies an initial set of algorithms for registration with IANA, and
specifies which are mandatory to implement. This document also specifies
optional suites of algorithms and attributes that can be used to
simplify the administration of IKEv2.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-ipsec-algorithms-00.txt

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Tue, 29 Apr 2003 13:17:05 -0400

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:

 Michael> Editorial comments/questions:

 Michael> Where are the ENCR_DES_IV32 and ENCR_RC4 defined?
 Michael> RFC2401bis?

Nowhere, I believe.

ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream ciphers
because IPsec works with IP datagrams.  Stream ciphers like RC4
require loss-free delivery, which IP does not offer.  So ENCR_RC4 is
simply a mistake that was never corrected.

       paul

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 29 Apr 2003 09:43:47 -0700

>	 section 3, plus all MANDATORY statements from other sections.

This is an interesting idea, but it kind of goes against what people 
had said they wanted, which was to have the MUSTs and SHOULDs with 
the algorithm specifiers.

>	 to define their own suites and give them different names."

All of these sound fine to me, if that's where the WG wants to go. On 
the other hand:

a) IANA can grok whatever we give them. Also, we don't want 
implementers referencing the RFC: we want them referencing the IANA 
registry. This is one of the big problems we have had with IKEv1.

b) We don't expect end users to read RFCs. If we want them to do 
that, someone (like VPNC) can create a "RFC xwyz in plain English" 
document.

>for their VPN use, and things will work.

But they don't need to be able to read that RFC	in order to specify it. :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked] (David Wagner)
Date: 29 Apr 2003 16:57:31 GMT

>How about TWOFISH ?

No, please.  Stick to AES and Triple-DES; they are very fine algorithms.

My strong advice is to use AES, not Twofish.  There's nothing wrong with
Twofish -- I'm pleased with the design and how it has held up -- but I
think AES is clearly the right choice over Twofish.  AES was selected
for the standard over all other competitors, and I think, rightly so.
Most importantly, AES is receiving far more scrutiny than Twofish.
This gives a powerful reason to prefer AES over Twofish (or any of the
other finalists, including Serpent, for that matter).

I prefer to view Twofish as deprecated these days and to encourage people
to use AES instead, unless there is some special requirement that makes
AES unsuitable.

Full disclosure: I was a co-designer of Twofish, so I'm probably biased.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 16:12:00 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    >> section 3, plus all MANDATORY statements from other sections.

    VPNC> This is an interesting idea, but it kind of goes against what people 
    VPNC> had said they wanted, which was to have the MUSTs and SHOULDs with 
    VPNC> the algorithm specifiers.

  Ah. I see.

    VPNC> a) IANA can grok whatever we give them. Also, we don't want 
    VPNC> implementers referencing the RFC: we want them referencing the IANA 
    VPNC> registry. This is one of the big problems we have had with IKEv1.

  Good point.

    >> for their VPN use, and things will work.

    VPNC> But they don't need to be able to read that RFC	in order to specify it. :-)

  Well, the UI Suites section is pretty much readable to end-users. The
purchasing people will spec it, but the admins will read the RFC when they
get a product which can interop, but doesn't present UI suites in the UI.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Apr 2003 16:13:21 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Paul" == Paul Koning <[email-masked]> writes:

    Paul> Nowhere, I believe.

    Paul> ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream ciphers
    Paul> because IPsec works with IP datagrams.  Stream ciphers like RC4
    Paul> require loss-free delivery, which IP does not offer.  So ENCR_RC4 is
    Paul> simply a mistake that was never corrected.

  I thought that we had a way to synchronous a stream cipher with an offset
that essentially replaces the IV. This is computationally expensive if you do
it wrong, but is currently done. I don't know - I never wrote RC4.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Apr 2003 14:23:27 -0400

>simply a mistake that was never corrected.

I agree with the conclusion, but not the rationale.  One could use a 
stream cipher with IPsec, so long as one carries the state info 
needed for the cipher with each packet, just like we carry an IV.

Steve

---

From: Paul Koning <[email-masked]>
Date: Wed, 30 Apr 2003 16:54:15 -0400

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

 Michael> Editorial comments/questions:
 >> Nowhere, I believe.
 >> 
 >> ENCR_RC4 is clearly nonsense -- IPsec cannot work with stream
 >> ciphers because IPsec works with IP datagrams.  Stream ciphers
 >> like RC4 require loss-free delivery, which IP does not offer.  So
 >> ENCR_RC4 is simply a mistake that was never corrected.
 >> 
 >> paul

 Stephen> I agree with the conclusion, but not the rationale.  One
 Stephen> could use a stream cipher with IPsec, so long as one carries
 Stephen> the state info needed for the cipher with each packet, just
 Stephen> like we carry an IV.

I suppose that is true, though handling out of order packets would be
extremely painful.

In any case, there is no "how to use RC4 with IPsec" RFC, and I
suggest that no one should contemplate writing one.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Apr 2003 17:44:25 -0400

>suggest that no one should contemplate writing one.
we are in agreement on that point.