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

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 30 Jan 2003 17:57:09 -0500

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 31 Jan 2003 10:17:25 -0800

Wearing his WG chair hat, Ted said about the revised identity proposal:

>consensus of the working group.

It is inappropriate for the WG chairs to, with less than two weeks 
before the document is supposed to be finished, to make such 
pronouncements about WG procedure. Many people assumed that because 
the proposal had as much support as other proposals, it would go into 
the current draft.

It is also inappropriate for the WG chairs to recast a proposal as 
something that it is not. The revised identity proposal doesn't 
change anything major about the management of administration of 
either IPsec or IKE. It clarifies the use of identity in PKIX 
certificates, and makes it more likely that IKEv2 will work in 
environments where IKEv1 does not, namely where fragmented UDP 
payloads get dropped.

>   This was discussed in two threads on

And, if I remember correctly, no one spoke against it. This is 
typical of this WG. Almost every other change to IKEv2 has been made 
with about the same amount of support. It is inappropriate for the WG 
chairs to now say "that much support is enough for some proposals, 
but not for this one".

>pursue adoption of Paul's proposed change.  Paul believes otherwise.

This is irrelevant. The revised identity proposal was barely 
discussed in that meeting *because it is unrelated to legacy 
authentication and remote configuration*. The revised identity 
proposal is almost exclusively about normal authentication with 
certificates.

The statement "Paul believes otherwise" is also completely untrue. 
Ted never asked me about it; if he had, I would have said "we didn't 
really discuss it much because it was irrelevant".

>revised identity proposal to please speak up.

The WG chairs need to explain to the WG how they will judge consensus 
on this. Without that, we cannot determine whether or not we should 
bother to have a discussion.

>increasing the complexity of the specification and implementations).

This paragraph means that the many years of on-and-off discussion 
about the lack of clarity of IKEv1 with respect to what does an ID 
payload mean when using certificates is now ignored. The fact that 
there is vastly less interoperability for certificate authentication 
than for preshared secret authentication (or even XAUTH 
authentication!) is now irrelevant.

According to the WG chairs, IKEv2 should use the same under-specified 
and non-specified rules for certificate processing as IKEv1.

Is this what the working group wants?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 31 Jan 2003 10:15:55 -0800

Wearing his WG chair hat, Ted said:

>advantages over 3DES.

The current proposal contains not only a list of MUSTs and SHOULDs, 
it has language that is supposed to go into the document about them. 
The counter-proposal doesn't change the support language. The 
counter-proposal offers no security or interoperability rationale. 
For example, the counter-proposal mandates both 3DES and AES. How 
does that help interoperability or security?

Ted's proposal (which is certainly not based on any consensus from 
the mailing list) essentially prevents any currently-deployed IPsec 
system that has 3DES-acceleration from running IKEv2 sensibly. The 
vendor would have to offer AES in software next to 3DES in hardware, 
and hopefully explain to the user what the difference is.

Is this what the WG wants? Or would the WG prefer a set of MUSTs and 
SHOULDs that allow vendors to update currently-deployed systems with 
IKEv2?

--Paul Hoffman, Director
--VPN Consortium

---

From: Cheryl Madson <[email-masked]>
Date: Fri, 31 Jan 2003 13:52:04 -0800

At 10:17 AM 1/31/2003, Paul Hoffman / VPNC wrote:

>This paragraph means that the many years of on-and-off discussion about 
>the lack of clarity of IKEv1 with respect to what does an ID payload mean 
>when using certificates is now ignored. The fact that there is vastly less 
>interoperability for certificate authentication than for preshared secret 
>authentication (or even XAUTH authentication!) is now irrelevant.
>
>According to the WG chairs, IKEv2 should use the same under-specified and 
>non-specified rules for certificate processing as IKEv1.
>

I've gone through *numerous* bakeoffs where vendors have implemented
different behaviors for various things related to certs. We've had several
meetings during bakeoffs to discuss this particular issue. Even if the
vendors are able to come to some sort of consensus during the bakeoff,
the WG has been extremely apathetic about any attempts to clarify things.

I argued that one of the requirements should be that any authentication
mechanism be fully specified in the context of SOI, or not be a candidate
mechanism. A series of random specs that someone has to figure out
how to piece together isn't an answer. [I also argued that the protocol
specification be flexible enough to allow future mechanisms.]

And I for one would sure hate to see certs excluded as a mechanism;
I do think it is an extremely useful mechanism.

But I'm also really tired of having to revisit the same issues years later
because we can't take the time to figure out in some detail what needs
to happen and to adequately specify things.

thx - C

====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Jan 2003 18:31:45 -0500

Ted,

I have to agree with Paul's observation that he provided a 
well-reasoned rationale for each choice for MUST vs. SHOULD for the 
cipher suites and these did receive some scrutiny & discussion prior 
to his posting to the overall list. Thus any suggested changes to his 
list really ought to be accompanied by a similar level of rationale. 
Overall, I am comfortable with Paul's list of MUSTs and SHOULDs. I 
could be persuaded to add some more MUSTs with regard to things like 
AES-CTR for ESP, but I think it is incumbent on you to provide more 
rationale rather than "just pick[ing] something."

I also would like to proposed some different text that addresses 
Paul's comments re support of private suites, specifically for IKE:

It is likely that IANA will add additional Suite-IDs in the future, and
some users may want to use private suites, especially for IKE where 
implementations should be capable of supporting different parameters, 
up to certain size limits. In support of this goal, all 
implementations of IKEv2 SHOULD [I'd prefer MUST, but Paul has argued 
eloquently for very restrictive criteria for MUST re suites.] include 
a management facility that allows specification (by a user or system 
administrator) of Diffie-Hellman parameters (the generator, modulus, 
and exponent lengths and values) for new IKE Suites. Implementations 
SHOULD provide a management interface via which these parameters and 
the associated Suite-IDs may be entered (by a user or system 
administrator), to enable negotiating such Suites.

All implementations of IKE v2 MUST include a management facility that 
enables a user or system administratror to specify the Suite IDs that 
are acceptable for use with IKE. Upon receipt of a payload with a 
suite ID, the implementation must compare the transmitted suite ID 
against those locally configured via the management controls, to 
verify that the proposed suite is acceptable based on local policy. 
The implementation MUST reject key exchange payloads that are not 
authorized by these IKE suite controls.

Also, I would suggest a slight edit to the Appendix B.1 text that 
Paul provided:

Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Future
IANA-registered and private use Suite-IDs MAY use Diffie-Hellman groups
that have modulus values and generators that are different than those in
this document or in [ADDGROUP].

I have not reviewed the Identity payload discussion sufficiently to 
comment on that part of the discussion at this time. I'll comment on 
that next week.

Steve