Subject: IKEV2: Issue #2: Cipher suites

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 07 Feb 2003 22:35:27 -0500

There seems general consensus over the cipher suites proposed by Paul
Hoffman.  However, not fully closed is the question of which ciphers
ought to be mandatory, and which merely optional.

The working group chairs note that this answer to these issue is very
largely dependent on the application for which IPSEC is used, and a
belief for when IKEv2 is likely to be available in the marketplace.
People who believe that IKEv2 will be deployed rapidly, and perhaps
requiring only software upgrades to existing hardware, have expressed
the desire to avoid requiring AES CBC or AES counter mode, because
many existing hardware accelerators do not support AES or counter
mode.  On the other hand, if IKEv2 does not reach maturity quickly,
the lack of a required AES cipher may very well look very silly.

It is also the case that IPSEC as applied to for VPN's will have very
radically different cipher requirements than those already expressed
for use by iSCSI.

For this reason, one potential solution (originally suggested by
Steve Bellovin to the working group chairs) towards achieving closure
on this issue would be to separate out into a separate document --- or
more likely, documents --- the specifications of which ciphers are
mandatory and which are merely optional.  Since which ciphers ought to
be mandatory will likely change more frequently than the base document
itself, combined with the need for different profiles for different
applications, we propose that the IKEv2 document remain silent about
which ciphers are required, and that separate documents, for VPN and
iSCSI applications, be drafted that contain these requirements.  

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs

---

From: Russ Housley <[email-masked]>
Date: Sun, 09 Feb 2003 11:58:30 -0500

Ted:

The S/MIME WG has separated algorithm requirements from the base protocol 
too.  This was done so that the algorithms could be updated without 
"opening up" the base protocol document.  This is more important when the 
base protocol becomes a Draft Standard or a Full Standard.

I belive that the algorithms proposed by Paul are the right ones for 
today.  One think I really like about the rationale is that it warns 
marketing folks and product planners which algorithms are likely to become 
mandatory to implement in a future update.

Russ

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 Feb 2003 11:13:50 -0800

Splitting out the list of ciphersuites and the list of which ones are 
MUSTs and SHOULDs would also bring us into line more with the IETF. 
The lists of MUSTs that the WG chairs have proposed do not follow the 
rules of RFC 2119, which is a normative reference in IKEv2. All the 
other MUSTs and SHOULDs in IKEv2 do follow the rules in RFC 2119, but 
these do not. It would be nice to have the main IKEv2 document 
actually conform to the IETF rules.

Another reason to split out the algorithms is that this WG has done a 
lousy job of keeping its list for IKEv1 up-to-date. DES (not 
TripleDES) is still a MUST. TIGER is still a SHOULD. If we can't even 
fix obvious problems like that in a timely fashion for IKEv1, we 
should not expect to do so for IKEv2.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: 13 Feb 2003 01:58:50 +0200

> ought to be mandatory, and which merely optional.

There was also proposal to split the suites to IKE and IPsec suites,
i.e put all IKE suites to have numbers 0-8191 and IPsec suites from
8192-16383 or similar.

Making that split will make the table easier to implement and
read.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Tero Kivinen <[email-masked]>
Date: 13 Feb 2003 03:22:56 +0200

> i.e put all IKE suites to have numbers 0-8191 and IPsec suites from

To reply my own comment, I think it would be even better to split
those tables completely. The crypto suite numbers should be allocated
in two different pools, one for the phase 1 and one for the phase 2.

This would remove prolems and errors where someone includes suite for
ESP in the phase 1 or IKE suite for child_sa. The parsing of SA
payload can be identical but the meaning of the values in the payloads
should depend on if it is phase 1 or 2 SA negotiation payload.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: [email-masked]
Date: Fri, 14 Feb 2003 21:05:12 -0500

> should depend on if it is phase 1 or 2 SA negotiation payload.

While negotiating ESP in phase 1 would be illegal, IKE can be negotiated an
a child_sa exchange,
and is used to roll over keys. So the SA payload needs an indicator
somewhere of whether
the proposed SA type is IKE or not. (If not implicitly in the suite ID,
then in a separate field).

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).