Moving forward with IKE V2: A proposal for final edits to ikev2-04

["Theodore Ts'o" <[e-mail]>]

Charlie Kaufman, the document editor for IKE v2, has been travelling and
out of e-mail contact this past week.  I'm told that he will be back and
(hopefully) responding to e-mail this weekend, but that he will be away
on more travel next week, and will be fully back on-line on February
seven.  This brings us relative uncomfortably close to our deadline of
trying to complete the IKEv2 proposal by February 15th.

The good news is that we believe that we are very close, and that one
last, good, hard push is what's necessary to get us to get over the
finish line.  For example, this past week, it looks like we were had
almost achieved consensus on the matter of the question of Secure Legacy
Authentication, with Derrell Piper (one of the co-authors of
draft-hoffman-sla-00.txt), Charlie Kaufman, Uri Blumenthal, and Steve
Kent all expressing comfort to his proposal, which represents a very
large percentage of the people who have been discussing this issue on
the IPSEC mailing list.  Never have we been so close to consensus on
this issue, which is great!

So in order to come to consensus, we would like to present the following
straw-man proposal, as a miniature "last call" for the working group.  In
Atlanta, we received very clear input from the working group that
support for Legacy Authentication is very, very important for IKE v2.
As we have seen with IKE v1, there are many ways of accomplishing this,
and not all people will agree on what might be the "best" method.  Even
if we continuing arguing for the next two years (and I don't think the
IESG will give us that long), it is extremely doubtful that we will ever
come to unanimity on this quesiton.

For this reason, what we propose is that we pick an approach, and be
done with it.  The question then before the working group is whether or
not there is another way to accomplish the task, but whether there are
either (a) fatal flaws in the proposal presented, (b) clear,
overwhelming advantages to do things a different way (and no handwaving;
it must be a complete proposal), or (c) minor enhancements that all can
agree are worthwhile to include in the protocol and worthwhile to
implement.  Otherwise we will be arguing until the cows come home
(and/or when the IESG shuts us down, or the mob from problem-statement
mailing list show up with the pitchforks, tar, and feathers :-).

So without further ado, please consider and comment the following
proposal as final editing directions to ikev2-04.txt:

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

1)  Use as the basis of secure legacy authentication the proposal made
    by Derrell Pipper on January 23rd, 2003:

       HDR, SAi1, KEi, Ni           -->
                                    <--    HDR, SAr1, KEr, Nr
       HDR*, IDi, [CERTREQ], [IDr,]
            SAi2, TSi, TSr          -->
                                    <--    HDR*, IDr, [CERT,] AUTH, EAP(n)
       HDR*, [AUTH,] EAP(n)         -->
                                    <--    HDR*, EAP(status) [, SAr2, TSi, TSr ]

For those EAP mechanisms which generate a shared key, the AUTH payload
MUST be sent from the client to the server when it has sufficient
information to generate it.  (as proposed by Charlie)

If there exists EAP mechanisms where the a new session key may
negotiated during the course of the EAP exchange, the client MUST send
another AUTH payload if/when a new session key is generated.   (as
proposed by Darrell --- this probably isn't a problem in practice)

Hugo has suggested that for EAP mechanisms that generate a shared key,
the responder should send an AUTH message based on the shared key in the
message containing the EAP(success) message, as backup in case for some
reason the CERT based exchange might have gotten spoofed somehow.  This
seems to me to be a case of gilding the lilly, and is probably not be
worth the extra complexity, but I encourage comment on the working group
about whether or not this additional twist should be included.

Hugo has a few other concerns about this proposal; none of them seem
fatal, but I encourage working group members to look over his message of
January 25th, and to please speak up ASAP if you believe these concerns
need to be addressed --- and if so, how.  

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

3) Change in signature processing.  In a discussion between Hugo and
    Charlie, on January 22-24th there was agreement to change section
    4.15 to make IKEv2 more robust to future changes to the protocol:

   4.15 Authentication of the IKE-SA

   The peers are authenticated by having each sign (or MAC using a
   shared secret as the key) a block of data. For the responder, the
   octets to be signed start with the first octet of the first SPI in
   the header of the second message and end with the last octet of the 
   last payload in the second message.  Appended to this (for purposes
   of computing the signature) [are] the initiator's nonce Ni (just the
   value, not the payload containing it), [and a value MIDr computed as
   prf(SK_ar,IDr). Note that neither the nonce Ni or value MIDi are
   transmitted.]  Similarly, the initiator
   signs the first message, starting with the first octet of the first
   SPI in the header and ending with the last octet of the last payload.
   Appended to this (for purposes of computing the signature) [are] the
   responder's nonce Nr, [and a value MIDi computed as prf(SK_ai,IDi)].

