[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4718

Network Working Group                                          P. Eronen
Internet-Draft                                                     Nokia
Expires: April 27, 2006                                       P. Hoffman
                                                          VPN Consortium
                                                        October 24, 2005


           IKEv2 Clarifications and Implementation Guidelines
             draft-eronen-ipsec-ikev2-clarifications-06.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document clarifies many areas of the IKEv2 specification.  It
   does not to introduce any changes to the protocol, but rather
   provides descriptions that are less prone to ambiguous
   interpretations.  The purpose of this document is to encourage the
   development of interoperable implementations.





Eronen & Hoffman         Expires April 27, 2006                 [Page 1]

Internet-Draft            IKEv2 Clarifications              October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Creating the IKE_SA  . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  SPI values in IKE_SA_INIT exchange . . . . . . . . . . . .  4
     2.2.  Message IDs for IKE_SA_INIT messages . . . . . . . . . . .  5
     2.3.  Retransmissions of IKE_SA_INIT requests  . . . . . . . . .  5
     2.4.  Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . . . .  6
     2.5.  Invalid cookies  . . . . . . . . . . . . . . . . . . . . .  8
   3.  Authentication . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Data included in AUTH payload calculation  . . . . . . . .  8
     3.2.  Hash function for RSA signatures . . . . . . . . . . . . .  9
     3.3.  Encoding method for RSA signatures . . . . . . . . . . . . 10
     3.4.  Identification type for EAP  . . . . . . . . . . . . . . . 10
     3.5.  Identity for policy lookups when using EAP . . . . . . . . 11
     3.6.  EAP authentication and the AUTH payload  . . . . . . . . . 11
     3.7.  Certificate encoding types . . . . . . . . . . . . . . . . 11
     3.8.  Shared key authentication and fixed PRF key size . . . . . 12
     3.9.  EAP authentication and fixed PRF key size  . . . . . . . . 13
     3.10. Matching ID payloads to certificate contents . . . . . . . 13
     3.11. Message IDs for IKE_AUTH messages  . . . . . . . . . . . . 13
   4.  Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  Creating SAs with the CREATE_CHILD_SA exchange . . . . . . 14
     4.2.  Creating an IKE_SA without a CHILD_SA  . . . . . . . . . . 16
     4.3.  Diffie-Hellman for first CHILD_SA  . . . . . . . . . . . . 17
     4.4.  Extended Sequence Numbers (ESN) transform  . . . . . . . . 17
     4.5.  Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . . . . 18
     4.6.  Negotiation of NON_FIRST_FRAGMENTS_ALSO  . . . . . . . . . 18
     4.7.  Semantics of complex traffic selector payloads . . . . . . 18
     4.8.  ICMP type/code in traffic selector payloads  . . . . . . . 19
     4.9.  Mobility header in traffic selector payloads . . . . . . . 20
     4.10. Narrowing the traffic selectors  . . . . . . . . . . . . . 21
     4.11. SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . . 21
     4.12. Traffic selectors violating own policy . . . . . . . . . . 22
     4.13. Definition of TSi and TSr  . . . . . . . . . . . . . . . . 22
     4.14. Port ranges end at 65535 . . . . . . . . . . . . . . . . . 23
   5.  Rekeying and deleting SAs  . . . . . . . . . . . . . . . . . . 23
     5.1.  Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 23
     5.2.  Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 24
     5.3.  SPIs when rekeying the IKE_SA  . . . . . . . . . . . . . . 25
     5.4.  SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 25
     5.5.  Changing PRFs when rekeying the IKE_SA . . . . . . . . . . 25
     5.6.  Deleting vs. closing SAs . . . . . . . . . . . . . . . . . 26
     5.7.  Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 26
     5.8.  Deleting an IKE_SA . . . . . . . . . . . . . . . . . . . . 26
     5.9.  Who is the original initiator of IKE_SA  . . . . . . . . . 27
     5.10. Sending traffic while rekeying . . . . . . . . . . . . . . 27
     5.11. Comparing nonces . . . . . . . . . . . . . . . . . . . . . 27



Eronen & Hoffman         Expires April 27, 2006                 [Page 2]

Internet-Draft            IKEv2 Clarifications              October 2005


     5.12. Simultaneous CHILD_SA rekeying . . . . . . . . . . . . . . 28
   6.  Configuration payloads . . . . . . . . . . . . . . . . . . . . 30
     6.1.  Assigning IP addresses . . . . . . . . . . . . . . . . . . 30
     6.2.  Length of configuration attribute type field . . . . . . . 30
     6.3.  Requesting any INTERNAL_IP4/IP6_ADDRESS  . . . . . . . . . 31
     6.4.  INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET  . . . . . . . . . 31
     6.5.  INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 34
     6.6.  Configuration payloads for IPv6  . . . . . . . . . . . . . 35
     6.7.  INTERNAL_IP6_NBNS  . . . . . . . . . . . . . . . . . . . . 36
     6.8.  INTERNAL_ADDRESS_EXPIRY  . . . . . . . . . . . . . . . . . 36
     6.9.  Address assignment failures  . . . . . . . . . . . . . . . 37
   7.  Miscellaneous issues . . . . . . . . . . . . . . . . . . . . . 37
     7.1.  Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 37
     7.2.  Relationship of IKEv2 to RFC2401bis  . . . . . . . . . . . 38
     7.3.  Reducing the window size . . . . . . . . . . . . . . . . . 38
     7.4.  Minimum size of nonces . . . . . . . . . . . . . . . . . . 38
     7.5.  Initial zero octets on port 4500 . . . . . . . . . . . . . 39
     7.6.  Destination port for NAT traversal . . . . . . . . . . . . 39
     7.7.  SPI values for messages outside of an IKE_SA . . . . . . . 40
     7.8.  Protocol ID/SPI fields in Notify payloads  . . . . . . . . 40
     7.9.  Which message should contain INITIAL_CONTACT . . . . . . . 40
     7.10. Alignment of payloads  . . . . . . . . . . . . . . . . . . 41
     7.11. Key length transform attribute . . . . . . . . . . . . . . 41
   8.  Status of the clarifications . . . . . . . . . . . . . . . . . 42
   9.  Implementation mistakes  . . . . . . . . . . . . . . . . . . . 43
   10. Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 44
   11. Security considerations  . . . . . . . . . . . . . . . . . . . 44
   12. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 45
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 45
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 45
     14.2. Informative References . . . . . . . . . . . . . . . . . . 46
   Appendix A.  Exchanges and payloads  . . . . . . . . . . . . . . . 47
     A.1.  IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 48
     A.2.  IKE_AUTH exchange without EAP  . . . . . . . . . . . . . . 48
     A.3.  IKE_AUTH exchange with EAP . . . . . . . . . . . . . . . . 49
     A.4.  CREATE_CHILD_SA exchange for creating/rekeying
           CHILD_SAs  . . . . . . . . . . . . . . . . . . . . . . . . 50
     A.5.  CREATE_CHILD_SA exchange for rekeying the IKE_SA . . . . . 50
     A.6.  INFORMATIONAL exchange . . . . . . . . . . . . . . . . . . 50
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
   Intellectual Property and Copyright Statements . . . . . . . . . . 52









Eronen & Hoffman         Expires April 27, 2006                 [Page 3]

Internet-Draft            IKEv2 Clarifications              October 2005


1.  Introduction

   This document clarifies many areas of the IKEv2 specification that
   may be difficult to understand to developers not intimately familiar
   with the specification and its history.  The clarifications in this
   document come from the discussion on the IPsec WG mailing list, from
   experience in interoperability testing, and from implementation
   issues that have been brought to the editors' attention.

   Readers are advised that this document is work-in-progress, and may
   contain incorrect interpretations.  Issues where the clarification is
   known to be incomplete, or there is no consensus on what the the
   interpretation should be, are marked as such.

   IKEv2/IPsec can be used for several different purposes, including
   IPsec-based remote access (sometimes called the "road warrior" case),
   site-to-site virtual private networks (VPNs), and host-to-host
   protection of application traffic.  While this document attempts to
   consider all of these uses, the remote access scenario has perhaps
   received more attention here than the other uses.

   This document does not place any requirements on anyone, and does not
   use [RFC2119] keywords such as "MUST" and "SHOULD", except in
   quotations from the original IKEv2 documents.  The requirements are
   given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
   algorithms document [IKEv2ALG].

   In this document, references to a numbered section (such as "Section
   2.15") mean that section in [IKEv2].  References to mailing list
   messages refer to the IPsec WG mailing list at ipsec@ietf.org.
   Archives of the mailing list can be found at
   <http://www.ietf.org/mail-archive/web/ipsec/index.html>.


2.  Creating the IKE_SA

2.1.  SPI values in IKE_SA_INIT exchange

   Normal IKE messages include the initiator's and responder's SPIs,
   both of which are non-zero, in the IKE header.  However, there are
   some corner cases where the IKEv2 specification is not fully
   consistent about what values should be used.

   First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero
   in any other message" (than the first message of the IKE_SA_INIT
   exchange).  However, the figure in Section 2.6 shows the second
   IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
   in 3.1.



Eronen & Hoffman         Expires April 27, 2006                 [Page 4]

Internet-Draft            IKEv2 Clarifications              October 2005


   Since the responder's SPI identifies security-related state held by
   the responder, and in this case no state is created, sending a zero
   value seems reasonable.

   Second, in addition to cookies, there are several other cases when
   the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
   (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  What
   responder SPI value should be used in the IKE_SA_INIT response in
   this case?

   Since the IKE_SA_INIT request always has a zero responder SPI, the
   value will not be actually used by the initiator.  Thus, we think
   sending a zero value is correct also in this case.

   If the responder sends a non-zero responder SPI, the initiator should
   not reject the response only for that reason.  However, when retrying
   the IKE_SA_INIT request, the initiator will use a zero responder SPI,
   as described in Section 3.1: "Responder's SPI [...]  This value MUST
   be zero in the first message of an IKE Initial Exchange (including
   repeats of that message including a cookie) [...]".  We believe the
   intent was to cover repeats of that message due to other reasons,
   such as INVALID_KE_PAYLOAD, as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.2.  Message IDs for IKE_SA_INIT messages

   The Message ID for IKE_SA_INIT messages is always zero.  This
   includes retries of the message due to responses such as COOKIE and
   INVALID_KE_PAYLOAD.

   This is because Message IDs are part of the IKE_SA state, and when
   the responder replies to IKE_SA_INIT request with N(COOKIE) or
   N(INVALID_KE_PAYLOAD), the responder does not allocate any state.

   (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
   combination" thread, Oct 2004.  Tero Kivinen's mail "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

2.3.  Retransmissions of IKE_SA_INIT requests

   When a responder receives an IKE_SA_INIT request, it has to determine
   whether the packet is a retransmission belonging to an existing
   "half-open" IKE_SA (in which case the responder retransmits the same
   response), or a new request (in which case the responder creates a
   new IKE_SA and sends a fresh response).




Eronen & Hoffman         Expires April 27, 2006                 [Page 5]

Internet-Draft            IKEv2 Clarifications              October 2005


   The specification does not describe in detail how this determination
   is done.  In particular, it is not sufficient to use the initiator's
   SPI and/or IP address for this purpose: two different peers behind a
   single NAT could choose the same initiator SPI (and the probability
   of this happening is not necessarily small, since IKEv2 does not
   require SPIs to be chosen randomly).  Instead, the responder should
   do the IKE_SA lookup using the whole packet or its hash (or at the
   minimum, the Ni payload which is always chosen randomly).

   For all other packets than IKE_SA_INIT requests, looking up right
   IKE_SA is of course done based on the the recipient's SPI (either the
   initiator or responder SPI depending on the value of the Initiator
   bit in the IKE header).

2.4.  Interaction of COOKIE and INVALID_KE_PAYLOAD

   There are two common reasons why the initiator may have to retry the
   IKE_SA_INIT exchange: the responder requests a cookie or wants a
   different Diffie-Hellman group than was included in the KEi payload.
   Both of these cases are quite simple alone, but it is not totally
   obvious what happens when they occur at the same time, that is, the
   IKE_SA_INIT exchange is retried several times.

   The main question seems to be the following: if the initiator
   receives a cookie from the responder, should it include the cookie in
   only the next retry of the IKE_SA_INIT request, or in all subsequent
   retries as well?  Section 3.10.1 says that:

      "This notification MUST be included in an IKE_SA_INIT request
      retry if a COOKIE notification was included in the initial
      response."

   This could be interpreted as saying that when a cookie is received in
   the initial response, it is included in all retries.  On the other
   hand, Section 2.6 says that:

      "Initiators who receive such responses MUST retry the
      IKE_SA_INIT with a Notify payload of type COOKIE containing
      the responder supplied cookie data as the first payload and
      all other payloads unchanged."

   Including the same cookie in later retries makes sense only if the
   "all other payloads unchanged" restriction applies only to the first
   retry, but not to subsequent retries.

   It seems that both interpretations can peacefully co-exist.  If the
   initiator includes the cookie only in the next retry, one additional
   roundtrip may be needed in some cases:



Eronen & Hoffman         Expires April 27, 2006                 [Page 6]

Internet-Draft            IKEv2 Clarifications              October 2005


      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), SAi1, KEi', Ni -->
                              <-- HDR(A,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   An additional roundtrip is needed also if the initiator includes the
   cookie in all retries, but the responder does not support this.  For
   instance, if the responder includes the SAi1 and KEi payloads in
   cookie calculation, it will reject the request by sending a new
   cookie (see also Section 2.5 of this document for more text about
   invalid cookies):

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                              <-- HDR(A,0), N(COOKIE')
      HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   If both peers support including the cookie in all retries, a slightly
   shorter exchange can happen:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE)
      HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
                              <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   This document recommends that implementations should support this
   shorter exchange, but it must not be assumed the other peer also
   supports this.







Eronen & Hoffman         Expires April 27, 2006                 [Page 7]

Internet-Draft            IKEv2 Clarifications              October 2005


   In theory, even this exchange has one unnecessary roundtrip, as both
   the cookie and Diffie-Hellman group could be checked at the same
   time:

      Initiator                   Responder
     -----------                 -----------
      HDR(A,0), SAi1, KEi, Ni -->
                              <-- HDR(A,0), N(COOKIE),
                                            N(INVALID_KE_PAYLOAD)
      HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
                              <-- HDR(A,B), SAr1, KEr, Nr

   However, it is clear that this case is not allowed by the text in
   Section 2.6, since "all other payloads" clearly includes the KEi
   payload as well.

   (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
   Sep-Oct 2005.)

2.5.  Invalid cookies

   There has been some confusion what should be done when an IKE_SA_INIT
   request containing an invalid cookie is received ("invalid" in the
   sense that its contents do not match the value expected by the
   responder).

   The correct action is to ignore the cookie, and process the message
   as if no cookie had been included (usually this means sending a
   response containing a new cookie).  This is shown in Section 2.6 when
   it says "The responder in that case MAY reject the message by sending
   another response with a new cookie [...]".

   Other possible actions, such as ignoring the whole request (or even
   all requests from this IP address for some time), create strange
   failure modes even in the absence of any malicious attackers, and do
   not provide any additional protection against DoS attacks.

   (References: "Invalid Cookie" thread, Sep-Oct 2005.)


3.  Authentication

3.1.  Data included in AUTH payload calculation

   Section 2.15 describes how the AUTH payloads are calculated; this
   calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr').  The
   text describes the method in words, but does not give clear
   definitions of what is signed or MACed.



Eronen & Hoffman         Expires April 27, 2006                 [Page 8]

Internet-Draft            IKEv2 Clarifications              October 2005


   The initiator's signed octets can be described as:

       InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
       GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
       RealIKEHDR =  SPIi | SPIr |  . . . | Length
       RealMessage1 = RealIKEHDR | RestOfMessage1
       NonceRPayload = PayloadHeader | NonceRData
       InitiatorIDPayload = PayloadHeader | RestOfIDPayload
       RestOfInitIDPayload = IDType | RESERVED | InitIDData
       MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

   The responder's signed octets can be described as:

       ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
       GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
       RealIKEHDR =  SPIi | SPIr |  . . . | Length
       RealMessage2 = RealIKEHDR | RestOfMessage2
       NonceIPayload = PayloadHeader | NonceIData
       ResponderIDPayload = PayloadHeader | RestOfIDPayload
       RestOfRespIDPayload = IDType | RESERVED | InitIDData
       MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

3.2.  Hash function for RSA signatures

   Section 3.8 says that RSA digital signature is "Computed as specified
   in section 2.15 using an RSA private key over a PKCS#1 padded hash."

   Unlike IKEv1, IKEv2 does not negotiate a hash function for the
   IKE_SA.  The algorithm for signatures is selected by the signing
   party who, in general, may not know beforehand what algorithms the
   verifying party supports.  Furthermore, [IKEv2ALG] does not say what
   algorithms implementations are required or recommended to support.
   This clearly has a potential for causing interoperability problems,
   since authentication will fail if the signing party selects an
   algorithm that is not supported by the verifying party, or not
   acceptable according to the verifying party's policy.

   This document recommends that all implementations support SHA-1, and
   use SHA-1 as the default hash function when generating the
   signatures, unless there are good reasons (such as explicit manual
   configuration) to believe that the other end supports something else.

   Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
   signature encoding method (see next section for details), which
   includes the algorithm identifier for the hash algorithm.  Thus, when
   the verifying party receives the AUTH payload it can determine which
   hash function was used.




Eronen & Hoffman         Expires April 27, 2006                 [Page 9]

Internet-Draft            IKEv2 Clarifications              October 2005


   Other possible choices include, for example, using the hash function
   that was used to sign the certificate.  However, this approach
   assumes that the recipient's "IKEv2 module" supports the same
   algorithms as the "certificate validation module" (which may not be
   true, especially if something like [SCVP] is used).  Furthermore, not
   all CERT payloads types include a signature; and the certificate
   could be signed with some other algorithm than RSA.

   (References: Magnus Alstrom's mail "RE:", 2005-01-03.  Pasi Eronen's
   reply, 2005-01-04.  Tero Kivinen's reply, 2005-01-04.)

3.3.  Encoding method for RSA signatures

   Section 3.8 says that the RSA digital signature is "Computed as
   specified in section 2.15 using an RSA private key over a PKCS#1
   padded hash."

   The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
   encoding methods (ways of "padding the hash") for signatures.
   However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20].  That
   version has only one encoding method for signatures (EMSA-PKCS1-
   v1_5), and thus there is no ambiguity.

   Note that this encoding method is different from the encoding method
   used in IKEv1.  If future revisions of IKEv2 provide support for
   other encoding methods (such as EMSA-PSS), they will be given new
   Auth Method numbers.

   (References: Pasi Eronen's mail "RE:", 2005-01-04.)

3.4.  Identification type for EAP

   Section 3.5 defines several different types for identification
   payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
   EAP [EAP] does not mandate the use of any particular type of
   identifier, but often EAP is used with Network Access Identifiers
   (NAIs) defined in [NAI] and [NAIbis].  Although NAIs look a bit like
   email addresses (e.g., "joe@example.com"), the syntax is not exactly
   the same as the syntax of email address in [RFC822].  This raises the
   question of which identification type should be used.

   This document recommends that ID_RFC822_ADDR identification type is
   used for those NAIs that include the realm component.  Therefore,
   responder implementations should not attempt to verify that the
   contents actually conform to the exact syntax given in [RFC822] or
   [RFC2822], but instead should accept any reasonable looking NAI.

   For NAIs that do not include the realm component, this document



Eronen & Hoffman         Expires April 27, 2006                [Page 10]

Internet-Draft            IKEv2 Clarifications              October 2005


   recommends using the ID_KEY_ID identification type.

   (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
   identifier issue with EAP" threads, Aug 2004.)

3.5.  Identity for policy lookups when using EAP

   When the initiator authentication uses EAP, it is possible that the
   contents of the IDi payload is used only for AAA routing purposes and
   selecting which EAP method to use.  This value may be different from
   the identity authenticated by the EAP method (see [EAP], Sections 5.1
   and 7.3).

   It is important that policy lookups and access control decisions use
   the actual authenticated identity.  Often the EAP server is
   implemented in a separate AAA server that communicates with the IKEv2
   responder using, e.g., RADIUS [RADEAP].  In this case, the
   authenticated identity has to be sent from the AAA server to the
   IKEv2 responder.

   (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2",
   2004-10-28.  "Policy lookups" thread, Oct/Nov 2004.  RFC 3748,
   Section 7.3.)

3.6.  EAP authentication and the AUTH payload

   Section 2.16 says that "For EAP methods that create a shared key as a
   side effect of authentication, that shared key MUST be used by both
   the initiator and responder to generate AUTH payloads in messages 5
   and 6 using the syntax for shared secrets specified in section 2.15."

   This text should say "messages 7 and 8".

   (References: "How to do authentication with EAP" thread, Feb 2005)

3.7.  Certificate encoding types

   Section 3.6 defines a total of twelve different certificate encoding
   types, and continues that "Specific syntax is for some of the
   certificate type codes above is not defined in this document."
   However, the text does not provide references to other documents that
   would contain information about the exact contents and use of those
   values.








Eronen & Hoffman         Expires April 27, 2006                [Page 11]

Internet-Draft            IKEv2 Clarifications              October 2005


   Without this information, it is not possible to develop interoperable
   implementations.  Therefore, this document recommends that the
   following certificate encoding values should not be used before new
   specifications that specify their use are available.

        PKCS #7 wrapped X.509 certificate    1
        PGP Certificate                      2
        DNS Signed Key                       3
        Kerberos Token                       6
        SPKI Certificate                     9

   (Future versions of this document may also contain clarifications
   about how these values are to be used.)

   This document recommends that most implementations should use only
   those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
   "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
   URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
   (13).

   Furthermore, Section 3.7 says that the "Certificate Encoding" field
   for the Certificate Request payload uses the same values as for
   Certificate payload.  However, the contents of the "Certification
   Authority" field are defined only for X.509 certificates (presumably
   covering at least types 4, 10, 12, and 13).  This document recommends
   that other values should not be used before new specifications that
   specify their use are available.

   The "Raw RSA Key" type needs one additional clarification.  Section
   3.6 says it contains "a PKCS #1 encoded RSA key".  What this means is
   a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].

3.8.  Shared key authentication and fixed PRF key size

   Section 2.15 says that "If the negotiated prf takes a fixed size key,
   the shared secret MUST be of that fixed size".  This statement is
   correct: the shared secret must be of the correct size.  If it is
   not, it cannot be used; there is no padding, truncation, or other
   processing involved to force it to that correct size.

   This requirement means that it is difficult to use these PRFs with
   shared key authentication.  The authors think this part of the
   specification was very poorly thought out, and using PRFs with a
   fixed key size is likely to result in interoperability problems.
   Thus, we recommend that such PRFs should not be used with shared key
   authentication.  PRF_AES128_CBC [RFC3664] originally used fixed key
   sizes; that RFC has been updated to handle variable key sizes in
   [RFC3664bis].



Eronen & Hoffman         Expires April 27, 2006                [Page 12]

Internet-Draft            IKEv2 Clarifications              October 2005


   Note that Section 2.13 also contains text that is related to PRFs
   with fixed key size: "When the key for the prf function has fixed
   length, the data provided as a key is truncated or padded with zeros
   as necessary unless exceptional processing is explained following the
   formula".  However, this text applies only to the prf+ construction,
   so it does not contradict the text in Section 2.15.

   (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
   2003-05-02.  Hugo Krawczyk's reply, 2003-05-12.  Thread "Question
   about PRFs with fixed size key", Jan 2005.)

3.9.  EAP authentication and fixed PRF key size

   As described in the previous section, PRFs with a fixed key size
   require a shared secret of exactly that size.  This restriction
   applies also to EAP authentication.  For instance, a PRF that
   requires a 128-bit key cannot be used with EAP since [EAP] specifies
   that the MSK is at least 512 bits long.

   (References: Thread "Question about PRFs with fixed size key", Jan
   2005.)

3.10.  Matching ID payloads to certificate contents

   In IKEv1, there was some confusion about whether or not the
   identities in certificates used to authenticate IKE were required to
   match the contents of the ID payloads.  There has been some work done
   on this in the PKI4IPSEC Working Group, but that work is not finished
   at this time.  However, Section 3.5 explicitly says that the ID
   payload "does not necessarily have to match anything in the CERT
   payload".

3.11.  Message IDs for IKE_AUTH messages

   According to Section 2.2, "The IKE_SA initial setup messages will
   always be numbered 0 and 1."  That is true when the IKE_AUTH exchange
   does not use EAP.  When EAP is used, each pair of messages have their
   message numbers incremented.  The first pair of AUTH messages will
   have an ID of 1, the second will be 2, and so on.

   (References: "Question about MsgID in AUTH exchange" thread, April
   2005.)


4.  Creating CHILD_SAs






Eronen & Hoffman         Expires April 27, 2006                [Page 13]

Internet-Draft            IKEv2 Clarifications              October 2005


4.1.  Creating SAs with the CREATE_CHILD_SA exchange

   Section 1.3's organization does not lead to clear understanding of
   what is needed in which environment.  The section can be reorganized
   with subsections for each use of the CREATE_CHILD_SA exchange
   (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)

   Further, specific parts of Section 3.1 can be clarified.  These
   include:

   o  It is not clear which SA to send in a rekeying a child SA.  The
      relevant sentence says "If this CREATE_CHILD_SA exchange is
      rekeying an existing SA other than the IKE_SA, the leading N
      payload of type REKEY_SA MUST identify the SA being rekeyed."
      That can be clarified by adding "sender's inbound" before "SA
      being rekeyed".

   o  The specific method for rekeying an IKE_SA is not described in the
      section that describes the rekeying.  This is described in Section
      2.8.  Relevant text from Section 2.8 can be moved here.

   o  Section 1.3 never mentions the REKEY_SA Notification, but it does
      have a mandatory Notification payload when rekeying.  The
      CREATE_CHILD_SA exchange MUST include a REKEY_SA Notification
      payload with an SPI field identifying the SA being rekeyed.

   o  The spec is partially wrong about the use of nonces in computing
      keys for CHILD_SAs.  Section 1.3 says "The nonces from the initial
      exchange are used in computing the keys for the CHILD_SA."
      However, that is not always true.  It is only true for a CHILD_SA
      created in the IKE_AUTH exchange.  Thus, the sentence can be
      ignored because the use of the nonces for computing the keys is
      clear in Section 2.17.

   The new Section 1.3 with subsections and the above changes might look
   like this.

   NEW-1.3 The CREATE_CHILD_SA Exchange

        The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
        to rekey both IKE_SAs and CHILD_SAs. This exchange consists of a
        single request/response pair, and some of its function was
        referred to as a phase 2 exchange in IKEv1. It MAY be initiated
        by either end of the IKE_SA after the initial exchanges are
        completed.

        All messages following the initial exchange are
        cryptographically protected using the cryptographic algorithms



Eronen & Hoffman         Expires April 27, 2006                [Page 14]

Internet-Draft            IKEv2 Clarifications              October 2005


        and keys negotiated in the first two messages of the IKE
        exchange.  These subsequent messages use the syntax of the
        Encrypted Payload described in section 3.14. All subsequent
        messages included an Encrypted Payload, even if they are
        referred to in the text as "empty". For both messages in the
        CREATE_CHILD_SA, the message following the header is encrypted
        and the message including the header is integrity protected
        using the cryptographic algorithms negotiated for the IKE_SA.

        The CREATE_CHILD_SA is used for rekeying IKE_SAs and
        CHILD_SAs. This section describes the first part of rekeying,
        the creation of new SAs; Section 2.8 covers the mechanics of
        rekeying, including moving traffic from old to new SAs and the
        deletion of the old SAs. The two sections must be read together
        to understand the entire process of rekeying.

        Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
        this section the term initiator refers to the endpoint
        initiating this exchange. An implementation MAY refuse all
        CREATE_CHILD_SA requests within an IKE_SA.

        The CREATE_CHILD_SA request MAY optionally contain a KE payload
        for an additional Diffie-Hellman exchange to enable stronger
        guarantees of forward secrecy for the CHILD_SA. The keying
        material for the CHILD_SA is a function of SK_d established
        during the establishment of the IKE_SA, the nonces exchanged
        during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
        value (if KE payloads are included in the CREATE_CHILD_SA
        exchange).

        If a CREATE_CHILD_SA exchange includes a KEi payload, at least
        one of the SA offers MUST include the Diffie-Hellman group of
        the KEi.  The Diffie-Hellman group of the KEi MUST be an element
        of the group the initiator expects the responder to accept
        (additional Diffie-Hellman groups can be proposed). If the
        responder rejects the Diffie-Hellman group of the KEi payload,
        the responder MUST reject the request and indicate its preferred
        Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
        payload.  In the case of such a rejection, the CREATE_CHILD_SA
        exchange fails, and the initiator SHOULD retry the exchange with
        a Diffie-Hellman proposal and KEi in the group that the
        responder gave in the INVALID_KE_PAYLOAD.

   NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange

        A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
        The CREATE_CHILD_SA request for creating a new CHILD_SA is:




Eronen & Hoffman         Expires April 27, 2006                [Page 15]

Internet-Draft            IKEv2 Clarifications              October 2005


            Initiator                                 Responder
           -----------                               -----------
            HDR, SK {SA, Ni, [KEi],
                       TSi, TSr}        -->

        The initiator sends SA offer(s) in the SA payload, a nonce in
        the Ni payload, optionally a Diffie-Hellman value in the KEi
        payload, and the proposed traffic selectors for the proposed
        CHILD_SA in the TSi and TSr payloads.

        The CREATE_CHILD_SA response for creating a new CHILD_SA is:

                                       <--    HDR, SK {SA, Nr, [KEr],
                                                    TSi, TSr}

        The responder replies (using the same Message ID to respond)
        with the accepted offer in an SA payload, and a Diffie-Hellman
        value in the KEr payload if KEi was included in the request and
        the selected cryptographic suite includes that group.

        The traffic selectors for traffic to be sent on that SA are
        specified in the TS payloads in the response, which may be a
        subset of what the initiator of the CHILD_SA proposed.


   The text about rekeying SAs can be found in Section 5.1 of this
   document.

4.2.  Creating an IKE_SA without a CHILD_SA

   CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
   exchange, or using a separate CREATE_CHILD_SA exchange.  The
   specification is not clear about what happens if creating the
   CHILD_SA during the IKE_AUTH exchange fails for some reason.

   Our recommendation in this sitation is that the IKE_SA is created as
   usual.  This is also in line with how the CREATE_CHILD_SA exchange
   works: a failure to create a CHILD_SA does not close the IKE_SA.

   The list of responses in the IKE_AUTH exchange that do not prevent an
   IKE_SA from being set up include at least the following:
   NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
   INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.

   (References: "Questions about internal address" thread, April, 2005.)






Eronen & Hoffman         Expires April 27, 2006                [Page 16]

Internet-Draft            IKEv2 Clarifications              October 2005


4.3.  Diffie-Hellman for first CHILD_SA

   Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
   Ni/Nr payloads.  This implies that the SA payload in IKE_AUTH
   exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
   any other value than NONE.  Implementations should probably leave the
   transform out entirely in this case.

4.4.  Extended Sequence Numbers (ESN) transform

   The description of the ESN transform in Section 3.3 has be proved
   difficult to understand.  When the ESN transform is included, it has
   the following meaning:

   o  A proposal containing one ESN transform with value 0 means "do not
      use extended sequence numbers".

   o  A proposal containing one ESN transform with value 1 means "use
      extended sequence numbers".

   o  A proposal containing two ESN transforms with values 0 and 1 means
      "I support both normal and extended sequence numbers, you choose".
      (Obviously this case is only allowed in requests; the response
      will contain only one ESN transform.)

   In most cases, the exchange initiator will include either the first
   or third alternative in its SA payload.  The second alternative is
   rarely useful for the initiator: it means that using normal sequence
   numbers is not acceptable (so if the responder does not support ESNs,
   the exchange will fail with NO_PROPOSAL_CHOSEN).

   Section 3.3.2 also says that "If Transform Type 5 is not included in
   a proposal, use of Extended Sequence Numbers is assumed".  Or in
   other words, omitting the ESN transform means the same thing as
   including one ESN transform with value 1.

   This choice of default value is somewhat counterintuitive and as
   described above, rarely useful.  IPsec WG decided recently to change
   this part of the specification, and make it mandatory to include the
   ESN transform for ESP/AH.

   (References: "Technical change needed to IKEv2 before publication",
   "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
   and "Results of straw poll regarding: IKEv2 interoperability issue"
   threads, March-April 2005.)






Eronen & Hoffman         Expires April 27, 2006                [Page 17]

Internet-Draft            IKEv2 Clarifications              October 2005


4.5.  Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED

   The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
   Section 3.10.1 says that "This notification asserts that the sending
   endpoint will NOT accept packets that contain Flow Confidentiality
   (TFC) padding".

   However, the text does not say in which messages this notification
   should be included, or whether the scope of this notification is a
   single CHILD_SA or all CHILD_SAs of the peer.

   Our interpretation is that the scope is a single CHILD_SA, and thus
   this notification is included in messages containing an SA payload
   negotiating a CHILD_SA.  If neither endpoint accepts TFC padding,
   this notification will be included in both the request proposing an
   SA and the response accepting it.  If this notification is included
   in only one of the messages, TFC padding can still be sent in one
   direction.

4.6.  Negotiation of NON_FIRST_FRAGMENTS_ALSO

   NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
   simply as "Used for fragmentation control.  See [RFC2401bis] for
   explanation."

   [RFC2401bis] says "Implementations that will transmit non-initial
   fragments on a tunnel mode SA that makes use of non-trivial port (or
   ICMP type/code or MH type) selectors MUST notify a peer via the IKE
   NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.  The peer MUST reject this
   proposal if it will not accept non-initial fragments in this context.
   If an implementation does not successfully negotiate transmission of
   non-initial fragments for such an SA, it MUST NOT send such fragments
   over the SA."

   However, it is not clear exactly how the negotiation works.  Our
   interpretation is that the negotiation works the same way as for
   IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
   is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
   in both the request proposing an SA and the response accepting it.
   In other words, if the peer "rejects this proposal", it only omits
   NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
   reject the whole CHILD_SA creation.

4.7.  Semantics of complex traffic selector payloads

   As described in Section 3.13, the TSi/TSr payloads can include one or
   more individual traffic selectors.




Eronen & Hoffman         Expires April 27, 2006                [Page 18]

Internet-Draft            IKEv2 Clarifications              October 2005


   There is no requirement that TSi and TSr contain the same number of
   individual traffic selectors.  Thus, they are interpreted as follows:
   a packet matches a given TSi/TSr if it matches at least one of the
   individual selectors in TSi, and at least one of the individual
   selectors in TSr.

   For instance, the following traffic selectors:

        TSi = ((17, 100, 192.0.1.66-192.0.1.66),
               (17, 200, 192.0.1.66-192.0.1.66))
        TSr = ((17, 300, 0.0.0.0-255.255.255.255),
               (17, 400, 0.0.0.0-255.255.255.255))

   would match UDP packets from 192.0.1.66 to anywhere, with any of the
   four combinations of source/destination ports (100,300), (100,400),
   (200,300), and (200, 400).

   This implies that some types of policies may require several CHILD_SA
   pairs.  For instance, a policy matching only source/destination ports
   (100,300) and (200,400), but not the other two combinations, cannot
   be negotiated as a single CHILD_SA pair using IKEv2.

   (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.8.  ICMP type/code in traffic selector payloads

   The traffic selector types 7 and 8 can also refer to ICMP type and
   code fields.  As described in Section 3.13.1, "For the ICMP protocol,
   the two one octet fields Type and Code are treated as a single 16 bit
   integer (with Type in the most significant eight bits and Code in the
   least significant eight bits) port number for the purposes of
   filtering based on this field."

   Since ICMP packets do not have separate source and destination port
   fields, there is some room for confusion what exactly the four TS
   payloads (two in the request, two in the response, each containing
   both start and end port fields) should contain.

   The answer to this question can be found from [RFC2401bis] Section
   4.4.1.3.

   To give a concrete example, if a host at 192.0.1.234 wants to create
   a transport mode SA for sending "Destination Unreachable" packets
   (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
   over this SA pair, the CREATE_CHILD_SA exchange would look like this:






Eronen & Hoffman         Expires April 27, 2006                [Page 19]

Internet-Draft            IKEv2 Clarifications              October 2005


      Initiator                   Responder
     -----------                 -----------
      HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
                TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->

         <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                       TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                       TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }

   Since IKEv2 always creates IPsec SAs in pairs, two SAs are also in
   this case, even though the second SA is never used for data traffic.

   An exchange creating an SA pair that can be used both for sending and
   receiving "Destination Unreachable" places the same value in all the
   port:

      Initiator                   Responder
     -----------                 -----------
      HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
                TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->

         <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                       TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                       TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }

   Note that there is an error that will be fixed before publication in
   [RFC2401bis] Section 4.4.1.3 case B: if the SPD entry applies both to
   sending and receiving, the MH message type (or ICMP type/code) should
   be in both local and remote port.  Otherwise, it would be
   indistinguishable from case C.

   (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)

4.9.  Mobility header in traffic selector payloads

   Traffic selectors can use IP Protocol ID 135 to match the IPv6
   mobility header [MIPv6].  However, the IKEv2 specification does not
   define how to represent the "MH Type" field in traffic selectors.

   At some point, it was expected that this will be defined in a
   separate document later.  However, [RFC2401bis] says that "For IKE,
   the IPv6 mobility header message type (MH type) is placed in the most
   significant eight bits of the 16 bit local "port" selector".  The
   direction semantics of TSi/TSr port fields are the same as for ICMP,
   and are described in the previous section.




Eronen & Hoffman         Expires April 27, 2006                [Page 20]

Internet-Draft            IKEv2 Clarifications              October 2005


   (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
   message type as selector", 2003-10-14.  "ICMP and MH TSs for IKEv2"
   thread, Sep 2005.)

4.10.  Narrowing the traffic selectors

   Section 2.9 describes how traffic selectors are negotiated when
   creating a CHILD_SA.  A more concise summary of the narrowing process
   is presented below.

   o  If the responder's policy does not allow any part of the traffic
      covered by TSi/TSr, it responds with TS_UNACCEPTABLE.

   o  If the responder's policy allows the entire set of traffic covered
      by TSi/TSr, no narrowing is necessary, and the responder can
      return the same TSi/TSr values.

   o  Otherwise, narrowing is needed.  If the responder's policy allows
      all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
      in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
      acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].

   o  If the responder's policy does not allow all traffic covered by
      TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
      an acceptable subset of TSi/TSr.

   In the last two cases, there may be several subsets that are
   acceptable (but their union is not); in this case, the responder
   arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE
   notification in the response.

4.11.  SINGLE_PAIR_REQUIRED

   The description of the SINGLE_PAIR_REQUIRED notify payload in
   Sections 2.9 and 3.10.1 is not fully consistent.

   We do not attempt to describe this payload in this document either,
   since it is expected that most implementations will not have policies
   that require separate SAs for each address pair.

   Thus, if only some part (or parts) of the TSi/TSr proposed by the
   initiator is (are) acceptable to the responder, most responders
   should simply narrow TSi/TSr to an acceptable subset (as described in
   the last two paragraphs of Section 2.9), rather than use
   SINGLE_PAIR_REQUIRED.






Eronen & Hoffman         Expires April 27, 2006                [Page 21]

Internet-Draft            IKEv2 Clarifications              October 2005


4.12.  Traffic selectors violating own policy

   Section 2.9 describes traffic selector negotiation in great detail.
   One aspect of this negotiation that may need some clarification is
   that when creating a new SA, the initiator should not propose traffic
   selectors that violate its own policy.  If this rule is not followed,
   valid traffic may be dropped.

   This is best illustrated by an example.  Suppose that host A has a
   policy whose effect is that traffic to 192.0.1.66 is sent via host B
   encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
   is also sent via B, but must use 3DES.  Suppose also that host B
   accepts any combination of AES and 3DES.

   If host A now proposes an SA that uses 3DES, and includes TSr
   containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
   B. Now, host B can also use this SA to send traffic from 192.0.1.66,
   but those packets will be dropped by A since it requires the use of
   AES for those traffic.  Even if host A creates a new SA only for
   192.0.1.66 that uses AES, host B may freely continue to use the first
   SA for the traffic.  In this situation, when proposing the SA, host A
   should have followed its own policy, and included a TSr containing
   ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

   In general, if (1) the initiator makes a proposal "for traffic X
   (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
   does not actually accept traffic X' with SA, and (3) the initiator
   would be willing to accept traffic X' with some SA' (!=SA), valid
   traffic can be unnecessarily dropped since the responder can apply
   either SA or SA' to traffic X'.

   (References: "Question about "narrowing" ..." thread, Feb 2005.
   "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
   Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
   negotiation examples", 2004-08-08.)

4.13.  Definition of TSi and TSr

   Section 2.9 has a mistake that is understandable from the example but
   still needs to be corrected.  It says:

      The first of the two TS payloads is known as TSi (Traffic
      Selector-initiator).  The second is known as TSr (Traffic
      Selector-responder). TSi specifies the source address of traffic
      forwarded from (or the destination address of traffic forwarded
      to) the initiator of the CHILD_SA pair. TSr specifies the
      destination address of the traffic forwarded from (or the source
      address of the traffic forwarded to) the responder of the CHILD_SA



Eronen & Hoffman         Expires April 27, 2006                [Page 22]

Internet-Draft            IKEv2 Clarifications              October 2005


      pair.

   The last sentence above should read "TSr specifies the destination
   address of the traffic forwarded to (or the source address of the
   traffic forwarded from) the responder of the CHILD_SA pair."

4.14.  Port ranges end at 65535

   In Section 2.19, the examples show traffic selectors with port ranges
   "0-65536".  That should be "0-65535".


5.  Rekeying and deleting SAs

5.1.  Rekeying SAs with the CREATE_CHILD_SA exchange

   Continued from Section 4.1 of this document.

   NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange

        The CREATE_CHILD_SA request for rekeying an IKE_SA is:

            Initiator                                 Responder
           -----------                               -----------
            HDR, SK {SA, Ni, KEi} -->

        The initiator sends SA offer(s) in the SA payload, a nonce in
        the Ni payload, and a Diffie-Hellman value in the KEi payload.
        New initiator and responder SPIs are supplied in the SPI fields.

        The CREATE_CHILD_SA response for rekeying an IKE_SA is:

                                       <--    HDR, SK {SA, Nr, KEr}

        The responder replies (using the same Message ID to respond)
        with the accepted offer in an SA payload, and a Diffie-Hellman
        value in the KEr payload if the selected cryptographic suite
        includes that group.

        The new IKE_SA has its message counters set to 0, regardless of
        what they were in the earlier IKE_SA. The window size starts at
        1 for any new IKE_SA.

        KEi and KEr are required for rekeying an IKE_SA.

   NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange

        The CREATE_CHILD_SA request for rekeying a CHILD_SA is:



Eronen & Hoffman         Expires April 27, 2006                [Page 23]

Internet-Draft            IKEv2 Clarifications              October 2005


            Initiator                                 Responder
           -----------                               -----------
            HDR, SK {N, SA, Ni, [KEi],
                TSi, TSr}             -->

        The initiator sends SA offer(s) in the SA payload, a nonce in
        the Ni payload, optionally a Diffie-Hellman value in the KEi
        payload, and the proposed traffic selectors for the proposed
        CHILD_SA in the TSi and TSr payloads. When rekeying an existing
        CHILD_SA, the leading N payload of type REKEY_SA MUST be
        included and MUST give the SPI (as they would be expected in
        the headers of inbound packets) of the SAs being rekeyed.

        The CREATE_CHILD_SA response for rekeying a CHILD_SA is:

                                       <--    HDR, SK {SA, Nr, [KEr],
                                                    TSi, TSr}

        The responder replies (using the same Message ID to respond)
        with the accepted offer in an SA payload, and a Diffie-Hellman
        value in the KEr payload if KEi was included in the request and
        the selected cryptographic suite includes that group.

        The traffic selectors for traffic to be sent on that SA are
        specified in the TS payloads in the response, which may be a
        subset of what the initiator of the CHILD_SA proposed.

5.2.  Rekeying the IKE_SA vs. reauthentication

   Rekeying the IKE_SA and reauthentication are different concepts in
   IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA and
   resets the Message ID counters, but it does not authenticate the
   parties again (no AUTH or EAP payloads are involved).

   While rekeying the IKE_SA may be important in some environments,
   reauthentication (the verification that the parties still have access
   to the long-term credentials) is often more important.

   IKEv2 does not have any special support for reauthentication.
   Reauthentication is done by creating a new IKE_SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
   payloads), creating new CHILD_SAs within the new IKE_SA (without
   REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
   deletes the old CHILD_SAs as well).

   This means that reauthentication also establishes new keys for the
   IKE_SA and CHILD_SAs.  Therefore, while rekeying can be performed
   more often than reauthentication, the situation where "authentication



Eronen & Hoffman         Expires April 27, 2006                [Page 24]

Internet-Draft            IKEv2 Clarifications              October 2005


   lifetime" is shorter than "key lifetime" does not make sense.

   While creation of a new IKE_SA can be initiated by either party
   (initiator or responder in the original IKE_SA), the use of EAP
   authentication and/or configuration payloads means in practice that
   reauthentication has to be initiated by the same party as the
   original IKE_SA.  IKEv2 does not currently allow the responder to
   request reauthentication in this case; however, there is ongoing work
   to add this functionality [ReAuth].

   (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)

5.3.  SPIs when rekeying the IKE_SA

   Section 2.18 says that "New initiator and responder SPIs are supplied
   in the SPI fields".  This refers to the SPI fields in the Proposal
   structures inside the Security Association (SA) payloads, not the SPI
   fields in the IKE header.

   (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
   Geoffrey Huang's reply, 2005-01-24.)

5.4.  SPI when rekeying a CHILD_SA

   Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
   identifies the SA being rekeyed."

   Since CHILD_SAs always exist in pairs, there are two different SPIs.
   The SPI placed in the REKEY_SA notification is the SPI the exchange
   initiator would expect in inbound ESP or AH packets (just as in
   Delete payloads).

5.5.  Changing PRFs when rekeying the IKE_SA

   When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
   new IKE_SA is computed using SK_d from the existing IKE_SA as
   follows:

      SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"

   If the old and new IKE_SA selected a different PRF, it is not totally
   clear which PRF should be used.

   Since the rekeying exchange belongs to the old IKE_SA, it is the old
   IKE_SA's PRF that is used.  This also follows the principle that the
   same key (the old SK_d) should not be used with multiple
   cryptographic algorithms.




Eronen & Hoffman         Expires April 27, 2006                [Page 25]

Internet-Draft            IKEv2 Clarifications              October 2005


   Note that this may work poorly if the new IKE_SA's PRF has a fixed
   key size, since the output of the PRF may not be of the correct size.
   This supports our opinion earlier in the document that the use of
   PRFs with a fixed key size is a bad idea.

   (References: "Changing PRFs when rekeying the IKE_SA" thread, June
   2005.)

5.6.  Deleting vs. closing SAs

   The IKEv2 specification talks about "closing" and "deleting" SAs, but
   it is not always clear what exactly is meant.  However, other parts
   of the specification make it clear that when local state related to a
   CHILD_SA is removed, the SA must also be actively deleted with a
   Delete payload.

   In particular, Section 2.4 says that "If an IKE endpoint chooses to
   delete CHILD_SAs, it MUST send Delete payloads to the other end
   notifying it of the deletion".  Section 1.4 also explains that "ESP
   and AH SAs always exist in pairs, with one SA in each direction.
   When an SA is closed, both members of the pair MUST be closed."

5.7.  Deleting a CHILD_SA pair

   Section 1.4 describes how to delete SA pairs using the Informational
   exchange: "To delete an SA, an INFORMATIONAL Exchange with one or
   more delete payloads is sent listing the SPIs (as they would be
   expected in the headers of inbound packets) of the SAs to be deleted.
   The recipient MUST close the designated SAs."

   The "one or more delete payloads" phrase has caused some confusion.
   You never send delete payloads for the two sides of an SA in a single
   message.  If you have many SAs to delete at the same time (such as
   the nested example given in that paragraph), you include delete
   payloads for in inbound half of each SA in your Informational
   exchange.

5.8.  Deleting an IKE_SA

   Since IKE_SAs do not exist in pairs, it is not totally clear what the
   response message should contain when the request deleted the IKE_SA.

   Since there is no information that needs to be sent to the other side
   (except that the request was received), an empty Informational
   response seems like the most logical choice.

   (References: "Question about delete IKE SA" thread, May 2005.)




Eronen & Hoffman         Expires April 27, 2006                [Page 26]

Internet-Draft            IKEv2 Clarifications              October 2005


5.9.  Who is the original initiator of IKE_SA

   In the IKEv2 document, "initiator" refers to the party who initiated
   the exchange being described, and "original initiator" refers to the
   party who initiated the whole IKE_SA.  However, there is some
   potential for confusion because the IKE_SA can be rekeyed by either
   party.

   To clear up this confusion, we propose that "original initiator"
   always refers to the party who initiated the exchange which resulted
   in the current IKE_SA.  In other words, if the the "original
   responder" starts rekeying the IKE_SA, that party becomes the
   "original initiator" of the new IKE_SA.

   (References: Paul Hoffman's mail "Original initiator in IKEv2", 2005-
   04-21.)

5.10.  Sending traffic while rekeying

   The last paragraph of Section 2.8 says: "The responder can be assured
   that the initiator is prepared to receive messages on an SA if either
   (1) it has received a cryptographically valid message on the new SA,
   or (2) the new SA rekeys an existing SA and it receives an IKE
   request to close the replaced SA.  When rekeying an SA, the responder
   SHOULD continue to send requests on the old SA until it one of those
   events occurs."

   It is clear that the paragraph is discussing both IKE_SAs and
   CHILD_SAs.  Therefore, the last sentence above should read "...SHOULD
   continue to send traffic on the old SA...".

5.11.  Comparing nonces

   Section 2.8 about rekeying says that "If redundant SAs are created
   though such a collision, the SA created with the lowest of the four
   nonces used in the two exchanges SHOULD be closed by the endpoint
   that created it."

   Here "lowest" uses an octet-by-octet (lexicographical) comparison
   (instead of, for instance, comparing the nonces as large integers).
   In other words, start by comparing the first octet; if they're equal,
   move to the next octet, and so on.  If you reach the end of one
   nonce, that nonce is the lower one.

   (References: "IKEv2 rekeying question" thread, July 2005.)






Eronen & Hoffman         Expires April 27, 2006                [Page 27]

Internet-Draft            IKEv2 Clarifications              October 2005


5.12.  Simultaneous CHILD_SA rekeying

   Section 2.8 says

      "If the two ends have the same lifetime policies, it is possible
      that both will initiate a rekeying at the same time (which will
      result in redundant SAs).  To reduce the probability of this
      happening, the timing of rekeying requests SHOULD be jittered
      (delayed by a random amount of time after the need for rekeying is
      noticed).

      This form of rekeying may temporarily result in multiple similar
      SAs between the same pairs of nodes.  When there are two SAs
      eligible to receive packets, a node MUST accept incoming packets
      through either SA.  If redundant SAs are created though such a
      collision, the SA created with the lowest of the four nonces used
      in the two exchanges SHOULD be closed by the endpoint that created
      it."

   However, a better explanation on what impact this has on
   implementations is needed.  Assume that hosts A and B have an
   existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
   rekeying it at the same time:

      Host A                      Host B
     --------                    --------
      send req1: N(REKEY_SA,SPIa1),
      SA(..,SPIa2,..),Ni1,..  -->
                              <-- send req2: N(REKEY_SA,SPIb1),
                                  SA(..,SPIb2,..),Ni2
      recv req2 <--

   At this point, A knows there is a simultaneous rekeying going on.
   However, it cannot yet know which of the exchanges will have the
   lowest nonce, so it will just note the situation and respond as
   usual.

      send resp2: SA(..,SPIa3,..),Nr1,.. -->
                              --> recv req1

   Now B also knows that simultaneous rekeying is going on.  It responds
   as usual.

                              <-- send resp1: SA(..,SPIb3,..),Nr2,..
       recv resp1 <--
                              --> recv resp2

   At this point, there are three CHILD_SA pairs between A and B (the



Eronen & Hoffman         Expires April 27, 2006                [Page 28]

Internet-Draft            IKEv2 Clarifications              October 2005


   old one and two new ones).  A and B can now compare the nonces.
   Suppose that the lowest nonce was Nr1 in message resp2; in this case,
   B (the sender of req2) deletes the redundant new SA, and A (the node
   that initiated the surviving rekeyed SA), deletes the old one.

      send req3: D(SPIa1) -->
                              <-- send req4: D(SPIb2)
                              --> recv req3
                              <-- send resp4: D(SPIb1)
      recv req4 <--
      send resp4: D(SPIa3) -->

   The rekeying is now finished.

   However, there is a second possible sequence of events that can
   happen if some packets are lost in the network, resulting in
   retransmissions.  The rekeying begins as usual, but A's first packet
   (req1) is lost.

      Host A                      Host B
     --------                    --------
      send req1: N(REKEY_SA,SPIa1),
      SA(..,SPIa2,..),Ni1,..  -->  (lost)
                              <-- send req2: N(REKEY_SA,SPIb1),
                                  SA(..,SPIb2,..),Ni2
      recv req2 <--
      send resp2: SA(..,SPIa3,..),Nr1,.. -->
                              --> recv resp2
                              <-- send req3: D(SPIb1)
      recv req3 <--
      send resp3: D(SPIa1) -->
                              --> recv resp3

   From B's point of view, the rekeying is now completed, and since it
   has not yet received A's req1, it does not even know that these was
   simultaneous rekeying.  However, A will continue retransmitting the
   message, and eventually it will reach B.

      resend req1 -->
                               --> recv req1

   What should B do in this point?  To B, it looks like A is trying to
   rekey an SA that no longer exists; thus failing the request with
   something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
   reasonable approach.

                               <-- send resp1: N(NO_PROPOSAL_CHOSEN)
      recv resp1 <--



Eronen & Hoffman         Expires April 27, 2006                [Page 29]

Internet-Draft            IKEv2 Clarifications              October 2005


   When A receives this error, it already knows there was simultaneous
   rekeying, so it can ignore the error message.


6.  Configuration payloads

6.1.  Assigning IP addresses

   Section 2.9 talks about traffic selector negotiation and mentions
   that "In support of the scenario described in section 1.1.3, an
   initiator may request that the responder assign an IP address and
   tell the initiator what it is."

   This sentence is correct, but its placement is slightly confusing.
   IKEv2 does allow the initiator to request assignment of an IP address
   from the responder, but this is done using configuration payloads,
   not traffic selector payloads.  An address in a TSi payload in a
   response does not mean that the responder has assigned that address
   to the initiator; it only means that if packets matching these
   traffic selectors are sent by the initiator, IPsec processing can be
   performed as agreed for this SA.  The TSi payload itself does not
   give the initiator permission to configure the initiator's TCP/IP
   stack with the address and use it as its source address.

   In other words, IKEv2 does not have two different mechanisms for
   assigning addresses, but only one: configuration payloads.  In the
   scenario described in Section 1.1.3, both configuration and traffic
   selector payloads are usually included in the same message, and often
   contain the same information in the response message (see Section 6.4
   of this document for some examples).  However, their semantics are
   still different.

6.2.  Length of configuration attribute type field

   In Section 3.15.1, Figure 23 shows that the length of the "Attribute
   Type" field is 15 bits, while the text below the figure says the
   length is 7 bits.

   The figure is correct, the field is 15 bits.

   (References: Tero Kivinen's mail "Comments to the
   draft-ietf-ipsec-ikev2-11.txt", 2003-11-09.  Yoav Nir's mail "Will
   ikev2-16 be the charm?", 2004-09-23.  Charlie Kaufman's
   mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04.  It is expected that
   this issue will be fixed during the "Authors' 48 hours" before the
   RFC is published.)





Eronen & Hoffman         Expires April 27, 2006                [Page 30]

Internet-Draft            IKEv2 Clarifications              October 2005


6.3.  Requesting any INTERNAL_IP4/IP6_ADDRESS

   When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
   3.15.1 says that "In a request message, the address specified is a
   requested address (or zero if no specific address is requested)".
   The question here is that does "zero" mean an address "0.0.0.0" or a
   zero length string?

   Earlier, the same section also says that "If an attribute in the
   CFG_REQUEST Configuration Payload is not zero length it is taken as a
   suggestion for that attribute".  Also, the table of configuration
   attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
   or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
   octets".

   Thus, if the client does not request a specific address, it includes
   a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
   containing an all-zeroes address.  The example in 2.19 is thus
   incorrect, since it shows the attribute as
   "INTERNAL_ADDRESS(0.0.0.0)".

   However, since the value is only a suggestion, implementations are
   recommended to ignore suggestions they do not accept; or in other
   words, treat the same way a zero-length INTERNAL_IP4_ADDRESS,
   "0.0.0.0", and any other addresses the implementation does not
   recognize as a reasonable suggestion.

6.4.  INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

   Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
   sub-networks that this edge-device protects.  This attribute is made
   up of two fields; the first being an IP address and the second being
   a netmask.  Multiple sub-networks MAY be requested.  The responder
   MAY respond with zero or more sub-network attributes."
   INTERNAL_IP6_SUBNET is defined in a similar manner.

   This raises two questions: first, since this information is usually
   included in the TSr payload, what functionality does this attribute
   add?  And second, what does this attribute mean in CFG_REQUESTs?

   For the first question, there seem to be two sensible
   interpretations.  Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
   response) indicates which subnets are accessible through the SA that
   was just created.

   The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
   that they indicate additional subnets that can be reached through
   this gateway, but need a separate SA.  According to this



Eronen & Hoffman         Expires April 27, 2006                [Page 31]

Internet-Draft            IKEv2 Clarifications              October 2005


   interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
   mainly when they contain addresses not included in TSr.

   The second interpretation is that the INTERNAL_IP4/6_SUBNET
   attributes express the gateway's policy about what traffic should be
   sent through the gateway.  The client can choose whether other
   traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
   through the gateway or directly the destination.  According to this
   interpretation, the attributes are useful mainly when TSr contains
   addresses not included in the INTERNAL_IP4/6_SUBNET attributes.

   It turns out that these two interpretations are not incompatible, but
   rather two sides of the same principle: traffic to the addresses
   listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
   this gateway.  If there are no existing IPsec SAs whose traffic
   selectors cover the address in question, new SAs have to be created.

   A couple of examples are given below.  For instance, if there are two
   subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
   contains the following:

        CP(CFG_REQUEST) =
          INTERNAL_IP4_ADDRESS()
        TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
        TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   Then a valid response could be the following (in which TSr and
   INTERNAL_IP4_SUBNET contain the same information):

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
               (0, 0-65535, 192.0.2.0-192.0.2.255))

   In these cases, the INTERNAL_IP4_SUBNET does not really carry any
   useful information.  Another possible reply would have been this:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   This would mean that the client can send all its traffic through the



Eronen & Hoffman         Expires April 27, 2006                [Page 32]

Internet-Draft            IKEv2 Clarifications              October 2005


   gateway, but the gateway does not mind if the client sends traffic
   not included by INTERNAL_IP4_SUBNET directly to the destination
   (without going through the gateway).

   A different situation arises if the gateway has a policy that
   requires the traffic for the two subnets to be carried in separate
   SAs.  Then a response like this would indicate to the client that if
   it wants access to the second subnet, it needs to create a separate
   SA:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)

   INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
   only part of the address space.  For instance, if the client requests
   the following:

        CP(CFG_REQUEST) =
          INTERNAL_IP4_ADDRESS()
        TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
        TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   Then the gateway's reply could be this:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   It is less clear what the attributes mean in CFG_REQUESTs, and
   whether other lengths than zero make sense in this situation (but for
   INTERNAL_IP6_SUBNET, zero length is not allowed at all!).  Currently
   this document recommends that implementations should not include
   INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
   CFG_REQUESTs.

   For the IPv4 case, this document recommends using only netmasks
   consisting of some amount of "1" bits followed by "0" bits; for
   instance, "255.0.255.0" would not be a valid netmask for
   INTERNAL_IP4_SUBNET.

   It is also worthwhile to note that the contents of the INTERNAL_IP4/



Eronen & Hoffman         Expires April 27, 2006                [Page 33]

Internet-Draft            IKEv2 Clarifications              October 2005


   6_SUBNET attributes do not imply link boundaries.  For instance, a
   gateway providing access to a large company intranet using addresses
   from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
   attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
   routers and separate links.

   (References: Tero Kivinen's mail "Intent of couple of attributes in
   Configuration Payload in IKEv2?", 2004-11-19.  Srinivasa Rao
   Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
   IKEv2", 2004-09-10.  Yoav Nir's mail "Re: New I-D: IKEv2
   Clarifications and Implementation Guidelines", 2005-02-07.
   "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
   April 2005.)

6.5.  INTERNAL_IP4_NETMASK

   Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says
   that "The internal network's netmask.  Only one netmask is allowed in
   the request and reply messages (e.g., 255.255.255.0) and it MUST be
   used only with an INTERNAL_IP4_ADDRESS attribute".

   However, it is not clear what exactly this attribute means, as the
   concept of "netmask" is not very well defined for point-to-point
   links (unlike multi-access links, where it means "you can reach hosts
   inside this netmask directly using layer 2, instead of sending
   packets via a router").  Even if the operating system's TCP/IP stack
   requires a netmask to be configured, for point-to-point links it
   could be just set to 255.255.255.255.  So, why is this information
   sent in IKEv2?

   One possible interpretation would be that the host is given a whole
   block of IP addresses instead of a single address.  This is also what
   Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
   does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
   IPv6-Prefix attribute does in [RADIUS6].  However, nothing in the
   specification supports this interpretation, and discussions on the
   IPsec WG mailing list have confirmed it was not intended.  Section
   3.15.1 also says that multiple addresses are assigned using multiple
   INTERNAL_IP4/6_ADDRESS attributes.

   Currently, this document's interpretation is the following:
   INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
   INTERNAL_IP4_SUBNET containing the same information ("send traffic to
   these addresses through me"), but also implies a link boundary.  For
   instance, the client could use its own address and the netmask to
   calculate the broadcast address of the link.  (Whether the gateway
   will actually deliver broadcast packets to other VPN clients and/or
   other nodes connected to this link is another matter.)



Eronen & Hoffman         Expires April 27, 2006                [Page 34]

Internet-Draft            IKEv2 Clarifications              October 2005


   An empty INTERNAL_IP4_NETMASK attribute can be included in a
   CFG_REQUEST to request this information (although the gateway can
   send the information even when not requested).  However, it seems
   that non-empty values for this attribute do not make sense in
   CFG_REQUESTs.

   Fortunately, Section 4 clearly says that a minimal implementation
   does not need to include or understand the INTERNAL_IP4_NETMASK
   attribute, and thus this document recommends that implementations
   should not use the INTERNAL_IP4_NETMASK attribute or assume that the
   other peer supports it.

   (References: Charlie Kaufman's mail "RE: Proposed Last Call based
   revisions to IKEv2", 2004-05-27.  Email discussion with Tero Kivinen,
   Jan 2005.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
   Implementation Guidelines", 2005-02-07.  "Clarifications open issue:
   INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)

6.6.  Configuration payloads for IPv6

   IKEv2 also defines configuration payloads for IPv6.  However, they
   are based on the corresponding IPv4 payloads, and do not fully follow
   the "normal IPv6 way of doing things".

   A client can be assigned an IPv6 address using the
   INTERNAL_IP6_ADDRESS configuration payload.  A minimal exchange could
   look like this:

        CP(CFG_REQUEST) =
          INTERNAL_IP6_ADDRESS()
          INTERNAL_IP6_DNS()
        TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
        TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

        CP(CFG_REPLY) =
          INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
          INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
        TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
        TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

   In particular, IPv6 stateless autoconfiguration or router
   advertisement messages are not used; neither is neighbor discovery.

   The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
   in the CFG_REQUEST to request a specific address or interface
   identifier.  The gateway first checks if the specified address is
   acceptable, and if it is, returns that one.  If the address was not
   acceptable, the gateway will attempt to use the interface identifier



Eronen & Hoffman         Expires April 27, 2006                [Page 35]

Internet-Draft            IKEv2 Clarifications              October 2005


   with some other prefix; if even that fails, the gateway will select
   another interface identifier.

   The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
   field.  When used in a CFG_REPLY, this corresponds to the
   INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
   called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
   See the previous section for more details.

   While this approach to configuring IPv6 addresses is reasonably
   simple, it has some limitations: IPsec tunnels configured using IKEv2
   are not fully-featured "interfaces" in the IPv6 addressing
   architecture [IPv6Addr] sense.  In particular, they do not
   necessarily have link-local addresses, and this may complicate the
   use of protocols that assume them, such as [MLDv2].  (Whether they
   are called "interfaces" in some particular operating system is a
   different issue.)

   (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
   "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
   April 2005.)

6.7.  INTERNAL_IP6_NBNS

   Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
   the IPv6 address of NetBIOS name servers.

   However, NetBIOS is not defined for IPv6, and probably never will be.
   Thus, this attribute most likely does not make much sense.

   (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
   BoF at IETF62.)

6.8.  INTERNAL_ADDRESS_EXPIRY

   Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
   "Specifies the number of seconds that the host can use the internal
   IP address.  The host MUST renew the IP address before this expiry
   time.  Only one of these attributes MAY be present in the reply."

   Expiry times and explicit renewals are primarily useful in
   environments like DHCP, where the server cannot reliably know when
   the client has gone away.  However, in IKEv2 this is known, and the
   gateway can simply free the address when the IKE_SA is deleted.

   Also, Section 4 says that supporting renewals is not mandatory.
   Given that this functionality is usually not needed, we recommend
   that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.



Eronen & Hoffman         Expires April 27, 2006                [Page 36]

Internet-Draft            IKEv2 Clarifications              October 2005


   (And since this attribute does not seem to make much sense for
   CFG_REQUESTs, clients should not send it either.)

   Note that according to Section 4, clients are required to understand
   INTERNAL_ADDRESS_EXPIRY if the receive it.  A minimum implementation
   would use the value to limit the lifetime of the IKE_SA.

   (References: Tero Kivinen's mail "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
   "Questions about internal address" thread, April 2005.)

6.9.  Address assignment failures

   If the responder encounters an error while attempting to assign an IP
   address to the initiator, it responds with an
   INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
   However, there are some more complex error cases.

   First, if the responder does not support configuration payloads at
   all, it can simply ignore all configuration payloads.  This type of
   implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
   If the initiator requires the assignment of an IP address, it will
   treat a response without CFG_REPLY as an error.

   A second case is where the responder does support configuration
   payloads, but only for particular type of addresses (IPv4 or IPv6).
   Section 4 says that "A minimal IPv4 responder implementation will
   ignore the contents of the CP payload except to determine that it
   includes an INTERNAL_IP4_ADDRESS attribute".  If, for instance, the
   initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
   in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
   IPv6 part and process the IPv4 request as usual.

   A third case is where the initiator requests multiple addresses of a
   type that the responder supports: what should happen if some (but not
   all) of the requests fail?  It seems that an optimistic approach
   would be the best one here: if the responder is able to assign at
   least one address, it replies with those; it sends
   INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.

   (References: "ikev2 and internal_ivpn_address" thread, June 2005.)


7.  Miscellaneous issues

7.1.  Matching ID_IPV4_ADDR and ID_IPV6_ADDR

   When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr



Eronen & Hoffman         Expires April 27, 2006                [Page 37]

Internet-Draft            IKEv2 Clarifications              October 2005


   payloads, IKEv2 does not require this address to match the address in
   the IP header (of IKEv2 packets), or anything in the TSi/TSr
   payloads.  The contents of IDi/IDr is used purely to fetch the policy
   and authentication data related to the other party.

   (References: "Identities types IP address,FQDN/user FQDN and DN and
   its usage in preshared key authentication" thread, Jan 2005.)

7.2.  Relationship of IKEv2 to RFC2401bis

   The IKEv2 specification refers to [RFC2401bis], but it never makes
   clear what the exact relationship is.

   However, there are some requirements in the specification that make
   it clear that IKEv2 requires [RFC2401bis].  In other words, an
   implementation that does IPsec processing strictly according to
   [RFC2401] cannot be compliant with the IKEv2 specification.

   One such example can be found in Section 2.24: "Specifically, tunnel
   encapsulators and decapsulators for all tunnel-mode Security
   Associations (SAs) created by IKEv2 [...]  MUST implement the tunnel
   encapsulation and decapsulation processing specified in [RFC2401bis]
   to prevent discarding of ECN congestion indications."

   Nevertheless, the changes required to existing [RFC2401]
   implementations are not very large, especially since supporting many
   of the new features (such as Extended Sequence Numbers) is optional.

7.3.  Reducing the window size

   In IKEv2, the window size is assumed to be a (possibly configurable)
   property of a particular implementation, and is not related to
   congestion control (unlike the window size in TCP, for instance).

   In particular, it is not defined what the responder should do when it
   receives a SET_WINDOW_SIZE notification containing a smaller value
   than is currently in effect.  Thus, there is currently no way to
   reduce the window size of an existing IKE_SA.  However, when rekeying
   an IKE_SA, the new IKE_SA starts with window size 1 until it is
   explicitly increased by sending a new SET_WINDOW_SIZE notification.

   (References: Tero Kivinen's mail "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)

7.4.  Minimum size of nonces

   Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
   MUST be at least 128 bits in size, and MUST be at least half the key



Eronen & Hoffman         Expires April 27, 2006                [Page 38]

Internet-Draft            IKEv2 Clarifications              October 2005


   size of the negotiated prf."

   However, the initiator chooses the nonce before the outcome of the
   negotiation is known.  In this case, the nonce has to be long enough
   for all the PRFs being proposed.

7.5.  Initial zero octets on port 4500

   It is not clear whether a peer sending an IKE_SA_INIT request on port
   4500 should include the initial four zero octets.  Section 2.23 talks
   about how to upgrade to tunneling over port 4500 after message 2, but
   it does not say what to do if message 1 is sent on port 4500.

       IKE MUST listen on port 4500 as well as port 500.

       [...]

       The IKE initiator MUST check these payloads if present and if
       they do not match the addresses in the outer packet MUST tunnel
       all future IKE and ESP packets associated with this IKE_SA over
       UDP port 4500.

       To tunnel IKE packets over UDP port 4500, the IKE header has four
       octets of zero prepended and the result immediately follows the
       UDP header. [...]

   The very beginning of Section 2 says "... though IKE messages may
   also be received on UDP port 4500 with a slightly different format
   (see section 2.23)."

   That "slightly different format" is only described in discussing what
   to do after changing to port 4500.  However, [RFC3948] shows clearly
   the format has the initial zeros even for initiators on port 4500.
   Furthermore, without the initial zeros, the processing engine cannot
   determine whether the packet is an IKE packet or an ESP packet.

   Thus, all packets sent on port 4500 need the four zero prefix;
   otherwise, the receiver won't know how to handle them.

7.6.  Destination port for NAT traversal

   Section 2.23 says that "an IPsec endpoint that discovers a NAT
   between it and its correspondent MUST send all subsequent traffic to
   and from port 4500".

   This sentence is misleading.  The peer "outside" the NAT uses source
   port 4500 for the traffic it sends, but the destination port is, of
   course, taken from packets sent by the peer behind the NAT.  This



Eronen & Hoffman         Expires April 27, 2006                [Page 39]

Internet-Draft            IKEv2 Clarifications              October 2005


   port number is usually dynamically allocated by the NAT.

7.7.  SPI values for messages outside of an IKE_SA

   The IKEv2 specification is not quite clear what SPI values should be
   used in the IKE header for the small number of notifications that are
   allowed to be sent outside of an IKE_SA.  Note that such
   notifications are explicitly *not* Informational exchanges; Section
   1.5 makes it clear that these are one-way messages that must not be
   responded to.

   There are two cases when such a one-way notification can be sent:
   INVALID_IKE_SPI and INVALID_SPI.

   In case of INVALID_IKE_SPI, the message sent is a response message,
   and Section 2.21 says that "If a response is sent, the response MUST
   be sent to the IP address and port from whence it came with the same
   IKE SPIs and the Message ID copied."

   In case of INVALID_SPI, however, there are no IKE SPI values that
   would be meaningful to the recipient of such a notification.  Also,
   the message sent is now an INFORMATIONAL request.  A strict
   interpretation of the specification would require the sender to
   invent garbage values for the SPI fields.  However, we think this was
   not the intention, and using zero values is acceptable.

   (References: "INVALID_IKE_SPI" thread, June 2005.)

7.8.  Protocol ID/SPI fields in Notify payloads

   Section 3.10 says that the Protocol ID field in Notify payloads "For
   notifications which do not relate to an existing SA, this field MUST
   be sent as zero and MUST be ignored on receipt".  However, the
   specification does not clearly say which notifications are related to
   existing SAs and which are not.

   Since the main purpose of the Protocol ID field is to specify the
   type of the SPI, our interpretation is that the Protocol ID field
   should be non-zero only when the SPI field is non-empty.

   There are currently only two notifications where this is the case:
   INVALID_SELECTORS and REKEY_SA.

7.9.  Which message should contain INITIAL_CONTACT

   The description of the INITIAL_CONTACT notification in Section 3.10.1
   says that "This notification asserts that this IKE_SA is the only
   IKE_SA currently active between the authenticated identities".



Eronen & Hoffman         Expires April 27, 2006                [Page 40]

Internet-Draft            IKEv2 Clarifications              October 2005


   However, neither Section 2.4 nor 3.10.1 says in which message this
   payload should be placed.

   The general agreement is that INITIAL_CONTACT is best communicated in
   the first IKE_AUTH request, not as a separate exchange afterwards.

   (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
   April 2005.  "Initial Contact messages" thread, December 2004.
   "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)

7.10.  Alignment of payloads

   Many IKEv2 payloads contain fields marked as "RESERVED", mostly
   because IKEv1 had them, and partly because they make the pictures
   easier to draw.  In particular, payloads in IKEv2 are not, in
   general, aligned to 4-byte boundaries.  (Note that payloads were not
   aligned to 4-byte boundaries in IKEv1 either.)

   (References: "IKEv2: potential 4-byte alignment problem" thread, June
   2004.)

7.11.  Key length transform attribute

   Section 3.3.5 says that "The only algorithms defined in this document
   that accept attributes are the AES based encryption, integrity, and
   pseudo-random functions, which require a single attribute specifying
   key width."

   This is incorrect.  The AES-based integrity and pseudo-random
   functions defined in [IKEv2] always use a 128-bit key.  In fact,
   there are currently no integrity or PRF algorithms that use the key
   length attribute (and we recommend that they should not be defined in
   the future either).

   For encryption algorithms, the situation is slightly more complex
   since there are three different types of algorithms:

   o  The key length attribute is never used with algorithms that use a
      fixed length key, such as DES and IDEA.

   o  The key length attribute is always included for the currently
      defined AES-based algorithms (CBC, CTR, CCM and GCM).  Omitting
      the key length attribute is not allowed; if the proposal does not
      contain it, the proposal has to be rejected.

   o  For other algorithms, the key length attribute can be included but
      is not mandatory.  These algorithms include, e.g., RC5, CAST and
      BLOWFISH.  If the key length attribute is not included, the



Eronen & Hoffman         Expires April 27, 2006                [Page 41]

Internet-Draft            IKEv2 Clarifications              October 2005


      default value specified in [RFC2451] is used.


8.  Status of the clarifications

   This document is work-in-progress, and it contains both relatively
   stable and finished parts, and other parts that are incomplete or
   even incorrect.  To help the reader in deciding how much weight
   should be given to each clarification, this section contains our
   opinions about which parts we believe to are stable, and which are
   likely to change in future versions.

   Those clarifications believed to be correct and without controversy
   are marked with three asterisks (***); those where the clarification
   is known to be incomplete and/or there is disagreement about what the
   correct interpretation is are marked with one asterisk (*).  The
   clarifications marked with two asterisks (**) are somewhere between
   the extremes.

   2.   Creating the IKE_SA
      2.1  SPI values in IKE_SA_INIT exchange                        ***
      2.2  Message IDs for IKE_SA_INIT messages                      ***
      2.3  Retransmissions of IKE_SA_INIT requests                   ***
      2.4  Interaction of COOKIE and INVALID_KE_PAYLOAD              ***
      2.5  Invalid cookies                                           ***
   3.   Authentication
      3.1  Data included in AUTH payload calculation                 ***
      3.2  Hash function for RSA signatures                          ***
      3.3  Encoding method for RSA signatures                        ***
      3.4  Identification type for EAP                               ***
      3.5  Identity for policy lookups when using EAP                ***
      3.6  EAP authentication and the AUTH payload                   ***
      3.7  Certificate encoding types                                ***
      3.8  Shared key authentication and fixed PRF key size          ***
      3.9  EAP authentication and fixed PRF key size                 ***
      3.10 Matching ID payloads to certificate contents              ***
      3.11 Message IDs for IKE_AUTH messages                         ***
   4.   Creating CHILD_SAs
      4.1  Creating SAs with the CREATE_CHILD_SA exchange            *
      4.2  Creating an IKE_SA without a CHILD_SA                     ***
      4.3  Diffie-Hellman for first CHILD_SA                         ***
      4.4  Extended Sequence Numbers (ESN) transform                 ***
      4.5  Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED              ***
      4.6  Negotiation of NON_FIRST_FRAGMENTS_ALSO                   ***
      4.7  Semantics of complex traffic selector payloads            ***
      4.8  ICMP type/code in traffic selector payloads               ***
      4.9  Mobility header in traffic selector payloads              ***
      4.10 Narrowing the traffic selectors                           ***



Eronen & Hoffman         Expires April 27, 2006                [Page 42]

Internet-Draft            IKEv2 Clarifications              October 2005


      4.11 SINGLE_PAIR_REQUIRED                                      ***
      4.12 Traffic selectors violating own policy                    ***
      4.13 Definition of TSi and TSr                                 ***
      4.14 Port ranges end at 65535                                  ***
   5.   Rekeying and deleting SAs
      5.1  Rekeying SAs with the CREATE_CHILD_SA exchange            *
      5.2  Rekeying the IKE_SA vs. reauthentication                  ***
      5.3  SPIs when rekeying the IKE_SA                             ***
      5.4  SPI when rekeying a CHILD_SA                              ***
      5.5  Changing PRFs when rekeying the IKE_SA                    ***
      5.6  Deleting vs. closing SAs                                  ***
      5.7  Deleting an SA pair                                       ***
      5.8  Deleting an IKE_SA                                        ***
      5.9  Who is the original initiator of IKE_SA                   ***
      5.10 Sending traffic while rekeying                            ***
      5.11 Comparing nonces                                          ***
      5.12 Simultaneous CHILD_SA rekeying                            *
   6.   Configuration payloads
      6.1  Assigning IP addresses                                    ***
      6.2  Length of configuration attribute type field              ***
      6.3  Requesting any INTERNAL_IP4/IP6_ADDRESS                   ***
      6.4  INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET                   ***
      6.5  INTERNAL_IP4_NETMASK                                      **
      6.6  Configuration payloads for IPv6                           **
      6.7  INTERNAL_IP6_NBNS                                         ***
      6.8  INTERNAL_ADDRESS_EXPIRY                                   ***
      6.9  Address assignment failures                               **
   7.   Miscellaneous issues
      7.1  Matching ID_IPV4_ADDR and ID_IPV6_ADDR                    ***
      7.2  Relationship of IKEv2 to RFC2401bis                       ***
      7.3  Reducing the window size                                  ***
      7.4  Minimum size of nonces                                    ***
      7.5  Initial zero octets on port 4500                          ***
      7.6  Destination port for NAT traversal                        ***
      7.7  SPI values for messages outside of an IKE_SA              ***
      7.8  Protocol ID/SPI fields in Notify payloads                 ***
      7.9  Which message should contain INITIAL_CONTACT              ***
      7.10 Alignment of payloads                                     ***
      7.11 Key length transform attribute                            ***

   Future versions of this document will, of course, change these
   estimates (and changes in both directions are possible, though
   hopefully it's more towards higher confidence).


9.  Implementation mistakes

   Some implementers at the first IKEv2 bakeoff didn't do everything



Eronen & Hoffman         Expires April 27, 2006                [Page 43]

Internet-Draft            IKEv2 Clarifications              October 2005


   correctly.  This may seem like an obvious statement, but it is
   probably useful to list a few things that were clear in the document
   and not needing clarification, that some implementors didn't do.  All
   of these things caused interoperability problems.

   o  Some implementations continued to send traffic on a CHILD_SA after
      it was rekeyed, even after receiving an DELETE payload.

   o  After rekeying an IKE_SA, some implementations did not reset their
      message counters to zero.  One set the counter to 2, another did
      not reset the counter at all.

   o  Some implementations could only handle a single pair of traffic
      selectors, or would only process the first pair in the proposal.

   o  Some implementations responded to a delete request by sending an
      empty INFORMATIONAL response, and then initiated their own
      INFORMATIONAL exchange with the pair of SAs to delete.

   o  Although this did not happen at the bakeoff, from the discussion
      there, it is clear that some people had not implemented message
      window sizes correctly.  Some implementations might have sent
      messages that did not fit into the responder's message windows,
      and some implementations may not have torn down an SA if they did
      not ever receive a message that they know they should have.


10.  Open issues

   This section lists issues that this document probably should address,
   but has not done so yet.

   o  Many of the configuration payload issues in this draft are still
      far from clear.  These need to be resolved before implementers can
      feel assured of creating interoperable implementations.

   o  It would be very useful to have actual examples of certificate
      type 12 (hash and URL of X.509 certificates) and type 13 (hash and
      URL of X.509 bundle).

   o  This document might want to explicitly talk about not doing ESP-
      in-AH even though it is possible.  We could say "implementations
      do not need to support this".


11.  Security considerations

   This document does not introduce any new security considerations to



Eronen & Hoffman         Expires April 27, 2006                [Page 44]

Internet-Draft            IKEv2 Clarifications              October 2005


   IKEv2.  If anything, clarifying complex areas of the specification
   can reduce the likelihood of implementation problems that may have
   security implications.


12.  IANA considerations

   This document does not change or create any IANA-registered values.


13.  Acknowledgments

   This document is mainly based on conversations on the IPsec WG
   mailing list.  The authors would especially like to thank Bernard
   Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
   Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero Kivinen, Yoav
   Nir, Michael Richardson, and Joel Snyder for their contributions.

   In addition, the authors would like to thank all the participants of
   the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
   for their questions and proposed clarifications.


14.  References

14.1.  Normative References

   [IKEv2]    Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
              Protocol", draft-ietf-ipsec-ikev2-17 (work in progress),
              September 2004.

   [IKEv2ALG]
              Schiller, J., "Cryptographic Algorithms for use in the
              Internet Key Exchange Version 2",
              draft-ietf-ipsec-ikev2-algorithms-05 (work in progress),
              April 2004.

   [PKCS1v20]
              Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
              Specifications Version 2.0", RFC 2437, October 1998.

   [PKCS1v21]
              Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.



Eronen & Hoffman         Expires April 27, 2006                [Page 45]

Internet-Draft            IKEv2 Clarifications              October 2005


   [RFC2401bis]
              Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
              in progress), March 2005.

14.2.  Informative References

   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [EAPKey]   Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying (work in
              progress), July 2005.

   [IPCPSubnet]
              Cisco Systems, Inc., "IPCP Subnet Mask Support
              Enhancements",  http://www.cisco.com/univercd/cc/td/doc/
              product/software/ios121/121newft/121limit/121dc/121dc3/
              ipcp_msk.htm, January 2003.

   [IPv6Addr]
              Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing  Architecture", RFC 3513, April 2004.

   [MIPv6]    Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [MLDv2]    Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [NAI]      Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [NAIbis]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", draft-ietf-radext-rfc2486bis
              (work in progress), July 2005.

   [RADEAP]   Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RADIUS6]  Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",



Eronen & Hoffman         Expires April 27, 2006                [Page 46]

Internet-Draft            IKEv2 Clarifications              October 2005


              RFC 3162, August 2001.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement  Levels", RFC 2119, March 1997.

   [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
              Algorithms", RFC 2451, November 1998.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC3664]  Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
              Internet Key Exchange Protocol (IKE)", RFC 3664,
              January 2004.

   [RFC3664bis]
              Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
              Internet Key Exchange Protocol (IKE)",
              draft-hoffman-rfc3664bis (work in progress), June 2005.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
              text messages", RFC 822, August 1982.

   [ReAuth]   Nir, Y., "Repeated Authentication in IKEv2",
              draft-nir-ikev2-auth-lt-02 (work in progress), May 2005.

   [SCVP]     Freeman, T., Housley, R., Malpani, A., Cooper, D., and T.
              Polk, "Simple Certificate Validation Protocol (SCVP)",
              draft-ietf-pkix-scvp-18 (work in progress), February 2005.


Appendix A.  Exchanges and payloads

   This appendix contains a short summary of the IKEv2 exchanges, and
   what payloads can appear in which message.  This appendix is purely
   informative; if it disagrees with the body of this document or the
   IKEv2 specification, the other text is considered correct.

   Vendor-ID (V) payloads may be included in any place in any message.
   This sequence shows what are, in our opinion, the most logical places
   for them.

   The specification does not say which messages can contain
   N(SET_WINDOW_SIZE).  It can possibly be included in any message, but



Eronen & Hoffman         Expires April 27, 2006                [Page 47]

Internet-Draft            IKEv2 Clarifications              October 2005


   it is not yet shown below.

A.1.  IKE_SA_INIT exchange

   request             --> [N(COOKIE)],
                           SA, KE, Ni,
                           [N(NAT_DETECTION_SOURCE_IP)+,
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [V+]

   normal response     <-- SA, KE, Nr,
   (no cookie)             [N(NAT_DETECTION_SOURCE_IP),
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [V+]

A.2.  IKE_AUTH exchange without EAP

   request             --> IDi, [CERT+],
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           AUTH,
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+]

   response            <-- IDr, [CERT+],
                           AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+]










Eronen & Hoffman         Expires April 27, 2006                [Page 48]

Internet-Draft            IKEv2 Clarifications              October 2005


A.3.  IKE_AUTH exchange with EAP

   first request       --> IDi,
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+]

   first response      <-- IDr, [CERT+], AUTH,
                           EAP,
                           [V+]

                     / --> EAP
   repeat 1..N times |
                     \ <-- EAP

   last request        --> AUTH

   last response       <-- AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+]


















Eronen & Hoffman         Expires April 27, 2006                [Page 49]

Internet-Draft            IKEv2 Clarifications              October 2005


A.4.  CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs

   request             --> [N(REKEY_SA)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Ni, [KEi], TSi, TSr

   response            <-- [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Nr, [KEr], TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)]

A.5.  CREATE_CHILD_SA exchange for rekeying the IKE_SA

   request             --> SA, Ni, [KEi]

   response            <-- SA, Nr, [KEr]

A.6.  INFORMATIONAL exchange

   request             --> [N+],
                           [D+],
                           [CP(CFG_REQUEST)]

   response            <-- [N+],
                           [D+],
                           [CP(CFG_REPLY)]




















Eronen & Hoffman         Expires April 27, 2006                [Page 50]

Internet-Draft            IKEv2 Clarifications              October 2005


Authors' Addresses

   Pasi Eronen
   Nokia Research Center
   P.O. Box 407
   FIN-00045 Nokia Group
   Finland

   Email: pasi.eronen@nokia.com


   Paul Hoffman
   VPN Consortium
   127 Segre Place
   Santa Cruz, CA 95060
   USA

   Email: paul.hoffman@vpnc.org

































Eronen & Hoffman         Expires April 27, 2006                [Page 51]

Internet-Draft            IKEv2 Clarifications              October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Eronen & Hoffman         Expires April 27, 2006                [Page 52]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/