Subject: Final editing changes to IKEv2

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 16 Mar 2004 12:54:27 -0500

The following represent the final changes that we believe the IPSEC
working group has developed a consensus to make to IKEv2.  If anyone
has any problems to these set of changes, please make them known within
48 hours.  Otherwise, they will represent editing instructions to the
IKEv2 document editor before we submit this document to the Area
Director for IETF Last Call.

1. Make the changes to IKEv2 cryptographic change which were proposed by
   Hugo, and which were signed off by CFRG:

   https://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00366.html

2. Add an additional round trip when utilizing  EAP to avoid the
   ambiguity of what "after having sufficient information to compute the
   key" might mean.  This is commonly done in most other applications
   that utilize EAP.

    http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html

3.  Add a notify message which specifies whether or not TFC padding is 
	done in ESPv2.   

    http://www.vpnc.org/ietf-ipsec/mail-archive/msg02695.html

	A suggestion has has been made for efficiency's sake that sense
	of the proposal made in the above URL be reversed, since the
	expectation is that normally the RFC padding will be supported:
                                                                               
     ESP_TFC_PADDING_NOT_SUPPORTED                   16394
                                                                               
            This notification asserts that the sending endpoint will NOT
            accept packets that contain Flow Confidetiality (TFC)
            padding.

4.  Clarification about encoding the icmp type/code (bit-packing issue) from
    Charlie Lynn

        http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html
                                                                               
5. Make the reference to UDP encaps I-D be normative, and change
   reference to the NAT Requirements I-D be informative.

   http://www.vpnc.org/ietf-ipsec/mail-archive/msg02607.html

6.  Incorporate the list and description of the IANA registries found in
    draft-ietf-ipsec-ikev2-iana-01.txt into IANA Considerations section
    of the IKEv2 I-D.  In adddition, include as the allocation rules for
    all of the IKEv2 registries the policy "Expert Review" required, as
    defined in RFC2434.  The actual initial contents of the registries
    themselves will *not* be included in IANA considerations section.
    Those will be provided to the IANA via the draft-ietf-ipsec-ikev2-iana I-D.
                 
7.  Update copyright statement and IPR statements per new texts found in RFC
    3667-3669

					Ted and Barbara

---

From: Yoav Nir <[email-masked]>
Date: Wed, 17 Mar 2004 15:32:26 +0200

This is one message that proposed two options, and did not receive any 
responses.  Is this a consensus?

Anyway, EAP is originally a PPP protocol.  The last message 
(success/failure) is not meant to be reliable.  If it is lost, its 
existence can be inferred in PPP by what happens next (IPCP in case of 
success, or LCP terminate in case of failure).  There is never any 
response to the EAP success message, so there is no need for the IKE 
machine to send it to the client as soon as it is received.

If the EAP machine first sends the Authentication success, and 
afterwards sends the key (or the reverse), the IKE machine should 
buffer whichever comes first until the other arrives, and then send 
both the EAP success and the auth payload in one message just as it is 
specified in -12.

It should be possible to resolve the ambiguity by saying that the 
client sends the AUTH payload as soon as it can, while the server sends 
it in the last packet along with the Success/Failure message.  I don't 
see a reason to add an extra roundtrip.