... where IDi and IDr are the entire Idx payload.

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

3) For the Cipher Suite issue, that we use Paul Hoffman's proposed set
   of Cipher suites.  There is less consensus on this issue on the
   mailing list, but most people don't seem to have strong feelings,
   so we believe we just pick something:

Suite-ID  Meaning
--------  -------
0         Covers: IKE				(MUST)
          168-bit 3DES CBC encryption
          Diffie-Hellman group 2 (1024-bit)
          HMAC-SHA1 integrity and prf

1         Covers: ESP				(MUST)
          3DES encryption with three keys
          HMAC-SHA1 integrity

2         Covers: AH				(SHOULD)
          HMAC-SHA1 integrity

3         Covers: IKE				(MUST)
          168-bit 3DES CBC encryption
          Diffie-Hellman group 5 (1536-bit)
          HMAC-SHA1 integrity and prf

4         Covers: IKE				(MUST)
          AES encryption in CBC mode with 128-bit keys
          Diffie-Hellman group 5 (1536-bit)
          HMAC-SHA1 integrity and prf

5         Covers: IKE				(MUST)
          AES encryption in CBC mode with 128-bit keys
          Diffie-Hellman group 14 (2048-bit)
          HMAC-SHA1 integrity and prf

6         Covers: ESP				(MUST)
          AES encryption in CBC mode with 128-bit keys
          HMAC-SHA1 integrity

7         Covers: IKE				(SHOULD)
          AES encryption in CTR mode with 128-bit keys
          Diffie-Hellman group 14 (2048-bit)
          AES-CBC MAC + XCBC integrity and prf

8         Covers: ESP				(SHOULD)
          AES encryption in CTR mode with 128-bit keys
          AES-CBC MAC + XCBC integrity

I have adjusted the MUST/SHOULD from Paul's message since I believe that
for implementations that will be moving to implement IKEv2, it is
reasonable to require the implementation of AES, as it as so many
advantages over 3DES.  If it weren't for the existing chips that only
support AES-CBC, I'd argue for making AES-CTR mandatory instead, but
given where we are, this set of MUST/SHOULD seems to me to be the most
reasonable set of ciphers.

Question: Should AES Counter mode be made mandatory to ensure
compatibility in the future?  Existing chips only support AES-CBC, so
this might make things harder for people as they transition to IKEV2.  On
the other hand, by the time we see start seeing IKEv2 products, it might
be reasonable to require the presence of AES-CTR support.

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

(SEMI-)CLOSED ISSUES
=====================

The following issues have been burbling on the list, although in the
opinion of the IPSEC Working group chairs, there isn't consensus in the
IPSEC working group to act on them.

If you feel otherwise, please speak now.

A)  Revised identity 
--------------------

Paul Hoffman has a proposal, draft-ietf-ipsec-revised-identity-00.txt,
which radically changes how identities are handled.   Specifically, it
would eliminate the ID payload with the following types:

      ID_IPV4_ADDR                        1
      ID_FQDN                             2
      ID_RFC822_ADDR                      3
      ID_IPV6_ADDR                        5
      ID_DER_ASN1_DN                      9
      ID_DER_ASN1_GN                      10
      ID_KEY_ID                           11

