diff options
Diffstat (limited to 'doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt')
| -rw-r--r-- | doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt | 3250 |
1 files changed, 0 insertions, 3250 deletions
diff --git a/doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt b/doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt deleted file mode 100644 index 00f50dc31..000000000 --- a/doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt +++ /dev/null @@ -1,3250 +0,0 @@ - - - - -Network Working Group P. Eronen -Internet-Draft Nokia -Intended status: Informational P. Hoffman -Expires: November 5, 2006 VPN Consortium - May 4, 2006 - - - IKEv2 Clarifications and Implementation Guidelines - draft-eronen-ipsec-ikev2-clarifications-09.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 November 5, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -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 November 5, 2006 [Page 1] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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. Certificate encoding types . . . . . . . . . . . . . . . . 11 - 3.7. Shared key authentication and fixed PRF key size . . . . . 12 - 3.8. EAP authentication and fixed PRF key size . . . . . . . . 13 - 3.9. Matching ID payloads to certificate contents . . . . . . . 13 - 3.10. Message IDs for IKE_AUTH messages . . . . . . . . . . . . 13 - 4. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1. Creating SAs with the CREATE_CHILD_SA exchange . . . . . . 13 - 4.2. Creating an IKE_SA without a CHILD_SA . . . . . . . . . . 16 - 4.3. Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 16 - 4.4. Extended Sequence Numbers (ESN) transform . . . . . . . . 16 - 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED . . . . . . . 17 - 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO . . . . . . . . . 17 - 4.7. Semantics of complex traffic selector payloads . . . . . . 18 - 4.8. ICMP type/code in traffic selector payloads . . . . . . . 18 - 4.9. Mobility header in traffic selector payloads . . . . . . . 19 - 4.10. Narrowing the traffic selectors . . . . . . . . . . . . . 20 - 4.11. SINGLE_PAIR_REQUIRED . . . . . . . . . . . . . . . . . . . 20 - 4.12. Traffic selectors violating own policy . . . . . . . . . . 21 - 4.13. Traffic selector authorization . . . . . . . . . . . . . . 21 - 5. Rekeying and deleting SAs . . . . . . . . . . . . . . . . . . 22 - 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 . . . . . . . . . . . . . . . . . 25 - 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 . . . . . . . . . 26 - 5.10. Comparing nonces . . . . . . . . . . . . . . . . . . . . . 27 - 5.11. Exchange collisions . . . . . . . . . . . . . . . . . . . 27 - 5.12. Diffie-Hellman and rekeying the IKE_SA . . . . . . . . . . 36 - 6. Configuration payloads . . . . . . . . . . . . . . . . . . . . 36 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 2] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 6.1. Assigning IP addresses . . . . . . . . . . . . . . . . . . 36 - 6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 37 - 6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 38 - 6.4. INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 40 - 6.5. Configuration payloads for IPv6 . . . . . . . . . . . . . 41 - 6.6. INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 43 - 6.7. INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . . . . 43 - 6.8. Address assignment failures . . . . . . . . . . . . . . . 43 - 7. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . . 44 - 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 44 - 7.2. Relationship of IKEv2 to RFC4301 . . . . . . . . . . . . . 44 - 7.3. Reducing the window size . . . . . . . . . . . . . . . . . 45 - 7.4. Minimum size of nonces . . . . . . . . . . . . . . . . . . 45 - 7.5. Initial zero octets on port 4500 . . . . . . . . . . . . . 45 - 7.6. Destination port for NAT traversal . . . . . . . . . . . . 46 - 7.7. SPI values for messages outside of an IKE_SA . . . . . . . 46 - 7.8. Protocol ID/SPI fields in Notify payloads . . . . . . . . 47 - 7.9. Which message should contain INITIAL_CONTACT . . . . . . . 47 - 7.10. Alignment of payloads . . . . . . . . . . . . . . . . . . 47 - 7.11. Key length transform attribute . . . . . . . . . . . . . . 48 - 7.12. IPsec IANA considerations . . . . . . . . . . . . . . . . 48 - 7.13. Combining ESP and AH . . . . . . . . . . . . . . . . . . . 49 - 8. Implementation mistakes . . . . . . . . . . . . . . . . . . . 49 - 9. Security considerations . . . . . . . . . . . . . . . . . . . 50 - 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 50 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 50 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 51 - Appendix A. Exchanges and payloads . . . . . . . . . . . . . . . 53 - A.1. IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 53 - A.2. IKE_AUTH exchange without EAP . . . . . . . . . . . . . . 54 - A.3. IKE_AUTH exchange with EAP . . . . . . . . . . . . . . . . 55 - A.4. CREATE_CHILD_SA exchange for creating/rekeying - CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 56 - A.5. CREATE_CHILD_SA exchange for rekeying the IKE_SA . . . . . 56 - A.6. INFORMATIONAL exchange . . . . . . . . . . . . . . . . . . 56 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . . . 58 - - - - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 3] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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. - - 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 or threads 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. - - 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. - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 4] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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). - - 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 5] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 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 November 5, 2006 [Page 6] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - functionality. 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 the shorter exchange. - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 7] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 November 5, 2006 [Page 8] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 peer supports something else. - - Note that hash function collision attacks are not important for the - AUTH payloads, since they are not intended for third-party - verification, and the data includes fresh nonces. See [HashUse] for - more discussion about hash function attacks and IPsec. - - Another reasonable choice would be to use the hash function that was - - - -Eronen & Hoffman Expires November 5, 2006 [Page 9] - -Internet-Draft IKEv2 Clarifications May 2006 - - - used by the CA when signing the peer certificate. However, this does - not guarantee that the IKEv2 peer would be able to validate the AUTH - payload, because the same code might not be used to validate - certificate signatures and IKEv2 message signatures, and these two - routines may support a different set of hash algorithms. The peer - could be configured with a fingerprint of the certificate, or - certificate validation could be performed by an external entity using - [SCVP]. Furthermore, not all CERT payloads types include a - signature, and the certificate could be signed with some algorithm - other than RSA. - - 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 at least - determine which hash function was used. - - (References: Magnus Nystrom's mail "RE:", 2005-01-03. Pasi Eronen's - reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft - of IKEv2.1" thread, Dec 2005/Jan 2006.) - -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 PKCS#1 specification [PKCS1v21] defines two different encoding - methods (ways of "padding the hash") for signatures. However, the - Internet-Draft approved by the IESG had a reference 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]. Although NAIs look a bit like email - addresses (e.g., "joe@example.com"), the syntax is not exactly the - - - -Eronen & Hoffman Expires November 5, 2006 [Page 10] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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. 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 November 5, 2006 [Page 11] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - - 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.7. 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_XCBC [RFC3664] originally used fixed key - sizes; that RFC has been updated to handle variable key sizes in - [RFC3664bis]. - - 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 12] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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.8. 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.9. 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. The PKI4IPsec Working Group - produced the document [PKI4IPsec] which covers this topic in much - more detail. However, Section 3.5 of [IKEv2] explicitly says that - the ID payload "does not necessarily have to match anything in the - CERT payload". - -3.10. 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 has 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 13] - -Internet-Draft IKEv2 Clarifications May 2006 - - - with subsections for each use of the CREATE_CHILD_SA exchange - (creating child SAs, rekeying IKE SAs, and rekeying child SAs.) - - The new Section 1.3 with subsections and the above changes might look - like the following. - - 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 - 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 include an Encrypted Payload, even if they are referred - to in the text as "empty". - - 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 or IKE_SA. The - keying material for the 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). The details are described in sections 2.17 and 2.18. - - 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 14] - -Internet-Draft IKEv2 Clarifications May 2006 - - - (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: - - 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. The request can also - contain Notify payloads that specify additional details for the - CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, - ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO. - - The CREATE_CHILD_SA response for creating a new CHILD_SA is: - - <-- HDR, SK {[N+], SA, Nr, - [KEr], TSi, TSr} - - The responder replies 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. As with the request, optional Notification - payloads can specify additional details for the CHILD_SA. - - 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. - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 15] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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.) - -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. The ESN transform 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). - - - -Eronen & Hoffman Expires November 5, 2006 [Page 16] - -Internet-Draft IKEv2 Clarifications May 2006 - - - Note that including the ESN transform is mandatory when creating - ESP/AH SAs (it was optional in earlier drafts of the IKEv2 - specification). - - (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.) - -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 [RFC4301] for - explanation." - - [RFC4301] 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. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 17] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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. - - 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 [RFC4301] Section - - - -Eronen & Hoffman Expires November 5, 2006 [Page 18] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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: - - 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 - created 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) } - - (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, [RFC4301] 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, - - - -Eronen & Hoffman Expires November 5, 2006 [Page 19] - -Internet-Draft IKEv2 Clarifications May 2006 - - - and are described in the previous section. - - (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 November 5, 2006 [Page 20] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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 encrypted using 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. Traffic selector authorization - - IKEv2 relies on information in the Peer Authorization Database (PAD) - when determining what kind of IPsec SAs a peer is allowed to create. - This process is described in [RFC4301] Section 4.4.3. When a peer - requests the creation of an IPsec SA with some traffic selectors, the - PAD must contain "Child SA Authorization Data" linking the identity - authenticated by IKEv2 and the addresses permitted for traffic - selectors. - - For example, the PAD might be configured so that authenticated - identity "sgw23.example.com" is allowed to create IPsec SAs for - - - -Eronen & Hoffman Expires November 5, 2006 [Page 21] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 192.0.2.0/24, meaning this security gateway is a valid - "representative" for these addresses. Host-to-host IPsec requires - similar entries, linking, for example, "fooserver4.example.com" with - 192.0.1.66/32, meaning this identity a valid "owner" or - "representative" of the address in question. - - As noted in [RFC4301], "It is necessary to impose these constraints - on creation of child SAs to prevent an authenticated peer from - spoofing IDs associated with other, legitimate peers." In the - example given above, a correct configuration of the PAD prevents - sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents - fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. - - It is important to note that simply sending IKEv2 packets using some - particular address does not imply a permission to create IPsec SAs - with that address in the traffic selectors. For example, even if - sgw23 would be able to spoof its IP address as 192.0.1.66, it could - not create IPsec SAs matching fooserver4's traffic. - - The IKEv2 specification does not specify how exactly IP address - assignment using configuration payloads interacts with the PAD. Our - interpretation is that when a security gateway assigns an address - using configuration payloads, it also creates a temporary PAD entry - linking the authenticated peer identity and the newly allocated inner - address. - - It has been recognized that configuring the PAD correctly may be - difficult in some environments. For instance, if IPsec is used - between a pair of hosts whose addresses are allocated dynamically - using DHCP, it is extremely difficult to ensure that the PAD - specifies the correct "owner" for each IP address. This would - require a mechanism to securely convey address assignments from the - DHCP server, and link them to identities authenticated using IKEv2. - - Due to this limitation, some vendors have been known to configure - their PADs to allow an authenticated peer to create IPsec SAs with - traffic selectors containing the same address that was used for the - IKEv2 packets. In environments where IP spoofing is possible (i.e., - almost everywhere) this essentially allows any peer to create IPsec - SAs with any traffic selectors. This is not an appropriate or secure - configuration in most circumstances. See [Aura05] for an extensive - discussion about this issue, and the limitations of host-to-host - IPsec in general. - - -5. Rekeying and deleting SAs - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 22] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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 optionally a Diffie-Hellman value in the KEi - payload. - - 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, a nonce in the Nr - payload, and, optionally, a Diffie-Hellman value in the KEr - payload. - - 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. The new initiator and responder SPIs are - supplied in the SPI fields of the SA payloads. - - 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(REKEY_SA), [N+], SA, - Ni, [KEi], TSi, TSr} --> - - The leading Notify payload of type REKEY_SA identifies the - CHILD_SA being rekeyed, and contains the SPI that the initiator - expects in the headers of inbound packets. In addition, 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 in the TSi and TSr payloads. - The request can also contain Notify payloads that specify - additional details for the CHILD_SA. - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 23] - -Internet-Draft IKEv2 Clarifications May 2006 - - - The CREATE_CHILD_SA response for rekeying a CHILD_SA is: - - <-- HDR, SK {[N+], SA, Nr, - [KEr], TSi, TSr} - - The responder replies 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 - 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.) - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 24] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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. - - 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 25] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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.) - -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 "original responder" - starts rekeying the IKE_SA, that party becomes the "original - - - -Eronen & Hoffman Expires November 5, 2006 [Page 26] - -Internet-Draft IKEv2 Clarifications May 2006 - - - initiator" of the new IKE_SA. - - (References: Paul Hoffman's mail "Original initiator in IKEv2", 2005- - 04-21.) - -5.10. 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.) - -5.11. Exchange collisions - - Since IKEv2 exchanges can be initiated by both peers, it is possible - that two exchanges affecting the same SA partly overlap. This can - lead to a situation where the SA state information is temporarily not - synchronized, and a peer can receive a request it cannot process in a - normal fashion. Some of these corner cases are discussed in the - specification, some are not. - - Obviously, using a window size greater than one leads to infinitely - more complex situations, especially if requests are processed out of - order. In this section, we concentrate on problems that can arise - even with window size 1. - - (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/ - Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.) - -5.11.1. Simultaneous CHILD_SA close - - Probably the simplest case happens if both peers decide to close the - same CHILD_SA pair at the same time: - - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 27] - -Internet-Draft IKEv2 Clarifications May 2006 - - - Host A Host B - -------- -------- - send req1: D(SPIa) --> - <-- send req2: D(SPIb) - --> recv req1 - <-- send resp1: () - recv resp1 - recv req2 - send resp2: () --> - --> recv resp2 - - This case is described in Section 1.4, and is handled by omitting the - Delete payloads from the response messages. - -5.11.2. Simultaneous IKE_SA close - - Both peers can also decide to close the IKE_SA at the same time. The - desired end result is obvious; however, in certain cases the final - exchanges may not be fully completed. - - Host A Host B - -------- -------- - send req1: D() --> - <-- send req2: D() - --> recv req1 - - At this point, host B should reply as usual (with empty Informational - response), close the IKE_SA, and stop retransmitting req2. This is - because once host A receives resp1, it may not be able to reply any - longer. The situation is symmetric, so host A should behave the same - way. - - Host A Host B - -------- -------- - <-- send resp1: () - send resp2: () - - Even if neither resp1 nor resp2 ever arrives, the end result is still - correct: the IKE_SA is gone. The same happens if host A never - receives req2. - -5.11.3. Simultaneous CHILD_SA rekeying - - Another case that is described in the specification is simultaneous - rekeying. Section 2.8 says - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 28] - -Internet-Draft IKEv2 Clarifications May 2006 - - - "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. Similarly - as host A, it has to respond 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 - 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. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 29] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 <-- - - When A receives this error, it already knows there was simultaneous - rekeying, so it can ignore the error message. - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 30] - -Internet-Draft IKEv2 Clarifications May 2006 - - -5.11.4. Simultaneous IKE_SA rekeying - - Probably the most complex case occurs when both peers try to rekey - the IKE_SA at the same time. Basically, the text in Section 2.8 - applies to this case as well; however, it is important to ensure that - the CHILD_SAs are inherited by the right IKE_SA. - - The case where both endpoints notice the simultaneous rekeying works - the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges, - three IKE_SAs exist between A and B; the one containing the lowest - nonce inherits the CHILD_SAs. - - However, there is a twist to the other case where one rekeying - finishes first: - - Host A Host B - -------- -------- - send req1: - SA(..,SPIa1,..),Ni1,.. --> - <-- send req2: SA(..,SPIb1,..),Ni2,.. - --> recv req1 - <-- send resp1: SA(..,SPIb2,..),Nr2,.. - recv resp1 <-- - send req3: D() --> - --> recv req3 - - At this point, host B sees a request to close the IKE_SA. There's - not much more to do than to reply as usual. However, at this point - host B should stop retransmitting req2, since once host A receives - resp3, it will delete all the state associated with the old IKE_SA, - and will not be able to reply to it. - - <-- send resp3: () - -5.11.5. Closing and rekeying a CHILD_SA - - A case similar to simultaneous rekeying can occur if one peer decides - to close an SA and the other peer tries to rekey it: - - Host A Host B - -------- -------- - send req1: D(SPIa) --> - <-- send req2: N(REKEY_SA,SPIb),SA,.. - --> recv req1 - - At this point, host B notices that host A is trying to close an SA - that host B is currently rekeying. Replying as usual is probably the - best choice: - - - -Eronen & Hoffman Expires November 5, 2006 [Page 31] - -Internet-Draft IKEv2 Clarifications May 2006 - - - <-- send resp1: D(SPIb) - - Depending on in which order req2 and resp1 arrive, host A sees either - a request to rekey an SA that it is currently closing, or a request - to rekey an SA that does not exist. In both cases, - NO_PROPOSAL_CHOSEN is probably fine. - - recv req2 - recv resp1 - send resp2: N(NO_PROPOSAL_CHOSEN) --> - --> recv resp2 - -5.11.6. Closing a new CHILD_SA - - Yet another case occurs when host A creates a CHILD_SA pair, but soon - thereafter host B decides to delete it (possible because its policy - changed): - - Host A Host B - -------- -------- - send req1: [N(REKEY_SA,SPIa1)], - SA(..,SPIa2,..),.. --> - --> recv req1 - (lost) <-- send resp1: SA(..,SPIb2,..),.. - - <-- send req2: D(SPIb2) - recv req2 - - At this point, host A has not yet received message resp1 (and is - retransmitting message req1), so it does not recognize SPIb in - message req2. What should host A do? - - One option would be to reply with an empty Informational response. - However, this same reply would also be sent if host A has received - resp1, but has already sent a new request to delete the SA that was - just created. This would lead to a situation where the peers are no - longer in sync about which SAs exist between them. However, host B - would eventually notice that the other half of the CHILD_SA pair has - not been deleted. Section 1.4 describes this case and notes that "a - node SHOULD regard half-closed connections as anomalous and audit - their existence should they persist", and continues that "if - connection state becomes sufficiently messed up, a node MAY close the - IKE_SA". - - Another solution that has been proposed is to reply with an - INVALID_SPI notification which contains SPIb. This would explicitly - tell host B that the SA was not deleted, so host B could try deleting - it again later. However, this usage is not part of the IKEv2 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 32] - -Internet-Draft IKEv2 Clarifications May 2006 - - - specification, and would not be in line with normal use of the - INVALID_SPI notification where the data field contains the SPI the - recipient of the notification would put in outbound packets. - - Yet another solution would be to ignore req2 at this time, and wait - until we have received resp1. However, this alternative has not been - fully analyzed at this time; in general, ignoring valid requests is - always a bit dangerous, because both endpoints could do it, leading - to a deadlock. - - This document recommends the first alternative. - -5.11.7. Rekeying a new CHILD_SA - - Yet another case occurs when a CHILD_SA is rekeyed soon after it has - been created: - - Host A Host B - -------- -------- - send req1: [N(REKEY_SA,SPIa1)], - SA(..,SPIa2,..),.. --> - (lost) <-- send resp1: SA(..,SPIb2,..),.. - - <-- send req2: N(REKEY_SA,SPIb2), - SA(..,SPIb3,..),.. - recv req2 <-- - - To host A, this looks like a request to rekey an SA that does not - exist. Like in the simultaneous rekeying case, replying with - NO_PROPOSAL_CHOSEN is probably reasonable: - - send resp2: N(NO_PROPOSAL_CHOSEN) --> - recv resp1 - -5.11.8. Collisions with IKE_SA rekeying - - Another set of cases occur when one peer starts rekeying the IKE_SA - at the same time the other peer starts creating, rekeying, or closing - a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon - after, host A starts rekeying the IKE_SA: - - Host A Host B - -------- -------- - <-- send req1: SA,Ni1,TSi,TSr - send req2: SA,Ni2,.. --> - --> recv req2 - - What should host B do at this point? Replying as usual would seem - - - -Eronen & Hoffman Expires November 5, 2006 [Page 33] - -Internet-Draft IKEv2 Clarifications May 2006 - - - like a reasonable choice: - - <-- send resp2: SA,Ni2,.. - recv resp2 <-- - send req3: D() --> - --> recv req3 - - Now, a problem arises: If host B now replies normally with an empty - Informational response, this will cause host A to delete state - associated with the IKE_SA. This means host B should stop - retransmitting req1. However, host B cannot know whether or not host - A has received req1. If host A did receive it, it will move the - CHILD_SA to the new IKE_SA as usual, and the state information will - then be out of sync. - - It seems this situation is tricky to handle correctly. Our proposal - is as follows: if a host receives a request to rekey the IKE_SA when - it has CHILD_SAs in "half-open" state (currently being created or - rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host - receives a request to create or rekey a CHILD_SA after it has started - rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS. - - The case where CHILD_SAs are being closed is even worse. Our - recommendation is that if a host receives a request to rekey the - IKE_SA when it has CHILD_SAs in "half-closed" state (currently being - closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host - receives a request to close a CHILD_SA after it has started rekeying - the IKE_SA, it should reply with an empty Informational response. - This ensures that at least the other peer will eventually notice that - the CHILD_SA is still in "half-closed" state, and will start a new - IKE_SA from scratch. - -5.11.9. Closing and rekeying the IKE_SA - - The final case considered in this section occurs if one peer decides - to close the IKE_SA while the other peer tries to rekey it. - - Host A Host B - -------- -------- - send req1: SA(..,SPIa1,..),Ni1 --> - <-- send req2: D() - --> recv req1 - recv req2 <-- - - At this point, host B should probably reply with NO_PROPOSAL_CHOSEN, - and host A should reply as usual, close the IKE_SA, and stop - retransmitting req1. - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 34] - -Internet-Draft IKEv2 Clarifications May 2006 - - - <-- send resp1: N(NO_PROPOSAL_CHOSEN) - send resp2: () - - If host A wants to continue communication with B, it can now start a - new IKE_SA. - -5.11.10. Summary - - If a host receives a request to rekey: - - o a CHILD_SA pair that the host is currently trying to close: reply - with NO_PROPOSAL_CHOSEN. - - o a CHILD_SA pair that the host is currently rekeying: reply as - usual, but prepare to close redundant SAs later based on the - nonces. - - o a CHILD_SA pair that does not exist: reply with - NO_PROPOSAL_CHOSEN. - - o the IKE_SA, and the host is currently rekeying the IKE_SA: reply - as usual, but prepare to close redundant SAs and move inherited - CHILD_SAs later based on the nonces. - - o the IKE_SA, and the host is currently creating, rekeying, or - closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN. - - o the IKE_SA, and the host is currently trying to close the IKE_SA: - reply with NO_PROPOSAL_CHOSEN. - - If a host receives a request to close: - - o a CHILD_SA pair that the host is currently trying to close: reply - without Delete payloads. - - o a CHILD_SA pair that the host is currently rekeying: reply as - usual, with Delete payload. - - o a CHILD_SA pair that does not exist: reply without Delete - payloads. - - o the IKE_SA, and the host is currently rekeying the IKE_SA: reply - as usual, and forget about our own rekeying request. - - o the IKE_SA, and the host is currently trying to close the IKE_SA: - reply as usual, and forget about our own close request. - - If a host receives a request to create or rekey a CHILD_SA when it is - - - -Eronen & Hoffman Expires November 5, 2006 [Page 35] - -Internet-Draft IKEv2 Clarifications May 2006 - - - currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS. - - If a host receives a request to delete a CHILD_SA when it is - currently rekeying the IKE_SA: reply without Delete payloads. - -5.12. Diffie-Hellman and rekeying the IKE_SA - - There has been some confusion whether doing a new Diffie-Hellman - exchange is mandatory when the IKE_SA is rekeyed. - - It seems that this case is allowed by the IKEv2 specification. - Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets. - Section 3.3.3 does not contradict this when it says that including - the D-H transform is mandatory: although including the transform is - mandatory, it can contain the value "NONE". - - However, having the option to skip the Diffie-Hellman exchange when - rekeying the IKE_SA does not add useful functionality to the - protocol. The main purpose of rekeying the IKE_SA is to ensure that - the compromise of old keying material does not provide information - about the current keys, or vice versa. This requires performing the - Diffie-Hellman exchange when rekeying. Furthermore, it is likely - that this option would have been removed from the protocol as - unnecessary complexity had it been discussed earlier. - - Given this, we recommend that implementations should have a hard- - coded policy that requires performing a new Diffie-Hellman exchange - when rekeying the IKE_SA. In other words, the initiator should not - propose the value "NONE" for the D-H transform, and the responder - should not accept such a proposal. This policy also implies that a - succesful exchange rekeying the IKE_SA always includes the KEi/KEr - payloads. - - (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange" - thread, Oct 2005. "Comments of - draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.) - - -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. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 36] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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.3 - of this document for some examples). However, their semantics are - still different. - -6.2. 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. - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 37] - -Internet-Draft IKEv2 Clarifications May 2006 - - -6.3. 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 is an IP address and the second is 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 to 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) - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 38] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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) - - 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) - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 39] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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/ - 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.4. 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 40] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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.) - - 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.5. 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". - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 41] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - 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.) - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 42] - -Internet-Draft IKEv2 Clarifications May 2006 - - -6.6. 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.7. 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. - (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 they 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.8. 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 43] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - 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 RFC4301 - - The IKEv2 specification refers to [RFC4301], but it never makes - clearly defines the exact relationship is. - - However, there are some requirements in the specification that make - it clear that IKEv2 requires [RFC4301]. 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 SAs created by - IKEv2 [...] MUST implement the tunnel encapsulation and - decapsulation processing specified in [RFC4301] to prevent discarding - - - -Eronen & Hoffman Expires November 5, 2006 [Page 44] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - 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. - - - - - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 45] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 - 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. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 46] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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 that 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". - 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 47] - -Internet-Draft IKEv2 Clarifications May 2006 - - - easier to draw. In particular, payloads in IKEv2 are not, in - general, aligned to 4-octet 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 - default value specified in [RFC2451] is used. - -7.12. IPsec IANA considerations - - There are currently three different IANA registry files that contain - important numbers for IPsec: ikev2-registry, isakmp-registry, and - ipsec-registry. Implementors should note that IKEv2 may use numbers - different from IKEv1 for a particular algorithm. - - For instance, an encryption algorithm can have up to three different - numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry, - the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec- - registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier" - isakmp-registry. Although some algorithms have the same number in - - - -Eronen & Hoffman Expires November 5, 2006 [Page 48] - -Internet-Draft IKEv2 Clarifications May 2006 - - - all three registries, the registries are not identical. - - Similarly, an integrity algorithm can have at least the IKEv2 - "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2 - "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1 - phase 2 ESP "Authentication Algorithm Security Association Attribute" - identifier in isakmp-registry. And there is also the IKEv1 phase 1 - "Hash Algorithm" list in ipsec-registry. - - This issue needs special care also when writing a specification for - how a new algorithm is used together with IPsec. - -7.13. Combining ESP and AH - - The IKEv2 specification contains some misleading text about how ESP - and AH can be combined. - - IKEv2 is based on [RFC4301] which does not include "SA bundles" that - were part of [RFC2401]. While a single packet can go through IPsec - processing multiple times, each of these passes uses a separate SA, - and the passes are coordinated by the forwarding tables. In IKEv2, - each of these SAs has to be created using a separate CREATE_CHILD_SA - exchange. Thus, the text in Section 2.7 about a single proposal - containing both ESP and AH is incorrect. - - Morever, the combination of ESP and AH (between the same endpoints) - become largely obsolete already in 1998 when RFC 2406 was published. - Our recommendation is that IKEv2 implementations should not support - this combination, and implementors should not assume the combination - can be made to work in interoperable manner. - - (References: "Rekeying SA bundles" thread, Oct 2005.) - - -8. Implementation mistakes - - Some implementers at the early IKEv2 bakeoffs 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. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 49] - -Internet-Draft IKEv2 Clarifications May 2006 - - - 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. - - -9. 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. - - -10. IANA considerations - - This document does not change or create any IANA-registered values. - - -11. 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. - - -12. References - -12.1. Normative References - - [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) - Protocol", RFC 4306, December 2005. - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 50] - -Internet-Draft IKEv2 Clarifications May 2006 - - - [IKEv2ALG] - Schiller, J., "Cryptographic Algorithms for Use in the - Internet Key Exchange Version 2 (IKEv2)", RFC 4307, - December 2005. - - [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. - - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - -12.2. Informative References - - [Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with - Host-to-Host IPsec", 13th International Workshop on - Security Protocols, Cambridge, UK, April 2005. - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. - Levkowetz, "Extensible Authentication Protocol (EAP)", - RFC 3748, June 2004. - - [HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec", - draft-hoffman-ike-ipsec-hash-use-01 (work in progress), - December 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 4291, 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 - - - -Eronen & Hoffman Expires November 5, 2006 [Page 51] - -Internet-Draft IKEv2 Clarifications May 2006 - - - Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. - - [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The - Network Access Identifier", RFC 4282, December 2005. - - [PKI4IPsec] - Korver, B., "Internet PKI Profile of IKEv1/ISAKMP, IKEv2, - and PKIX", draft-ietf-pki4ipsec-ikecert-profile (work in - progress), February 2006. - - [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. - - [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), October 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 Internet Key Exchange - (IKEv2) Protocol", RFC 4478, April 2006. - - - -Eronen & Hoffman Expires November 5, 2006 [Page 52] - -Internet-Draft IKEv2 Clarifications May 2006 - - - [SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and T. - Polk, "Simple Certificate Validation Protocol (SCVP)", - draft-ietf-pkix-scvp-21 (work in progress), October 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 - 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+] - - - - - - - - - - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 53] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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 November 5, 2006 [Page 54] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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 November 5, 2006 [Page 55] - -Internet-Draft IKEv2 Clarifications May 2006 - - -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)] - - -Authors' Addresses - - Pasi Eronen - Nokia Research Center - P.O. Box 407 - FIN-00045 Nokia Group - Finland - - Email: pasi.eronen@nokia.com - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 56] - -Internet-Draft IKEv2 Clarifications May 2006 - - - Paul Hoffman - VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 - USA - - Email: paul.hoffman@vpnc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 57] - -Internet-Draft IKEv2 Clarifications May 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - 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. - - 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. - - -Intellectual Property - - 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. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Eronen & Hoffman Expires November 5, 2006 [Page 58] - - |