Network Working Group P. Eronen Internet-Draft Nokia Expires: January 16, 2006 P. Hoffman VPN Consortium July 15, 2005 IKEv2 Clarifications and Implementation Guidelines draft-eronen-ipsec-ikev2-clarifications-04.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 January 16, 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 January 16, 2006 [Page 1] Internet-Draft IKEv2 Clarifications July 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 3. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Data included in AUTH payload calculation . . . . . . . . 7 3.2 Hash function for RSA signatures . . . . . . . . . . . . . 7 3.3 Encoding method for RSA signatures . . . . . . . . . . . . 8 3.4 Identification type for EAP . . . . . . . . . . . . . . . 9 3.5 Identity for policy lookups when using EAP . . . . . . . . 9 3.6 EAP authentication and the AUTH payload . . . . . . . . . 9 3.7 Certificate encoding types . . . . . . . . . . . . . . . . 10 3.8 Shared key authentication and fixed PRF key size . . . . . 10 3.9 EAP authentication and fixed PRF key size . . . . . . . . 11 3.10 Matching ID payloads to certificate contents . . . . . . 11 3.11 Message IDs for IKE_AUTH messages . . . . . . . . . . . 11 4. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . 12 4.1 Creating SAs with the CREATE_CHILD_SA exchange . . . . . . 12 4.2 Creating an IKE_SA without a CHILD_SA . . . . . . . . . . 14 4.3 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 15 4.4 Extended Sequence Numbers (ESN) transform . . . . . . . . 15 4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . . . . 16 4.6 Negotiation of NON_FIRST_FRAGMENTS_ALSO . . . . . . . . . 16 4.7 Semantics of complex traffic selector payloads . . . . . . 16 4.8 ICMP type/code in traffic selector payloads . . . . . . . 17 4.9 Mobility header in traffic selector payloads . . . . . . . 17 4.10 Narrowing the traffic selectors . . . . . . . . . . . . 18 4.11 SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . 18 4.12 Traffic selectors violating own policy . . . . . . . . . 19 4.13 Definition of TSi and TSr . . . . . . . . . . . . . . . 19 4.14 Port ranges end at 65535 . . . . . . . . . . . . . . . . 20 5. Rekeying and deleting SAs . . . . . . . . . . . . . . . . . 20 5.1 Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 20 5.2 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 21 5.3 SPIs when rekeying the IKE_SA . . . . . . . . . . . . . . 22 5.4 SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 22 5.5 Changing PRFs when rekeying the IKE_SA . . . . . . . . . . 22 5.6 Deleting vs. closing SAs . . . . . . . . . . . . . . . . . 23 5.7 Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 23 5.8 Deleting an IKE_SA . . . . . . . . . . . . . . . . . . . . 23 5.9 Who is the original initiator of IKE_SA . . . . . . . . . 24 5.10 Sending traffic while rekeying . . . . . . . . . . . . . 24 6. Configuration payloads . . . . . . . . . . . . . . . . . . . 24 6.1 Assigning IP addresses . . . . . . . . . . . . . . . . . . 24 Eronen & Hoffman Expires January 16, 2006 [Page 2] Internet-Draft IKEv2 Clarifications July 2005 6.2 Length of configuration attribute type field . . . . . . . 25 6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 25 6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 26 6.5 INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 28 6.6 Configuration payloads for IPv6 . . . . . . . . . . . . . 29 6.7 INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . . 30 6.8 INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 31 6.9 INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . . . . 31 7. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . 32 7.1 Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 32 7.2 Relationship of IKEv2 to RFC2401bis . . . . . . . . . . . 32 7.3 Reducing the window size . . . . . . . . . . . . . . . . . 33 7.4 Minimum size of nonces . . . . . . . . . . . . . . . . . . 33 7.5 Initial zero octets on port 4500 . . . . . . . . . . . . . 33 7.6 SPI values for messages outside of an IKE_SA . . . . . . . 34 7.7 Protocol ID/SPI fields in Notify payloads . . . . . . . . 34 7.8 Which message should contain INITIAL_CONTACT . . . . . . . 35 7.9 Alignment of payloads . . . . . . . . . . . . . . . . . . 35 8. Status of the clarifications . . . . . . . . . . . . . . . . 35 9. Implementation mistakes . . . . . . . . . . . . . . . . . . 37 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 38 11. Security considerations . . . . . . . . . . . . . . . . . . 38 12. IANA considerations . . . . . . . . . . . . . . . . . . . . 38 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 38 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.1 Normative References . . . . . . . . . . . . . . . . . . 39 14.2 Informative References . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 A. Exchanges and payloads . . . . . . . . . . . . . . . . . . . 41 A.1 IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 42 A.2 IKE_AUTH exchange without EAP . . . . . . . . . . . . . . 42 A.3 IKE_AUTH exchange with EAP . . . . . . . . . . . . . . . . 43 A.4 CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs . 43 A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA . . . . . 44 A.6 INFORMATIONAL exchange . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . 45 Eronen & Hoffman Expires January 16, 2006 [Page 3] Internet-Draft IKEv2 Clarifications July 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 . 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 January 16, 2006 [Page 4] Internet-Draft IKEv2 Clarifications July 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. 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). 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 Eronen & Hoffman Expires January 16, 2006 [Page 5] Internet-Draft IKEv2 Clarifications July 2005 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. There are basically two different cases, depending on whether the responder checks cookies before the KEi payload or vice versa. If cookies are checked first, the IKE_SA_INIT exchanges will look like this: 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 If the KE payload is checked before cookies, the exchange is slightly shorter: HDR(A,0), 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 If checking both KE payload and cookies at the same time were allowed, it would potentially result in a even shorter exchange: 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 the spec. Section 2.6 clearly says that if the initiator receives a cookie, it "MUST retry the IKE_SA_INIT with a Notify payload of type Eronen & Hoffman Expires January 16, 2006 [Page 6] Internet-Draft IKEv2 Clarifications July 2005 COOKIE containing the responder supplied cookie data as the first payload and all other payloads unchanged." Since "all other payloads" clearly includes the KEi payload as well, selecting a different Diffie-Hellman group for it is not allowed when it occurs together with a cookie. 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. 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. Eronen & Hoffman Expires January 16, 2006 [Page 7] Internet-Draft IKEv2 Clarifications July 2005 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. 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.) Eronen & Hoffman Expires January 16, 2006 [Page 8] Internet-Draft IKEv2 Clarifications July 2005 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 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." Eronen & Hoffman Expires January 16, 2006 [Page 9] Internet-Draft IKEv2 Clarifications July 2005 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. 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, Eronen & Hoffman Expires January 16, 2006 [Page 10] Internet-Draft IKEv2 Clarifications July 2005 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] uses fixed key sizes; that RFC is currently being updated to handle variable key sizes. 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 Eronen & Hoffman Expires January 16, 2006 [Page 11] Internet-Draft IKEv2 Clarifications July 2005 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 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 Eronen & Hoffman Expires January 16, 2006 [Page 12] Internet-Draft IKEv2 Clarifications July 2005 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 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 Eronen & Hoffman Expires January 16, 2006 [Page 13] Internet-Draft IKEv2 Clarifications July 2005 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: 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 It is recommended that the responder set up an IKE_SA even if it is not possible to set up a CHILD_SA, as long as there is agreement on the cryptographic parts of the IKE_SA. This might happen when the parties in the IKE_AUTH exchange agree on cryptographic protocols but fail to agree on IPsec issues. The list of responses in the IKE_AUTH exchange that should not prevent an IKE_SA from being set up include NO_PROPOSAL_CHOSEN, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and TS_UNACCEPTABLE. Eronen & Hoffman Expires January 16, 2006 [Page 14] Internet-Draft IKEv2 Clarifications July 2005 (References: "Questions about internal address" thread, April, 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 January 16, 2006 [Page 15] Internet-Draft IKEv2 Clarifications July 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 January 16, 2006 [Page 16] Internet-Draft IKEv2 Clarifications July 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." This encoding is quite clear. However, as both TSi and TSr are always present, together they have two "start port" fields (one in TSi and one in TSr) and two "end port" fields. Since ICMP messages only have a single type/code field (instead of separate source/ destination ports, like TCP and UDP), there is some room for confusion. One sensible interpretation would be that in case of ICMP, the "start port" fields in TSi and TSr must always be equal, and likewise for the "end port" fields. 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 Eronen & Hoffman Expires January 16, 2006 [Page 17] Internet-Draft IKEv2 Clarifications July 2005 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." (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header message type as selector", 2003-10-14.) 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 Eronen & Hoffman Expires January 16, 2006 [Page 18] Internet-Draft IKEv2 Clarifications July 2005 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. 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' (!=SAi), 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: Eronen & Hoffman Expires January 16, 2006 [Page 19] Internet-Draft IKEv2 Clarifications July 2005 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 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. Eronen & Hoffman Expires January 16, 2006 [Page 20] Internet-Draft IKEv2 Clarifications July 2005 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: 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 Eronen & Hoffman Expires January 16, 2006 [Page 21] Internet-Draft IKEv2 Clarifications July 2005 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 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 Eronen & Hoffman Expires January 16, 2006 [Page 22] Internet-Draft IKEv2 Clarifications July 2005 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. 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 It is not clear that SAs must be actively deleted. The text sometimes says that SAs are "closed" when it means that the SAs are actively deleted. Section 1.4 says "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." It is important to note that SAs that are closed need to be actively deleted with DELETE payloads. 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 or 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. Eronen & Hoffman Expires January 16, 2006 [Page 23] Internet-Draft IKEv2 Clarifications July 2005 (References: "Question about delete IKE SA" thread, May 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...". 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 Eronen & Hoffman Expires January 16, 2006 [Page 24] Internet-Draft IKEv2 Clarifications July 2005 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.) 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)". Eronen & Hoffman Expires January 16, 2006 [Page 25] Internet-Draft IKEv2 Clarifications July 2005 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 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. These two interpretations are not totally incompatible: in both cases, they suggest that traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway (and, of course, the packets have to be sent over some SA whose traffic selectors cover the address in question). Eronen & Hoffman Expires January 16, 2006 [Page 26] Internet-Draft IKEv2 Clarifications July 2005 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 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) Eronen & Hoffman Expires January 16, 2006 [Page 27] Internet-Draft IKEv2 Clarifications July 2005 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. (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.) 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"). Eronen & Hoffman Expires January 16, 2006 [Page 28] Internet-Draft IKEv2 Clarifications July 2005 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] and the IPCP "subnet mask" extension does in PPP [IPCPSubnet]. This interpretation would also work nicely with IPv6 (see the following section). However, one IKEv2 guru assured the authors that this interpretation is not correct. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4_ADDRESS attributes. Currently, this document's interpretation is the following: o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing as INTERNAL_IP4_SUBNET containing the same information (see the previous section for description of INTERNAL_IP4_SUBNET). o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the example in Section 2.19 is incorrect in this sense. (Another interpretation would be that by sending, for instance, the combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and INTERNAL_IP4_NETMASK(255.255.255.0), the client is asking to be assigned one IP address from the network 192.0.2.0/24. However, this interpretation is not supported by the IKEv2 spec.) This interpretation is not yet settled; and it would imply that the whole attribute is totally unnecessary. Yet another possible interpretation would be that INTERNAL_IP4_NETMASK indicates a broadcast address, meaning that if a client sends a packet to this address, the gateway will decrypt it and send copies to all other VPN clients in that address range. However, no implementation is known to do this, and there is nothing in the IKEv2 spec that would support this interpretation. 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 at all. (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.) 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 Eronen & Hoffman Expires January 16, 2006 [Page 29] Internet-Draft IKEv2 Clarifications July 2005 the "normal IPv6 way of doing things". A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. Presumably, the idea was that a minimal exchange would look something 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/?) 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. While this approach 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.) 6.7 INTERNAL_IP6_ADDRESS prefix length Earlier versions of the IKEv2 draft had an INTERNAL_IP6_NETMASK attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted when the prefix length field was added to the INTERNAL_IP6_ADDRESS attribute. Thus, it seems logical to assume that their purpose would be similar; however, this is far from obvious. The draft quite clearly says that the client is assigned an IPv6 address using the INTERNAL_IP6_ADDRESS attribute. However, as with the netmask in IPv4, it is not clear what the prefix length here means. Again, one possible interpretation is that a prefix length smaller than 128 in a CFG_REPLY means that the client is assigned a whole block of IPv6 addresses. This would be in line with the IPv6 Eronen & Hoffman Expires January 16, 2006 [Page 30] Internet-Draft IKEv2 Clarifications July 2005 addressing architecture in general, and with, e.g., the Framed-IPv6- Prefix attribute in [RADIUS6]. However, the previous section rejected this interpretation for IPv4, so it would seem strange to adopt it only for IPv6. Thus, if we assume that INTERNAL_IP4_NETMASK and the prefix length in INTERNAL_IP6_ADDRESS have the same meaning, and the reasoning in the previous section is correct, then a CFG_REPLY containing a prefix length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET. However, CFG_REQUESTs are more complicated. It seems that a CFG_REQUEST message that requests a specific IPv6 address (usually an address this client was using earlier) should have prefix length 128. But what do other prefix lengths mean in CFG_REQUESTs? Section 3.15.1 says that "With IPv6, a requestor MAY supply the low order address bytes it wants to use": presumably the prefix length tells how many low order bits there are (i.e., if the prefix length is X, there requester supplies 128-X low order address bits). However, this is quite confusing: if, say, a prefix length 126 means that "I want to use these 128-126=2 low order bits", why does prefix length 128 mean that "I want to use these 128 low order bits"? Another interpretation is that instead of "low order", the draft should have said "high order", and thus a prefix length smaller than 128 means "I'd like to get an address from this subnet". Given this very confusing discussion, this document recommends that implementations should not use other INTERNAL_IP6_ADDRESS prefix lengths than 128. 6.8 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.9 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." Eronen & Hoffman Expires January 16, 2006 [Page 31] Internet-Draft IKEv2 Clarifications July 2005 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. (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.) 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 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 document refers to [RFC2401bis], but it never makes clear what the exact relationship is. That is probably because there is no exact relationship. However, the IKEv2 document could state this explicitly. Section 2.24 of IKEv2 says "Specifically, tunnel encapsulators and decapsulators for all tunnel-mode Security Associations (SAs) created by IKEv2 MUST support the ECN full-functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC2401bis] to prevent discarding of ECN congestion indications." This, in essence, says that IKEv2 must be used with [RFC2401bis] only, not with RFC 2401, because RFC 2401 has no requirements for ECN. Eronen & Hoffman Expires January 16, 2006 [Page 32] Internet-Draft IKEv2 Clarifications July 2005 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 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 Eronen & Hoffman Expires January 16, 2006 [Page 33] Internet-Draft IKEv2 Clarifications July 2005 (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 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.7 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. Eronen & Hoffman Expires January 16, 2006 [Page 34] Internet-Draft IKEv2 Clarifications July 2005 There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA. 7.8 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". However, neither Section 2.4 nor 3.10.1 says in which message this payload should be placed. The text does talk about authenticated identities, so it seems the notification cannot be sent before both endpoints have been authenticated. Thus, the possible places are the last IKE_AUTH response message and a separate Informational exchange. Based on how this was implemented in IKEv1, it seems the intent was to use a separate Informational exchange. (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.) 7.9 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.) 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 Eronen & Hoffman Expires January 16, 2006 [Page 35] Internet-Draft IKEv2 Clarifications July 2005 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 *** 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 *** 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 ** 6. Configuration payloads 6.1 Assigning IP addresses ** 6.2 Length of configuration attribute type field *** Eronen & Hoffman Expires January 16, 2006 [Page 36] Internet-Draft IKEv2 Clarifications July 2005 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_ADDRESS prefix length * 6.8 INTERNAL_IP6_NBNS *** 6.9 INTERNAL_ADDRESS_EXPIRY ** 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 SPI values for messages outside of an IKE_SA * 7.7 Protocol ID/SPI fields in Notify payloads ** 7.8 Which message should contain INITIAL_CONTACT ** 7.9 Alignment of payloads *** 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 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, Eronen & Hoffman Expires January 16, 2006 [Page 37] Internet-Draft IKEv2 Clarifications July 2005 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 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, Mika Joutsenvirta, Charlie Kaufman, 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 Eronen & Hoffman Expires January 16, 2006 [Page 38] Internet-Draft IKEv2 Clarifications July 2005 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. [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-06 (work in progress), April 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 Eronen & Hoffman Expires January 16, 2006 [Page 39] Internet-Draft IKEv2 Clarifications July 2005 (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-05 (work in progress), February 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", RFC 3162, August 2001. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [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. [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. Eronen & Hoffman Expires January 16, 2006 [Page 40] Internet-Draft IKEv2 Clarifications July 2005 Polk, "Simple Certificate Validation Protocol (SCVP)", draft-ietf-pkix-scvp-18 (work in progress), February 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 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 it is not yet shown below. Note: N(INITIAL_CONTACT) is still under discussion and is not shown below. Eronen & Hoffman Expires January 16, 2006 [Page 41] Internet-Draft IKEv2 Clarifications July 2005 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(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 January 16, 2006 [Page 42] Internet-Draft IKEv2 Clarifications July 2005 A.3 IKE_AUTH exchange with EAP first request --> IDi, [[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+] A.4 CREATE_CHILD_SA exchange for creating/rekeying CHILD_SAs request --> [N(REKEY)], [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)] Eronen & Hoffman Expires January 16, 2006 [Page 43] Internet-Draft IKEv2 Clarifications July 2005 A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA request --> N(REKEY), 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 January 16, 2006 [Page 44] Internet-Draft IKEv2 Clarifications July 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 January 16, 2006 [Page 45]