et.al, and replaces it with a FullID payload with the following types:

	1  PKIX certificate
	2  Certificate bundle
	3  Hash-and-URL of PKIX certificate
	4  URL to a PKIX certificate bundle
	5  PKIX keyIdentifier
	6  IDForSharedSecret

This would be fundamental change in the management and administraton of
IPSEC and IKE, so is not something to adopt lightly, and without a clear
consensus of the working group.  This was discussed in two threads on
the IPSEC mailing list: one starting on November 5th (subject Adding
revised identities to IKEv2), and one starting on December 8th (subject:
Summary of revised identity changes).  People who spoke in favor on the
mailing list included Francis Dupont and Bill Sommerfeld, with qualified
support from Michael Richardson (if support for bare keys is added) and
Tero Kivinen (who is concerned about the complexity of the proposal).

This proposal was discussed in Atlanta, but Charlie, Barbara, and Ted
were left with the impression that there was not consensus among those
who met to discuss legacy authentication after the IPSEC wg meeting to
pursue adoption of Paul's proposed change.  Paul believes otherwise.
Since it is the job of working group chairs to determine consensus, we
(Barbara and Ted) hereby ask that those who believe we should pursue the
revised identity proposal to please speak up.

It should be noted that there are some intermediate positions beyond
what is currently in draft-ietf-ipsec-ikev2-04.txt and the
revised-identies draft.  For example, we could add the Hash-and-URL type
to the Certificate payload, if the goal is shrink the size of IKE
messages (with the tradeoff of increasing complexity in IKE
implementations).   We could also add a CERT hash type to the ID
payload, without nuking the traditional FQDN or IPv4/6 addresses
identity mechanisms (although again, by adding new types, we would be
increasing the complexity of the specification and implementations).

Due the relatively small number of people who have spoken in favor of
this proposal or its less-radical alternates, the default choice for
IKEv2 has to be what is currently in ikev2-04.  So those who believe we
should make this change (or those who strongly believe we should not)
are requested to speak up now, or forever hold your peace....


B) DHCP-based vs. MODECFG style remote access configuration
-----------------------------------------------------------

Currently, draft-ietf-ipsec-ikev2-04.txt handles remote access via a
Configuration payload with defined attributes.  An alternate mechanism
involves using tunneled DHCP requests.  The latter approach is about to
be published as an RFC by the IPSRA working group.  Proponents of this
method argue that it is more powerful than modecfg (because of the
extensibility and large number of options already specified for DHCP;
for example, being able to specify DNS, time, print, or WINS servers,
and so on.)  It is also argued that it requires less code on the
server/firewall, since an existing DHCP server can be used.

Proponents of the modecfg approach argue that many implementation
already have support for modecfg, and that setting up sort-lived
specialized tunnels to allow the DHCP packets to flow through the
gateway is kludgy, and requires multiple special case entries into
packet forwarding tables.  Modecfg proponents also argue that it is also
possible to transform modecfg requests into DHCP requests, so there are
implementation choices that do not require reimplementation of the
DHCP's address assignment function.  They also point out that it
certainly is possible --- and in some ways easier --- to obtain the
time, print, WINS server information by using DHCP (via the DHCPINFORM
request) after the IPSEC tunnel is setup and the client address is
assigned.

Either approach seems to be workable.  It is certainly true that most of
the people in Atlanta were implementors who were already familiar with
modecfg, representing a large implementation community.  That being
said, there is also some number of working group members that are in
favor of an approach similar to draft-ietf-ipsec-dhcp-13, including Van
Aken Dirk, Michael Richardson, and Scott G. Kelley.   One way or
another, however we need to make a choice and move forward.

Given that we have a fully specified solution in the ikev2-04 draft, and
it would seem that while there is a sizeable minority in favor of the
ipsec-dhcp-13 approach, the majority are comfortable with the modecfg
based approach.  So at this point, we, as working group chairs, judge
that the consensus is with the current approach.

If there are those who feel otherwise, or who see fatal problems with
the current approach, please speak now.

					Ted and Barabara
					IPSEC wg chairs