From d6bd078a65ae4ca534f0955bf3c35bc94ea776a0 Mon Sep 17 00:00:00 2001 From: Martin Willi Date: Wed, 2 Apr 2008 13:20:14 +0000 Subject: updated RFCs/drafts --- .../draft-eronen-ipsec-ikev2-clarifications-09.txt | 3250 --------- doc/standards/draft-hoffman-ikev2-1-00.txt | 6720 ------------------ doc/standards/draft-hoffman-ikev2bis-00.txt | 6776 ------------------ doc/standards/draft-hoffman-ikev2bis-03.txt | 7224 ++++++++++++++++++++ doc/standards/draft-myers-ikev2-ocsp-03.txt | 785 --- doc/standards/draft-sheffer-ipsec-failover-03.txt | 1401 ++++ doc/standards/rfc4806.txt | 619 ++ 7 files changed, 9244 insertions(+), 17531 deletions(-) delete mode 100644 doc/standards/draft-eronen-ipsec-ikev2-clarifications-09.txt delete mode 100644 doc/standards/draft-hoffman-ikev2-1-00.txt delete mode 100644 doc/standards/draft-hoffman-ikev2bis-00.txt create mode 100644 doc/standards/draft-hoffman-ikev2bis-03.txt delete mode 100644 doc/standards/draft-myers-ikev2-ocsp-03.txt create mode 100644 doc/standards/draft-sheffer-ipsec-failover-03.txt create mode 100644 doc/standards/rfc4806.txt 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 - . - - -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] - - diff --git a/doc/standards/draft-hoffman-ikev2-1-00.txt b/doc/standards/draft-hoffman-ikev2-1-00.txt deleted file mode 100644 index cd6b0ec22..000000000 --- a/doc/standards/draft-hoffman-ikev2-1-00.txt +++ /dev/null @@ -1,6720 +0,0 @@ - - - -Network Working Group P. Hoffman -Internet-Draft VPN Consortium -Expires: July 5, 2006 January 2006 - - - Internet Key Exchange Protocol: IKEv2.1 - draft-hoffman-ikev2-1-00.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 July 5, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes version 2.1 of the Internet Key Exchange - (IKE) protocol. IKEv2.1 is heavily based on IKEv2 from RFC 4306 - (edited by Charlie Kaufman), and includes all of the clarifications - from the "IKEv2 Clarifications" document (edited by Pasi Eronen and - Paul Hoffman). IKEv2.1 makes additional changes to those two - documents in places where IKEv2 was unclear and the clarifications - document did not commit to a particular protocol interpretation. - - - - - -Hoffman Expires July 5, 2006 [Page 1] - -Internet-Draft IKEv2 January 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 - 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 7 - 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 - 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 - 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 - 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 - 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 - 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA - Exchange . . . . . . . . . . . . . . . . . . . . . . 13 - 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 13 - 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA - Exchange . . . . . . . . . . . . . . . . . . . . . . 14 - 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 - 1.5. Informational Messages outside of an IKE_SA . . . . . . . 16 - 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 - 1.7. Introduction to IKEv2.1 . . . . . . . . . . . . . . . . . 17 - 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 18 - 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 19 - 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 19 - 2.3. Window Size for Overlapping Requests . . . . . . . . . . 20 - 2.4. State Synchronization and Connection Timeouts . . . . . . 21 - 2.5. Version Numbers and Forward Compatibility . . . . . . . . 23 - 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 27 - 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 28 - 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 29 - 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 31 - 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 33 - 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 34 - 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 37 - 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 38 - 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 38 - 2.13. Generating Keying Material . . . . . . . . . . . . . . . 39 - 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 40 - 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 41 - 2.16. Extensible Authentication Protocol Methods . . . . . . . 43 - 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 45 - 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 46 - 2.19. Requesting an Internal Address on a Remote Network . . . 47 - 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 48 - 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 49 - 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 50 - 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 53 - - - -Hoffman Expires July 5, 2006 [Page 2] - -Internet-Draft IKEv2 January 2006 - - - 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 53 - 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 53 - 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 56 - 3.3. Security Association Payload . . . . . . . . . . . . . . 58 - 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 60 - 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 62 - 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 64 - 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 65 - 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 66 - 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 67 - 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 68 - 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 69 - 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 71 - 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 74 - 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 76 - 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 77 - 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 77 - 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 78 - 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 84 - 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 85 - 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 86 - 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 88 - 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 90 - 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 92 - 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 94 - 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 97 - 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 99 - 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 100 - 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 100 - 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 102 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 104 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 108 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 108 - 8.2. Informative References . . . . . . . . . . . . . . . . . 109 - Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 112 - Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 114 - B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 114 - B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 114 - Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 115 - C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 115 - C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 116 - C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 117 - C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying - CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 118 - C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 118 - C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 118 - - - -Hoffman Expires July 5, 2006 [Page 3] - -Internet-Draft IKEv2 January 2006 - - - Appendix D. Changes Between Internet Draft Versions . . . . . . 118 - D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 118 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119 - Intellectual Property and Copyright Statements . . . . . . . . . 119 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 4] - -Internet-Draft IKEv2 January 2006 - - -1. Introduction - - {{ An introduction to IKEv2.1 is given at the end of Section 1. It - is put there (instead of here) to preserve the section numbering of - the original IKEv2 document. }} - - IP Security (IPsec) provides confidentiality, data integrity, access - control, and data source authentication to IP datagrams. These - services are provided by maintaining shared state between the source - and the sink of an IP datagram. This state defines, among other - things, the specific services provided to the datagram, which - cryptographic algorithms will be used to provide the services, and - the keys used as input to the cryptographic algorithms. - - Establishing this shared state in a manual fashion does not scale - well. Therefore, a protocol to establish this state dynamically is - needed. This memo describes such a protocol -- the Internet Key - Exchange (IKE). This is version 2.1 of IKE. Version 1 of IKE was - defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 - was defined in [IKEV2]. This single document is intended to replace - all three of those RFCs. - - Definitions of the primitive terms in this document (such as Security - Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It - should be noted that parts of IKEv2 and IKEv2.1 rely on some of the - processing rules in [IPSECARCH], as described in various sections of - this document. - - IKE performs mutual authentication between two parties and - establishes an IKE security association (SA) that includes shared - secret information that can be used to efficiently establish SAs for - Encapsulating Security Payload (ESP) [ESP] and/or Authentication - Header (AH) [AH] and a set of cryptographic algorithms to be used by - the SAs to protect the traffic that they carry. In this document, - the term "suite" or "cryptographic suite" refers to a complete set of - algorithms used to protect an SA. An initiator proposes one or more - suites by listing supported algorithms that can be combined into - suites in a mix-and-match fashion. IKE can also negotiate use of IP - Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. - We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get - set up through that IKE_SA we call "CHILD_SAs". - - All IKE communications consist of pairs of messages: a request and a - response. The pair is called an "exchange". We call the first - messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges - and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL - exchanges. In the common case, there is a single IKE_SA_INIT - exchange and a single IKE_AUTH exchange (a total of four messages) to - - - -Hoffman Expires July 5, 2006 [Page 5] - -Internet-Draft IKEv2 January 2006 - - - establish the IKE_SA and the first CHILD_SA. In exceptional cases, - there may be more than one of each of these exchanges. In all cases, - all IKE_SA_INIT exchanges MUST complete before any other exchange - type, then all IKE_AUTH exchanges MUST complete, and following that - any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur - in any order. In some scenarios, only a single CHILD_SA is needed - between the IPsec endpoints, and therefore there would be no - additional exchanges. Subsequent exchanges MAY be used to establish - additional CHILD_SAs between the same authenticated pair of endpoints - and to perform housekeeping functions. - - IKE message flow always consists of a request followed by a response. - It is the responsibility of the requester to ensure reliability. If - the response is not received within a timeout interval, the requester - needs to retransmit the request (or abandon the connection). - - The first request/response of an IKE session (IKE_SA_INIT) negotiates - security parameters for the IKE_SA, sends nonces, and sends Diffie- - Hellman values. - - The second request/response (IKE_AUTH) transmits identities, proves - knowledge of the secrets corresponding to the two identities, and - sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. - - The types of subsequent exchanges are CREATE_CHILD_SA (which creates - a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error - conditions, or does other housekeeping). Every request requires a - response. An INFORMATIONAL request with no payloads (other than the - empty Encrypted payload required by the syntax) is commonly used as a - check for liveness. These subsequent exchanges cannot be used until - the initial exchanges have completed. - - In the description that follows, we assume that no errors occur. - Modifications to the flow should errors occur are described in - Section 2.21. - -1.1. Usage Scenarios - - IKE is expected to be used to negotiate ESP and/or AH SAs in a number - of different scenarios, each with its own special requirements. - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 6] - -Internet-Draft IKEv2 January 2006 - - -1.1.1. Security Gateway to Security Gateway Tunnel - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec ! ! - Protected !Tunnel ! tunnel !Tunnel ! Protected - Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet - ! ! ! ! - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 1: Security Gateway to Security Gateway Tunnel - - In this scenario, neither endpoint of the IP connection implements - IPsec, but network nodes between them protect traffic for part of the - way. Protection is transparent to the endpoints, and depends on - ordinary routing to send packets through the tunnel endpoints for - processing. Each endpoint would announce the set of addresses - "behind" it, and packets would be sent in tunnel mode where the inner - IP header would contain the IP addresses of the actual endpoints. - -1.1.2. Endpoint-to-Endpoint Transport - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec transport ! ! - !Protected! or tunnel mode SA !Protected! - !Endpoint !<---------------------------------------->!Endpoint ! - ! ! ! ! - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 2: Endpoint to Endpoint - - In this scenario, both endpoints of the IP connection implement - IPsec, as required of hosts in [IPSECARCH]. Transport mode will - commonly be used with no inner IP header. If there is an inner IP - header, the inner addresses will be the same as the outer addresses. - A single pair of addresses will be negotiated for packets to be - protected by this SA. These endpoints MAY implement application - layer access controls based on the IPsec authenticated identities of - the participants. This scenario enables the end-to-end security that - has been a guiding principle for the Internet since [ARCHPRINC], - [TRANSPARENCY], and a method of limiting the inherent problems with - complexity in networks noted by [ARCHGUIDEPHIL]. Although this - scenario may not be fully applicable to the IPv4 Internet, it has - been deployed successfully in specific scenarios within intranets - using IKEv1. It should be more broadly enabled during the transition - to IPv6 and with the adoption of IKEv2. - - It is possible in this scenario that one or both of the protected - endpoints will be behind a network address translation (NAT) node, in - - - -Hoffman Expires July 5, 2006 [Page 7] - -Internet-Draft IKEv2 January 2006 - - - which case the tunneled packets will have to be UDP encapsulated so - that port numbers in the UDP headers can be used to identify - individual endpoints "behind" the NAT (see Section 2.23). - -1.1.3. Endpoint to Security Gateway Tunnel - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec ! ! Protected - !Protected! tunnel !Tunnel ! Subnet - !Endpoint !<------------------------>!Endpoint !<--- and/or - ! ! ! ! Internet - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 3: Endpoint to Security Gateway Tunnel - - In this scenario, a protected endpoint (typically a portable roaming - computer) connects back to its corporate network through an IPsec- - protected tunnel. It might use this tunnel only to access - information on the corporate network, or it might tunnel all of its - traffic back through the corporate network in order to take advantage - of protection provided by a corporate firewall against Internet-based - attacks. In either case, the protected endpoint will want an IP - address associated with the security gateway so that packets returned - to it will go to the security gateway and be tunneled back. This IP - address may be static or may be dynamically allocated by the security - gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 - includes a mechanism (namely, configuration payloads) for the - initiator to request an IP address owned by the security gateway for - use for the duration of its SA. - - In this scenario, packets will use tunnel mode. On each packet from - the protected endpoint, the outer IP header will contain the source - IP address associated with its current location (i.e., the address - that will get traffic routed to the endpoint directly), while the - inner IP header will contain the source IP address assigned by the - security gateway (i.e., the address that will get traffic routed to - the security gateway for forwarding to the endpoint). The outer - destination address will always be that of the security gateway, - while the inner destination address will be the ultimate destination - for the packet. - - In this scenario, it is possible that the protected endpoint will be - behind a NAT. In that case, the IP address as seen by the security - gateway will not be the same as the IP address sent by the protected - endpoint, and packets will have to be UDP encapsulated in order to be - routed properly. - - - - - -Hoffman Expires July 5, 2006 [Page 8] - -Internet-Draft IKEv2 January 2006 - - -1.1.4. Other Scenarios - - Other scenarios are possible, as are nested combinations of the - above. One notable example combines aspects of 1.1.1 and 1.1.3. A - subnet may make all external accesses through a remote security - gateway using an IPsec tunnel, where the addresses on the subnet are - routed to the security gateway by the rest of the Internet. An - example would be someone's home network being virtually on the - Internet with static IP addresses even though connectivity is - provided by an ISP that assigns a single dynamically assigned IP - address to the user's security gateway (where the static IP addresses - and an IPsec relay are provided by a third party located elsewhere). - -1.2. The Initial Exchanges - - Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH - exchanges (known in IKEv1 as Phase 1). These initial exchanges - normally consist of four messages, though in some scenarios that - number can grow. All communications using IKE consist of request/ - response pairs. We'll describe the base exchange first, followed by - variations. The first pair of messages (IKE_SA_INIT) negotiate - cryptographic algorithms, exchange nonces, and do a Diffie-Hellman - exchange [DH]. - - The second pair of messages (IKE_AUTH) authenticate the previous - messages, exchange identities and certificates, and establish the - first CHILD_SA. Parts of these messages are encrypted and integrity - protected with keys established through the IKE_SA_INIT exchange, so - the identities are hidden from eavesdroppers and all fields in all - the messages are authenticated. - - In the following descriptions, the payloads contained in the message - are indicated by names as listed below. - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 9] - -Internet-Draft IKEv2 January 2006 - - - Notation Payload - ----------------------------------------- - AUTH Authentication - CERT Certificate - CERTREQ Certificate Request - CP Configuration - D Delete - E Encrypted - EAP Extensible Authentication - HDR IKE Header - IDi Identification - Initiator - IDr Identification - Responder - KE Key Exchange - Ni, Nr Nonce - N Notify - SA Security Association - TSi Traffic Selector - Initiator - TSr Traffic Selector - Responder - V Vendor ID - - The details of the contents of each payload are described in section - 3. Payloads that may optionally appear will be shown in brackets, - such as [CERTREQ], indicate that optionally a certificate request - payload can be included. - - {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED" - Some payloads in IKEv2 (and historically in IKEv1) are not aligned to - 4-byte boundaries. - - The initial exchanges are as follows: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SAi1, KEi, Ni --> - - HDR contains the Security Parameter Indexes (SPIs), version numbers, - and flags of various sorts. The SAi1 payload states the - cryptographic algorithms the initiator supports for the IKE_SA. The - KE payload sends the initiator's Diffie-Hellman value. Ni is the - initiator's nonce. - - <-- HDR, SAr1, KEr, Nr, [CERTREQ] - - The responder chooses a cryptographic suite from the initiator's - offered choices and expresses that choice in the SAr1 payload, - completes the Diffie-Hellman exchange with the KEr payload, and sends - its nonce in the Nr payload. - - - - -Hoffman Expires July 5, 2006 [Page 10] - -Internet-Draft IKEv2 January 2006 - - - At this point in the negotiation, each party can generate SKEYSEED, - from which all keys are derived for that IKE_SA. All but the headers - of all the messages that follow are encrypted and integrity - protected. The keys used for the encryption and integrity protection - are derived from SKEYSEED and are known as SK_e (encryption) and SK_a - (authentication, a.k.a. integrity protection). A separate SK_e and - SK_a is computed for each direction. In addition to the keys SK_e - and SK_a derived from the DH value for protection of the IKE_SA, - another quantity SK_d is derived and used for derivation of further - keying material for CHILD_SAs. The notation SK { ... } indicates - that these payloads are encrypted and integrity protected using that - direction's SK_e and SK_a. - - HDR, SK {IDi, [CERT,] [CERTREQ,] - [IDr,] AUTH, SAi2, - TSi, TSr} --> - - The initiator asserts its identity with the IDi payload, proves - knowledge of the secret corresponding to IDi and integrity protects - the contents of the first message using the AUTH payload (see - Section 2.15). It might also send its certificate(s) in CERT - payload(s) and a list of its trust anchors in CERTREQ payload(s). If - any CERT payloads are included, the first certificate provided MUST - contain the public key used to verify the AUTH field. The optional - payload IDr enables the initiator to specify which of the responder's - identities it wants to talk to. This is useful when the machine on - which the responder is running is hosting multiple identities at the - same IP address. The initiator begins negotiation of a CHILD_SA - using the SAi2 payload. The final fields (starting with SAi2) are - described in the description of the CREATE_CHILD_SA exchange. - - <-- HDR, SK {IDr, [CERT,] AUTH, - SAr2, TSi, TSr} - - The responder asserts its identity with the IDr payload, optionally - sends one or more certificates (again with the certificate containing - the public key used to verify AUTH listed first), authenticates its - identity and protects the integrity of the second message with the - AUTH payload, and completes negotiation of a CHILD_SA with the - additional fields described below in the CREATE_CHILD_SA exchange. - - The recipients of messages 3 and 4 MUST verify that all signatures - and MACs are computed correctly and that the names in the ID payloads - correspond to the keys used to generate the AUTH payload. - - {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange - fails for some reason, the IKE_SA is still created as usual. The - list of responses in the IKE_AUTH exchange that do not prevent an - - - -Hoffman Expires July 5, 2006 [Page 11] - -Internet-Draft IKEv2 January 2006 - - - 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. - - {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr - or Ni/Nr payloads. Thus, the SA payload in IKE_AUTH exchange cannot - contain Transform Type 4 (Diffie-Hellman Group) with any other value - than NONE. Implementations MUST leave the transform out entirely in - this case. - -1.3. The CREATE_CHILD_SA Exchange - - {{ This is a heavy rewrite of most of this section. The major - organization changes are described in Clarif-4.1 and Clarif-5.1. }} - - The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to - rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single - request/response pair, and some of its function was referred to as a - phase 2 exchange in IKEv1. It MAY be initiated by either end of the - IKE_SA after the initial exchanges are completed. - - All messages following the initial exchange are cryptographically - protected using the cryptographic algorithms and keys negotiated in - the first two messages of the IKE exchange. These subsequent - messages use the syntax of the Encrypted Payload described in - Section 3.14. All subsequent messages included an Encrypted Payload, - even if they are referred to in the text as "empty". For both - messages in the CREATE_CHILD_SA, the message following the header is - encrypted and the message including the header is integrity protected - using the cryptographic algorithms negotiated for the IKE_SA. - - The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs. This - section describes the first part of rekeying, the creation of new - SAs; Section 2.8 covers the mechanics of rekeying, including moving - traffic from old to new SAs and the deletion of the old SAs. The two - sections must be read together to understand the entire process of - rekeying. - - Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this - section the term initiator refers to the endpoint initiating this - exchange. An implementation MAY refuse all CREATE_CHILD_SA requests - within an IKE_SA. - - The CREATE_CHILD_SA request MAY optionally contain a KE payload for - an additional Diffie-Hellman exchange to enable stronger guarantees - of forward secrecy for the CHILD_SA. The keying material for the - CHILD_SA is a function of SK_d established during the establishment - of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA - - - -Hoffman Expires July 5, 2006 [Page 12] - -Internet-Draft IKEv2 January 2006 - - - exchange, and the Diffie-Hellman value (if KE payloads are included - in the CREATE_CHILD_SA exchange). - - If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of - the SA offers MUST include the Diffie-Hellman group of the KEi. The - Diffie-Hellman group of the KEi MUST be an element of the group the - initiator expects the responder to accept (additional Diffie-Hellman - groups can be proposed). If the responder rejects the Diffie-Hellman - group of the KEi payload, the responder MUST reject the request and - indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD - Notification payload. In the case of such a rejection, the - CREATE_CHILD_SA exchange fails, and the initiator will probably retry - the exchange with a Diffie-Hellman proposal and KEi in the group that - the responder gave in the INVALID_KE_PAYLOAD. - -1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange - - A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The - CREATE_CHILD_SA request for creating a new CHILD_SA is: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {SA, Ni, [KEi], - TSi, TSr} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, optionally a Diffie-Hellman value in the KEi payload, and - the proposed traffic selectors for the proposed CHILD_SA in the TSi - and TSr payloads. - - The CREATE_CHILD_SA response for creating a new CHILD_SA is: - - <-- HDR, SK {SA, Nr, [KEr], - TSi, TSr} - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if KEi was included in the request and the selected - cryptographic suite includes that group. - - The traffic selectors for traffic to be sent on that SA are specified - in the TS payloads in the response, which may be a subset of what the - initiator of the CHILD_SA proposed. - -1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA request for rekeying an IKE_SA is: - - - - -Hoffman Expires July 5, 2006 [Page 13] - -Internet-Draft IKEv2 January 2006 - - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {SA, Ni, KEi} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, and a Diffie-Hellman value in the KEi payload. New - initiator and responder SPIs are supplied in the SPI fields. - - The CREATE_CHILD_SA response for rekeying an IKE_SA is: - - <-- HDR, SK {SA, Nr, KEr} - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if the selected cryptographic suite includes that group. - - The new IKE_SA has its message counters set to 0, regardless of what - they were in the earlier IKE_SA. The window size starts at 1 for any - new IKE_SA. - - KEi and KEr are required for rekeying an IKE_SA. - -1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA request for rekeying a CHILD_SA is: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {N, SA, Ni, [KEi], - TSi, TSr} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, optionally a Diffie-Hellman value in the KEi payload, and - the proposed traffic selectors for the proposed CHILD_SA in the TSi - and TSr payloads. When rekeying an existing CHILD_SA, the leading N - payload of type REKEY_SA MUST be included and MUST give the SPI (as - they would be expected in the headers of inbound packets) of the SAs - being rekeyed. - - The CREATE_CHILD_SA response for rekeying a CHILD_SA is: - - <-- HDR, SK {SA, Nr, [KEr], - Si, TSr} - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if KEi was included in the request and the selected - cryptographic suite includes that group. - - - -Hoffman Expires July 5, 2006 [Page 14] - -Internet-Draft IKEv2 January 2006 - - - 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. - -1.4. The INFORMATIONAL Exchange - - At various points during the operation of an IKE_SA, peers may desire - to convey control messages to each other regarding errors or - notifications of certain events. To accomplish this, IKE defines an - INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur - after the initial exchanges and are cryptographically protected with - the negotiated keys. - - Control messages that pertain to an IKE_SA MUST be sent under that - IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent - under the protection of the IKE_SA which generated them (or its - successor if the IKE_SA was replaced for the purpose of rekeying). - - Messages in an INFORMATIONAL exchange contain zero or more - Notification, Delete, and Configuration payloads. The Recipient of - an INFORMATIONAL exchange request MUST send some response (else the - Sender will assume the message was lost in the network and will - retransmit it). That response MAY be a message with no payloads. - The request message in an INFORMATIONAL exchange MAY also contain no - payloads. This is the expected way an endpoint can ask the other - endpoint to verify that it is alive. - - {{ Clarif-5.6 }} 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 (that is, deleted). When SAs are nested, as when data (and - IP headers if in tunnel mode) are encapsulated first with IPComp, - then with ESP, and finally with AH between the same pair of - endpoints, all of the SAs MUST be deleted together. Each endpoint - MUST close its incoming SAs and allow the other endpoint to close the - other SA in each pair. 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. {{ Clarif-5.7 - }} Note that 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 for nested SAs), you include delete payloads for in - inbound half of each SA in your Informational exchange. - - Normally, the reply in the INFORMATIONAL exchange will contain delete - payloads for the paired SAs going in the other direction. There is - one exception. If by chance both ends of a set of SAs independently - decide to close them, each may send a delete payload and the two - requests may cross in the network. If a node receives a delete - - - -Hoffman Expires July 5, 2006 [Page 15] - -Internet-Draft IKEv2 January 2006 - - - request for SAs for which it has already issued a delete request, it - MUST delete the outgoing SAs while processing the request and the - incoming SAs while processing the response. In that case, the - responses MUST NOT include delete payloads for the deleted SAs, since - that would result in duplicate deletion and could in theory delete - the wrong SA. - - {{ Demoted the SHOULD }} Half-closed connections are anomalous and, - and a node with auditing capability will probably audit their - existence if they persist. Note that this specification nowhere - specifies time periods, so it is up to individual endpoints to decide - how long to wait. A node MAY refuse to accept incoming data on half- - closed connections but MUST NOT unilaterally close them and reuse the - SPIs. If connection state becomes sufficiently messed up, a node MAY - close the IKE_SA; doing so will implicitly close all SAs negotiated - under it. It can then rebuild the SAs it needs on a clean base under - a new IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes - the IKE_SA is an empty Informational response. - - The INFORMATIONAL exchange is defined as: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {[N,] [D,] - [CP,] ...} --> - <-- HDR, SK {[N,] [D,] - [CP], ...} - - The processing of an INFORMATIONAL exchange is determined by its - component payloads. - -1.5. Informational Messages outside of an IKE_SA - - If an encrypted IKE packet arrives on port 500 or 4500 with an - unrecognized SPI, it could be because the receiving node has recently - crashed and lost state or because of some other system malfunction or - attack. If the receiving node has an active IKE_SA to the IP address - from whence the packet came, it MAY send a notification of the - wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it - does not have such an IKE_SA, it MAY send an Informational message - without cryptographic protection to the source IP address. Such a - message is not part of an informational exchange, and the receiving - node MUST NOT respond to it. Doing so could cause a message loop. - - {{ Clarif-7.7 }} There are two cases when such a one-way notification - is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are - sent outside of an IKE_SA. Note that such notifications are - explicitly not Informational exchanges; these are one-way messages - - - -Hoffman Expires July 5, 2006 [Page 16] - -Internet-Draft IKEv2 January 2006 - - - that must not be responded to. In case of INVALID_IKE_SPI, the - message sent is a response message, and thus it is 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. Using zero values or random values are both - acceptable. - -1.6. Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [MUSTSHOULD]. - - The term "Expert Review" is to be interpreted as defined in - [IANACONS]. - -1.7. Introduction to IKEv2.1 - - IKEv2.1 is very similar to IKEv2. Most of the differences between - this document at [IKEV2] are clarifications, mostly based on - [Clarif]. The changes listed in that document were discussed in the - IPsec Working Group and, after the Working Group was disbanded, on - the IPsec mailing list. That document contains detailed explanations - of areas that were unclear in IKEv2, and is thus useful to - implementers of IKEv2 and IKEv2.1. - - In the body of this document, notes that are enclosed in double curly - braces {{ such as this }} point out changes from IKEv2. Changes that - come from [Clarif] are marked with the section from that document, - such as "{{ Clarif-2.10 }}". - - This document also make the figures and references a bit more regular - than in IKEv2. - - IKEv2 developers have noted that the SHOULD-level requirements are - often unclear in that they don't say when it is OK to not obey the - requirements. They also have noted that there are MUST-level - requirements that are not related to interoperability. This document - has more explanation of some of these SHOULD-level requirements, and - some SHOULD-level and MUST-level requirements have been changed to - better match the definitions in [MUSTSHOULD]. All non-capitalized - uses of the words SHOULD and MUST now mean their normal English - sense, not the interoperability sense of [MUSTSHOULD]. - - IKEv2 (and IKEv1) developers have noted that there is a great deal of - material in the tables of codes in Section 3.10. This leads to - implementers not having all the needed information in the main body - - - -Hoffman Expires July 5, 2006 [Page 17] - -Internet-Draft IKEv2 January 2006 - - - of the docment. A later version of this document may move much of - the material from those tables into the associated parts of the main - body of the document. - - A later version of this document will probably have all the {{ }} - comments removed from the body of the document and instead appear in - an appendix. - - -2. IKE Protocol Details and Variations - - IKE normally listens and sends on UDP port 500, though IKE messages - may also be received on UDP port 4500 with a slightly different - format (see Section 2.23). Since UDP is a datagram (unreliable) - protocol, IKE includes in its definition recovery from transmission - errors, including packet loss, packet replay, and packet forgery. - IKE is designed to function so long as (1) at least one of a series - of retransmitted packets reaches its destination before timing out; - and (2) the channel is not so full of forged and replayed packets so - as to exhaust the network or CPU capacities of either endpoint. Even - in the absence of those minimum performance requirements, IKE is - designed to fail cleanly (as though the network were broken). - - Although IKEv2 messages are intended to be short, they contain - structures with no hard upper bound on size (in particular, X.509 - certificates), and IKEv2 itself does not have a mechanism for - fragmenting large messages. IP defines a mechanism for fragmentation - of oversize UDP messages, but implementations vary in the maximum - message size supported. Furthermore, use of IP fragmentation opens - an implementation to denial of service attacks [DOSUDPPROT]. - Finally, some NAT and/or firewall implementations may block IP - fragments. - - All IKEv2 implementations MUST be able to send, receive, and process - IKE messages that are up to 1280 bytes long, and they SHOULD be able - to send, receive, and process messages that are up to 3000 bytes - long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware - of the maximum UDP message size supported and MAY shorten messages by - leaving out some certificates or cryptographic suite proposals if - that will keep messages below the maximum. Use of the "Hash and URL" - formats rather than including certificates in exchanges where - possible can avoid most problems. {{ Demoted the SHOULD }} - Implementations and configuration need to keep in mind, however, that - if the URL lookups are possible only after the IPsec SA is - established, recursion issues could prevent this technique from - working. - - - - - -Hoffman Expires July 5, 2006 [Page 18] - -Internet-Draft IKEv2 January 2006 - - -2.1. Use of Retransmission Timers - - All messages in IKE exist in pairs: a request and a response. The - setup of an IKE_SA normally consists of two request/response pairs. - Once the IKE_SA is set up, either end of the security association may - initiate requests at any time, and there can be many requests and - responses "in flight" at any given moment. But each message is - labeled as either a request or a response, and for each request/ - response pair one end of the security association is the initiator - and the other is the responder. - - For every pair of IKE messages, the initiator is responsible for - retransmission in the event of a timeout. The responder MUST never - retransmit a response unless it receives a retransmission of the - request. In that event, the responder MUST ignore the retransmitted - request except insofar as it triggers a retransmission of the - response. The initiator MUST remember each request until it receives - the corresponding response. The responder MUST remember each - response until it receives a request whose sequence number is larger - than the sequence number in the response plus its window size (see - Section 2.3). - - IKE is a reliable protocol, in the sense that the initiator MUST - retransmit a request until either it receives a corresponding reply - OR it deems the IKE security association to have failed and it - discards all state associated with the IKE_SA and any CHILD_SAs - negotiated using that IKE_SA. - - {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the - prefix of four zeros; otherwise, the receiver won't know how to - handle them. - -2.2. Use of Sequence Numbers for Message ID - - Every IKE message contains a Message ID as part of its fixed header. - This Message ID is used to match up requests and responses, and to - identify retransmissions of messages. - - The Message ID is a 32-bit quantity, which is zero for the first IKE - request in each direction. {{ Clarif-3.11 }} When the IKE_AUTH - exchange does not use EAP, the IKE_SA initial setup messages will - always be numbered 0 and 1. When EAP is used, each pair of messages - have their message numbers incremented; the first pair of AUTH - messages will have an ID of 1, the second will be 2, and so on. - - Each endpoint in the IKE Security Association maintains two "current" - Message IDs: the next one to be used for a request it initiates and - the next one it expects to see in a request from the other end. - - - -Hoffman Expires July 5, 2006 [Page 19] - -Internet-Draft IKEv2 January 2006 - - - These counters increment as requests are generated and received. - Responses always contain the same message ID as the corresponding - request. That means that after the initial exchange, each integer n - may appear as the message ID in four distinct messages: the nth - request from the original IKE initiator, the corresponding response, - the nth request from the original IKE responder, and the - corresponding response. If the two ends make very different numbers - of requests, the Message IDs in the two directions can be very - different. There is no ambiguity in the messages, however, because - the (I)nitiator and (R)esponse bits in the message header specify - which of the four messages a particular one is. - - {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always - zero, including for retries of the message due to responses such as - COOKIE and INVALID_KE_PAYLOAD. - - Note that Message IDs are cryptographically protected and provide - protection against message replays. In the unlikely event that - Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be - closed. Rekeying an IKE_SA resets the sequence numbers. - - {{ Clarif-2.3 }} 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). It is - not sufficient to use the initiator's SPI and/or IP address to - differentiate between the two cases because two different peers - behind a single NAT could choose the same initiator SPI. Instead, a - robust responder will do the IKE_SA lookup using the whole packet, - its hash, or the Ni payload. - -2.3. Window Size for Overlapping Requests - - In order to maximize IKE throughput, an IKE endpoint MAY issue - multiple requests before getting a response to any of them if the - other endpoint has indicated its ability to handle such requests. - For simplicity, an IKE implementation MAY choose to process requests - strictly in order and/or wait for a response to one request before - issuing another. Certain rules must be followed to ensure - interoperability between implementations using different strategies. - - After an IKE_SA is set up, either end can initiate one or more - requests. These requests may pass one another over the network. An - IKE endpoint MUST be prepared to accept and process a request while - it has a request outstanding in order to avoid a deadlock in this - situation. {{ Changed the SHOULD to MUST }} An IKE endpoint MUST be - prepared to accept and process multiple requests while it has a - - - -Hoffman Expires July 5, 2006 [Page 20] - -Internet-Draft IKEv2 January 2006 - - - request outstanding. - - An IKE endpoint MUST wait for a response to each of its messages - before sending a subsequent message unless it has received a - SET_WINDOW_SIZE Notify message from its peer informing it that the - peer is prepared to maintain state for multiple outstanding messages - in order to allow greater throughput. - - An IKE endpoint MUST NOT exceed the peer's stated window size for - transmitted IKE requests. In other words, if the responder stated - its window size is N, then when the initiator needs to make a request - X, it MUST wait until it has received responses to all requests up - through request X-N. An IKE endpoint MUST keep a copy of (or be able - to regenerate exactly) each request it has sent until it receives the - corresponding response. An IKE endpoint MUST keep a copy of (or be - able to regenerate exactly) the number of previous responses equal to - its declared window size in case its response was lost and the - initiator requests its retransmission by retransmitting the request. - - An IKE endpoint supporting a window size greater than one should be - capable of processing incoming requests out of order to maximize - performance in the event of network failures or packet reordering. - - {{ Clarif-7.3 }} 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 - example). 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; you can only - increase it. 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. - -2.4. State Synchronization and Connection Timeouts - - An IKE endpoint is allowed to forget all of its state associated with - an IKE_SA and the collection of corresponding CHILD_SAs at any time. - This is the anticipated behavior in the event of an endpoint crash - and restart. It is important when an endpoint either fails or - reinitializes its state that the other endpoint detect those - conditions and not continue to waste network bandwidth by sending - packets over discarded SAs and having them fall into a black hole. - - Since IKE is designed to operate in spite of Denial of Service (DoS) - attacks from the network, an endpoint MUST NOT conclude that the - other endpoint has failed based on any routing information (e.g., - ICMP messages) or IKE messages that arrive without cryptographic - - - -Hoffman Expires July 5, 2006 [Page 21] - -Internet-Draft IKEv2 January 2006 - - - protection (e.g., Notify messages complaining about unknown SPIs). - An endpoint MUST conclude that the other endpoint has failed only - when repeated attempts to contact it have gone unanswered for a - timeout period or when a cryptographically protected INITIAL_CONTACT - notification is received on a different IKE_SA to the same - authenticated identity. {{ Demoted the SHOULD }} An endpoint should - suspect that the other endpoint has failed based on routing - information and initiate a request to see whether the other endpoint - is alive. To check whether the other side is alive, IKE specifies an - empty INFORMATIONAL message that (like all IKE requests) requires an - acknowledgement (note that within the context of an IKE_SA, an - "empty" message consists of an IKE header followed by an Encrypted - payload that contains no payloads). If a cryptographically protected - message has been received from the other side recently, unprotected - notifications MAY be ignored. Implementations MUST limit the rate at - which they take actions based on unprotected messages. - - Numbers of retries and lengths of timeouts are not covered in this - specification because they do not affect interoperability. It is - suggested that messages be retransmitted at least a dozen times over - a period of at least several minutes before giving up on an SA, but - different environments may require different rules. To be a good - network citizen, retranmission times MUST increase exponentially to - avoid flooding the network and making an existing congestion - situation worse. If there has only been outgoing traffic on all of - the SAs associated with an IKE_SA, it is essential to confirm - liveness of the other endpoint to avoid black holes. If no - cryptographically protected messages have been received on an IKE_SA - or any of its CHILD_SAs recently, the system needs to perform a - liveness check in order to prevent sending messages to a dead peer. - Receipt of a fresh cryptographically protected message on an IKE_SA - or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its - CHILD_SAs. Note that this places requirements on the failure modes - of an IKE endpoint. An implementation MUST NOT continue sending on - any SA if some failure prevents it from receiving on all of the - associated SAs. If CHILD_SAs can fail independently from one another - without the associated IKE_SA being able to send a delete message, - then they MUST be negotiated by separate IKE_SAs. - - There is a Denial of Service attack on the initiator of an IKE_SA - that can be avoided if the initiator takes the proper care. Since - the first two messages of an SA setup are not cryptographically - protected, an attacker could respond to the initiator's message - before the genuine responder and poison the connection setup attempt. - To prevent this, the initiator MAY be willing to accept multiple - responses to its first message, treat each as potentially legitimate, - respond to it, and then discard all the invalid half-open connections - when it receives a valid cryptographically protected response to any - - - -Hoffman Expires July 5, 2006 [Page 22] - -Internet-Draft IKEv2 January 2006 - - - one of its requests. Once a cryptographically valid response is - received, all subsequent responses should be ignored whether or not - they are cryptographically valid. - - Note that with these rules, there is no reason to negotiate and agree - upon an SA lifetime. If IKE presumes the partner is dead, based on - repeated lack of acknowledgement to an IKE message, then the IKE SA - and all CHILD_SAs set up through that IKE_SA are deleted. - - An IKE endpoint may at any time delete inactive CHILD_SAs to recover - resources used to hold their state. If an IKE endpoint chooses to - delete CHILD_SAs, it MUST send Delete payloads to the other end - notifying it of the deletion. It MAY similarly time out the IKE_SA. - {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all - associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a - Delete payload indicating that it has closed the IKE_SA unless the - other endpoint is no longer responding. - -2.5. Version Numbers and Forward Compatibility - - {{ The version number is changed in the following paragraph, and the - discussion of handling of multiple versions is also changed - throughout the section. }} - - This document describes version 2.1 of IKE, meaning the major version - number is 2 and the minor version number is 1. It is likely that - some implementations will want to support version 1.0 and version 2.0 - and version 2.1, and in the future, other versions. - - The major version number should be incremented only if the packet - formats or required actions have changed so dramatically that an - older version node would not be able to interoperate with a newer - version node if it simply ignored the fields it did not understand - and took the actions specified in the older specification. The minor - version number indicates new capabilities, and MUST be ignored by a - node with a smaller minor version number, but used for informational - purposes by the node with the larger minor version number. For - example, it might indicate the ability to process a newly defined - notification message. The node with the larger minor version number - would simply note that its correspondent would not be able to - understand that message and therefore would not send it. - - In the discussion of clarifications to IKEv2, it became clear that - there was a need for additional "MUST" and "SHOULD" requirements. - Some of those changes are reflected in IKEv2.1. Thus, the node with - the higher version number may also need to note that its - correspondent may not be following the same required actions, which - could affect interoperability. - - - -Hoffman Expires July 5, 2006 [Page 23] - -Internet-Draft IKEv2 January 2006 - - - {{ Promoted the SHOULD }} If an endpoint receives a message with a - higher major version number, it MUST drop the message and MUST send - an unauthenticated notification message containing the highest - version number it supports. If an endpoint supports major version n, - and major version m, it MUST support all versions between n and m. - If it receives a message with a major version that it supports, it - MUST respond with that version number. In order to prevent two nodes - from being tricked into corresponding with a lower major version - number than the maximum that they both support, IKE has a flag that - indicates that the node is capable of speaking a higher major version - number. - - Thus, the major version number in the IKE header indicates the - version number of the message, not the highest version number that - the transmitter supports. If the initiator is capable of speaking - versions n, n+1, and n+2, and the responder is capable of speaking - versions n and n+1, then they will negotiate speaking n+1, where the - initiator will set the flag indicating its ability to speak a higher - version. If they mistakenly (perhaps through an active attacker - sending error messages) negotiate to version n, then both will notice - that the other side can support a higher version number, and they - MUST break the connection and reconnect using version n+1. - - Note that IKEv1 does not follow these rules, because there is no way - in v1 of noting that you are capable of speaking a higher version - number. So an active attacker can trick two v2-capable nodes into - speaking v1. {{ Demoted the SHOULD }} When a v2-capable node - negotiates down to v1, it should note that fact in its logs. - - Also for forward compatibility, all fields marked RESERVED MUST be - set to zero by an implementation running version 2.0 or later, and - their content MUST be ignored by an implementation running version - 2.0 or later ("Be conservative in what you send and liberal in what - you receive"). In this way, future versions of the protocol can use - those fields in a way that is guaranteed to be ignored by - implementations that do not understand them. Similarly, payload - types that are not defined are reserved for future use; - implementations of a version where they are undefined MUST skip over - those payloads and ignore their contents. - - IKEv2 adds a "critical" flag to each payload header for further - flexibility for forward compatibility. If the critical flag is set - and the payload type is unrecognized, the message MUST be rejected - and the response to the IKE request containing that payload MUST - include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an - unsupported critical payload was included. If the critical flag is - not set and the payload type is unsupported, that payload MUST be - ignored. - - - -Hoffman Expires July 5, 2006 [Page 24] - -Internet-Draft IKEv2 January 2006 - - - {{ Demoted the SHOULD }}Although new payload types may be added in - the future and may appear interleaved with the fields defined in this - specification, implementations MUST send the payloads defined in this - specification in the order shown in the figures in Section 2 and - implementations MAY reject as invalid a message with those payloads - in any other order. - -2.6. Cookies - - The term "cookies" originates with Karn and Simpson [PHOTURIS] in - Photuris, an early proposal for key management with IPsec, and it has - persisted. The Internet Security Association and Key Management - Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- - octet fields titled "cookies", and that syntax is used by both IKEv1 - and IKEv2 though in IKEv2 they are referred to as the IKE SPI and - there is a new separate field in a Notify payload holding the cookie. - The initial two eight-octet fields in the header are used as a - connection identifier at the beginning of IKE packets. {{ Promoted - the SHOULD }} Each endpoint chooses one of the two SPIs and MUST - choose them so as to be unique identifiers of an IKE_SA. An SPI - value of zero is special and indicates that the remote SPI value is - not yet known by the sender. - - Unlike ESP and AH where only the recipient's SPI appears in the - header of a message, in IKE the sender's SPI is also sent in every - message. Since the SPI chosen by the original initiator of the - IKE_SA is always sent first, an endpoint with multiple IKE_SAs open - that wants to find the appropriate IKE_SA using the SPI it assigned - must look at the I(nitiator) Flag bit in the header to determine - whether it assigned the first or the second eight octets. - - In the first message of an initial IKE exchange, the initiator will - not know the responder's SPI value and will therefore set that field - to zero. - - An expected attack against IKE is state and CPU exhaustion, where the - target is flooded with session initiation requests from forged IP - addresses. This attack can be made less effective if an - implementation of a responder uses minimal CPU and commits no state - to an SA until it knows the initiator can receive packets at the - address from which it claims to be sending them. To accomplish this, - a responder SHOULD -- when it detects a large number of half-open - IKE_SAs -- reject initial IKE messages unless they contain a Notify - payload of type COOKIE. {{ Clarified the SHOULD }} If the responder - wants to set up an SA, it SHOULD instead send an unprotected IKE - message as a response and include COOKIE Notify payload with the - cookie data to be returned. Initiators who receive such responses - MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE - - - -Hoffman Expires July 5, 2006 [Page 25] - -Internet-Draft IKEv2 January 2006 - - - containing the responder supplied cookie data as the first payload - and all other payloads unchanged. The initial exchange will then be - as follows: - - Initiator Responder - ------------------------------------------------------------------- - 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, [CERTREQ] - HDR(A,B), SK {IDi, [CERT,] - [CERTREQ,] [IDr,] AUTH, - SAi2, TSi, TSr} --> - <-- HDR(A,B), SK {IDr, [CERT,] - AUTH, SAr2, TSi, TSr} - - The first two messages do not affect any initiator or responder state - except for communicating the cookie. In particular, the message - sequence numbers in the first four messages will all be zero and the - message sequence numbers in the last two messages will be one. 'A' - is the SPI assigned by the initiator, while 'B' is the SPI assigned - by the responder. - - {{ Clarif-2.1 }} Because the responder's SPI identifies security- - related state held by the responder, and in this case no state is - created, the responder sends a zero value for the responder's SPI. - - {{ Demoted the SHOULD }} An IKE implementation should implement its - responder cookie generation in such a way as to not require any saved - state to recognize its valid cookie when the second IKE_SA_INIT - message arrives. The exact algorithms and syntax they use to - generate cookies do not affect interoperability and hence are not - specified here. The following is an example of how an endpoint could - use cookies to implement limited DOS protection. - - A good way to do this is to set the responder cookie to be: - - Cookie = | Hash(Ni | IPi | SPIi | ) - - where is a randomly generated secret known only to the - responder and periodically changed and | indicates concatenation. - should be changed whenever is - regenerated. The cookie can be recomputed when the IKE_SA_INIT - arrives the second time and compared to the cookie in the received - message. If it matches, the responder knows that the cookie was - generated since the last change to and that IPi must be the - - - -Hoffman Expires July 5, 2006 [Page 26] - -Internet-Draft IKEv2 January 2006 - - - same as the source address it saw the first time. Incorporating SPIi - into the calculation ensures that if multiple IKE_SAs are being set - up in parallel they will all get different cookies (assuming the - initiator chooses unique SPIi's). Incorporating Ni into the hash - ensures that an attacker who sees only message 2 can't successfully - forge a message 3. - - If a new value for is chosen while there are connections in - the process of being initialized, an IKE_SA_INIT might be returned - with other than the current . The responder in - that case MAY reject the message by sending another response with a - new cookie or it MAY keep the old value of around for a - short time and accept cookies computed from either one. {{ Demoted - the SHOULD NOT }} The responder should not accept cookies - indefinitely after is changed, since that would defeat part - of the denial of service protection. {{ Demoted the SHOULD }} The - responder should change the value of frequently, especially - if under attack. - - {{ Clarif-2.1 }} In addition to cookies, there are several cases - where the IKE_SA_INIT exchange does not result in the creation of an - IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a - case, sending a zero value for the Responder's SPI is correct. If - the responder sends a non-zero responder SPI, the initiator should - not reject the response for only that reason. - - {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request - containing a cookie whose contents do not match the value expected, - that party MUST ignore the cookie and process the message as if no - cookie had been included; usually this means sending a response - containing a new cookie. - -2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD - - {{ This section added by Clarif-2.4 }} - - 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. - If the initiator receives a cookie from the responder, the initiator - needs to decide whether or not tp include the cookie in only the next - retry of the IKE_SA_INIT request, or in all subsequent retries as - well. - - If the initiator includes the cookie only in the next retry, one - additional roundtrip may be needed in some cases. An additional - roundtrip is needed also if the initiator includes the cookie in all - retries, but the responder does not support this. For instance, if - - - -Hoffman Expires July 5, 2006 [Page 27] - -Internet-Draft IKEv2 January 2006 - - - the responder includes the SAi1 and KEi payloads in cookie - calculation, it will reject the request by sending a new cookie. - - If both peers support including the cookie in all retries, a slightly - shorter exchange can happen. Implementations MUST support this - shorter exchange, but MUST NOT assume other implementations also - supports this shorter exchange. - -2.7. Cryptographic Algorithm Negotiation - - The payload type known as "SA" indicates a proposal for a set of - choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well - as cryptographic algorithms associated with each protocol. - - An SA payload consists of one or more proposals. Each proposal - includes one or more protocols (usually one). Each protocol contains - one or more transforms -- each specifying a cryptographic algorithm. - Each transform contains zero or more attributes (attributes are - needed only if the transform identifier does not completely specify - the cryptographic algorithm). - - This hierarchical structure was designed to efficiently encode - proposals for cryptographic suites when the number of supported - suites is large because multiple values are acceptable for multiple - transforms. The responder MUST choose a single suite, which MAY be - any subset of the SA proposal following the rules below: - - Each proposal contains one or more protocols. If a proposal is - accepted, the SA response MUST contain the same protocols in the same - order as the proposal. The responder MUST accept a single proposal - or reject them all and return an error. (Example: if a single - proposal contains ESP and AH and that proposal is accepted, both ESP - and AH MUST be accepted. If ESP and AH are included in separate - proposals, the responder MUST accept only one of them). - - Each IPsec protocol proposal contains one or more transforms. Each - transform contains a transform type. The accepted cryptographic - suite MUST contain exactly one transform of each type included in the - proposal. For example: if an ESP proposal includes transforms - ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, - AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one - of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six - combinations are acceptable. - - Since the initiator sends its Diffie-Hellman value in the - IKE_SA_INIT, it must guess the Diffie-Hellman group that the - responder will select from its list of supported groups. If the - initiator guesses wrong, the responder will respond with a Notify - - - -Hoffman Expires July 5, 2006 [Page 28] - -Internet-Draft IKEv2 January 2006 - - - payload of type INVALID_KE_PAYLOAD indicating the selected group. In - this case, the initiator MUST retry the IKE_SA_INIT with the - corrected Diffie-Hellman group. The initiator MUST again propose its - full set of acceptable cryptographic suites because the rejection - message was unauthenticated and otherwise an active attacker could - trick the endpoints into negotiating a weaker suite than a stronger - one that they both prefer. - -2.8. Rekeying - - {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use - secret keys that should be used only for a limited amount of time and - to protect a limited amount of data. This limits the lifetime of the - entire security association. When the lifetime of a security - association expires, the security association MUST NOT be used. If - there is demand, new security associations MAY be established. - Reestablishment of security associations to take the place of ones - that expire is referred to as "rekeying". - - To allow for minimal IPsec implementations, the ability to rekey SAs - without restarting the entire IKE_SA is optional. An implementation - MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA - has expired or is about to expire and rekeying attempts using the - mechanisms described here fail, an implementation MUST close the - IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ - Demoted the SHOULD }} Implementations should support in-place - rekeying of SAs, since doing so offers better performance and is - likely to reduce the number of packets lost during the transition. - - To rekey a CHILD_SA within an existing IKE_SA, create a new, - equivalent SA (see Section 2.17 below), and when the new one is - established, delete the old one. To rekey an IKE_SA, establish a new - equivalent IKE_SA (see Section 2.18 below) with the peer to whom the - old IKE_SA is shared using a CREATE_CHILD_SA within the existing - IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's - CHILD_SAs. Use the new IKE_SA for all control messages needed to - maintain the CHILD_SAs created by the old IKE_SA, and delete the old - IKE_SA. The Delete payload to delete itself MUST be the last request - sent over an IKE_SA. - - {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the - new SA should be established before the old one expires and becomes - unusable. Enough time should elapse between the time the new SA is - established and the old one becomes unusable so that traffic can be - switched over to the new SA. - - A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes - were negotiated. In IKEv2, each end of the SA is responsible for - - - -Hoffman Expires July 5, 2006 [Page 29] - -Internet-Draft IKEv2 January 2006 - - - enforcing its own lifetime policy on the SA and rekeying the SA when - necessary. If the two ends have different lifetime policies, the end - with the shorter lifetime will end up always being the one to request - the rekeying. If an SA bundle has been inactive for a long time and - if an endpoint would not initiate the SA in the absence of traffic, - the endpoint MAY choose to close the SA instead of rekeying it when - its lifetime expires. {{ Demoted the SHOULD }} It should do so if - there has been no traffic since the last time the SA was rekeyed. - - Note that IKEv2 deliberately allows parallel SAs with the same - traffic selectors between common endpoints. One of the purposes of - this is to support traffic quality of service (QoS) differences among - the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of - [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints - and the traffic selectors may not uniquely identify an SA between - those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on - the basis of duplicate traffic selectors SHOULD NOT be used. - - {{ Demoted the SHOULD }} The node that initiated the surviving - rekeyed SA should delete the replaced SA after the new one is - established. - - There are timing windows -- particularly in the presence of lost - packets -- where endpoints may not agree on the state of an SA. The - responder to a CREATE_CHILD_SA MUST be prepared to accept messages on - an SA before sending its response to the creation request, so there - is no ambiguity for the initiator. The initiator MAY begin sending - on an SA as soon as it processes the response. The initiator, - however, cannot receive on a newly created SA until it receives and - processes the response to its CREATE_CHILD_SA request. How, then, is - the responder to know when it is OK to send on the newly created SA? - - From a technical correctness and interoperability perspective, the - responder MAY begin sending on an SA as soon as it sends its response - to the CREATE_CHILD_SA request. In some situations, however, this - could result in packets unnecessarily being dropped, so an - implementation MAY want to defer such sending. - - The responder can be assured that the initiator is prepared to - receive messages on an SA if either (1) it has received a - cryptographically valid message on the new SA, or (2) the new SA - rekeys an existing SA and it receives an IKE request to close the - replaced SA. {{ Clarif-5.10 }} When rekeying an SA, the responder - SHOULD continue to send traffic on the old SA until one of those - events occurs. When establishing a new SA, the responder MAY defer - sending messages on a new SA until either it receives one or a - timeout has occurred. {{ Demoted the SHOULD }} If an initiator - receives a message on an SA for which it has not received a response - - - -Hoffman Expires July 5, 2006 [Page 30] - -Internet-Draft IKEv2 January 2006 - - - to its CREATE_CHILD_SA request, it should interpret that as a likely - packet loss and retransmit the CREATE_CHILD_SA request. An initiator - MAY send a dummy message on a newly created SA if it has no messages - queued in order to assure the responder that the initiator is ready - to receive messages. - - {{ Clarif-5.9 }} Throughout this 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. The - "original initiator" always refers to the party who initiated the - exchange which resulted in the current IKE_SA. In other words, if - the the "original responder" starts rekeying the IKE_SA, that party - becomes the "original initiator" of the new IKE_SA. - -2.8.1. Simultaneous CHILD_SA rekeying - - {{ The first two paragraphs were moved, and the rest was added, based - on Clarif-5.12 }} - - 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. {{ Clarif-5.11 }} - "Lowest" means 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. - - The following is an explanation on the impact this has on - implementations. 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 - - - -Hoffman Expires July 5, 2006 [Page 31] - -Internet-Draft IKEv2 January 2006 - - - recv req2 <-- - - At this point, A knows there is a simultaneous rekeying going on. - However, it cannot yet know which of the exchanges will have the - lowest nonce, so it will just note the situation and respond as - usual. - - send resp2: SA(..,SPIa3,..), - Nr1,.. --> - --> recv req1 - - Now B also knows that simultaneous rekeying is going on. It responds - as usual. - - <-- send resp1: SA(..,SPIb3,..), - Nr2,.. - recv resp1 <-- - --> recv resp2 - - At this point, there are three CHILD_SA pairs between A and B (the - old one and two new ones). A and B can now compare the nonces. - Suppose that the lowest nonce was Nr1 in message resp2; in this case, - B (the sender of req2) deletes the redundant new SA, and A (the node - that initiated the surviving rekeyed SA), deletes the old one. - - send req3: D(SPIa1) --> - <-- send req4: D(SPIb2) - --> recv req3 - <-- send resp4: D(SPIb1) - recv req4 <-- - send resp4: D(SPIa3) --> - - The rekeying is now finished. - - However, there is a second possible sequence of events that can - happen if some packets are lost in the network, resulting in - retransmissions. The rekeying begins as usual, but A's first packet - (req1) is lost. - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 32] - -Internet-Draft IKEv2 January 2006 - - - 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 - - To B, it looks like A is trying to rekey an SA that no longer exists; - thus, B responds to the request with something non-fatal such as - NO_PROPOSAL_CHOSEN. - - <-- 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. - -2.8.2. Rekeying the IKE_SA Versus Reauthentication - - {{ Added this section from Clarif-5.2 }} - - 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). - - Although 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. - - - -Hoffman Expires July 5, 2006 [Page 33] - -Internet-Draft IKEv2 January 2006 - - - 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]. - -2.9. Traffic Selector Negotiation - - {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives - an IP packet and matches a "protect" selector in its Security Policy - Database (SPD), the subsystem protects that packet with IPsec. When - no SA exists yet, it is the task of IKE to create it. Maintenance of - a system's SPD is outside the scope of IKE (see [PFKEY] for an - example protocol), though some implementations might update their SPD - in connection with the running of IKE (for an example scenario, see - Section 1.1.3). - - Traffic Selector (TS) payloads allow endpoints to communicate some of - the information from their SPD to their peers. TS payloads specify - the selection criteria for packets that will be forwarded over the - newly set up SA. This can serve as a consistency check in some - scenarios to assure that the SPDs are consistent. In others, it - guides the dynamic update of the SPD. - - Two TS payloads appear in each of the messages in the exchange that - creates a CHILD_SA pair. Each TS payload contains one or more - Traffic Selectors. Each Traffic Selector consists of an address - range (IPv4 or IPv6), a port range, and an IP protocol ID. 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. {{ Clarif-6.1 }} That request is done using - configuration payloads, not traffic selectors. 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 - - - -Hoffman Expires July 5, 2006 [Page 34] - -Internet-Draft IKEv2 January 2006 - - - can be performed as agreed for this SA. - - IKEv2 allows the responder to choose a subset of the traffic proposed - by the initiator. This could happen when the configurations of the - two endpoints are being updated but only one end has received the new - information. Since the two endpoints may be configured by different - people, the incompatibility may persist for an extended period even - in the absence of errors. It also allows for intentionally different - configurations, as when one end is configured to tunnel all addresses - and depends on the other end to have the up-to-date list. - - The first of the two TS payloads is known as TSi (Traffic Selector- - initiator). The second is known as TSr (Traffic Selector-responder). - TSi specifies the source address of traffic forwarded from (or the - destination address of traffic forwarded to) the initiator of the - CHILD_SA pair. TSr specifies the destination address of the traffic - forwarded to (or the source address of the traffic forwarded from) - the responder of the CHILD_SA pair. For example, if the original - initiator request the creation of a CHILD_SA pair, and wishes to - tunnel all traffic from subnet 192.0.1.* on the initiator's side to - subnet 192.0.2.* on the responder's side, the initiator would include - a single traffic selector in each TS payload. TSi would specify the - address range (192.0.1.0 - 192.0.1.255) and TSr would specify the - address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was - acceptable to the responder, it would send identical TS payloads - back. (Note: The IP address range 192.0.2.* has been reserved for - use in examples in RFCs and similar documents. This document needed - two such ranges, and so also used 192.0.1.*. This should not be - confused with any actual address.) - - The responder is allowed to narrow the choices by selecting a subset - of the traffic, for instance by eliminating or narrowing the range of - one or more members of the set of traffic selectors, provided the set - does not become the NULL set. - - It is possible for the responder's policy to contain multiple smaller - ranges, all encompassed by the initiator's traffic selector, and with - the responder's policy being that each of those ranges should be sent - over a different SA. Continuing the example above, the responder - might have a policy of being willing to tunnel those addresses to and - from the initiator, but might require that each address pair be on a - separately negotiated CHILD_SA. If the initiator generated its - request in response to an incoming packet from 192.0.1.43 to - 192.0.2.123, there would be no way for the responder to determine - which pair of addresses should be included in this tunnel, and it - would have to make a guess or reject the request with a status of - SINGLE_PAIR_REQUIRED. - - - - -Hoffman Expires July 5, 2006 [Page 35] - -Internet-Draft IKEv2 January 2006 - - - {{ Clarif-4.11 }} Few implementations will have policies that require - separate SAs for each address pair. Because of this, if only some - part (or parts) of the TSi/TSr proposed by the initiator is (are) - acceptable to the responder, responders SHOULD narrow TSi/TSr to an - acceptable subset rather than use SINGLE_PAIR_REQUIRED. - - To enable the responder to choose the appropriate range in this case, - if the initiator has requested the SA due to a data packet, the - initiator SHOULD include as the first traffic selector in each of TSi - and TSr a very specific traffic selector including the addresses in - the packet triggering the request. In the example, the initiator - would include in TSi two traffic selectors: the first containing the - address range (192.0.1.43 - 192.0.1.43) and the source port and IP - protocol from the packet and the second containing (192.0.1.0 - - 192.0.1.255) with all ports and IP protocols. The initiator would - similarly include two traffic selectors in TSr. - - If the responder's policy does not allow it to accept the entire set - of traffic selectors in the initiator's request, but does allow him - to accept the first selector of TSi and TSr, then the responder MUST - narrow the traffic selectors to a subset that includes the - initiator's first choices. In this example, the responder might - respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and - IP protocols. - - If the initiator creates the CHILD_SA pair not in response to an - arriving packet, but rather, say, upon startup, then there may be no - specific addresses the initiator prefers for the initial tunnel over - any other. In that case, the first values in TSi and TSr MAY be - ranges rather than specific values, and the responder chooses a - subset of the initiator's TSi and TSr that are acceptable. If more - than one subset is acceptable but their union is not, the responder - MUST accept some subset and MAY include a Notify payload of type - ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to - try again. This case will occur only when the initiator and - responder are configured differently from one another. If the - initiator and responder agree on the granularity of tunnels, the - initiator will never request a tunnel wider than the responder will - accept. {{ Demoted the SHOULD }} Such misconfigurations should be - recorded in error logs. - - {{ Clarif-4.10 }} A concise summary of the narrowing process is: - - 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 - - - -Hoffman Expires July 5, 2006 [Page 36] - -Internet-Draft IKEv2 January 2006 - - - 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. - -2.9.1. Traffic Selectors Violating Own Policy - - {{ Clarif-4.12 }} - - When creating a new SA, the initiator should not propose traffic - selectors that violate its own policy. If this rule is not followed, - valid traffic may be dropped. - - This is best illustrated by an example. Suppose that host A has a - policy whose effect is that traffic to 192.0.1.66 is sent via host B - encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 - is also sent via B, but must use 3DES. Suppose also that host B - accepts any combination of AES and 3DES. - - If host A now proposes an SA that uses 3DES, and includes TSr - containing (192.0.1.0-192.0.1.0.255), this will be accepted by host - B. Now, host B can also use this SA to send traffic from 192.0.1.66, - but those packets will be dropped by A since it requires the use of - AES for those traffic. Even if host A creates a new SA only for - 192.0.1.66 that uses AES, host B may freely continue to use the first - SA for the traffic. In this situation, when proposing the SA, host A - should have followed its own policy, and included a TSr containing - ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. - - In general, if (1) the initiator makes a proposal "for traffic X - (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator - does not actually accept traffic X' with SA, and (3) the initiator - would be willing to accept traffic X' with some SA' (!=SA), valid - traffic can be unnecessarily dropped since the responder can apply - either SA or SA' to traffic X'. - - - - - -Hoffman Expires July 5, 2006 [Page 37] - -Internet-Draft IKEv2 January 2006 - - -2.10. Nonces - - The IKE_SA_INIT messages each contain a nonce. These nonces are used - as inputs to cryptographic functions. The CREATE_CHILD_SA request - and the CREATE_CHILD_SA response also contain nonces. These nonces - are used to add freshness to the key derivation technique used to - obtain keys for CHILD_SA, and to ensure creation of strong pseudo- - random bits from the Diffie-Hellman key. 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. ("prf" refers to - "pseudo-random function", one of the cryptographic algorithms - negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the - initiator chooses the nonce before the outcome of the negotiation is - known. Because of that, the nonce has to be long enough for all the - PRFs being proposed. If the same random number source is used for - both keys and nonces, care must be taken to ensure that the latter - use does not compromise the former. - -2.11. Address and Port Agility - - IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and - AH associations for the same IP addresses it runs over. The IP - addresses and ports in the outer header are, however, not themselves - cryptographically protected, and IKE is designed to work even through - Network Address Translation (NAT) boxes. An implementation MUST - accept incoming requests even if the source port is not 500 or 4500, - and MUST respond to the address and port from which the request was - received. It MUST specify the address and port at which the request - was received as the source address and port in the response. IKE - functions identically over IPv4 or IPv6. - -2.12. Reuse of Diffie-Hellman Exponentials - - IKE generates keying material using an ephemeral Diffie-Hellman - exchange in order to gain the property of "perfect forward secrecy". - This means that once a connection is closed and its corresponding - keys are forgotten, even someone who has recorded all of the data - from the connection and gets access to all of the long-term keys of - the two endpoints cannot reconstruct the keys used to protect the - conversation without doing a brute force search of the session key - space. - - Achieving perfect forward secrecy requires that when a connection is - closed, each endpoint MUST forget not only the keys used by the - connection but also any information that could be used to recompute - those keys. In particular, it MUST forget the secrets used in the - Diffie-Hellman calculation and any state that may persist in the - state of a pseudo-random number generator that could be used to - - - -Hoffman Expires July 5, 2006 [Page 38] - -Internet-Draft IKEv2 January 2006 - - - recompute the Diffie-Hellman secrets. - - Since the computing of Diffie-Hellman exponentials is computationally - expensive, an endpoint may find it advantageous to reuse those - exponentials for multiple connection setups. There are several - reasonable strategies for doing this. An endpoint could choose a new - exponential only periodically though this could result in less-than- - perfect forward secrecy if some connection lasts for less than the - lifetime of the exponential. Or it could keep track of which - exponential was used for each connection and delete the information - associated with the exponential only when some corresponding - connection was closed. This would allow the exponential to be reused - without losing perfect forward secrecy at the cost of maintaining - more state. - - Decisions as to whether and when to reuse Diffie-Hellman exponentials - is a private decision in the sense that it will not affect - interoperability. An implementation that reuses exponentials MAY - choose to remember the exponential used by the other endpoint on past - exchanges and if one is reused to avoid the second half of the - calculation. - -2.13. Generating Keying Material - - In the context of the IKE_SA, four cryptographic algorithms are - negotiated: an encryption algorithm, an integrity protection - algorithm, a Diffie-Hellman group, and a pseudo-random function - (prf). The pseudo-random function is used for the construction of - keying material for all of the cryptographic algorithms used in both - the IKE_SA and the CHILD_SAs. - - We assume that each encryption algorithm and integrity protection - algorithm uses a fixed-size key and that any randomly chosen value of - that fixed size can serve as an appropriate key. For algorithms that - accept a variable length key, a fixed key size MUST be specified as - part of the cryptographic transform negotiated. For algorithms for - which not all values are valid keys (such as DES or 3DES with key - parity), the algorithm by which keys are derived from arbitrary - values MUST be specified by the cryptographic transform. For - integrity protection functions based on Hashed Message Authentication - Code (HMAC), the fixed key size is the size of the output of the - underlying hash function. When the prf function takes a variable - length key, variable length data, and produces a fixed-length output - (e.g., when using HMAC), the formulas in this document apply. When - the key for the prf function has fixed length, the data provided as a - key is truncated or padded with zeros as necessary unless exceptional - processing is explained following the formula. - - - - -Hoffman Expires July 5, 2006 [Page 39] - -Internet-Draft IKEv2 January 2006 - - - Keying material will always be derived as the output of the - negotiated prf algorithm. Since the amount of keying material needed - may be greater than the size of the output of the prf algorithm, we - will use the prf iteratively. We will use the terminology prf+ to - describe the function that outputs a pseudo-random stream based on - the inputs to a prf as follows: (where | indicates concatenation) - - prf+ (K,S) = T1 | T2 | T3 | T4 | ... - - where: - T1 = prf (K, S | 0x01) - T2 = prf (K, T1 | S | 0x02) - T3 = prf (K, T2 | S | 0x03) - T4 = prf (K, T3 | S | 0x04) - - continuing as needed to compute all required keys. The keys are - taken from the output string without regard to boundaries (e.g., if - the required keys are a 256-bit Advanced Encryption Standard (AES) - key and a 160-bit HMAC key, and the prf function generates 160 bits, - the AES key will come from T1 and the beginning of T2, while the HMAC - key will come from the rest of T2 and the beginning of T3). - - The constant concatenated to the end of each string feeding the prf - is a single octet. prf+ in this document is not defined beyond 255 - times the size of the prf output. - -2.14. Generating Keying Material for the IKE_SA - - The shared keys are computed as follows. A quantity called SKEYSEED - is calculated from the nonces exchanged during the IKE_SA_INIT - exchange and the Diffie-Hellman shared secret established during that - exchange. SKEYSEED is used to calculate seven other secrets: SK_d - used for deriving new keys for the CHILD_SAs established with this - IKE_SA; SK_ai and SK_ar used as a key to the integrity protection - algorithm for authenticating the component messages of subsequent - exchanges; SK_ei and SK_er used for encrypting (and of course - decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are - used when generating an AUTH payload. - - SKEYSEED and its derivatives are computed as follows: - - SKEYSEED = prf(Ni | Nr, g^ir) - - {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } - = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) - - (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, - SK_pi, and SK_pr are taken in order from the generated bits of the - - - -Hoffman Expires July 5, 2006 [Page 40] - -Internet-Draft IKEv2 January 2006 - - - prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman - exchange. g^ir is represented as a string of octets in big endian - order padded with zeros if necessary to make it the length of the - modulus. Ni and Nr are the nonces, stripped of any headers. If the - negotiated prf takes a fixed-length key and the lengths of Ni and Nr - do not add up to that length, half the bits must come from Ni and - half from Nr, taking the first bits of each. - - The two directions of traffic flow use different keys. The keys used - to protect messages from the original initiator are SK_ai and SK_ei. - The keys used to protect messages in the other direction are SK_ar - and SK_er. Each algorithm takes a fixed number of bits of keying - material, which is specified as part of the algorithm. For integrity - algorithms based on a keyed hash, the key size is always equal to the - length of the output of the underlying hash function. - -2.15. Authentication of the IKE_SA - - When not using extensible authentication (see Section 2.16), the - peers are authenticated by having each sign (or MAC using a shared - secret as the key) a block of data. For the responder, the octets to - be signed start with the first octet of the first SPI in the header - of the second message and end with the last octet of the last payload - in the second message. Appended to this (for purposes of computing - the signature) are the initiator's nonce Ni (just the value, not the - payload containing it), and the value prf(SK_pr,IDr') where IDr' is - the responder's ID payload excluding the fixed header. Note that - neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. - Similarly, the initiator signs the first message, starting with the - first octet of the first SPI in the header and ending with the last - octet of the last payload. Appended to this (for purposes of - computing the signature) are the responder's nonce Nr, and the value - prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the - entire ID payloads excluding the fixed header. It is critical to the - security of the exchange that each side sign the other side's nonce. - - {{ Clarif-3.1 }} - - 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) - - - -Hoffman Expires July 5, 2006 [Page 41] - -Internet-Draft IKEv2 January 2006 - - - 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) - - Note that all of the payloads are included under the signature, - including any payload types not defined in this document. If the - first message of the exchange is sent twice (the second time with a - responder cookie and/or a different Diffie-Hellman group), it is the - second version of the message that is signed. - - Optionally, messages 3 and 4 MAY include a certificate, or - certificate chain providing evidence that the key used to compute a - digital signature belongs to the name in the ID payload. The - signature or MAC will be computed using algorithms dictated by the - type of key used by the signer, and specified by the Auth Method - field in the Authentication payload. There is no requirement that - the initiator and responder sign with the same cryptographic - algorithms. The choice of cryptographic algorithms depends on the - type of key each has. In particular, the initiator may be using a - shared key while the responder may have a public signature key and - certificate. It will commonly be the case (but it is not required) - that if a shared secret is used for authentication that the same key - is used in both directions. Note that it is a common but typically - insecure practice to have a shared key derived solely from a user- - chosen password without incorporating another source of randomness. - - This is typically insecure because user-chosen passwords are unlikely - to have sufficient unpredictability to resist dictionary attacks and - these attacks are not prevented in this authentication method. - (Applications using password-based authentication for bootstrapping - and IKE_SA should use the authentication method in Section 2.16, - which is designed to prevent off-line dictionary attacks.) {{ Demoted - the SHOULD }} The pre-shared key needs to contain as much - unpredictability as the strongest key being negotiated. In the case - of a pre-shared key, the AUTH value is computed as: - - AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) - - where the string "Key Pad for IKEv2" is 17 ASCII characters without - null termination. The shared secret can be variable length. The pad - string is added so that if the shared secret is derived from a - - - -Hoffman Expires July 5, 2006 [Page 42] - -Internet-Draft IKEv2 January 2006 - - - password, the IKE implementation need not store the password in - cleartext, but rather can store the value prf(Shared Secret,"Key Pad - for IKEv2"), which could not be used as a password equivalent for - protocols other than IKEv2. As noted above, deriving the shared - secret from a password is not secure. This construction is used - because it is anticipated that people will do it anyway. The - management interface by which the Shared Secret is provided MUST - accept ASCII strings of at least 64 octets and MUST NOT add a null - terminator before using them as shared secrets. It MUST also accept - a HEX encoding of the Shared Secret. The management interface MAY - accept other encodings if the algorithm for translating the encoding - to a binary string is specified. - - {{ Clarif-3.8 }} If the negotiated prf takes a fixed-size key, the - shared secret MUST be of that fixed size. This requirement means - that it is difficult to use these PRFs with shared key authentication - because it limits the shared secrets that can be used. Thus, PRFs - that require a fixed-size key SHOULD NOT be used with shared key - authentication. For example, PRF_AES128_CBC [PRFAES128CBC] - originally used fixed key sizes; that RFC has been updated to handle - variable key sizes in [PRFAES128CBC-bis]. Note that Section 2.13 - also contains text that is related to PRFs with fixed key size. - However, the text in that section applies only to the prf+ - construction. - -2.16. Extensible Authentication Protocol Methods - - In addition to authentication using public key signatures and shared - secrets, IKE supports authentication using methods defined in RFC - 3748 [EAP]. Typically, these methods are asymmetric (designed for a - user authenticating to a server), and they may not be mutual. For - this reason, these protocols are typically used to authenticate the - initiator to the responder and MUST be used in conjunction with a - public key signature based authentication of the responder to the - initiator. These methods are often associated with mechanisms - referred to as "Legacy Authentication" mechanisms. - - While this memo references [EAP] with the intent that new methods can - be added in the future without updating this specification, some - simpler variations are documented here and in Section 3.16. [EAP] - defines an authentication protocol requiring a variable number of - messages. Extensible Authentication is implemented in IKE as - additional IKE_AUTH exchanges that MUST be completed in order to - initialize the IKE_SA. - - An initiator indicates a desire to use extensible authentication by - leaving out the AUTH payload from message 3. By including an IDi - payload but not an AUTH payload, the initiator has declared an - - - -Hoffman Expires July 5, 2006 [Page 43] - -Internet-Draft IKEv2 January 2006 - - - identity but has not proven it. If the responder is willing to use - an extensible authentication method, it will place an Extensible - Authentication Protocol (EAP) payload in message 4 and defer sending - SAr2, TSi, and TSr until initiator authentication is complete in a - subsequent IKE_AUTH exchange. In the case of a minimal extensible - authentication, the initial SA establishment will appear as follows: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SAi1, KEi, Ni --> - <-- HDR, SAr1, KEr, Nr, [CERTREQ] - HDR, SK {IDi, [CERTREQ,] - [IDr,] SAi2, - TSi, TSr} --> - <-- HDR, SK {IDr, [CERT,] AUTH, - EAP } - HDR, SK {EAP} --> - <-- HDR, SK {EAP (success)} - HDR, SK {AUTH} --> - <-- HDR, SK {AUTH, SAr2, TSi, TSr } - - {{ Clarif-3.11 }} As described in Section 2.2, when EAP is used, each - pair of IKE_SA initial setup messages will have their message numbers - incremented; the first pair of AUTH messages will have an ID of 1, - the second will be 2, and so on. - - For EAP methods that create a shared key as a side effect of - authentication, that shared key MUST be used by both the initiator - and responder to generate AUTH payloads in messages 7 and 8 using the - syntax for shared secrets specified in Section 2.15. The shared key - from EAP is the field from the EAP specification named MSK. The - shared key generated during an IKE exchange MUST NOT be used for any - other purpose. - - EAP methods that do not establish a shared key SHOULD NOT be used, as - they are subject to a number of man-in-the-middle attacks [EAPMITM] - if these EAP methods are used in other protocols that do not use a - server-authenticated tunnel. Please see the Security Considerations - section for more details. If EAP methods that do not generate a - shared key are used, the AUTH payloads in messages 7 and 8 MUST be - generated using SK_pi and SK_pr, respectively. - - {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs - to be capable of extending the initial protocol exchange to at least - ten IKE_AUTH exchanges in the event the responder sends notification - messages and/or retries the authentication prompt. Once the protocol - exchange defined by the chosen EAP authentication method has - successfully terminated, the responder MUST send an EAP payload - - - -Hoffman Expires July 5, 2006 [Page 44] - -Internet-Draft IKEv2 January 2006 - - - containing the Success message. Similarly, if the authentication - method has failed, the responder MUST send an EAP payload containing - the Failure message. The responder MAY at any time terminate the IKE - exchange by sending an EAP payload containing the Failure message. - - Following such an extended exchange, the EAP AUTH payloads MUST be - included in the two messages following the one containing the EAP - Success message. - - {{ Clarif-3.5 }} 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. - 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. In this case, the authenticated identity has to be sent - from the AAA server to the IKEv2 responder. - - {{ Clarif-3.9 }} The information in Section 2.17 about PRFs with - fixed-size keys also applies to EAP authentication. For instance, a - PRF that requires a 128-bit key cannot be used with EAP because - specifies that the MSK is at least 512 bits long. - -2.17. Generating Keying Material for CHILD_SAs - - A single CHILD_SA is created by the IKE_AUTH exchange, and additional - CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. - Keying material for them is generated as follows: - - KEYMAT = prf+(SK_d, Ni | Nr) - - Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this - request is the first CHILD_SA created or the fresh Ni and Nr from the - CREATE_CHILD_SA exchange if this is a subsequent creation. - - For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman - exchange, the keying material is defined as: - - KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) - - where g^ir (new) is the shared secret from the ephemeral Diffie- - Hellman exchange of this CREATE_CHILD_SA exchange (represented as an - octet string in big endian order padded with zeros in the high-order - bits if necessary to make it the length of the modulus). - - A single CHILD_SA negotiation may result in multiple security - associations. ESP and AH SAs exist in pairs (one in each direction), - - - -Hoffman Expires July 5, 2006 [Page 45] - -Internet-Draft IKEv2 January 2006 - - - and four SAs could be created in a single CHILD_SA negotiation if a - combination of ESP and AH is being negotiated. - - Keying material MUST be taken from the expanded KEYMAT in the - following order: - - o All keys for SAs carrying data from the initiator to the responder - are taken before SAs going in the reverse direction. - - o If multiple IPsec protocols are negotiated, keying material is - taken in the order in which the protocol headers will appear in - the encapsulated packet. - - o If a single protocol has both encryption and authentication keys, - the encryption key is taken from the first octets of KEYMAT and - the authentication key is taken from the next octets. - - Each cryptographic algorithm takes a fixed number of bits of keying - material specified as part of the algorithm. - -2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA - (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs - are supplied in the SPI fields in the Proposal structures inside the - Security Association (SA) payloads (not the SPI fields in the IKE - header). The TS payloads are omitted when rekeying an IKE_SA. - 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) - - where g^ir (new) is the shared secret from the ephemeral Diffie- - Hellman exchange of this CREATE_CHILD_SA exchange (represented as an - octet string in big endian order padded with zeros if necessary to - make it the length of the modulus) and Ni and Nr are the two nonces - stripped of any headers. - - {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different - PRF. Because the rekeying exchange belongs to the old IKE_SA, it is - the old IKE_SA's PRF that is used. Note that this may not work if - the new IKE_SA's PRF has a fixed key size because the output of the - PRF may not be of the correct size. - - The new IKE_SA MUST reset its message counters to 0. - - SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as - specified in Section 2.14. - - - -Hoffman Expires July 5, 2006 [Page 46] - -Internet-Draft IKEv2 January 2006 - - -2.19. Requesting an Internal Address on a Remote Network - - Most commonly occurring in the endpoint-to-security-gateway scenario, - an endpoint may need an IP address in the network protected by the - security gateway and may need to have that address dynamically - assigned. A request for such a temporary address can be included in - any request to create a CHILD_SA (including the implicit request in - message 3) by including a CP payload. - - This function provides address allocation to an IPsec Remote Access - Client (IRAC) trying to tunnel into a network protected by an IPsec - Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an - IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled - address (and optionally other information concerning the protected - network) in the IKE_AUTH exchange. The IRAS may procure an address - for the IRAC from any number of sources such as a DHCP/BOOTP server - or its own address pool. - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {IDi, [CERT,] - [CERTREQ,] [IDr,] AUTH, - CP(CFG_REQUEST), SAi2, - TSi, TSr} --> - <-- HDR, SK {IDr, [CERT,] AUTH, - CP(CFG_REPLY), SAr2, - TSi, TSr} - - In all cases, the CP payload MUST be inserted before the SA payload. - In variations of the protocol where there are multiple IKE_AUTH - exchanges, the CP payloads MUST be inserted in the messages - containing the SA payloads. - - CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute - (either IPv4 or IPv6) but MAY contain any number of additional - attributes the initiator wants returned in the response. - - For example, message from initiator to responder: - - {{ Clarif-6.3 }} - - CP(CFG_REQUEST)= - INTERNAL_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) - - NOTE: Traffic Selectors contain (protocol, port range, address - range). - - - -Hoffman Expires July 5, 2006 [Page 47] - -Internet-Draft IKEv2 January 2006 - - - Message from responder to initiator: - - CP(CFG_REPLY)= - INTERNAL_ADDRESS(192.0.2.202) - INTERNAL_NETMASK(255.255.255.0) - INTERNAL_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535,192.0.2.202-192.0.2.202) - TSr = (0, 0-65535,192.0.2.0-192.0.2.255) - - All returned values will be implementation dependent. As can be seen - in the above example, the IRAS MAY also send other attributes that - were not included in CP(CFG_REQUEST) and MAY ignore the non- - mandatory attributes that it does not support. - - The responder MUST NOT send a CFG_REPLY without having first received - a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS - to perform an unnecessary configuration lookup if the IRAC cannot - process the REPLY. In the case where the IRAS's configuration - requires that CP be used for a given identity IDi, but IRAC has - failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and - terminate the IKE exchange with a FAILED_CP_REQUIRED error. - -2.20. Requesting the Peer's Version - - An IKE peer wishing to inquire about the other peer's IKE software - version information MAY use the method below. This is an example of - a configuration request within an INFORMATIONAL exchange, after the - IKE_SA and first CHILD_SA have been created. - - An IKE implementation MAY decline to give out version information - prior to authentication or even after authentication to prevent - trolling in case some implementation is known to have some security - weakness. In that case, it MUST either return an empty string or no - CP payload if CP is not supported. - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK{CP(CFG_REQUEST)} --> - <-- HDR, SK{CP(CFG_REPLY)} - - CP(CFG_REQUEST)= - APPLICATION_VERSION("") - - CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar - Inc.") - - - - - - -Hoffman Expires July 5, 2006 [Page 48] - -Internet-Draft IKEv2 January 2006 - - -2.21. Error Handling - - There are many kinds of errors that can occur during IKE processing. - If a request is received that is badly formatted or unacceptable for - reasons of policy (e.g., no matching cryptographic algorithms), the - response MUST contain a Notify payload indicating the error. If an - error occurs outside the context of an IKE request (e.g., the node is - getting ESP messages on a nonexistent SPI), the node SHOULD initiate - an INFORMATIONAL exchange with a Notify payload describing the - problem. - - Errors that occur before a cryptographically protected IKE_SA is - established must be handled very carefully. There is a trade-off - between wanting to be helpful in diagnosing a problem and responding - to it and wanting to avoid being a dupe in a denial of service attack - based on forged messages. - - If a node receives a message on UDP port 500 or 4500 outside the - context of an IKE_SA known to it (and not a request to start one), it - may be the result of a recent crash of the node. If the message is - marked as a response, the node MAY audit the suspicious event but - MUST NOT respond. If the message is marked as a request, the node - MAY audit the suspicious event and MAY send a response. 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. The response MUST NOT be cryptographically protected and - MUST contain a Notify payload indicating INVALID_IKE_SPI. - - A node receiving such an unprotected Notify payload MUST NOT respond - and MUST NOT change the state of any existing SAs. The message might - be a forgery or might be a response the genuine correspondent was - tricked into sending. {{ Demoted two SHOULDs }} A node should treat - such a message (and also a network message like ICMP destination - unreachable) as a hint that there might be problems with SAs to that - IP address and should initiate a liveness test for any such IKE_SA. - An implementation SHOULD limit the frequency of such tests to avoid - being tricked into participating in a denial of service attack. - - A node receiving a suspicious message from an IP address with which - it has an IKE_SA MAY send an IKE Notify payload in an IKE - INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The - recipient MUST NOT change the state of any SAs as a result but may - wish to audit the event to aid in diagnosing malfunctions. A node - MUST limit the rate at which it will send messages in response to - unprotected messages. - - - - - - -Hoffman Expires July 5, 2006 [Page 49] - -Internet-Draft IKEv2 January 2006 - - -2.22. IPComp - - Use of IP compression [IPCOMP] can be negotiated as part of the setup - of a CHILD_SA. While IP compression involves an extra header in each - packet and a compression parameter index (CPI), the virtual - "compression association" has no life outside the ESP or AH SA that - contains it. Compression associations disappear when the - corresponding ESP or AH SA goes away. It is not explicitly mentioned - in any DELETE payload. - - Negotiation of IP compression is separate from the negotiation of - cryptographic parameters associated with a CHILD_SA. A node - requesting a CHILD_SA MAY advertise its support for one or more - compression algorithms through one or more Notify payloads of type - IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single - compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. - These payloads MUST NOT occur in messages that do not contain SA - payloads. - - Although there has been discussion of allowing multiple compression - algorithms to be accepted and to have different compression - algorithms available for the two directions of a CHILD_SA, - implementations of this specification MUST NOT accept an IPComp - algorithm that was not proposed, MUST NOT accept more than one, and - MUST NOT compress using an algorithm other than one proposed and - accepted in the setup of the CHILD_SA. - - A side effect of separating the negotiation of IPComp from - cryptographic parameters is that it is not possible to propose - multiple cryptographic suites and propose IP compression with some of - them but not others. - -2.23. NAT Traversal - - Network Address Translation (NAT) gateways are a controversial - subject. This section briefly describes what they are and how they - are likely to act on IKE traffic. Many people believe that NATs are - evil and that we should not design our protocols so as to make them - work better. IKEv2 does specify some unintuitive processing rules in - order that NATs are more likely to work. - - NATs exist primarily because of the shortage of IPv4 addresses, - though there are other rationales. IP nodes that are "behind" a NAT - have IP addresses that are not globally unique, but rather are - assigned from some space that is unique within the network behind the - NAT but that are likely to be reused by nodes behind other NATs. - Generally, nodes behind NATs can communicate with other nodes behind - the same NAT and with nodes with globally unique addresses, but not - - - -Hoffman Expires July 5, 2006 [Page 50] - -Internet-Draft IKEv2 January 2006 - - - with nodes behind other NATs. There are exceptions to that rule. - When those nodes make connections to nodes on the real Internet, the - NAT gateway "translates" the IP source address to an address that - will be routed back to the gateway. Messages to the gateway from the - Internet have their destination addresses "translated" to the - internal address that will route the packet to the correct endnode. - - NATs are designed to be "transparent" to endnodes. Neither software - on the node behind the NAT nor the node on the Internet requires - modification to communicate through the NAT. Achieving this - transparency is more difficult with some protocols than with others. - Protocols that include IP addresses of the endpoints within the - payloads of the packet will fail unless the NAT gateway understands - the protocol and modifies the internal references as well as those in - the headers. Such knowledge is inherently unreliable, is a network - layer violation, and often results in subtle problems. - - Opening an IPsec connection through a NAT introduces special - problems. If the connection runs in transport mode, changing the IP - addresses on packets will cause the checksums to fail and the NAT - cannot correct the checksums because they are cryptographically - protected. Even in tunnel mode, there are routing problems because - transparently translating the addresses of AH and ESP packets - requires special logic in the NAT and that logic is heuristic and - unreliable in nature. For that reason, IKEv2 can negotiate UDP - encapsulation of IKE and ESP packets. This encoding is slightly less - efficient but is easier for NATs to process. In addition, firewalls - may be configured to pass IPsec traffic over UDP but not ESP/AH or - vice versa. - - It is a common practice of NATs to translate TCP and UDP port numbers - as well as addresses and use the port numbers of inbound packets to - decide which internal node should get a given packet. For this - reason, even though IKE packets MUST be sent from and to UDP port - 500, they MUST be accepted coming from any port and responses MUST be - sent to the port from whence they came. This is because the ports - may be modified as the packets pass through NATs. Similarly, IP - addresses of the IKE endpoints are generally not included in the IKE - payloads because the payloads are cryptographically protected and - could not be transparently modified by NATs. - - Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working - through a NAT, it is generally better to pass IKE packets over port - 4500 because some older NATs handle IKE traffic on port 500 cleverly - in an attempt to transparently establish IPsec connections between - endpoints that don't handle NAT traversal themselves. Such NATs may - interfere with the straightforward NAT traversal envisioned by this - document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT - - - -Hoffman Expires July 5, 2006 [Page 51] - -Internet-Draft IKEv2 January 2006 - - - between it and its correspondent MUST send all subsequent traffic - from port 4500, which NATs should not treat specially (as they might - with port 500). - - The specific requirements for supporting NAT traversal [NATREQ] are - listed below. Support for NAT traversal is optional. In this - section only, requirements listed as MUST apply only to - implementations supporting NAT traversal. - - o IKE MUST listen on port 4500 as well as port 500. IKE MUST - respond to the IP address and port from which packets arrived. - - o Both IKE initiator and responder MUST include in their IKE_SA_INIT - packets Notify payloads of type NAT_DETECTION_SOURCE_IP and - NAT_DETECTION_DESTINATION_IP. Those payloads can be used to - detect if there is NAT between the hosts, and which end is behind - the NAT. The location of the payloads in the IKE_SA_INIT packets - are just after the Ni and Nr payloads (before the optional CERTREQ - payload). - - o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches - the hash of the source IP and port found from the IP header of the - packet containing the payload, it means that the other end is - behind NAT (i.e., someone along the route changed the source - address of the original packet to match the address of the NAT - box). In this case, this end should allow dynamic update of the - other ends IP address, as described later. - - o If the NAT_DETECTION_DESTINATION_IP payload received does not - match the hash of the destination IP and port found from the IP - header of the packet containing the payload, it means that this - end is behind a NAT. In this case, this end SHOULD start sending - keepalive packets as explained in [UDPENCAPS]. - - o 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. - - o 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. To tunnel ESP packets over UDP port 4500, the ESP - header immediately follows the UDP header. Since the first four - bytes of the ESP header contain the SPI, and the SPI cannot - validly be zero, it is always possible to distinguish ESP and IKE - messages. - - - - - -Hoffman Expires July 5, 2006 [Page 52] - -Internet-Draft IKEv2 January 2006 - - - o The original source and destination IP address required for the - transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) - are obtained from the Traffic Selectors associated with the - exchange. In the case of NAT traversal, the Traffic Selectors - MUST contain exactly one IP address, which is then used as the - original IP address. - - o There are cases where a NAT box decides to remove mappings that - are still alive (for example, the keepalive interval is too long, - or the NAT box is rebooted). To recover in these cases, hosts - that are not behind a NAT SHOULD send all packets (including - retransmission packets) to the IP address and port from the last - valid authenticated packet from the other end (i.e., dynamically - update the address). {{ Promoted the SHOULD }} A host behind a NAT - MUST NOT do this because it opens a DoS attack possibility. Any - authenticated IKE packet or any authenticated UDP-encapsulated ESP - packet can be used to detect that the IP address or the port has - changed. - - Note that similar but probably not identical actions will likely be - needed to make IKE work with Mobile IP, but such processing is not - addressed by this document. - -2.24. Explicit Congestion Notification (ECN) - - When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], - ECN usage is not appropriate for the outer IP headers because tunnel - decapsulation processing discards ECN congestion indications to the - detriment of the network. ECN support for IPsec tunnels for IKEv1- - based IPsec requires multiple operating modes and negotiation (see - [ECN]). IKEv2 simplifies this situation by requiring that ECN be - usable in the outer IP headers of all tunnel-mode IPsec SAs created - by IKEv2. Specifically, tunnel encapsulators and decapsulators for - all tunnel-mode SAs created by IKEv2 MUST support the ECN full- - functionality option for tunnels specified in [ECN] and MUST - implement the tunnel encapsulation and decapsulation processing - specified in [IPSECARCH] to prevent discarding of ECN congestion - indications. - - -3. Header and Payload Formats - -3.1. The IKE Header - - IKE messages use UDP ports 500 and/or 4500, with one IKE message per - UDP datagram. Information from the beginning of the packet through - the UDP header is largely ignored except that the IP addresses and - UDP ports from the headers are reversed and used for return packets. - - - -Hoffman Expires July 5, 2006 [Page 53] - -Internet-Draft IKEv2 January 2006 - - - When sent on UDP port 500, IKE messages begin immediately following - the UDP header. When sent on UDP port 4500, IKE messages have - prepended four octets of zero. These four octets of zero are not - part of the IKE message and are not included in any of the length - fields or checksums defined by IKE. Each IKE message begins with the - IKE header, denoted HDR in this memo. Following the header are one - or more IKE payloads each identified by a "Next Payload" field in the - preceding payload. Payloads are processed in the order in which they - appear in an IKE message by invoking the appropriate processing - routine according to the "Next Payload" field in the IKE header and - subsequently according to the "Next Payload" field in the IKE payload - itself until a "Next Payload" field of zero indicates that no - payloads follow. If a payload of type "Encrypted" is found, that - payload is decrypted and its contents parsed as additional payloads. - An Encrypted payload MUST be the last payload in a packet and an - Encrypted payload MUST NOT contain another Encrypted payload. - - The Recipient SPI in the header identifies an instance of an IKE - security association. It is therefore possible for a single instance - of IKE to multiplex distinct sessions with multiple peers. - - All multi-octet fields representing integers are laid out in big - endian order (aka most significant byte first, or network byte - order). - - The format of the IKE header is shown in Figure 4. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! IKE_SA Initiator's SPI ! - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! IKE_SA Responder's SPI ! - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Message ID ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: IKE Header Format - - o Initiator's SPI (8 octets) - A value chosen by the initiator to - identify a unique IKE security association. This value MUST NOT - be zero. - - - -Hoffman Expires July 5, 2006 [Page 54] - -Internet-Draft IKEv2 January 2006 - - - o Responder's SPI (8 octets) - A value chosen by the responder to - identify a unique IKE security association. This value MUST be - zero in the first message of an IKE Initial Exchange (including - repeats of that message including a cookie). {{ The phrase "and - MUST NOT be zero in any other message" was removed; Clarif-2.1 }} - - o Next Payload (1 octet) - Indicates the type of payload that - immediately follows the header. The format and value of each - payload are defined below. - - o Major Version (4 bits) - Indicates the major version of the IKE - protocol in use. Implementations based on this version of IKE - MUST set the Major Version to 2. Implementations based on - previous versions of IKE and ISAKMP MUST set the Major Version to - 1. Implementations based on this version of IKE MUST reject or - ignore messages containing a version number greater than 2. - - o Minor Version (4 bits) - Indicates the minor version of the IKE - protocol in use. Implementations based on this version of IKE - MUST set the Minor Version to 0. They MUST ignore the minor - version number of received messages. - - o Exchange Type (1 octet) - Indicates the type of exchange being - used. This constrains the payloads sent in each message and - orderings of messages in an exchange. - - Exchange Type Value - ---------------------------------- - RESERVED 0-33 - IKE_SA_INIT 34 - IKE_AUTH 35 - CREATE_CHILD_SA 36 - INFORMATIONAL 37 - RESERVED TO IANA 38-239 - Reserved for private use 240-255 - - o Flags (1 octet) - Indicates specific options that are set for the - message. Presence of options are indicated by the appropriate bit - in the flags field being set. The bits are defined LSB first, so - bit 0 would be the least significant bit of the Flags octet. In - the description below, a bit being 'set' means its value is '1', - while 'cleared' means its value is '0'. - - * X(reserved) (bits 0-2) - These bits MUST be cleared when - sending and MUST be ignored on receipt. - - * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages - sent by the original initiator of the IKE_SA and MUST be - - - -Hoffman Expires July 5, 2006 [Page 55] - -Internet-Draft IKEv2 January 2006 - - - cleared in messages sent by the original responder. It is used - by the recipient to determine which eight octets of the SPI - were generated by the recipient. - - * V(ersion) (bit 4 of Flags) - This bit indicates that the - transmitter is capable of speaking a higher major version - number of the protocol than the one indicated in the major - version number field. Implementations of IKEv2 must clear this - bit when sending and MUST ignore it in incoming messages. - - * R(esponse) (bit 5 of Flags) - This bit indicates that this - message is a response to a message containing the same message - ID. This bit MUST be cleared in all request messages and MUST - be set in all responses. An IKE endpoint MUST NOT generate a - response to a message that is marked as being a response. - - * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared - when sending and MUST be ignored on receipt. - - o Message ID (4 octets) - Message identifier used to control - retransmission of lost packets and matching of requests and - responses. It is essential to the security of the protocol - because it is used to prevent message replay attacks. See - Section 2.1 and Section 2.2. - - o Length (4 octets) - Length of total message (header + payloads) in - octets. - -3.2. Generic Payload Header - - Each IKE payload defined in Section 3.3 through Section 3.16 begins - with a generic payload header, shown in Figure 5. Figures for each - payload below will include the generic payload header, but for - brevity the description of each field will be omitted. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 5: Generic Payload Header - - The Generic Payload Header fields are defined as follows: - - o Next Payload (1 octet) - Identifier for the payload type of the - next payload in the message. If the current payload is the last - in the message, then this field will be 0. This field provides a - - - -Hoffman Expires July 5, 2006 [Page 56] - -Internet-Draft IKEv2 January 2006 - - - "chaining" capability whereby additional payloads can be added to - a message by appending it to the end of the message and setting - the "Next Payload" field of the preceding payload to indicate the - new payload's type. An Encrypted payload, which must always be - the last payload of a message, is an exception. It contains data - structures in the format of additional payloads. In the header of - an Encrypted payload, the Next Payload field is set to the payload - type of the first contained payload (instead of 0). The payload - type values are: - - Next Payload Type Notation Value - -------------------------------------------------- - No Next Payload 0 - RESERVED 1-32 - Security Association SA 33 - Key Exchange KE 34 - Identification - Initiator IDi 35 - Identification - Responder IDr 36 - Certificate CERT 37 - Certificate Request CERTREQ 38 - Authentication AUTH 39 - Nonce Ni, Nr 40 - Notify N 41 - Delete D 42 - Vendor ID V 43 - Traffic Selector - Initiator TSi 44 - Traffic Selector - Responder TSr 45 - Encrypted E 46 - Configuration CP 47 - Extensible Authentication EAP 48 - RESERVED TO IANA 49-127 - PRIVATE USE 128-255 - - (Payload type values 1-32 should not be assigned in the - future so that there is no overlap with the code assignments - for IKEv1.) - - o Critical (1 bit) - MUST be set to zero if the sender wants the - recipient to skip this payload if it does not understand the - payload type code in the Next Payload field of the previous - payload. MUST be set to one if the sender wants the recipient to - reject this entire message if it does not understand the payload - type. MUST be ignored by the recipient if the recipient - understands the payload type code. MUST be set to zero for - payload types defined in this document. Note that the critical - bit applies to the current payload rather than the "next" payload - whose type code appears in the first octet. The reasoning behind - not setting the critical bit for payloads defined in this document - - - -Hoffman Expires July 5, 2006 [Page 57] - -Internet-Draft IKEv2 January 2006 - - - is that all implementations MUST understand all payload types - defined in this document and therefore must ignore the Critical - bit's value. Skipped payloads are expected to have valid Next - Payload and Payload Length fields. - - o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on - receipt. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - -3.3. Security Association Payload - - The Security Association Payload, denoted SA in this memo, is used to - negotiate attributes of a security association. Assembly of Security - Association Payloads requires great peace of mind. An SA payload MAY - contain multiple proposals. If there is more than one, they MUST be - ordered from most preferred to least preferred. Each proposal may - contain multiple IPsec protocols (where a protocol is IKE, ESP, or - AH), each protocol MAY contain multiple transforms, and each - transform MAY contain multiple attributes. When parsing an SA, an - implementation MUST check that the total Payload Length is consistent - with the payload's internal lengths and counts. Proposals, - Transforms, and Attributes each have their own variable length - encodings. They are nested such that the Payload Length of an SA - includes the combined contents of the SA, Proposal, Transform, and - Attribute information. The length of a Proposal includes the lengths - of all Transforms and Attributes it contains. The length of a - Transform includes the lengths of all Attributes it contains. - - The syntax of Security Associations, Proposals, Transforms, and - Attributes is based on ISAKMP; however the semantics are somewhat - different. The reason for the complexity and the hierarchy is to - allow for multiple possible combinations of algorithms to be encoded - in a single SA. Sometimes there is a choice of multiple algorithms, - whereas other times there is a combination of algorithms. For - example, an initiator might want to propose using (AH w/MD5 and ESP - w/3DES) OR (ESP w/MD5 and 3DES). - - One of the reasons the semantics of the SA payload has changed from - ISAKMP and IKEv1 is to make the encodings more compact in common - cases. - - The Proposal structure contains within it a Proposal # and an IPsec - protocol ID. Each structure MUST have the same Proposal # as the - previous one or be one (1) greater. The first Proposal MUST have a - Proposal # of one (1). If two successive structures have the same - Proposal number, it means that the proposal consists of the first - - - -Hoffman Expires July 5, 2006 [Page 58] - -Internet-Draft IKEv2 January 2006 - - - structure AND the second. So a proposal of AH AND ESP would have two - proposal structures, one for AH and one for ESP and both would have - Proposal #1. A proposal of AH OR ESP would have two proposal - structures, one for AH with Proposal #1 and one for ESP with Proposal - #2. - - Each Proposal/Protocol structure is followed by one or more transform - structures. The number of different transforms is generally - determined by the Protocol. AH generally has a single transform: an - integrity check algorithm. ESP generally has two: an encryption - algorithm and an integrity check algorithm. IKE generally has four - transforms: a Diffie-Hellman group, an integrity check algorithm, a - prf algorithm, and an encryption algorithm. If an algorithm that - combines encryption and integrity protection is proposed, it MUST be - proposed as an encryption algorithm and an integrity protection - algorithm MUST NOT be proposed. For each Protocol, the set of - permissible transforms is assigned transform ID numbers, which appear - in the header of each transform. - - If there are multiple transforms with the same Transform Type, the - proposal is an OR of those transforms. If there are multiple - Transforms with different Transform Types, the proposal is an AND of - the different groups. For example, to propose ESP with (3DES or - IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two - Transform Type 1 candidates (one for 3DES and one for IDEA) and two - Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). - This effectively proposes four combinations of algorithms. If the - initiator wanted to propose only a subset of those, for example (3DES - and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that - as multiple transforms within a single Proposal. Instead, the - initiator would have to construct two different Proposals, each with - two transforms. - - A given transform MAY have one or more Attributes. Attributes are - necessary when the transform can be used in more than one way, as - when an encryption algorithm has a variable key size. The transform - would specify the algorithm and the attribute would specify the key - size. Most transforms do not have attributes. A transform MUST NOT - have multiple attributes of the same type. To propose alternate - values for an attribute (for example, multiple key sizes for the AES - encryption algorithm), and implementation MUST include multiple - Transforms with the same Transform Type each with a single Attribute. - - Note that the semantics of Transforms and Attributes are quite - different from those in IKEv1. In IKEv1, a single Transform carried - multiple algorithms for a protocol with one carried in the Transform - and the others carried in the Attributes. - - - - -Hoffman Expires July 5, 2006 [Page 59] - -Internet-Draft IKEv2 January 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: Security Association Payload - - o Proposals (variable) - One or more proposal substructures. - - The payload type for the Security Association Payload is thirty three - (33). - -3.3.1. Proposal Substructure - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 (last) or 2 ! RESERVED ! Proposal Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ SPI (variable) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7: Proposal Substructure - - o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the - last Proposal Substructure in the SA. This syntax is inherited - from ISAKMP, but is unnecessary because the last Proposal could be - identified from the length of the SA. The value (2) corresponds - to a Payload Type of Proposal in IKEv1, and the first four octets - of the Proposal structure are designed to look somewhat like the - header of a Payload. - - o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on - receipt. - - o Proposal Length (2 octets) - Length of this proposal, including - all transforms and attributes that follow. - - - -Hoffman Expires July 5, 2006 [Page 60] - -Internet-Draft IKEv2 January 2006 - - - o Proposal # (1 octet) - When a proposal is made, the first proposal - in an SA payload MUST be #1, and subsequent proposals MUST either - be the same as the previous proposal (indicating an AND of the two - proposals) or one more than the previous proposal (indicating an - OR of the two proposals). When a proposal is accepted, all of the - proposal numbers in the SA payload MUST be the same and MUST match - the number on the proposal sent that was accepted. - - o Protocol ID (1 octet) - Specifies the IPsec protocol identifier - for the current negotiation. The defined values are: - - Protocol Protocol ID - ----------------------------------- - RESERVED 0 - IKE 1 - AH 2 - ESP 3 - RESERVED TO IANA 4-200 - PRIVATE USE 201-255 - - o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field - MUST be zero; the SPI is obtained from the outer header. During - subsequent negotiations, it is equal to the size, in octets, of - the SPI of the corresponding protocol (8 for IKE, 4 for ESP and - AH). - - o # of Transforms (1 octet) - Specifies the number of transforms in - this proposal. - - o SPI (variable) - The sending entity's SPI. Even if the SPI Size - is not a multiple of 4 octets, there is no padding applied to the - payload. When the SPI Size field is zero, this field is not - present in the Security Association payload. - - o Transforms (variable) - One or more transform substructures. - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 61] - -Internet-Draft IKEv2 January 2006 - - -3.3.2. Transform Substructure - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 (last) or 3 ! RESERVED ! Transform Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !Transform Type ! RESERVED ! Transform ID ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Transform Attributes ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 8: Transform Substructure - - o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the - last Transform Substructure in the Proposal. This syntax is - inherited from ISAKMP, but is unnecessary because the last - Proposal could be identified from the length of the SA. The value - (3) corresponds to a Payload Type of Transform in IKEv1, and the - first four octets of the Transform structure are designed to look - somewhat like the header of a Payload. - - o RESERVED - MUST be sent as zero; MUST be ignored on receipt. - - o Transform Length - The length (in octets) of the Transform - Substructure including Header and Attributes. - - o Transform Type (1 octet) - The type of transform being specified - in this transform. Different protocols support different - transform types. For some protocols, some of the transforms may - be optional. If a transform is optional and the initiator wishes - to propose that the transform be omitted, no transform of the - given type is included in the proposal. If the initiator wishes - to make use of the transform optional to the responder, it - includes a transform substructure with transform ID = 0 as one of - the options. - - o Transform ID (2 octets) - The specific instance of the transform - type being proposed. - - The tranform type values are: - - - - - - - - -Hoffman Expires July 5, 2006 [Page 62] - -Internet-Draft IKEv2 January 2006 - - - Description Trans. Used In - Type - ------------------------------------------------------------------ - RESERVED 0 - Encryption Algorithm (ENCR) 1 IKE and ESP - Pseudo-random Function (PRF) 2 IKE - Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP - Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP - Extended Sequence Numbers (ESN) 5 AH and ESP - RESERVED TO IANA 6-240 - PRIVATE USE 241-255 - - For Transform Type 1 (Encryption Algorithm), defined Transform IDs - are: - - Name Number Defined In - --------------------------------------------------- - RESERVED 0 - ENCR_DES_IV64 1 (RFC1827) - ENCR_DES 2 (RFC2405), [DES] - ENCR_3DES 3 (RFC2451) - ENCR_RC5 4 (RFC2451) - ENCR_IDEA 5 (RFC2451), [IDEA] - ENCR_CAST 6 (RFC2451) - ENCR_BLOWFISH 7 (RFC2451) - ENCR_3IDEA 8 (RFC2451) - ENCR_DES_IV32 9 - RESERVED 10 - ENCR_NULL 11 (RFC2410) - ENCR_AES_CBC 12 (RFC3602) - ENCR_AES_CTR 13 (RFC3664) - RESERVED TO IANA 14-1023 - PRIVATE USE 1024-65535 - - For Transform Type 2 (Pseudo-random Function), defined Transform IDs - are: - - Name Number Defined In - ------------------------------------------------------ - RESERVED 0 - PRF_HMAC_MD5 1 (RFC2104), [MD5] - PRF_HMAC_SHA1 2 (RFC2104), [SHA] - PRF_HMAC_TIGER 3 (RFC2104) - PRF_AES128_XCBC 4 (RFC3664) - RESERVED TO IANA 5-1023 - PRIVATE USE 1024-65535 - - For Transform Type 3 (Integrity Algorithm), defined Transform IDs - - - -Hoffman Expires July 5, 2006 [Page 63] - -Internet-Draft IKEv2 January 2006 - - - are: - - Name Number Defined In - ---------------------------------------- - NONE 0 - AUTH_HMAC_MD5_96 1 (RFC2403) - AUTH_HMAC_SHA1_96 2 (RFC2404) - AUTH_DES_MAC 3 - AUTH_KPDK_MD5 4 (RFC1826) - AUTH_AES_XCBC_96 5 (RFC3566) - RESERVED TO IANA 6-1023 - PRIVATE USE 1024-65535 - - For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs - are: - - Name Number - -------------------------------------- - NONE 0 - Defined in Appendix B 1 - 2 - RESERVED 3 - 4 - Defined in [ADDGROUP] 5 - RESERVED TO IANA 6 - 13 - Defined in [ADDGROUP] 14 - 18 - RESERVED TO IANA 19 - 1023 - PRIVATE USE 1024-65535 - - For Transform Type 5 (Extended Sequence Numbers), defined Transform - IDs are: - - Name Number - -------------------------------------------- - No Extended Sequence Numbers 0 - Extended Sequence Numbers 1 - RESERVED 2 - 65535 - -3.3.3. Valid Transform Types by Protocol - - The number and type of transforms that accompany an SA payload are - dependent on the protocol in the SA itself. An SA payload proposing - the establishment of an SA has the following mandatory and optional - transform types. A compliant implementation MUST understand all - mandatory and optional types for each protocol it supports (though it - need not accept proposals with unacceptable suites). A proposal MAY - omit the optional types if the only value for them it will accept is - NONE. - - - - - -Hoffman Expires July 5, 2006 [Page 64] - -Internet-Draft IKEv2 January 2006 - - - Protocol Mandatory Types Optional Types - --------------------------------------------------- - IKE ENCR, PRF, INTEG, D-H - ESP ENCR, ESN INTEG, D-H - AH INTEG, ESN D-H - -3.3.4. Mandatory Transform IDs - - The specification of suites that MUST and SHOULD be supported for - interoperability has been removed from this document because they are - likely to change more rapidly than this document evolves. - - An important lesson learned from IKEv1 is that no system should only - implement the mandatory algorithms and expect them to be the best - choice for all customers. For example, at the time that this - document was written, many IKEv1 implementers were starting to - migrate to AES in Cipher Block Chaining (CBC) mode for Virtual - Private Network (VPN) applications. Many IPsec systems based on - IKEv2 will implement AES, additional Diffie-Hellman groups, and - additional hash algorithms, and some IPsec customers already require - these algorithms in addition to the ones listed above. - - It is likely that IANA will add additional transforms in the future, - and some users may want to use private suites, especially for IKE - where implementations should be capable of supporting different - parameters, up to certain size limits. In support of this goal, all - implementations of IKEv2 SHOULD include a management facility that - allows specification (by a user or system administrator) of Diffie- - Hellman (DH) parameters (the generator, modulus, and exponent lengths - and values) for new DH groups. Implementations SHOULD provide a - management interface through which these parameters and the - associated transform IDs may be entered (by a user or system - administrator), to enable negotiating such groups. - - All implementations of IKEv2 MUST include a management facility that - enables a user or system administrator to specify the suites that are - acceptable for use with IKE. Upon receipt of a payload with a set of - transform IDs, the implementation MUST compare the transmitted - transform IDs against those locally configured via the management - controls, to verify that the proposed suite is acceptable based on - local policy. The implementation MUST reject SA proposals that are - not authorized by these IKE suite controls. Note that cryptographic - suites that MUST be implemented need not be configured as acceptable - to local policy. - - - - - - - -Hoffman Expires July 5, 2006 [Page 65] - -Internet-Draft IKEv2 January 2006 - - -3.3.5. Transform Attributes - - Each transform in a Security Association payload may include - attributes that modify or complete the specification of the - transform. These attributes are type/value pairs and are defined - below. For example, if an encryption algorithm has a variable-length - key, the key length to be used may be specified as an attribute. - Attributes can have a value with a fixed two octet length or a - variable-length value. For the latter, the attribute is encoded as - type/length/value. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !A! Attribute Type ! AF=0 Attribute Length ! - !F! ! AF=1 Attribute Value ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! AF=0 Attribute Value ! - ! AF=1 Not Transmitted ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 9: Data Attributes - - o Attribute Type (2 octets) - Unique identifier for each type of - attribute (see below). The most significant bit of this field is - the Attribute Format bit (AF). It indicates whether the data - attributes follow the Type/Length/Value (TLV) format or a - shortened Type/Value (TV) format. If the AF bit is zero (0), then - the Data Attributes are of the Type/Length/Value (TLV) form. If - the AF bit is a one (1), then the Data Attributes are of the Type/ - Value form. - - o Attribute Length (2 octets) - Length in octets of the Attribute - Value. When the AF bit is a one (1), the Attribute Value is only - 2 octets and the Attribute Length field is not present. - - o Attribute Value (variable length) - Value of the Attribute - associated with the Attribute Type. If the AF bit is a zero (0), - this field has a variable length defined by the Attribute Length - field. If the AF bit is a one (1), the Attribute Value has a - length of 2 octets. - - o Key Length - When using an Encryption Algorithm that has a - variable-length key, this attribute specifies the key length in - bits (MUST use network byte order). This attribute MUST NOT be - used when the specified Encryption Algorithm uses a fixed-length - key. - - - - -Hoffman Expires July 5, 2006 [Page 66] - -Internet-Draft IKEv2 January 2006 - - - Note that only a single attribute type (Key Length) is defined, and - it is fixed length. The variable-length encoding specification is - included only for future extensions. {{ Clarif-7.11 removed the - sentence that listed, incorrectly, the algorithms defined in the - document that accept attributes. }} - - Attributes described as basic MUST NOT be encoded using the variable- - length encoding. Variable-length attributes MUST NOT be encoded as - basic even if their value can fit into two octets. NOTE: This is a - change from IKEv1, where increased flexibility may have simplified - the composer of messages but certainly complicated the parser. - - Attribute Type Value Attribute Format - ------------------------------------------------------------ - RESERVED 0-13 - Key Length (in bits) 14 TV - RESERVED 15-17 - RESERVED TO IANA 18-16383 - PRIVATE USE 16384-32767 - Values 0-13 and 15-17 were used in a similar context in - IKEv1, and should not be assigned except to matching values. - -3.3.6. Attribute Negotiation - - During security association negotiation initiators present offers to - responders. Responders MUST select a single complete set of - parameters from the offers (or reject all offers if none are - acceptable). If there are multiple proposals, the responder MUST - choose a single proposal number and return all of the Proposal - substructures with that Proposal number. If there are multiple - Transforms with the same type, the responder MUST choose a single - one. Any attributes of a selected transform MUST be returned - unmodified. The initiator of an exchange MUST check that the - accepted offer is consistent with one of its proposals, and if not - that response MUST be rejected. - - Negotiating Diffie-Hellman groups presents some special challenges. - SA offers include proposed attributes and a Diffie-Hellman public - number (KE) in the same message. If in the initial exchange the - initiator offers to use one of several Diffie-Hellman groups, it - SHOULD pick the one the responder is most likely to accept and - include a KE corresponding to that group. If the guess turns out to - be wrong, the responder will indicate the correct group in the - response and the initiator SHOULD pick an element of that group for - its KE value when retrying the first message. It SHOULD, however, - continue to propose its full supported set of groups in order to - prevent a man-in-the-middle downgrade attack. - - - - -Hoffman Expires July 5, 2006 [Page 67] - -Internet-Draft IKEv2 January 2006 - - - Implementation Note: - - Certain negotiable attributes can have ranges or could have multiple - acceptable values. These include the key length of a variable key - length symmetric cipher. To further interoperability and to support - upgrading endpoints independently, implementers of this protocol - SHOULD accept values that they deem to supply greater security. For - instance, if a peer is configured to accept a variable-length cipher - with a key length of X bits and is offered that cipher with a larger - key length, the implementation SHOULD accept the offer if it supports - use of the longer key. - - Support of this capability allows an implementation to express a - concept of "at least" a certain level of security-- "a key length of - _at least_ X bits for cipher Y". - -3.4. Key Exchange Payload - - The Key Exchange Payload, denoted KE in this memo, is used to - exchange Diffie-Hellman public numbers as part of a Diffie-Hellman - key exchange. The Key Exchange Payload consists of the IKE generic - payload header followed by the Diffie-Hellman public value itself. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! DH Group # ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Key Exchange Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 10: Key Exchange Payload Format - - A key exchange payload is constructed by copying one's Diffie-Hellman - public value into the "Key Exchange Data" portion of the payload. - The length of the Diffie-Hellman public value MUST be equal to the - length of the prime modulus over which the exponentiation was - performed, prepending zero bits to the value if necessary. - - The DH Group # identifies the Diffie-Hellman group in which the Key - Exchange Data was computed (see Section 3.3.2). If the selected - proposal uses a different Diffie-Hellman group, the message MUST be - rejected with a Notify payload of type INVALID_KE_PAYLOAD. - - - - -Hoffman Expires July 5, 2006 [Page 68] - -Internet-Draft IKEv2 January 2006 - - - The payload type for the Key Exchange payload is thirty four (34). - -3.5. Identification Payloads - - The Identification Payloads, denoted IDi and IDr in this memo, allow - peers to assert an identity to one another. This identity may be - used for policy lookup, but does not necessarily have to match - anything in the CERT payload; both fields may be used by an - implementation to perform access control decisions. {{ Clarif-7.1 }} - 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. - - NOTE: In IKEv1, two ID payloads were used in each direction to hold - Traffic Selector (TS) information for data passing over the SA. In - IKEv2, this information is carried in TS payloads (see Section 3.13). - - The Identification Payload consists of the IKE generic payload header - followed by identification fields as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ID Type ! RESERVED | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Identification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 11: Identification Payload Format - - o ID Type (1 octet) - Specifies the type of Identification being - used. - - o RESERVED - MUST be sent as zero; MUST be ignored on receipt. - - o Identification Data (variable length) - Value, as indicated by the - Identification Type. The length of the Identification Data is - computed from the size in the ID payload header. - - The payload types for the Identification Payload are thirty five (35) - for IDi and thirty six (36) for IDr. - - - - -Hoffman Expires July 5, 2006 [Page 69] - -Internet-Draft IKEv2 January 2006 - - - The following table lists the assigned values for the Identification - Type field: - - ID Type Value - ------------------------------------------------------------------- - RESERVED 0 - - ID_IPV4_ADDR 1 - A single four (4) octet IPv4 address. - - ID_FQDN 2 - A fully-qualified domain name string. An example of a ID_FQDN - is, "example.com". The string MUST not contain any terminators - (e.g., NULL, CR, etc.). - - ID_RFC822_ADDR 3 - A fully-qualified RFC822 email address string, An example of a - ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not - contain any terminators. - - RESERVED TO IANA 4 - - ID_IPV6_ADDR 5 - A single sixteen (16) octet IPv6 address. - - RESERVED TO IANA 6 - 8 - - ID_DER_ASN1_DN 9 - The binary Distinguished Encoding Rules (DER) encoding of an - ASN.1 X.500 Distinguished Name [X.501]. - - ID_DER_ASN1_GN 10 - The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. - - ID_KEY_ID 11 - An opaque octet stream which may be used to pass vendor- - specific information necessary to do certain proprietary - types of identification. - - RESERVED TO IANA 12-200 - - PRIVATE USE 201-255 - - Two implementations will interoperate only if each can generate a - type of ID acceptable to the other. To assure maximum - interoperability, implementations MUST be configurable to send at - least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and - MUST be configurable to accept all of these types. Implementations - - - -Hoffman Expires July 5, 2006 [Page 70] - -Internet-Draft IKEv2 January 2006 - - - SHOULD be capable of generating and accepting all of these types. - IPv6-capable implementations MUST additionally be configurable to - accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable - to send only ID_IPV6_ADDR. - - {{ Clarif-3.4 }} 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 same as the syntax of email address in [MAILFORMAT]. For those - NAIs that include the realm component, the ID_RFC822_ADDR - identification type SHOULD be used. Responder implementations should - not attempt to verify that the contents actually conform to the exact - syntax given in [MAILFORMAT], but instead should accept any - reasonable-looking NAI. For NAIs that do not include the realm - component,the ID_KEY_ID identification type SHOULD be used. - -3.6. Certificate Payload - - The Certificate Payload, denoted CERT in this memo, provides a means - to transport certificates or other authentication-related information - via IKE. Certificate payloads SHOULD be included in an exchange if - certificates are available to the sender unless the peer has - indicated an ability to retrieve this information from elsewhere - using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the - term "Certificate Payload" is somewhat misleading, because not all - authentication mechanisms use certificates and data other than - certificates may be passed in this payload. - - The Certificate Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert Encoding ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certificate Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 12: Certificate Payload Format - - o Certificate Encoding (1 octet) - This field indicates the type of - certificate or certificate-related information contained in the - Certificate Data field. - - - - -Hoffman Expires July 5, 2006 [Page 71] - -Internet-Draft IKEv2 January 2006 - - - Certificate Encoding Value - ------------------------------------------------- - RESERVED 0 - PKCS #7 wrapped X.509 certificate 1 - PGP Certificate 2 - DNS Signed Key 3 - X.509 Certificate - Signature 4 - Kerberos Token 6 - Certificate Revocation List (CRL) 7 - Authority Revocation List (ARL) 8 - SPKI Certificate 9 - X.509 Certificate - Attribute 10 - Raw RSA Key 11 - Hash and URL of X.509 certificate 12 - Hash and URL of X.509 bundle 13 - RESERVED to IANA 14 - 200 - PRIVATE USE 201 - 255 - - o Certificate Data (variable length) - Actual encoding of - certificate data. The type of certificate is indicated by the - Certificate Encoding field. - - The payload type for the Certificate Payload is thirty seven (37). - - Specific syntax is for some of the certificate type codes above is - not defined in this document. The types whose syntax is defined in - this document are: - - o X.509 Certificate - Signature (4) contains a DER encoded X.509 - certificate whose public key is used to validate the sender's AUTH - payload. - - o Certificate Revocation List (7) contains a DER encoded X.509 - certificate revocation list. - - o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.7 }} - Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a - DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). - - o Hash and URL encodings (12-13) allow IKE messages to remain short - by replacing long data structures with a 20 octet SHA-1 hash (see - [SHA]) of the replaced value followed by a variable-length URL - that resolves to the DER encoded data structure itself. This - improves efficiency when the endpoints have certificate data - cached and makes IKE less subject to denial of service attacks - that become easier to mount when IKE messages are large enough to - require IP fragmentation [DOSUDPPROT]. - - - - -Hoffman Expires July 5, 2006 [Page 72] - -Internet-Draft IKEv2 January 2006 - - - Use the following ASN.1 definition for an X.509 bundle: - - CertBundle - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-cert-bundle(34) } - - DEFINITIONS EXPLICIT TAGS ::= - BEGIN - - IMPORTS - Certificate, CertificateList - FROM PKIX1Explicit88 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) } ; - - CertificateOrCRL ::= CHOICE { - cert [0] Certificate, - crl [1] CertificateList } - - CertificateBundle ::= SEQUENCE OF CertificateOrCRL - - END - - Implementations MUST be capable of being configured to send and - accept up to four X.509 certificates in support of authentication, - and also MUST be capable of being configured to send and accept the - first two Hash and URL formats (with HTTP URLs). Implementations - SHOULD be capable of being configured to send and accept Raw RSA - keys. If multiple certificates are sent, the first certificate MUST - contain the public key used to sign the AUTH payload. The other - certificates may be sent in any order. - - {{ Clarif-3.7 }} Because the contents and use of some of the - certificate types are not defined, they SHOULD NOT be used. In - specific, implementations SHOULD NOT use the following types unless - they are later defined in a standards-track document: - - PKCS #7 wrapped X.509 certificate 1 - PGP Certificate 2 - DNS Signed Key 3 - Kerberos Token 6 - SPKI Certificate 9 - - - - - - - -Hoffman Expires July 5, 2006 [Page 73] - -Internet-Draft IKEv2 January 2006 - - -3.7. Certificate Request Payload - - The Certificate Request Payload, denoted CERTREQ in this memo, - provides a means to request preferred certificates via IKE and can - appear in the IKE_INIT_SA response and/or the IKE_AUTH request. - Certificate Request payloads MAY be included in an exchange when the - sender needs to get the certificate of the receiver. If multiple CAs - are trusted and the cert encoding does not allow a list, then - multiple Certificate Request payloads SHOULD be transmitted. - - The Certificate Request Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert Encoding ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certification Authority ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 13: Certificate Request Payload Format - - o Certificate Encoding (1 octet) - Contains an encoding of the type - or format of certificate requested. Values are listed in - Section 3.6. - - o Certification Authority (variable length) - Contains an encoding - of an acceptable certification authority for the type of - certificate requested. - - The payload type for the Certificate Request Payload is thirty eight - (38). - - The Certificate Encoding field has the same values as those defined - in Section 3.6. The Certification Authority field contains an - indicator of trusted authorities for this certificate type. The - Certification Authority value is a concatenated list of SHA-1 hashes - of the public keys of trusted Certification Authorities (CAs). Each - is encoded as the SHA-1 hash of the Subject Public Key Info element - (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. - The twenty-octet hashes are concatenated and included with no other - formatting. - - {{ Clarif-3.7 }} The contents of the "Certification Authority" field - are defined only for X.509 certificates, which are types 4, 10, 12, - - - -Hoffman Expires July 5, 2006 [Page 74] - -Internet-Draft IKEv2 January 2006 - - - and 13. Other values SHOULD NOT be used until standards-track - specifications that specify their use are published. - - Note that the term "Certificate Request" is somewhat misleading, in - that values other than certificates are defined in a "Certificate" - payload and requests for those values can be present in a Certificate - Request Payload. The syntax of the Certificate Request payload in - such cases is not defined in this document. - - The Certificate Request Payload is processed by inspecting the "Cert - Encoding" field to determine whether the processor has any - certificates of this type. If so, the "Certification Authority" - field is inspected to determine if the processor has any certificates - that can be validated up to one of the specified certification - authorities. This can be a chain of certificates. - - If an end-entity certificate exists that satisfies the criteria - specified in the CERTREQ, a certificate or certificate chain SHOULD - be sent back to the certificate requestor if the recipient of the - CERTREQ: - - o is configured to use certificate authentication, - - o is allowed to send a CERT payload, - - o has matching CA trust policy governing the current negotiation, - and - - o has at least one time-wise and usage appropriate end-entity - certificate chaining to a CA provided in the CERTREQ. - - Certificate revocation checking must be considered during the - chaining process used to select a certificate. Note that even if two - peers are configured to use two different CAs, cross-certification - relationships should be supported by appropriate selection logic. - - The intent is not to prevent communication through the strict - adherence of selection of a certificate based on CERTREQ, when an - alternate certificate could be selected by the sender that would - still enable the recipient to successfully validate and trust it - through trust conveyed by cross-certification, CRLs, or other out-of- - band configured means. Thus, the processing of a CERTREQ should be - seen as a suggestion for a certificate to select, not a mandated one. - If no certificates exist, then the CERTREQ is ignored. This is not - an error condition of the protocol. There may be cases where there - is a preferred CA sent in the CERTREQ, but an alternate might be - acceptable (perhaps after prompting a human operator). - - - - -Hoffman Expires July 5, 2006 [Page 75] - -Internet-Draft IKEv2 January 2006 - - -3.8. Authentication Payload - - The Authentication Payload, denoted AUTH in this memo, contains data - used for authentication purposes. The syntax of the Authentication - data varies according to the Auth Method as specified below. - - The Authentication Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Auth Method ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Authentication Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 14: Authentication Payload Format - - o Auth Method (1 octet) - Specifies the method of authentication - used. Values defined are: - - * RSA Digital Signature (1) - Computed as specified in - Section 2.15 using an RSA private key over a PKCS#1 padded hash - (see [RSA] and [PKCS1]). {{ Clarif-3.2 }} To promote - interoperability, implementations that support this type SHOULD - support signatures that use SHA-1 as the hash function and - SHOULD use SHA-1 as the default hash function when generating - signatures. {{ Clarif-3.3 }} A newer version of PKCS#1 (v2.1) - defines two different encoding methods (ways of "padding the - hash") for signatures. However, IKEv2 and this document point - specifically to the PKCS#1 v2.0 which has only one encoding - method for signatures (EMSA-PKCS1- v1_5). - - * Shared Key Message Integrity Code (2) - Computed as specified - in Section 2.15 using the shared key associated with the - identity in the ID payload and the negotiated prf function - - * DSS Digital Signature (3) - Computed as specified in - Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 - hash. - - * The values 0 and 4-200 are reserved to IANA. The values 201- - 255 are available for private use. - - - - -Hoffman Expires July 5, 2006 [Page 76] - -Internet-Draft IKEv2 January 2006 - - - o Authentication Data (variable length) - see Section 2.15. - - The payload type for the Authentication Payload is thirty nine (39). - -3.9. Nonce Payload - - The Nonce Payload, denoted Ni and Nr in this memo for the initiator's - and responder's nonce respectively, contains random data used to - guarantee liveness during an exchange and protect against replay - attacks. - - The Nonce Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Nonce Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 15: Nonce Payload Format - - o Nonce Data (variable length) - Contains the random data generated - by the transmitting entity. - - The payload type for the Nonce Payload is forty (40). - - The size of a Nonce MUST be between 16 and 256 octets inclusive. - Nonce values MUST NOT be reused. - -3.10. Notify Payload - - The Notify Payload, denoted N in this document, is used to transmit - informational data, such as error conditions and state transitions, - to an IKE peer. A Notify Payload may appear in a response message - (usually specifying why a request was rejected), in an INFORMATIONAL - Exchange (to report an error not in an IKE request), or in any other - message to indicate sender capabilities or to modify the meaning of - the request. - - The Notify Payload is defined as follows: - - - - - - - -Hoffman Expires July 5, 2006 [Page 77] - -Internet-Draft IKEv2 January 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol ID ! SPI Size ! Notify Message Type ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Notification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 16: Notify Payload Format - - o Protocol ID (1 octet) - If this notification concerns an existing - SA, this field indicates the type of that SA. For IKE_SA - notifications, this field MUST be one (1). For notifications - concerning IPsec SAs this field MUST contain either (2) to - indicate AH or (3) to indicate ESP. {{ Clarif-7.8 }} For - notifications that do not relate to an existing SA, this field - MUST be sent as zero and MUST be ignored on receipt; this is only - true for the INVALID_SELECTORS and REKEY_SA notifications. . All - other values for this field are reserved to IANA for future - assignment. - - o SPI Size (1 octet) - Length in octets of the SPI as defined by the - IPsec protocol ID or zero if no SPI is applicable. For a - notification concerning the IKE_SA, the SPI Size MUST be zero. - - o Notify Message Type (2 octets) - Specifies the type of - notification message. - - o SPI (variable length) - Security Parameter Index. - - o Notification Data (variable length) - Informational or error data - transmitted in addition to the Notify Message Type. Values for - this field are type specific (see below). - - The payload type for the Notify Payload is forty one (41). - -3.10.1. Notify Message Types - - Notification information can be error messages specifying why an SA - could not be established. It can also be status data that a process - - - -Hoffman Expires July 5, 2006 [Page 78] - -Internet-Draft IKEv2 January 2006 - - - managing an SA database wishes to communicate with a peer process. - The table below lists the Notification messages and their - corresponding values. The number of different error statuses was - greatly reduced from IKEv1 both for simplification and to avoid - giving configuration information to probers. - - Types in the range 0 - 16383 are intended for reporting errors. An - implementation receiving a Notify payload with one of these types - that it does not recognize in a response MUST assume that the - corresponding request has failed entirely. {{ Demoted the SHOULD }} - Unrecognized error types in a request and status types in a request - or response MUST be ignored, and they should be logged. - - Notify payloads with status types MAY be added to any message and - MUST be ignored if not recognized. They are intended to indicate - capabilities, and as part of SA negotiation are used to negotiate - non-cryptographic parameters. - - NOTIFY messages: error types Value - ------------------------------------------------------------------- - - RESERVED 0 - - UNSUPPORTED_CRITICAL_PAYLOAD 1 - Sent if the payload has the "critical" bit set and the payload - type is not recognized. Notification Data contains the one-octet - payload type. - - INVALID_IKE_SPI 4 - Indicates an IKE message was received with an unrecognized - destination SPI. This usually indicates that the recipient has - rebooted and forgotten the existence of an IKE_SA. - - INVALID_MAJOR_VERSION 5 - Indicates the recipient cannot handle the version of IKE - specified in the header. The closest version number that the - recipient can support will be in the reply header. - - INVALID_SYNTAX 7 - Indicates the IKE message that was received was invalid because - some type, length, or value was out of range or because the - request was rejected for policy reasons. To avoid a denial of - service attack using forged messages, this status may only be - returned for and in an encrypted packet if the message ID and - cryptographic checksum were valid. To avoid leaking information - to someone probing a node, this status MUST be sent in response - to any error not covered by one of the other status types. - {{ Demoted the SHOULD }} To aid debugging, more detailed error - - - -Hoffman Expires July 5, 2006 [Page 79] - -Internet-Draft IKEv2 January 2006 - - - information should be written to a console or log. - - INVALID_MESSAGE_ID 9 - Sent when an IKE message ID outside the supported window is - received. This Notify MUST NOT be sent in a response; the invalid - request MUST NOT be acknowledged. Instead, inform the other side - by initiating an INFORMATIONAL exchange with Notification data - containing the four octet invalid message ID. Sending this - notification is optional, and notifications of this type MUST be - rate limited. - - INVALID_SPI 11 - MAY be sent in an IKE INFORMATIONAL exchange when a node receives - an ESP or AH packet with an invalid SPI. The Notification Data - contains the SPI of the invalid packet. This usually indicates a - node has rebooted and forgotten an SA. If this Informational - Message is sent outside the context of an IKE_SA, it should only - be used by the recipient as a "hint" that something might be - wrong (because it could easily be forged). - - NO_PROPOSAL_CHOSEN 14 - None of the proposed crypto suites was acceptable. - - INVALID_KE_PAYLOAD 17 - The D-H Group # field in the KE payload is not the group # - selected by the responder for this exchange. There are two octets - of data associated with this notification: the accepted D-H Group - # in big endian order. - - AUTHENTICATION_FAILED 24 - Sent in the response to an IKE_AUTH message when for some reason - the authentication failed. There is no associated data. - - SINGLE_PAIR_REQUIRED 34 - This error indicates that a CREATE_CHILD_SA request is - unacceptable because its sender is only willing to accept traffic - selectors specifying a single pair of addresses. The requestor is - expected to respond by requesting an SA for only the specific - traffic it is trying to forward. - - NO_ADDITIONAL_SAS 35 - This error indicates that a CREATE_CHILD_SA request is - unacceptable because the responder is unwilling to accept any - more CHILD_SAs on this IKE_SA. Some minimal implementations may - only accept a single CHILD_SA setup in the context of an initial - IKE exchange and reject any subsequent attempts to add more. - - INTERNAL_ADDRESS_FAILURE 36 - - - -Hoffman Expires July 5, 2006 [Page 80] - -Internet-Draft IKEv2 January 2006 - - - Indicates an error assigning an internal address (i.e., - INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the - processing of a Configuration Payload by a responder. If this - error is generated within an IKE_AUTH exchange, no CHILD_SA will - be created. - - FAILED_CP_REQUIRED 37 - Sent by responder in the case where CP(CFG_REQUEST) was expected - but not received, and so is a conflict with locally configured - policy. There is no associated data. - - TS_UNACCEPTABLE 38 - Indicates that none of the addresses/protocols/ports in the - supplied traffic selectors is acceptable. - - INVALID_SELECTORS 39 - MAY be sent in an IKE INFORMATIONAL exchange when a node receives - an ESP or AH packet whose selectors do not match those of the SA - on which it was delivered (and that caused the packet to be - dropped). The Notification Data contains the start of the - offending packet (as in ICMP messages) and the SPI field of the - notification is set to match the SPI of the IPsec SA. - - RESERVED TO IANA 40-8191 - - PRIVATE USE 8192-16383 - - - NOTIFY messages: status types Value - ------------------------------------------------------------------- - - INITIAL_CONTACT 16384 - This notification asserts that this IKE_SA is the only IKE_SA - currently active between the authenticated identities. It MAY be - sent when an IKE_SA is established after a crash, and the - recipient MAY use this information to delete any other IKE_SAs it - has to the same authenticated identity without waiting for a - timeout. This notification MUST NOT be sent by an entity that may - be replicated (e.g., a roaming user's credentials where the user - is allowed to connect to the corporate firewall from two remote - systems at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT - notification, if sent, MUST be in the first IKE_AUTH request, - not as a separate exchange afterwards. - - SET_WINDOW_SIZE 16385 - This notification asserts that the sending endpoint is capable of - keeping state for multiple outstanding exchanges, permitting the - recipient to send multiple requests before getting a response to - - - -Hoffman Expires July 5, 2006 [Page 81] - -Internet-Draft IKEv2 January 2006 - - - the first. The data associated with a SET_WINDOW_SIZE - notification MUST be 4 octets long and contain the big endian - representation of the number of messages the sender promises to - keep. Window size is always one until the initial exchanges - complete. - - ADDITIONAL_TS_POSSIBLE 16386 - This notification asserts that the sending endpoint narrowed the - proposed traffic selectors but that other traffic selectors would - also have been acceptable, though only in a separate SA (see - section 2.9). There is no data associated with this Notify type. - It may be sent only as an additional payload in a message - including accepted TSs. - - IPCOMP_SUPPORTED 16387 - This notification may be included only in a message containing an - SA payload negotiating a CHILD_SA and indicates a willingness by - its sender to use IPComp on this SA. The data associated with - this notification includes a two-octet IPComp CPI followed by a - one-octet transform ID optionally followed by attributes whose - length and format are defined by that transform ID. A message - proposing an SA may contain multiple IPCOMP_SUPPORTED - notifications to indicate multiple supported algorithms. A - message accepting an SA may contain at most one. - - The transform IDs currently defined are: - - Name Number Defined In - ------------------------------------- - RESERVED 0 - IPCOMP_OUI 1 - IPCOMP_DEFLATE 2 RFC 2394 - IPCOMP_LZS 3 RFC 2395 - IPCOMP_LZJH 4 RFC 3051 - RESERVED TO IANA 5-240 - PRIVATE USE 241-255 - - NAT_DETECTION_SOURCE_IP 16388 - This notification is used by its recipient to determine whether - the source is behind a NAT box. The data associated with this - notification is a SHA-1 digest of the SPIs (in the order they - appear in the header), IP address, and port on which this packet - was sent. There MAY be multiple Notify payloads of this type in a - message if the sender does not know which of several network - attachments will be used to send the packet. The recipient of - this notification MAY compare the supplied value to a SHA-1 hash - of the SPIs, source IP address, and port, and if they don't match - it SHOULD enable NAT traversal (see section 2.23). Alternately, - - - -Hoffman Expires July 5, 2006 [Page 82] - -Internet-Draft IKEv2 January 2006 - - - it MAY reject the connection attempt if NAT traversal is not - supported. - - NAT_DETECTION_DESTINATION_IP 16389 - This notification is used by its recipient to determine whether - it is behind a NAT box. The data associated with this - notification is a SHA-1 digest of the SPIs (in the order they - appear in the header), IP address, and port to which this packet - was sent. The recipient of this notification MAY compare the - supplied value to a hash of the SPIs, destination IP address, and - port, and if they don't match it SHOULD invoke NAT traversal (see - section 2.23). If they don't match, it means that this end is - behind a NAT and this end SHOULD start sending keepalive packets - as defined in [UDPENCAPS]. Alternately, it MAY reject the - connection attempt if NAT traversal is not supported. - - COOKIE 16390 - This notification MAY be included in an IKE_SA_INIT response. It - indicates that the request should be retried with a copy of this - notification as the first payload. This notification MUST be - included in an IKE_SA_INIT request retry if a COOKIE notification - was included in the initial response. The data associated with - this notification MUST be between 1 and 64 octets in length - (inclusive). - - USE_TRANSPORT_MODE 16391 - This notification MAY be included in a request message that also - includes an SA payload requesting a CHILD_SA. It requests that - the CHILD_SA use transport mode rather than tunnel mode for the - SA created. If the request is accepted, the response MUST also - include a notification of type USE_TRANSPORT_MODE. If the - responder declines the request, the CHILD_SA will be established - in tunnel mode. If this is unacceptable to the initiator, the - initiator MUST delete the SA. Note: Except when using this option - to negotiate transport mode, all CHILD_SAs will use tunnel mode. - - Note: The ECN decapsulation modifications specified in - [IPSECARCH] MUST be performed for every tunnel mode SA created - by IKEv2. - - HTTP_CERT_LOOKUP_SUPPORTED 16392 - This notification MAY be included in any message that can include - a CERTREQ payload and indicates that the sender is capable of - looking up certificates based on an HTTP-based URL (and hence - presumably would prefer to receive certificate specifications in - that format). - - REKEY_SA 16393 - - - -Hoffman Expires July 5, 2006 [Page 83] - -Internet-Draft IKEv2 January 2006 - - - This notification MUST be included in a CREATE_CHILD_SA exchange - if the purpose of the exchange is to replace an existing ESP or - AH SA. The SPI field identifies the SA being rekeyed. - {{ Clarif-5.4 }} The SPI placed in the REKEY_SA - notification is the SPI the exchange initiator would expect in - inbound ESP or AH packets. There is no data. - - ESP_TFC_PADDING_NOT_SUPPORTED 16394 - This notification asserts that the sending endpoint will NOT - accept packets that contain Flow Confidentiality (TFC) padding. - {{ Clarif-4.5 }} The scope of this message 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 SHOULD 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 the other - direction. - - NON_FIRST_FRAGMENTS_ALSO 16395 - Used for fragmentation control. See [IPSECARCH] for explanation. - {{ Clarif-4.6 }} 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. If the peer rejects this proposal, the peer only - omits NON_FIRST_FRAGMENTS_ALSO notification from the response, - but does not reject the whole CHILD_SA creation. - - RESERVED TO IANA 16396-40959 - - PRIVATE USE 40960-65535 - -3.11. Delete Payload - - The Delete Payload, denoted D in this memo, contains a protocol - specific security association identifier that the sender has removed - from its security association database and is, therefore, no longer - valid. Figure 17 shows the format of the Delete Payload. It is - possible to send multiple SPIs in a Delete payload; however, each SPI - MUST be for the same protocol. Mixing of protocol identifiers MUST - NOT be performed in the Delete payload. It is permitted, however, to - include multiple Delete payloads in a single INFORMATIONAL exchange - where each Delete payload lists SPIs for a different protocol. - - Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but - no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the - IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI - is the SPI the sending endpoint would expect in inbound ESP or AH - - - -Hoffman Expires July 5, 2006 [Page 84] - -Internet-Draft IKEv2 January 2006 - - - packets. - - The Delete Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol ID ! SPI Size ! # of SPIs ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index(es) (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 17: Delete Payload Format - - o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 - for ESP. - - o SPI Size (1 octet) - Length in octets of the SPI as defined by the - protocol ID. It MUST be zero for IKE (SPI is in message header) - or four for AH and ESP. - - o # of SPIs (2 octets) - The number of SPIs contained in the Delete - payload. The size of each SPI is defined by the SPI Size field. - - o Security Parameter Index(es) (variable length) - Identifies the - specific security association(s) to delete. The length of this - field is determined by the SPI Size and # of SPIs fields. - - The payload type for the Delete Payload is forty two (42). - -3.12. Vendor ID Payload - - The Vendor ID Payload, denoted V in this memo, contains a vendor - defined constant. The constant is used by vendors to identify and - recognize remote instances of their implementations. This mechanism - allows a vendor to experiment with new features while maintaining - backward compatibility. - - A Vendor ID payload MAY announce that the sender is capable to - accepting certain extensions to the protocol, or it MAY simply - identify the implementation as an aid in debugging. A Vendor ID - payload MUST NOT change the interpretation of any information defined - in this specification (i.e., the critical bit MUST be set to 0). - Multiple Vendor ID payloads MAY be sent. An implementation is NOT - - - -Hoffman Expires July 5, 2006 [Page 85] - -Internet-Draft IKEv2 January 2006 - - - REQUIRED to send any Vendor ID payload at all. - - A Vendor ID payload may be sent as part of any message. Reception of - a familiar Vendor ID payload allows an implementation to make use of - Private USE numbers described throughout this memo-- private - payloads, private exchanges, private notifications, etc. Unfamiliar - Vendor IDs MUST be ignored. - - Writers of Internet-Drafts who wish to extend this protocol MUST - define a Vendor ID payload to announce the ability to implement the - extension in the Internet-Draft. It is expected that Internet-Drafts - that gain acceptance and are standardized will be given "magic - numbers" out of the Future Use range by IANA, and the requirement to - use a Vendor ID will go away. - - The Vendor ID Payload fields are defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Vendor ID (VID) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 18: Vendor ID Payload Format - - o Vendor ID (variable length) - It is the responsibility of the - person choosing the Vendor ID to assure its uniqueness in spite of - the absence of any central registry for IDs. Good practice is to - include a company name, a person name, or some such. If you want - to show off, you might include the latitude and longitude and time - where you were when you chose the ID and some random input. A - message digest of a long unique string is preferable to the long - unique string itself. - - The payload type for the Vendor ID Payload is forty three (43). - -3.13. Traffic Selector Payload - - The Traffic Selector Payload, denoted TS in this memo, allows peers - to identify packet flows for processing by IPsec security services. - The Traffic Selector Payload consists of the IKE generic payload - header followed by individual traffic selectors as follows: - - - - - -Hoffman Expires July 5, 2006 [Page 86] - -Internet-Draft IKEv2 January 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Number of TSs ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 19: Traffic Selectors Payload Format - - o Number of TSs (1 octet) - Number of traffic selectors being - provided. - - o RESERVED - This field MUST be sent as zero and MUST be ignored on - receipt. - - o Traffic Selectors (variable length) - One or more individual - traffic selectors. - - The length of the Traffic Selector payload includes the TS header and - all the traffic selectors. - - The payload type for the Traffic Selector payload is forty four (44) - for addresses at the initiator's end of the SA and forty five (45) - for addresses at the responder's end. - - {{ Clarif-4.7 }} 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). - - Thus, some types of policies may require several CHILD_SA pairs. For - - - -Hoffman Expires July 5, 2006 [Page 87] - -Internet-Draft IKEv2 January 2006 - - - 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. - -3.13.1. Traffic Selector - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! TS Type !IP Protocol ID*| Selector Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Start Port* | End Port* | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Starting Address* ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Ending Address* ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 20: Traffic Selector - - *Note: All fields other than TS Type and Selector Length depend on - the TS Type. The fields shown are for TS Types 7 and 8, the only two - values currently defined. - - o TS Type (one octet) - Specifies the type of traffic selector. - - o IP protocol ID (1 octet) - Value specifying an associated IP - protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the - protocol ID is not relevant to this traffic selector-- the SA can - carry all protocols. - - o Selector Length - Specifies the length of this Traffic Selector - Substructure including the header. - - o Start Port (2 octets) - Value specifying the smallest port number - allowed by this Traffic Selector. For protocols for which port is - undefined, or if all ports are allowed, this field MUST be zero. - 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. - - - - - -Hoffman Expires July 5, 2006 [Page 88] - -Internet-Draft IKEv2 January 2006 - - - o End Port (2 octets) - Value specifying the largest port number - allowed by this Traffic Selector. For protocols for which port is - undefined, or if all ports are allowed, this field MUST be 65535. - 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 purposed of filtering based on this - field. - - o Starting Address - The smallest address included in this Traffic - Selector (length determined by TS type). - - o Ending Address - The largest address included in this Traffic - Selector (length determined by TS type). - - Systems that are complying with [IPSECARCH] that wish to indicate - "ANY" ports MUST set the start port to 0 and the end port to 65535; - note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems - working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but - not "ANY" ports, MUST set the start port to 65535 and the end port to - 0. - - {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can - also refer to ICMP type and code fields. Note, however, that ICMP - packets do not have separate source and destination port fields. The - method for specifying the traffic selectors for ICMP is shown by - example in Section 4.4.1.3 of [IPSECARCH]. - - {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID - 135 to match the IPv6 mobility header [MIPV6]. This document does - not specify how to represent the "MH Type" field in traffic - selectors, although it is likely that a different document will - specify this in the future. Note that [IPSECARCH] says that the IPv6 - mobility header (MH) message 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. - - The following table lists the assigned values for the Traffic - Selector Type field and the corresponding Address Selector Data. - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 89] - -Internet-Draft IKEv2 January 2006 - - - TS Type Value - ------------------------------------------------------------------- - RESERVED 0-6 - - TS_IPV4_ADDR_RANGE 7 - - A range of IPv4 addresses, represented by two four-octet - values. The first value is the beginning IPv4 address - (inclusive) and the second value is the ending IPv4 address - (inclusive). All addresses falling between the two specified - addresses are considered to be within the list. - - TS_IPV6_ADDR_RANGE 8 - - A range of IPv6 addresses, represented by two sixteen-octet - values. The first value is the beginning IPv6 address - (inclusive) and the second value is the ending IPv6 address - (inclusive). All addresses falling between the two specified - addresses are considered to be within the list. - - RESERVED TO IANA 9-240 - PRIVATE USE 241-255 - -3.14. Encrypted Payload - - The Encrypted Payload, denoted SK{...} or E in this memo, contains - other payloads in encrypted form. The Encrypted Payload, if present - in a message, MUST be the last payload in the message. Often, it is - the only payload in the message. - - The algorithms for encryption and integrity protection are negotiated - during IKE_SA setup, and the keys are computed as specified in - Section 2.14 and Section 2.18. - - The encryption and integrity protection algorithms are modeled after - the ESP algorithms described in RFCs 2104 [HMAC], 4303 [ESP], and - 2451 [ESPCBC]. This document completely specifies the cryptographic - processing of IKE data, but those documents should be consulted for - design rationale. We require a block cipher with a fixed block size - and an integrity check algorithm that computes a fixed-length - checksum over a variable size message. - - The payload type for an Encrypted payload is forty six (46). The - Encrypted Payload consists of the IKE generic payload header followed - by individual fields as follows: - - - - - - -Hoffman Expires July 5, 2006 [Page 90] - -Internet-Draft IKEv2 January 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Initialization Vector ! - ! (length is block size for encryption algorithm) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Encrypted IKE Payloads ~ - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! Padding (0-255 octets) ! - +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ - ! ! Pad Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Integrity Checksum Data ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 21: Encrypted Payload Format - - o Next Payload - The payload type of the first embedded payload. - Note that this is an exception in the standard header format, - since the Encrypted payload is the last payload in the message and - therefore the Next Payload field would normally be zero. But - because the content of this payload is embedded payloads and there - was no natural place to put the type of the first one, that type - is placed here. - - o Payload Length - Includes the lengths of the header, IV, Encrypted - IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. - - o Initialization Vector - A randomly chosen value whose length is - equal to the block length of the underlying encryption algorithm. - Recipients MUST accept any value. Senders SHOULD either pick this - value pseudo-randomly and independently for each message or use - the final ciphertext block of the previous message sent. Senders - MUST NOT use the same value for each message, use a sequence of - values with low hamming distance (e.g., a sequence number), or use - ciphertext from a received message. - - o IKE Payloads are as specified earlier in this section. This field - is encrypted with the negotiated cipher. - - o Padding MAY contain any value chosen by the sender, and MUST have - a length that makes the combination of the Payloads, the Padding, - and the Pad Length to be a multiple of the encryption block size. - This field is encrypted with the negotiated cipher. - - - - - -Hoffman Expires July 5, 2006 [Page 91] - -Internet-Draft IKEv2 January 2006 - - - o Pad Length is the length of the Padding field. The sender SHOULD - set the Pad Length to the minimum value that makes the combination - of the Payloads, the Padding, and the Pad Length a multiple of the - block size, but the recipient MUST accept any length that results - in proper alignment. This field is encrypted with the negotiated - cipher. - - o Integrity Checksum Data is the cryptographic checksum of the - entire message starting with the Fixed IKE Header through the Pad - Length. The checksum MUST be computed over the encrypted message. - Its length is determined by the integrity algorithm negotiated. - -3.15. Configuration Payload - - The Configuration payload, denoted CP in this document, is used to - exchange configuration information between IKE peers. The exchange - is for an IRAC to request an internal IP address from an IRAS and to - exchange other information of the sort that one would acquire with - Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly - connected to a LAN. - - Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ - CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST - and CFG_SET payloads may optionally be added to any IKE request. The - IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK - or a Notify payload with an error type indicating why the request - could not be honored. An exception is that a minimal implementation - MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response - message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted - as an indication that the request was not supported. - - "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information - from its peer. If an attribute in the CFG_REQUEST Configuration - Payload is not zero-length, it is taken as a suggestion for that - attribute. The CFG_REPLY Configuration Payload MAY return that - value, or a new one. It MAY also add new attributes and not include - some requested ones. Requestors MUST ignore returned attributes that - they do not recognize. - - Some attributes MAY be multi-valued, in which case multiple attribute - values of the same type are sent and/or returned. Generally, all - values of an attribute are returned when the attribute is requested. - For some attributes (in this version of the specification only - internal addresses), multiple requests indicates a request that - multiple values be assigned. For these attributes, the number of - values returned SHOULD NOT exceed the number requested. - - If the data type requested in a CFG_REQUEST is not recognized or not - - - -Hoffman Expires July 5, 2006 [Page 92] - -Internet-Draft IKEv2 January 2006 - - - supported, the responder MUST NOT return an error type but rather - MUST either send a CFG_REPLY that MAY be empty or a reply not - containing a CFG_REPLY payload at all. Error returns are reserved - for cases where the request is recognized but cannot be performed as - requested or the request is badly formatted. - - "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data - to its peer. In this case, the CFG_SET Configuration Payload - contains attributes the initiator wants its peer to alter. The - responder MUST return a Configuration Payload if it accepted any of - the configuration data and it MUST contain the attributes that the - responder accepted with zero-length data. Those attributes that it - did not accept MUST NOT be in the CFG_ACK Configuration Payload. If - no attributes were accepted, the responder MUST return either an - empty CFG_ACK payload or a response message without a CFG_ACK - payload. There are currently no defined uses for the CFG_SET/CFG_ACK - exchange, though they may be used in connection with extensions based - on Vendor IDs. An minimal implementation of this specification MAY - ignore CFG_SET payloads. - - {{ Demoted the SHOULD }} Extensions via the CP payload should not be - used for general purpose management. Its main intent is to provide a - bootstrap mechanism to exchange information within IPsec from IRAS to - IRAC. While it MAY be useful to use such a method to exchange - information between some Security Gateways (SGW) or small networks, - existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], - SNMP, or LDAP [LDAP] should be preferred for enterprise management as - well as subsequent information exchanges. - - The Configuration Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! CFG Type ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Configuration Attributes ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 22: Configuration Payload Format - - The payload type for the Configuration Payload is forty seven (47). - - - - - -Hoffman Expires July 5, 2006 [Page 93] - -Internet-Draft IKEv2 January 2006 - - - o CFG Type (1 octet) - The type of exchange represented by the - Configuration Attributes. - - CFG Type Value - -------------------------- - RESERVED 0 - CFG_REQUEST 1 - CFG_REPLY 2 - CFG_SET 3 - CFG_ACK 4 - RESERVED TO IANA 5-127 - PRIVATE USE 128-255 - - o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on - receipt. - - o Configuration Attributes (variable length) - These are type length - values specific to the Configuration Payload and are defined - below. There may be zero or more Configuration Attributes in this - payload. - -3.15.1. Configuration Attributes - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !R| Attribute Type ! Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Value ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 23: Configuration Attribute Format - - o Reserved (1 bit) - This bit MUST be set to zero and MUST be - ignored on receipt. - - o Attribute Type (15 bits) - A unique identifier for each of the - Configuration Attribute Types. - - o Length (2 octets) - Length in octets of Value. - - o Value (0 or more octets) - The variable-length value of this - Configuration Attribute. The following attribute types have been - defined: - - - - - -Hoffman Expires July 5, 2006 [Page 94] - -Internet-Draft IKEv2 January 2006 - - - Multi- - Attribute Type Value Valued Length - ------------------------------------------------------- - RESERVED 0 - INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets - INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets - INTERNAL_IP4_DNS 3 YES 0 or 4 octets - INTERNAL_IP4_NBNS 4 YES 0 or 4 octets - INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets - INTERNAL_IP4_DHCP 6 YES 0 or 4 octets - APPLICATION_VERSION 7 NO 0 or more - INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets - RESERVED 9 - INTERNAL_IP6_DNS 10 YES 0 or 16 octets - INTERNAL_IP6_NBNS 11 YES 0 or 16 octets - INTERNAL_IP6_DHCP 12 YES 0 or 16 octets - INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets - SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 - INTERNAL_IP6_SUBNET 15 YES 17 octets - RESERVED TO IANA 16-16383 - PRIVATE USE 16384-32767 - - * These attributes may be multi-valued on return only if - multiple values were requested. - - o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the - internal network, sometimes called a red node address or private - address and MAY be a private address on the Internet. {{ - Clarif-6.3}} In a request message, the address specified is a - requested address (or a zero-length address if no specific address - is requested). If a specific address is requested, it likely - indicates that a previous connection existed with this address and - the requestor would like to reuse that address. With IPv6, a - requestor MAY supply the low-order address bytes it wants to use. - Multiple internal addresses MAY be requested by requesting - multiple internal address attributes. The responder MAY only send - up to the number of addresses requested. The INTERNAL_IP6_ADDRESS - is made up of two fields: the first is a 16-octet IPv6 address, - and the second is a one-octet prefix-length as defined in - [ADDRIPV6]. - - The requested address is valid until the expiry time defined with - the INTERNAL_ADDRESS_EXPIRY attribute or there are no IKE_SAs - between the peers. - - o INTERNAL_IP4_NETMASK - 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 - - - -Hoffman Expires July 5, 2006 [Page 95] - -Internet-Draft IKEv2 January 2006 - - - INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.5 }} - 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. 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). Non-empty values - for this attribute in a CFG_REQUEST do not make sense and thus - MUST NOT be included. - - o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS - server within the network. Multiple DNS servers MAY be requested. - The responder MAY respond with zero or more DNS server attributes. - - o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a - NetBios Name Server (WINS) within the network. Multiple NBNS - servers MAY be requested. The responder MAY respond with zero or - more NBNS server attributes. {{ Clarif-6.7 }} NetBIOS is not - defined for IPv6; therefore, INTERNAL_IP6_NBNS SHOULD NOT be used. - - o INTERNAL_ADDRESS_EXPIRY - 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. {{ Clarif-6.8 }} 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. Further, - supporting renewals is not mandatory. Thus - INTERNAL_ADDRESS_EXPIRY attribute MUST NOT be used. - - o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send - any internal DHCP requests to the address contained within the - attribute. Multiple DHCP servers MAY be requested. The responder - MAY respond with zero or more DHCP server attributes. - - o APPLICATION_VERSION - The version or application information of - the IPsec host. This is a string of printable ASCII characters - that is NOT null terminated. - - o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- - device protects. This attribute is made up of two fields: the - first being an IP address and the second being a netmask. - Multiple sub-networks MAY be requested. The responder MAY respond - with zero or more sub-network attributes. - - - - -Hoffman Expires July 5, 2006 [Page 96] - -Internet-Draft IKEv2 January 2006 - - - o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute - MUST be zero-length and specifies a query to the responder to - reply back with all of the attributes that it supports. The - response contains an attribute that contains a set of attribute - identifiers each in 2 octets. The length divided by 2 (octets) - would state the number of supported attributes contained in the - response. - - o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- - device protects. This attribute is made up of two fields: the - first is a 16-octet IPv6 address, and the second is a one-octet - prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY - be requested. The responder MAY respond with zero or more sub- - network attributes. - - Note that no recommendations are made in this document as to how an - implementation actually figures out what information to send in a - reply. That is, we do not recommend any specific method of an IRAS - determining which DNS server should be returned to a requesting IRAC. - -3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET - - {{ Section added based on Clarif-6.4 }} - - INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, - ones that need one or more separate SAs, that can be reached through - the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET - attributes may also 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. Thus, - traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET - attributes should be sent through the gateway that announces the - attributes. If there are no existing IPsec SAs whose traffic - selectors cover the address in question, new SAs need to be created. - - For instance, if there are two subnets, 192.0.1.0/26 and - 192.0.2.0/24, and the client's request contains the following: - - CP(CFG_REQUEST) = - INTERNAL_IP4_ADDRESS() - TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) - TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) - - then a valid response could be the following (in which TSr and - INTERNAL_IP4_SUBNET contain the same information): - - - - - -Hoffman Expires July 5, 2006 [Page 97] - -Internet-Draft IKEv2 January 2006 - - - 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. - - A different 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) - - That reply 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) - - then the gateway's reply might be: - - - -Hoffman Expires July 5, 2006 [Page 98] - -Internet-Draft IKEv2 January 2006 - - - 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) - - Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in - CFG_REQUESTs is unclear, they MUST NOT be used in CFG_REQUESTs. - -3.15.3. Configuration payloads for IPv6 - - {{ Added this section from Clarif-6.6 }} - - The configuration payloads for IPv6 are based on the corresponding - IPv4 payloads, and do not fully follow the "normal IPv6 way of doing - things". In particular, IPv6 stateless autoconfiguration or router - advertisement messages are not used; neither is neighbor discovery. - - A client can be assigned an IPv6 address using the - INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might - 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) - - The client MAY 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 attempts to use the interface identifier with some other - prefix; if even that fails, the gateway selects 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. - - Although this approach to configuring IPv6 addresses is reasonably - - - -Hoffman Expires July 5, 2006 [Page 99] - -Internet-Draft IKEv2 January 2006 - - - simple, it has some limitations. IPsec tunnels configured using - IKEv2 are not fully-featured "interfaces" in the IPv6 addressing - architecture sense [IPV6ADDR]. In particular, they do not - necessarily have link-local addresses, and this may complicate the - use of protocols that assume them, such as [MLDV2]. - -3.15.4. Address Assignment Failures - - {{ Added this section from Clarif-6.9 }} - - If the responder encounters an error while attempting to assign an IP - address to the initiator, it responds with an - INTERNAL_ADDRESS_FAILURE notification. However, there are some more - complex error cases. - - If the responder does not support configuration payloads at all, it - can simply ignore all configuration payloads. This type of - implementation never sends INTERNAL_ADDRESS_FAILURE notifications. - If the initiator requires the assignment of an IP address, it will - treat a response without CFG_REPLY as an error. - - The initiator may request a particular type of address (IPv4 or IPv6) - that the responder does not support, even though the responder - supports configuration payloads. In this case, the responder simply - ignores the type of address it does not support and processes the - rest of the request as usual. - - If the initiator requests multiple addresses of a type that the - responder supports, and some (but not all) of the requests fail, the - responder replies with the successful addresses only. The responder - sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. - -3.16. Extensible Authentication Protocol (EAP) Payload - - The Extensible Authentication Protocol Payload, denoted EAP in this - memo, allows IKE_SAs to be authenticated using the protocol defined - in RFC 3748 [EAP] and subsequent extensions to that protocol. The - full set of acceptable values for the payload is defined elsewhere, - but a short summary of RFC 3748 is included here to make this - document stand alone in the common cases. - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 100] - -Internet-Draft IKEv2 January 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ EAP Message ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 24: EAP Payload Format - - The payload type for an EAP Payload is forty eight (48). - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Code ! Identifier ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Type ! Type_Data... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Figure 25: EAP Message Format - - o Code (1 octet) indicates whether this message is a Request (1), - Response (2), Success (3), or Failure (4). - - o Identifier (1 octet) is used in PPP to distinguish replayed - messages from repeated ones. Since in IKE, EAP runs over a - reliable protocol, it serves no function here. In a response - message, this octet MUST be set to match the identifier in the - corresponding request. In other messages, this field MAY be set - to any value. - - o Length (2 octets) is the length of the EAP message and MUST be - four less than the Payload Length of the encapsulating payload. - - o Type (1 octet) is present only if the Code field is Request (1) or - Response (2). For other codes, the EAP message length MUST be - four octets and the Type and Type_Data fields MUST NOT be present. - In a Request (1) message, Type indicates the data being requested. - In a Response (2) message, Type MUST either be Nak or match the - type of the data requested. The following types are defined in - RFC 3748: - - - - - - - -Hoffman Expires July 5, 2006 [Page 101] - -Internet-Draft IKEv2 January 2006 - - - 1 Identity - 2 Notification - 3 Nak (Response Only) - 4 MD5-Challenge - 5 One-Time Password (OTP) - 6 Generic Token Card - - o Type_Data (Variable Length) varies with the Type of Request and - the associated Response. For the documentation of the EAP - methods, see [EAP]. - - {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an - indication of initiator identity in message 3 of the protocol, the - responder should not send EAP Identity requests. The initiator may, - however, respond to such requests if it receives them. - - -4. Conformance Requirements - - In order to assure that all implementations of IKEv2 can - interoperate, there are "MUST support" requirements in addition to - those listed elsewhere. Of course, IKEv2 is a security protocol, and - one of its major functions is to allow only authorized parties to - successfully complete establishment of SAs. So a particular - implementation may be configured with any of a number of restrictions - concerning algorithms and trusted authorities that will prevent - universal interoperability. - - IKEv2 is designed to permit minimal implementations that can - interoperate with all compliant implementations. There are a series - of optional features that can easily be ignored by a particular - implementation if it does not support that feature. Those features - include: - - o Ability to negotiate SAs through a NAT and tunnel the resulting - ESP SA over UDP. - - o Ability to request (and respond to a request for) a temporary IP - address on the remote end of a tunnel. - - o Ability to support various types of legacy authentication. - - o Ability to support window sizes greater than one. - - o Ability to establish multiple ESP and/or AH SAs within a single - IKE_SA. - - - - - -Hoffman Expires July 5, 2006 [Page 102] - -Internet-Draft IKEv2 January 2006 - - - o Ability to rekey SAs. - - To assure interoperability, all implementations MUST be capable of - parsing all payload types (if only to skip over them) and to ignore - payload types that it does not support unless the critical bit is set - in the payload header. If the critical bit is set in an unsupported - payload header, all implementations MUST reject the messages - containing those payloads. - - Every implementation MUST be capable of doing four-message - IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, - one for ESP and/or AH). Implementations MAY be initiate-only or - respond-only if appropriate for their platform. Every implementation - MUST be capable of responding to an INFORMATIONAL exchange, but a - minimal implementation MAY respond to any INFORMATIONAL message with - an empty INFORMATIONAL reply (note that within the context of an - IKE_SA, an "empty" message consists of an IKE header followed by an - Encrypted payload with no payloads contained in it). A minimal - implementation MAY support the CREATE_CHILD_SA exchange only in so - far as to recognize requests and reject them with a Notify payload of - type NO_ADDITIONAL_SAS. A minimal implementation need not be able to - initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA - expires (based on locally configured values of either lifetime or - octets passed), and implementation MAY either try to renew it with a - CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and - create a new one. If the responder rejects the CREATE_CHILD_SA - request with a NO_ADDITIONAL_SAS notification, the implementation - MUST be capable of instead deleting the old SA and creating a new - one. - - Implementations are not required to support requesting temporary IP - addresses or responding to such requests. If an implementation does - support issuing such requests, it MUST include a CP payload in - message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or - INTERNAL_IP6_ADDRESS. All other fields are optional. If an - implementation supports responding to such requests, it MUST parse - the CP payload of type CFG_REQUEST in message 3 and recognize a field - of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports - leasing an address of the appropriate type, it MUST return a CP - payload of type CFG_REPLY containing an address of the requested - type. {{ Demoted the SHOULD }} The responder may include any other - related attributes. - - A minimal IPv4 responder implementation will ignore the contents of - the CP payload except to determine that it includes an - INTERNAL_IP4_ADDRESS attribute and will respond with the address and - other related attributes regardless of whether the initiator - requested them. - - - -Hoffman Expires July 5, 2006 [Page 103] - -Internet-Draft IKEv2 January 2006 - - - A minimal IPv4 initiator will generate a CP payload containing only - an INTERNAL_IP4_ADDRESS attribute and will parse the response - ignoring attributes it does not know how to use. {{ Clarif-6.8 - removes the sentence about processing INTERNAL_ADDRESS_EXPIRY. }} - Minimal initiators need not be able to request lease renewals and - minimal responders need not respond to them. - - For an implementation to be called conforming to this specification, - it MUST be possible to configure it to accept the following: - - o PKIX Certificates containing and signed by RSA keys of size 1024 - or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, - ID_RFC822_ADDR, or ID_DER_ASN1_DN. - - o Shared key authentication where the ID passes is any of ID_KEY_ID, - ID_FQDN, or ID_RFC822_ADDR. - - o Authentication where the responder is authenticated using PKIX - Certificates and the initiator is authenticated using shared key - authentication. - - -5. Security Considerations - - While this protocol is designed to minimize disclosure of - configuration information to unauthenticated peers, some such - disclosure is unavoidable. One peer or the other must identify - itself first and prove its identity first. To avoid probing, the - initiator of an exchange is required to identify itself first, and - usually is required to authenticate itself first. The initiator can, - however, learn that the responder supports IKE and what cryptographic - protocols it supports. The responder (or someone impersonating the - responder) can probe the initiator not only for its identity, but - using CERTREQ payloads may be able to determine what certificates the - initiator is willing to use. - - Use of EAP authentication changes the probing possibilities somewhat. - When EAP authentication is used, the responder proves its identity - before the initiator does, so an initiator that knew the name of a - valid initiator could probe the responder for both its name and - certificates. - - Repeated rekeying using CREATE_CHILD_SA without additional Diffie- - Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a - single key or overrun of either endpoint. Implementers should take - note of this fact and set a limit on CREATE_CHILD_SA exchanges - between exponentiations. This memo does not prescribe such a limit. - - - - -Hoffman Expires July 5, 2006 [Page 104] - -Internet-Draft IKEv2 January 2006 - - - The strength of a key derived from a Diffie-Hellman exchange using - any of the groups defined here depends on the inherent strength of - the group, the size of the exponent used, and the entropy provided by - the random number generator used. Due to these inputs, it is - difficult to determine the strength of a key for any of the defined - groups. Diffie-Hellman group number two, when used with a strong - random number generator and an exponent no less than 200 bits, is - common for use with 3DES. Group five provides greater security than - group two. Group one is for historic purposes only and does not - provide sufficient strength except for use with DES, which is also - for historic use only. Implementations should make note of these - estimates when establishing policy and negotiating security - parameters. - - Note that these limitations are on the Diffie-Hellman groups - themselves. There is nothing in IKE that prohibits using stronger - groups nor is there anything that will dilute the strength obtained - from stronger groups (limited by the strength of the other algorithms - negotiated including the prf function). In fact, the extensible - framework of IKE encourages the definition of more groups; use of - elliptical curve groups may greatly increase strength using much - smaller numbers. - - It is assumed that all Diffie-Hellman exponents are erased from - memory after use. In particular, these exponents MUST NOT be derived - from long-lived secrets like the seed to a pseudo-random generator - that is not erased after use. - - The strength of all keys is limited by the size of the output of the - negotiated prf function. For this reason, a prf function whose - output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with - this protocol. - - The security of this protocol is critically dependent on the - randomness of the randomly chosen parameters. These should be - generated by a strong random or properly seeded pseudo-random source - (see [RANDOMNESS]). Implementers should take care to ensure that use - of random numbers for both keys and nonces is engineered in a fashion - that does not undermine the security of the keys. - - For information on the rationale of many of the cryptographic design - choices in this protocol, see [SIGMA] and [SKEME]. Though the - security of negotiated CHILD_SAs does not depend on the strength of - the encryption and integrity protection negotiated in the IKE_SA, - implementations MUST NOT negotiate NONE as the IKE integrity - protection algorithm or ENCR_NULL as the IKE encryption algorithm. - - When using pre-shared keys, a critical consideration is how to assure - - - -Hoffman Expires July 5, 2006 [Page 105] - -Internet-Draft IKEv2 January 2006 - - - the randomness of these secrets. The strongest practice is to ensure - that any pre-shared key contain as much randomness as the strongest - key being negotiated. Deriving a shared secret from a password, - name, or other low-entropy source is not secure. These sources are - subject to dictionary and social engineering attacks, among others. - - The NAT_DETECTION_*_IP notifications contain a hash of the addresses - and ports in an attempt to hide internal IP addresses behind a NAT. - Since the IPv4 address space is only 32 bits, and it is usually very - sparse, it would be possible for an attacker to find out the internal - address used behind the NAT box by trying all possible IP addresses - and trying to find the matching hash. The port numbers are normally - fixed to 500, and the SPIs can be extracted from the packet. This - reduces the number of hash calculations to 2^32. With an educated - guess of the use of private address space, the number of hash - calculations is much smaller. Designers should therefore not assume - that use of IKE will not leak internal address information. - - When using an EAP authentication method that does not generate a - shared key for protecting a subsequent AUTH payload, certain man-in- - the-middle and server impersonation attacks are possible [EAPMITM]. - These vulnerabilities occur when EAP is also used in protocols that - are not protected with a secure tunnel. Since EAP is a general- - purpose authentication protocol, which is often used to provide - single-signon facilities, a deployed IPsec solution that relies on an - EAP authentication method that does not generate a shared key (also - known as a non-key-generating EAP method) can become compromised due - to the deployment of an entirely unrelated application that also - happens to use the same non-key-generating EAP method, but in an - unprotected fashion. Note that this vulnerability is not limited to - just EAP, but can occur in other scenarios where an authentication - infrastructure is reused. For example, if the EAP mechanism used by - IKEv2 utilizes a token authenticator, a man-in-the-middle attacker - could impersonate the web server, intercept the token authentication - exchange, and use it to initiate an IKEv2 connection. For this - reason, use of non-key-generating EAP methods SHOULD be avoided where - possible. Where they are used, it is extremely important that all - usages of these EAP methods SHOULD utilize a protected tunnel, where - the initiator validates the responder's certificate before initiating - the EAP exchange. {{ Demoted the SHOULD }} Implementers should - describe the vulnerabilities of using non-key-generating EAP methods - in the documentation of their implementations so that the - administrators deploying IPsec solutions are aware of these dangers. - - An implementation using EAP MUST also use a public-key-based - authentication of the server to the client before the EAP exchange - begins, even if the EAP method offers mutual authentication. This - avoids having additional IKEv2 protocol variations and protects the - - - -Hoffman Expires July 5, 2006 [Page 106] - -Internet-Draft IKEv2 January 2006 - - - EAP data from active attackers. - - If the messages of IKEv2 are long enough that IP-level fragmentation - is necessary, it is possible that attackers could prevent the - exchange from completing by exhausting the reassembly buffers. The - chances of this can be minimized by using the Hash and URL encodings - instead of sending certificates (see Section 3.6). Additional - mitigations are discussed in [DOSUDPPROT]. - - -6. IANA Considerations - - {{ This section was changed to not re-define any new IANA registries. - }} - - [IKEV2] defined many field types and values. IANA has already - registered those types and values, so the are not listed here again. - No new types or values are registered in IKEv2.1. - - -7. Acknowledgements - - {{ Added new acknowledgements. }} - - Charlie Kaufman did a huge amount of work on the original IKEv2 - document, on which this document is primarily based. Pasi Eronen - worked hard on the clarifications document, which is the basis for - the differences between IKEv2 and IKEv2.1. The individuals on the - IPsec mailing list was very helpful in both pointing out where - clarifications and changes were needed, as well as in reviewing the - clarifications suggested by others. - - The acknowledgements from the IKEv2 document were: - - This document is a collaborative effort of the entire IPsec WG. If - there were no limit to the number of authors that could appear on an - RFC, the following, in alphabetical order, would have been listed: - Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt - Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John - Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero - Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer - Reingold, and Michael Richardson. Many other people contributed to - the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, - each of which has its own list of authors. Hugh Daniel suggested the - feature of having the initiator, in message 3, specify a name for the - responder, and gave the feature the cute name "You Tarzan, Me Jane". - David Faucher and Valery Smyzlov helped refine the design of the - traffic selector negotiation. - - - -Hoffman Expires July 5, 2006 [Page 107] - -Internet-Draft IKEv2 January 2006 - - - This paragraph lists references that appear only in figures. The - section is only here to keep the 'xml2rfc' program happy, and will be - removed when the document is published. Feel free to ignore it. - [DES] [IDEA] [MD5] [X.501] [X.509] - - -8. References - -8.1. Normative References - - [ADDGROUP] - Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) - Diffie-Hellman groups for Internet Key Exchange (IKE)", - RFC 3526, May 2003. - - [ADDRIPV6] - Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - [Clarif] "IKEv2 Clarifications and Implementation Guidelines", - draft-eronen-ipsec-ikev2-clarifications (work in - progress). - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. - Levkowetz, "Extensible Authentication Protocol (EAP)", - RFC 3748, June 2004. - - [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", - RFC 3168, September 2001. - - [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [IANACONS] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434. - - [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - RFC 4306, December 2005. - - [IPSECARCH] - Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - - [MUSTSHOULD] - Bradner, S., "Key Words for use in RFCs to indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - -Hoffman Expires July 5, 2006 [Page 108] - -Internet-Draft IKEv2 January 2006 - - - [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [UDPENCAPS] - Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. - Stenberg, "UDP Encapsulation of IPsec ESP Packets", - RFC 3948, January 2005. - -8.2. Informative References - - [AH] Kent, S., "IP Authentication Header", RFC 4302, - December 2005. - - [ARCHGUIDEPHIL] - Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3439, December 2002. - - [ARCHPRINC] - Carpenter, B., "Architectural Principles of the Internet", - RFC 1958, June 1996. - - [DES] American National Standards Institute, "American National - Standard for Information Systems-Data Link Encryption", - ANSI X3.106, 1983. - - [DH] Diffie, W. and M. Hellman, "New Directions in - Cryptography", IEEE Transactions on Information Theory, - V.IT-22 n. 6, June 1977. - - [DHCP] Droms, R., "Dynamic Host Configuration Protocol", - RFC 2131, March 1997. - - [DIFFSERVARCH] - Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., - and W. Weiss, "An Architecture for Differentiated - Services", RFC 2475. - - [DIFFSERVFIELD] - Nichols, K., Blake, S., Baker, F., and D. Black, - "Definition of the Differentiated Services Field (DS - Field) in the IPv4 and IPv6 Headers", RFC 2474, - December 1998. - - [DIFFTUNNEL] - Black, D., "Differentiated Services and Tunnels", - RFC 2983, October 2000. - - - -Hoffman Expires July 5, 2006 [Page 109] - -Internet-Draft IKEv2 January 2006 - - - [DOI] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [DOSUDPPROT] - C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection - for UDP-based protocols", ACM Conference on Computer and - Communications Security , October 2003. - - [DSS] National Institute of Standards and Technology, U.S. - Department of Commerce, "Digital Signature Standard", - FIPS 186, May 1994. - - [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in - Tunneled Authentication Protocols", November 2002, - . - - [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. - - [EXCHANGEANALYSIS] - R. Perlman and C. Kaufman, "Analysis of the IPsec key - exchange Standard", WET-ICE Security Conference, MIT , - 2001, - . - - [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH - Series in Information Processing, v. 1, Konstanz: Hartung- - Gorre Verlag, 1992. - - [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP - Payload Compression Protocol (IPComp)", RFC 3173, - September 2001. - - [IPSECARCH-OLD] - Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [IPV6ADDR] - Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - - - -Hoffman Expires July 5, 2006 [Page 110] - -Internet-Draft IKEv2 January 2006 - - - [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet - Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [MAILFORMAT] - Resnick, P., "Internet Message Format", RFC 2822, - April 2001. - - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support - in IPv6", RFC 3775, June 2004. - - [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery - Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. - - [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", - RFC 2486, January 1999. - - [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation - (NAT) Compatibility Requirements", RFC 3715, March 2004. - - [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", - RFC 2412, November 1998. - - [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key - Management API, Version 2", RFC 2367, July 1998. - - [PHOTURIS] - Karn, P. and W. Simpson, "Photuris: Session-Key Management - Protocol", RFC 2522, March 1999. - - [PKCS1] B. Kaliski and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2", September 1998. - - [PRFAES128CBC] - Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the - Internet Key Exchange Protocol (IKE)", RFC 3664, - January 2004. - - [PRFAES128CBC-bis] - Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the - Internet Key Exchange Protocol (IKE)", - draft-hoffman-rfc3664bis (work in progress), October 2005. - - - -Hoffman Expires July 5, 2006 [Page 111] - -Internet-Draft IKEv2 January 2006 - - - [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, - "Remote Authentication Dial In User Service (RADIUS)", - RFC 2138, April 1997. - - [RANDOMNESS] - Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - - [REAUTH] Nir, Y., ""Repeated Authentication in IKEv2", - draft-nir-ikev2-auth-lt (work in progress), May 2005. - - [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for - Obtaining Digital Signatures and Public-Key - Cryptosystems", February 1978. - - [SHA] National Institute of Standards and Technology, U.S. - Department of Commerce, "Secure Hash Standard", - FIPS 180-1, May 1994. - - [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to - Authenticated Diffie-Hellman and its Use in the IKE - Protocols", Advances in Cryptography - CRYPTO 2003 - Proceedings LNCS 2729, 2003, . - - [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange - Mechanism for Internet", IEEE Proceedings of the 1996 - Symposium on Network and Distributed Systems Security , - 1996. - - [TRANSPARENCY] - Carpenter, B., "Internet Transparency", RFC 2775, - February 2000. - - [X.501] ITU-T, "Recommendation X.501: Information Technology - - Open Systems Interconnection - The Directory: Models", - 1993. - - [X.509] ITU-T, "Recommendation X.509 (1997 E): Information - Technology - Open Systems Interconnection - The Directory: - Authentication Framework", 1997. - - -Appendix A. Summary of changes from IKEv1 - - The goals of this revision to IKE are: - - - - -Hoffman Expires July 5, 2006 [Page 112] - -Internet-Draft IKEv2 January 2006 - - - 1. To define the entire IKE protocol in a single document, - replacing RFCs 2407, 2408, and 2409 and incorporating subsequent - changes to support NAT Traversal, Extensible Authentication, and - Remote Address acquisition; - - 2. To simplify IKE by replacing the eight different initial - exchanges with a single four-message exchange (with changes in - authentication mechanisms affecting only a single AUTH payload - rather than restructuring the entire exchange) see - [EXCHANGEANALYSIS]; - - 3. To remove the Domain of Interpretation (DOI), Situation (SIT), - and Labeled Domain Identifier fields, and the Commit and - Authentication only bits; - - 4. To decrease IKE's latency in the common case by making the - initial exchange be 2 round trips (4 messages), and allowing the - ability to piggyback setup of a CHILD_SA on that exchange; - - 5. To replace the cryptographic syntax for protecting the IKE - messages themselves with one based closely on ESP to simplify - implementation and security analysis; - - 6. To reduce the number of possible error states by making the - protocol reliable (all messages are acknowledged) and sequenced. - This allows shortening CREATE_CHILD_SA exchanges from 3 messages - to 2; - - 7. To increase robustness by allowing the responder to not do - significant processing until it receives a message proving that - the initiator can receive messages at its claimed IP address, - and not commit any state to an exchange until the initiator can - be cryptographically authenticated; - - 8. To fix cryptographic weaknesses such as the problem with - symmetries in hashes used for authentication documented by Tero - Kivinen; - - 9. To specify Traffic Selectors in their own payloads type rather - than overloading ID payloads, and making more flexible the - Traffic Selectors that may be specified; - - 10. To specify required behavior under certain error conditions or - when data that is not understood is received in order to make it - easier to make future revisions in a way that does not break - backwards compatibility; - - - - - -Hoffman Expires July 5, 2006 [Page 113] - -Internet-Draft IKEv2 January 2006 - - - 11. To simplify and clarify how shared state is maintained in the - presence of network failures and Denial of Service attacks; and - - 12. To maintain existing syntax and magic numbers to the extent - possible to make it likely that implementations of IKEv1 can be - enhanced to support IKEv2 with minimum effort. - - -Appendix B. Diffie-Hellman Groups - - There are two Diffie-Hellman groups defined here for use in IKE. - These groups were generated by Richard Schroeppel at the University - of Arizona. Properties of these primes are described in [OAKLEY]. - - The strength supplied by group one may not be sufficient for the - mandatory-to-implement encryption algorithm and is here for historic - reasons. - - Additional Diffie-Hellman groups have been defined in [ADDGROUP]. - -B.1. Group 1 - 768 Bit MODP - - This group is assigned id 1 (one). - - The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } - Its hexadecimal value is: - - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - The generator is 2. - -B.2. Group 2 - 1024 Bit MODP - - This group is assigned id 2 (two). - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its hexadecimal value is: - - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - - - -Hoffman Expires July 5, 2006 [Page 114] - -Internet-Draft IKEv2 January 2006 - - - The generator is 2. - - -Appendix C. Exchanges and Payloads - - {{ Clarif-AppA }} - - 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, the - other text is considered correct. - - Vendor-ID (V) payloads may be included in any place in any message. - This sequence here shows what are the most logical places for them. - -C.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+] - - - - - - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 115] - -Internet-Draft IKEv2 January 2006 - - -C.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+] - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 116] - -Internet-Draft IKEv2 January 2006 - - -C.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+] - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 117] - -Internet-Draft IKEv2 January 2006 - - -C.4. CREATE_CHILD_SA Exchange for Creating or 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)] - -C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA - - request --> SA, Ni, [KEi] - - response <-- SA, Nr, [KEr] - -C.6. INFORMATIONAL Exchange - - request --> [N+], - [D+], - [CP(CFG_REQUEST)] - - response <-- [N+], - [D+], - [CP(CFG_REPLY)] - - -Appendix D. Changes Between Internet Draft Versions - - This section will be removed before publication as an RFC. - -D.1. Changes from IKEv2 to draft -00 - - There were a zillion additions from the Clarifications document. - These are noted with "{{ Clarif-nn }}". - - Cleaned up many of the figures. Made the table headings consistent. - Made some tables easier to read by removing blank spaces. Removed - the "reserved to IANA" and "private use" text wording and moved it - into the tables. - - Changed many SHOULD and MUST requirements to better match RFC 2119. - - - -Hoffman Expires July 5, 2006 [Page 118] - -Internet-Draft IKEv2 January 2006 - - -Author's Address - - Paul Hoffman - VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 - US - - Phone: 1-831-426-9827 - Email: paul.hoffman@vpnc.org - - -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 - - - -Hoffman Expires July 5, 2006 [Page 119] - -Internet-Draft IKEv2 January 2006 - - - 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 currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hoffman Expires July 5, 2006 [Page 120] - diff --git a/doc/standards/draft-hoffman-ikev2bis-00.txt b/doc/standards/draft-hoffman-ikev2bis-00.txt deleted file mode 100644 index 9d1b9d74d..000000000 --- a/doc/standards/draft-hoffman-ikev2bis-00.txt +++ /dev/null @@ -1,6776 +0,0 @@ - - - -Network Working Group C. Kaufman -Internet-Draft Microsoft -Expires: August 27, 2006 P. Hoffman - VPN Consortium - P. Eronen - Nokia - February 23, 2006 - - - Internet Key Exchange Protocol: IKEv2 - draft-hoffman-ikev2bis-00.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 August 27, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes version 2 of the Internet Key Exchange (IKE) - protocol. It is a restatement of RFC 4306, and includes all of the - clarifications from the "IKEv2 Clarifications" document. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 1] - -Internet-Draft IKEv2bis February 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 - 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 7 - 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 - 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 - 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9 - 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 - 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 - 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA - Exchange . . . . . . . . . . . . . . . . . . . . . . 13 - 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 - 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA - Exchange . . . . . . . . . . . . . . . . . . . . . . 14 - 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 - 1.5. Informational Messages outside of an IKE_SA . . . . . . . 16 - 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 - 1.7. Differences Between RFC 4306 and This Document . . . . . 17 - 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 18 - 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 19 - 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 19 - 2.3. Window Size for Overlapping Requests . . . . . . . . . . 20 - 2.4. State Synchronization and Connection Timeouts . . . . . . 21 - 2.5. Version Numbers and Forward Compatibility . . . . . . . . 23 - 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 27 - 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 28 - 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 29 - 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 31 - 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 33 - 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 34 - 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 37 - 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 38 - 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 38 - 2.13. Generating Keying Material . . . . . . . . . . . . . . . 39 - 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 40 - 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 41 - 2.16. Extensible Authentication Protocol Methods . . . . . . . 43 - 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 45 - 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 46 - 2.19. Requesting an Internal Address on a Remote Network . . . 47 - 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 48 - 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 49 - 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 50 - 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 50 - 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 53 - - - -Kaufman, et al. Expires August 27, 2006 [Page 2] - -Internet-Draft IKEv2bis February 2006 - - - 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 53 - 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 53 - 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 56 - 3.3. Security Association Payload . . . . . . . . . . . . . . 58 - 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 60 - 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 62 - 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 64 - 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 65 - 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 66 - 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 67 - 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 68 - 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 69 - 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 71 - 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 74 - 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 76 - 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 77 - 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 77 - 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 78 - 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 84 - 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 85 - 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 86 - 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 88 - 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 90 - 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 92 - 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 94 - 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 97 - 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 99 - 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 100 - 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 100 - 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 102 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 104 - 5.1. Traffic selector authorization . . . . . . . . . . . . . 107 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 108 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 109 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 109 - 8.2. Informative References . . . . . . . . . . . . . . . . . 110 - Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 114 - Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 115 - B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 115 - B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 115 - Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 116 - C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 116 - C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 117 - C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 118 - C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying - CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 119 - C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 119 - - - -Kaufman, et al. Expires August 27, 2006 [Page 3] - -Internet-Draft IKEv2bis February 2006 - - - C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 119 - Appendix D. Changes Between Internet Draft Versions . . . . . . 119 - D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 119 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 - Intellectual Property and Copyright Statements . . . . . . . . . 120 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 4] - -Internet-Draft IKEv2bis February 2006 - - -1. Introduction - - {{ An introduction to the differences between RFC 4306 [IKEV2] and - this document is given at the end of Section 1. It is put there - (instead of here) to preserve the section numbering of the original - IKEv2 document. }} - - IP Security (IPsec) provides confidentiality, data integrity, access - control, and data source authentication to IP datagrams. These - services are provided by maintaining shared state between the source - and the sink of an IP datagram. This state defines, among other - things, the specific services provided to the datagram, which - cryptographic algorithms will be used to provide the services, and - the keys used as input to the cryptographic algorithms. - - Establishing this shared state in a manual fashion does not scale - well. Therefore, a protocol to establish this state dynamically is - needed. This memo describes such a protocol -- the Internet Key - Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], - 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2]. This - single document is intended to replace all three of those RFCs. - - Definitions of the primitive terms in this document (such as Security - Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It - should be noted that parts of IKEv2 rely on some of the processing - rules in [IPSECARCH], as described in various sections of this - document. - - IKE performs mutual authentication between two parties and - establishes an IKE security association (SA) that includes shared - secret information that can be used to efficiently establish SAs for - Encapsulating Security Payload (ESP) [ESP] and/or Authentication - Header (AH) [AH] and a set of cryptographic algorithms to be used by - the SAs to protect the traffic that they carry. In this document, - the term "suite" or "cryptographic suite" refers to a complete set of - algorithms used to protect an SA. An initiator proposes one or more - suites by listing supported algorithms that can be combined into - suites in a mix-and-match fashion. IKE can also negotiate use of IP - Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. - We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get - set up through that IKE_SA we call "CHILD_SAs". - - All IKE communications consist of pairs of messages: a request and a - response. The pair is called an "exchange". We call the first - messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges - and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL - exchanges. In the common case, there is a single IKE_SA_INIT - exchange and a single IKE_AUTH exchange (a total of four messages) to - - - -Kaufman, et al. Expires August 27, 2006 [Page 5] - -Internet-Draft IKEv2bis February 2006 - - - establish the IKE_SA and the first CHILD_SA. In exceptional cases, - there may be more than one of each of these exchanges. In all cases, - all IKE_SA_INIT exchanges MUST complete before any other exchange - type, then all IKE_AUTH exchanges MUST complete, and following that - any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur - in any order. In some scenarios, only a single CHILD_SA is needed - between the IPsec endpoints, and therefore there would be no - additional exchanges. Subsequent exchanges MAY be used to establish - additional CHILD_SAs between the same authenticated pair of endpoints - and to perform housekeeping functions. - - IKE message flow always consists of a request followed by a response. - It is the responsibility of the requester to ensure reliability. If - the response is not received within a timeout interval, the requester - needs to retransmit the request (or abandon the connection). - - The first request/response of an IKE session (IKE_SA_INIT) negotiates - security parameters for the IKE_SA, sends nonces, and sends Diffie- - Hellman values. - - The second request/response (IKE_AUTH) transmits identities, proves - knowledge of the secrets corresponding to the two identities, and - sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. - - The types of subsequent exchanges are CREATE_CHILD_SA (which creates - a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error - conditions, or does other housekeeping). Every request requires a - response. An INFORMATIONAL request with no payloads (other than the - empty Encrypted payload required by the syntax) is commonly used as a - check for liveness. These subsequent exchanges cannot be used until - the initial exchanges have completed. - - In the description that follows, we assume that no errors occur. - Modifications to the flow should errors occur are described in - Section 2.21. - -1.1. Usage Scenarios - - IKE is expected to be used to negotiate ESP and/or AH SAs in a number - of different scenarios, each with its own special requirements. - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 6] - -Internet-Draft IKEv2bis February 2006 - - -1.1.1. Security Gateway to Security Gateway Tunnel - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec ! ! - Protected !Tunnel ! tunnel !Tunnel ! Protected - Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet - ! ! ! ! - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 1: Security Gateway to Security Gateway Tunnel - - In this scenario, neither endpoint of the IP connection implements - IPsec, but network nodes between them protect traffic for part of the - way. Protection is transparent to the endpoints, and depends on - ordinary routing to send packets through the tunnel endpoints for - processing. Each endpoint would announce the set of addresses - "behind" it, and packets would be sent in tunnel mode where the inner - IP header would contain the IP addresses of the actual endpoints. - -1.1.2. Endpoint-to-Endpoint Transport - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec transport ! ! - !Protected! or tunnel mode SA !Protected! - !Endpoint !<---------------------------------------->!Endpoint ! - ! ! ! ! - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 2: Endpoint to Endpoint - - In this scenario, both endpoints of the IP connection implement - IPsec, as required of hosts in [IPSECARCH]. Transport mode will - commonly be used with no inner IP header. If there is an inner IP - header, the inner addresses will be the same as the outer addresses. - A single pair of addresses will be negotiated for packets to be - protected by this SA. These endpoints MAY implement application - layer access controls based on the IPsec authenticated identities of - the participants. This scenario enables the end-to-end security that - has been a guiding principle for the Internet since [ARCHPRINC], - [TRANSPARENCY], and a method of limiting the inherent problems with - complexity in networks noted by [ARCHGUIDEPHIL]. Although this - scenario may not be fully applicable to the IPv4 Internet, it has - been deployed successfully in specific scenarios within intranets - using IKEv1. It should be more broadly enabled during the transition - to IPv6 and with the adoption of IKEv2. - - It is possible in this scenario that one or both of the protected - endpoints will be behind a network address translation (NAT) node, in - - - -Kaufman, et al. Expires August 27, 2006 [Page 7] - -Internet-Draft IKEv2bis February 2006 - - - which case the tunneled packets will have to be UDP encapsulated so - that port numbers in the UDP headers can be used to identify - individual endpoints "behind" the NAT (see Section 2.23). - -1.1.3. Endpoint to Security Gateway Tunnel - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! IPsec ! ! Protected - !Protected! tunnel !Tunnel ! Subnet - !Endpoint !<------------------------>!Endpoint !<--- and/or - ! ! ! ! Internet - +-+-+-+-+-+ +-+-+-+-+-+ - - Figure 3: Endpoint to Security Gateway Tunnel - - In this scenario, a protected endpoint (typically a portable roaming - computer) connects back to its corporate network through an IPsec- - protected tunnel. It might use this tunnel only to access - information on the corporate network, or it might tunnel all of its - traffic back through the corporate network in order to take advantage - of protection provided by a corporate firewall against Internet-based - attacks. In either case, the protected endpoint will want an IP - address associated with the security gateway so that packets returned - to it will go to the security gateway and be tunneled back. This IP - address may be static or may be dynamically allocated by the security - gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 - includes a mechanism (namely, configuration payloads) for the - initiator to request an IP address owned by the security gateway for - use for the duration of its SA. - - In this scenario, packets will use tunnel mode. On each packet from - the protected endpoint, the outer IP header will contain the source - IP address associated with its current location (i.e., the address - that will get traffic routed to the endpoint directly), while the - inner IP header will contain the source IP address assigned by the - security gateway (i.e., the address that will get traffic routed to - the security gateway for forwarding to the endpoint). The outer - destination address will always be that of the security gateway, - while the inner destination address will be the ultimate destination - for the packet. - - In this scenario, it is possible that the protected endpoint will be - behind a NAT. In that case, the IP address as seen by the security - gateway will not be the same as the IP address sent by the protected - endpoint, and packets will have to be UDP encapsulated in order to be - routed properly. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 8] - -Internet-Draft IKEv2bis February 2006 - - -1.1.4. Other Scenarios - - Other scenarios are possible, as are nested combinations of the - above. One notable example combines aspects of 1.1.1 and 1.1.3. A - subnet may make all external accesses through a remote security - gateway using an IPsec tunnel, where the addresses on the subnet are - routed to the security gateway by the rest of the Internet. An - example would be someone's home network being virtually on the - Internet with static IP addresses even though connectivity is - provided by an ISP that assigns a single dynamically assigned IP - address to the user's security gateway (where the static IP addresses - and an IPsec relay are provided by a third party located elsewhere). - -1.2. The Initial Exchanges - - Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH - exchanges (known in IKEv1 as Phase 1). These initial exchanges - normally consist of four messages, though in some scenarios that - number can grow. All communications using IKE consist of request/ - response pairs. We'll describe the base exchange first, followed by - variations. The first pair of messages (IKE_SA_INIT) negotiate - cryptographic algorithms, exchange nonces, and do a Diffie-Hellman - exchange [DH]. - - The second pair of messages (IKE_AUTH) authenticate the previous - messages, exchange identities and certificates, and establish the - first CHILD_SA. Parts of these messages are encrypted and integrity - protected with keys established through the IKE_SA_INIT exchange, so - the identities are hidden from eavesdroppers and all fields in all - the messages are authenticated. - - In the following descriptions, the payloads contained in the message - are indicated by names as listed below. - - - - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 9] - -Internet-Draft IKEv2bis February 2006 - - - Notation Payload - ----------------------------------------- - AUTH Authentication - CERT Certificate - CERTREQ Certificate Request - CP Configuration - D Delete - E Encrypted - EAP Extensible Authentication - HDR IKE Header - IDi Identification - Initiator - IDr Identification - Responder - KE Key Exchange - Ni, Nr Nonce - N Notify - SA Security Association - TSi Traffic Selector - Initiator - TSr Traffic Selector - Responder - V Vendor ID - - The details of the contents of each payload are described in section - 3. Payloads that may optionally appear will be shown in brackets, - such as [CERTREQ], indicate that optionally a certificate request - payload can be included. - - {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". - Some payloads in IKEv2 (and historically in IKEv1) are not aligned to - 4-byte boundaries. - - The initial exchanges are as follows: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SAi1, KEi, Ni --> - - HDR contains the Security Parameter Indexes (SPIs), version numbers, - and flags of various sorts. The SAi1 payload states the - cryptographic algorithms the initiator supports for the IKE_SA. The - KE payload sends the initiator's Diffie-Hellman value. Ni is the - initiator's nonce. - - <-- HDR, SAr1, KEr, Nr, [CERTREQ] - - The responder chooses a cryptographic suite from the initiator's - offered choices and expresses that choice in the SAr1 payload, - completes the Diffie-Hellman exchange with the KEr payload, and sends - its nonce in the Nr payload. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 10] - -Internet-Draft IKEv2bis February 2006 - - - At this point in the negotiation, each party can generate SKEYSEED, - from which all keys are derived for that IKE_SA. All but the headers - of all the messages that follow are encrypted and integrity - protected. The keys used for the encryption and integrity protection - are derived from SKEYSEED and are known as SK_e (encryption) and SK_a - (authentication, a.k.a. integrity protection). A separate SK_e and - SK_a is computed for each direction. In addition to the keys SK_e - and SK_a derived from the DH value for protection of the IKE_SA, - another quantity SK_d is derived and used for derivation of further - keying material for CHILD_SAs. The notation SK { ... } indicates - that these payloads are encrypted and integrity protected using that - direction's SK_e and SK_a. - - HDR, SK {IDi, [CERT,] [CERTREQ,] - [IDr,] AUTH, SAi2, - TSi, TSr} --> - - The initiator asserts its identity with the IDi payload, proves - knowledge of the secret corresponding to IDi and integrity protects - the contents of the first message using the AUTH payload (see - Section 2.15). It might also send its certificate(s) in CERT - payload(s) and a list of its trust anchors in CERTREQ payload(s). If - any CERT payloads are included, the first certificate provided MUST - contain the public key used to verify the AUTH field. The optional - payload IDr enables the initiator to specify which of the responder's - identities it wants to talk to. This is useful when the machine on - which the responder is running is hosting multiple identities at the - same IP address. The initiator begins negotiation of a CHILD_SA - using the SAi2 payload. The final fields (starting with SAi2) are - described in the description of the CREATE_CHILD_SA exchange. - - <-- HDR, SK {IDr, [CERT,] AUTH, - SAr2, TSi, TSr} - - The responder asserts its identity with the IDr payload, optionally - sends one or more certificates (again with the certificate containing - the public key used to verify AUTH listed first), authenticates its - identity and protects the integrity of the second message with the - AUTH payload, and completes negotiation of a CHILD_SA with the - additional fields described below in the CREATE_CHILD_SA exchange. - - The recipients of messages 3 and 4 MUST verify that all signatures - and MACs are computed correctly and that the names in the ID payloads - correspond to the keys used to generate the AUTH payload. - - {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange - fails for some reason, the IKE_SA is still created as usual. The - list of responses in the IKE_AUTH exchange that do not prevent an - - - -Kaufman, et al. Expires August 27, 2006 [Page 11] - -Internet-Draft IKEv2bis February 2006 - - - 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. - - {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr - or Ni/Nr payloads. Thus, the SA payload in IKE_AUTH exchange cannot - contain Transform Type 4 (Diffie-Hellman Group) with any value other - than NONE. Implementations SHOULD NOT send such a transform because - it cannot be interpreted consistently, and implementations SHOULD - ignore any such tranforms they receive. - -1.3. The CREATE_CHILD_SA Exchange - - {{ This is a heavy rewrite of most of this section. The major - organization changes are described in Clarif-4.1 and Clarif-5.1. }} - - 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". For both - messages in the CREATE_CHILD_SA, the message following the header is - encrypted and the message including the header is integrity protected - using the cryptographic algorithms negotiated for the IKE_SA. - - The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs. - An SA is rekeyed by creating a new SA and then deleting the old one. - This section describes the first part of rekeying, the creation of - new SAs; Section 2.8 covers the mechanics of rekeying, including - moving traffic from old to new SAs and the deletion of the old SAs. - The two sections must be read together to understand the entire - process of rekeying. - - Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this - section the term initiator refers to the endpoint initiating this - exchange. An implementation MAY refuse all CREATE_CHILD_SA requests - within an IKE_SA. - - The CREATE_CHILD_SA request MAY optionally contain a KE payload for - an additional Diffie-Hellman exchange to enable stronger guarantees - of forward secrecy for the CHILD_SA. The keying material for the - - - -Kaufman, et al. Expires August 27, 2006 [Page 12] - -Internet-Draft IKEv2bis February 2006 - - - CHILD_SA is a function of SK_d established during the establishment - of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA - exchange, and the Diffie-Hellman value (if KE payloads are included - in the CREATE_CHILD_SA exchange). - - If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of - the SA offers MUST include the Diffie-Hellman group of the KEi. The - Diffie-Hellman group of the KEi MUST be an element of the group the - initiator expects the responder to accept (additional Diffie-Hellman - groups can be proposed). If the responder rejects the Diffie-Hellman - group of the KEi payload, the responder MUST reject the request and - indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD - Notification payload. In the case of such a rejection, the - CREATE_CHILD_SA exchange fails, and the initiator will probably retry - the exchange with a Diffie-Hellman proposal and KEi in the group that - the responder gave in the INVALID_KE_PAYLOAD. - -1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange - - A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The - CREATE_CHILD_SA request for creating a new CHILD_SA is: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {SA, Ni, [KEi], - TSi, TSr} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, optionally a Diffie-Hellman value in the KEi payload, and - the proposed traffic selectors for the proposed CHILD_SA in the TSi - and TSr payloads. - - The CREATE_CHILD_SA response for creating a new CHILD_SA is: - - <-- HDR, SK {SA, Nr, [KEr], - TSi, TSr} - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if KEi was included in the request and the selected - cryptographic suite includes that group. - - The traffic selectors for traffic to be sent on that SA are specified - in the TS payloads in the response, which may be a subset of what the - initiator of the CHILD_SA proposed. - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 13] - -Internet-Draft IKEv2bis February 2006 - - -1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA request for rekeying an IKE_SA is: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {SA, Ni, KEi} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, and a Diffie-Hellman value in the KEi payload. New - initiator and responder SPIs are supplied in the SPI fields. - - The CREATE_CHILD_SA response for rekeying an IKE_SA is: - - <-- HDR, SK {SA, Nr, KEr} - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if the selected cryptographic suite includes that group. - - The new IKE_SA has its message counters set to 0, regardless of what - they were in the earlier IKE_SA. The window size starts at 1 for any - new IKE_SA. - - KEi and KEr are required for rekeying an IKE_SA. - -1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA request for rekeying a CHILD_SA is: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {N, SA, Ni, [KEi], - TSi, TSr} --> - - The initiator sends SA offer(s) in the SA payload, a nonce in the Ni - payload, optionally a Diffie-Hellman value in the KEi payload, and - the proposed traffic selectors for the proposed CHILD_SA in the TSi - and TSr payloads. When rekeying an existing CHILD_SA, the leading N - payload of type REKEY_SA MUST be included and MUST give the SPI (as - they would be expected in the headers of inbound packets) of the SAs - being rekeyed. - - The CREATE_CHILD_SA response for rekeying a CHILD_SA is: - - <-- HDR, SK {SA, Nr, [KEr], - Si, TSr} - - - - -Kaufman, et al. Expires August 27, 2006 [Page 14] - -Internet-Draft IKEv2bis February 2006 - - - The responder replies (using the same Message ID to respond) with the - accepted offer in an SA payload, and a Diffie-Hellman value in the - KEr payload if KEi was included in the request and the selected - cryptographic suite includes that group. - - The traffic selectors for traffic to be sent on that SA are specified - in the TS payloads in the response, which may be a subset of what the - initiator of the CHILD_SA proposed. - -1.4. The INFORMATIONAL Exchange - - At various points during the operation of an IKE_SA, peers may desire - to convey control messages to each other regarding errors or - notifications of certain events. To accomplish this, IKE defines an - INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur - after the initial exchanges and are cryptographically protected with - the negotiated keys. - - Control messages that pertain to an IKE_SA MUST be sent under that - IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent - under the protection of the IKE_SA which generated them (or its - successor if the IKE_SA was replaced for the purpose of rekeying). - - Messages in an INFORMATIONAL exchange contain zero or more - Notification, Delete, and Configuration payloads. The Recipient of - an INFORMATIONAL exchange request MUST send some response (else the - Sender will assume the message was lost in the network and will - retransmit it). That response MAY be a message with no payloads. - The request message in an INFORMATIONAL exchange MAY also contain no - payloads. This is the expected way an endpoint can ask the other - endpoint to verify that it is alive. - - {{ Clarif-5.6 }} 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 (that is, deleted). When SAs are nested, as when data (and - IP headers if in tunnel mode) are encapsulated first with IPComp, - then with ESP, and finally with AH between the same pair of - endpoints, all of the SAs MUST be deleted together. Each endpoint - MUST close its incoming SAs and allow the other endpoint to close the - other SA in each pair. 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. {{ Clarif-5.7 - }} Note that one never sends delete payloads for the two sides of an - SA in a single message. If there are many SAs to delete at the same - time (such as for nested SAs), one includes delete payloads for in - inbound half of each SA pair in your Informational exchange. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 15] - -Internet-Draft IKEv2bis February 2006 - - - Normally, the reply in the INFORMATIONAL exchange will contain delete - payloads for the paired SAs going in the other direction. There is - one exception. If by chance both ends of a set of SAs independently - decide to close them, each may send a delete payload and the two - requests may cross in the network. If a node receives a delete - request for SAs for which it has already issued a delete request, it - MUST delete the outgoing SAs while processing the request and the - incoming SAs while processing the response. In that case, the - responses MUST NOT include delete payloads for the deleted SAs, since - that would result in duplicate deletion and could in theory delete - the wrong SA. - - {{ Demoted the SHOULD }} Half-closed connections are anomalous, and a - node with auditing capability should probably audit their existence - if they persist. Note that this specification nowhere specifies time - periods, so it is up to individual endpoints to decide how long to - wait. A node MAY refuse to accept incoming data on half-closed - connections but MUST NOT unilaterally close them and reuse the SPIs. - If connection state becomes sufficiently messed up, a node MAY close - the IKE_SA; doing so will implicitly close all SAs negotiated under - it. It can then rebuild the SAs it needs on a clean base under a new - IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes the - IKE_SA is an empty Informational response. - - The INFORMATIONAL exchange is defined as: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {[N,] [D,] - [CP,] ...} --> - <-- HDR, SK {[N,] [D,] - [CP], ...} - - The processing of an INFORMATIONAL exchange is determined by its - component payloads. - -1.5. Informational Messages outside of an IKE_SA - - If an encrypted IKE packet arrives on port 500 or 4500 with an - unrecognized SPI, it could be because the receiving node has recently - crashed and lost state or because of some other system malfunction or - attack. If the receiving node has an active IKE_SA to the IP address - from whence the packet came, it MAY send a notification of the - wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it - does not have such an IKE_SA, it MAY send an Informational message - without cryptographic protection to the source IP address. Such a - message is not part of an informational exchange, and the receiving - node MUST NOT respond to it. Doing so could cause a message loop. - - - -Kaufman, et al. Expires August 27, 2006 [Page 16] - -Internet-Draft IKEv2bis February 2006 - - - {{ Clarif-7.7 }} There are two cases when such a one-way notification - is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are - sent outside of an IKE_SA. Note that such notifications are - explicitly not Informational exchanges; these are one-way messages - that must not be responded to. In case of INVALID_IKE_SPI, the - message sent is a response message, and thus it is 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. Using zero values or random values are both - acceptable. - -1.6. Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [MUSTSHOULD]. - - The term "Expert Review" is to be interpreted as defined in - [IANACONS]. - -1.7. Differences Between RFC 4306 and This Document - - {{ Added this entire section, including this recursive remark. }} - - This document contains clarifications and amplifications to IKEv2 - [IKEV2]. The clarifications are mostly based on [Clarif]. The - changes listed in that document were discussed in the IPsec Working - Group and, after the Working Group was disbanded, on the IPsec - mailing list. That document contains detailed explanations of areas - that were unclear in IKEv2, and is thus useful to implementers of - IKEv2. - - The protocol described in this document retains the same major - version number (2) and minor version number (0) as was used in RFC - 4306. - - In the body of this document, notes that are enclosed in double curly - braces {{ such as this }} point out changes from IKEv2. Changes that - come from [Clarif] are marked with the section from that document, - such as "{{ Clarif-2.10 }}". - - This document also make the figures and references a bit more regular - than in [IKEV2]. - - IKEv2 developers have noted that the SHOULD-level requirements are - often unclear in that they don't say when it is OK to not obey the - requirements. They also have noted that there are MUST-level - - - -Kaufman, et al. Expires August 27, 2006 [Page 17] - -Internet-Draft IKEv2bis February 2006 - - - requirements that are not related to interoperability. This document - has more explanation of some of these requirements. All non- - capitalized uses of the words SHOULD and MUST now mean their normal - English sense, not the interoperability sense of [MUSTSHOULD]. - - IKEv2 (and IKEv1) developers have noted that there is a great deal of - material in the tables of codes in Section 3.10. This leads to - implementers not having all the needed information in the main body - of the docment. A later version of this document may move much of - the material from those tables into the associated parts of the main - body of the document. - - A later version of this document will probably have all the {{ }} - comments removed from the body of the document and instead appear in - an appendix. - - -2. IKE Protocol Details and Variations - - IKE normally listens and sends on UDP port 500, though IKE messages - may also be received on UDP port 4500 with a slightly different - format (see Section 2.23). Since UDP is a datagram (unreliable) - protocol, IKE includes in its definition recovery from transmission - errors, including packet loss, packet replay, and packet forgery. - IKE is designed to function so long as (1) at least one of a series - of retransmitted packets reaches its destination before timing out; - and (2) the channel is not so full of forged and replayed packets so - as to exhaust the network or CPU capacities of either endpoint. Even - in the absence of those minimum performance requirements, IKE is - designed to fail cleanly (as though the network were broken). - - Although IKEv2 messages are intended to be short, they contain - structures with no hard upper bound on size (in particular, X.509 - certificates), and IKEv2 itself does not have a mechanism for - fragmenting large messages. IP defines a mechanism for fragmentation - of oversize UDP messages, but implementations vary in the maximum - message size supported. Furthermore, use of IP fragmentation opens - an implementation to denial of service attacks [DOSUDPPROT]. - Finally, some NAT and/or firewall implementations may block IP - fragments. - - All IKEv2 implementations MUST be able to send, receive, and process - IKE messages that are up to 1280 bytes long, and they SHOULD be able - to send, receive, and process messages that are up to 3000 bytes - long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware - of the maximum UDP message size supported and MAY shorten messages by - leaving out some certificates or cryptographic suite proposals if - that will keep messages below the maximum. Use of the "Hash and URL" - - - -Kaufman, et al. Expires August 27, 2006 [Page 18] - -Internet-Draft IKEv2bis February 2006 - - - formats rather than including certificates in exchanges where - possible can avoid most problems. {{ Demoted the SHOULD }} - Implementations and configuration need to keep in mind, however, that - if the URL lookups are possible only after the IPsec SA is - established, recursion issues could prevent this technique from - working. - - {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the - prefix of four zeros; otherwise, the receiver won't know how to - handle them. - -2.1. Use of Retransmission Timers - - All messages in IKE exist in pairs: a request and a response. The - setup of an IKE_SA normally consists of two request/response pairs. - Once the IKE_SA is set up, either end of the security association may - initiate requests at any time, and there can be many requests and - responses "in flight" at any given moment. But each message is - labeled as either a request or a response, and for each request/ - response pair one end of the security association is the initiator - and the other is the responder. - - For every pair of IKE messages, the initiator is responsible for - retransmission in the event of a timeout. The responder MUST never - retransmit a response unless it receives a retransmission of the - request. In that event, the responder MUST ignore the retransmitted - request except insofar as it triggers a retransmission of the - response. The initiator MUST remember each request until it receives - the corresponding response. The responder MUST remember each - response until it receives a request whose sequence number is larger - than the sequence number in the response plus its window size (see - Section 2.3). - - IKE is a reliable protocol, in the sense that the initiator MUST - retransmit a request until either it receives a corresponding reply - OR it deems the IKE security association to have failed and it - discards all state associated with the IKE_SA and any CHILD_SAs - negotiated using that IKE_SA. - -2.2. Use of Sequence Numbers for Message ID - - Every IKE message contains a Message ID as part of its fixed header. - This Message ID is used to match up requests and responses, and to - identify retransmissions of messages. - - The Message ID is a 32-bit quantity, which is zero for the first IKE - request in each direction. {{ Clarif-3.10 }} When the IKE_AUTH - exchange does not use EAP, the IKE_SA initial setup messages will - - - -Kaufman, et al. Expires August 27, 2006 [Page 19] - -Internet-Draft IKEv2bis February 2006 - - - always be numbered 0 and 1. When EAP is used, each pair of messages - have their message numbers incremented; the first pair of AUTH - messages will have an ID of 1, the second will be 2, and so on. - - Each endpoint in the IKE Security Association maintains two "current" - Message IDs: the next one to be used for a request it initiates and - the next one it expects to see in a request from the other end. - These counters increment as requests are generated and received. - Responses always contain the same message ID as the corresponding - request. That means that after the initial exchange, each integer n - may appear as the message ID in four distinct messages: the nth - request from the original IKE initiator, the corresponding response, - the nth request from the original IKE responder, and the - corresponding response. If the two ends make very different numbers - of requests, the Message IDs in the two directions can be very - different. There is no ambiguity in the messages, however, because - the (I)nitiator and (R)esponse bits in the message header specify - which of the four messages a particular one is. - - {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always - zero, including for retries of the message due to responses such as - COOKIE and INVALID_KE_PAYLOAD. - - Note that Message IDs are cryptographically protected and provide - protection against message replays. In the unlikely event that - Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be - closed. Rekeying an IKE_SA resets the sequence numbers. - - {{ Clarif-2.3 }} 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), or it is - a retransmission of a now-opened IKE_SA (in whcih case the responder - ignores it). It is not sufficient to use the initiator's SPI and/or - IP address to differentiate between the two cases because two - different peers behind a single NAT could choose the same initiator - SPI. Instead, a robust responder will do the IKE_SA lookup using the - whole packet, its hash, or the Ni payload. - -2.3. Window Size for Overlapping Requests - - In order to maximize IKE throughput, an IKE endpoint MAY issue - multiple requests before getting a response to any of them if the - other endpoint has indicated its ability to handle such requests. - For simplicity, an IKE implementation MAY choose to process requests - strictly in order and/or wait for a response to one request before - issuing another. Certain rules must be followed to ensure - - - -Kaufman, et al. Expires August 27, 2006 [Page 20] - -Internet-Draft IKEv2bis February 2006 - - - interoperability between implementations using different strategies. - - After an IKE_SA is set up, either end can initiate one or more - requests. These requests may pass one another over the network. An - IKE endpoint MUST be prepared to accept and process a request while - it has a request outstanding in order to avoid a deadlock in this - situation. {{ Downgraded the SHOULD }} An IKE endpoint may also - accept and process multiple requests while it has a request - outstanding. - - An IKE endpoint MUST wait for a response to each of its messages - before sending a subsequent message unless it has received a - SET_WINDOW_SIZE Notify message from its peer informing it that the - peer is prepared to maintain state for multiple outstanding messages - in order to allow greater throughput. - - An IKE endpoint MUST NOT exceed the peer's stated window size for - transmitted IKE requests. In other words, if the responder stated - its window size is N, then when the initiator needs to make a request - X, it MUST wait until it has received responses to all requests up - through request X-N. An IKE endpoint MUST keep a copy of (or be able - to regenerate exactly) each request it has sent until it receives the - corresponding response. An IKE endpoint MUST keep a copy of (or be - able to regenerate exactly) the number of previous responses equal to - its declared window size in case its response was lost and the - initiator requests its retransmission by retransmitting the request. - - An IKE endpoint supporting a window size greater than one ought to be - capable of processing incoming requests out of order to maximize - performance in the event of network failures or packet reordering. - - {{ Clarif-7.3 }} The window size is normally a (possibly - configurable) property of a particular implementation, and is not - related to congestion control (unlike the window size in TCP, for - example). 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; you can only - increase it. 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. - -2.4. State Synchronization and Connection Timeouts - - An IKE endpoint is allowed to forget all of its state associated with - an IKE_SA and the collection of corresponding CHILD_SAs at any time. - This is the anticipated behavior in the event of an endpoint crash - and restart. It is important when an endpoint either fails or - - - -Kaufman, et al. Expires August 27, 2006 [Page 21] - -Internet-Draft IKEv2bis February 2006 - - - reinitializes its state that the other endpoint detect those - conditions and not continue to waste network bandwidth by sending - packets over discarded SAs and having them fall into a black hole. - - Since IKE is designed to operate in spite of Denial of Service (DoS) - attacks from the network, an endpoint MUST NOT conclude that the - other endpoint has failed based on any routing information (e.g., - ICMP messages) or IKE messages that arrive without cryptographic - protection (e.g., Notify messages complaining about unknown SPIs). - An endpoint MUST conclude that the other endpoint has failed only - when repeated attempts to contact it have gone unanswered for a - timeout period or when a cryptographically protected INITIAL_CONTACT - notification is received on a different IKE_SA to the same - authenticated identity. {{ Demoted the SHOULD }} An endpoint should - suspect that the other endpoint has failed based on routing - information and initiate a request to see whether the other endpoint - is alive. To check whether the other side is alive, IKE specifies an - empty INFORMATIONAL message that (like all IKE requests) requires an - acknowledgement (note that within the context of an IKE_SA, an - "empty" message consists of an IKE header followed by an Encrypted - payload that contains no payloads). If a cryptographically protected - message has been received from the other side recently, unprotected - notifications MAY be ignored. Implementations MUST limit the rate at - which they take actions based on unprotected messages. - - Numbers of retries and lengths of timeouts are not covered in this - specification because they do not affect interoperability. It is - suggested that messages be retransmitted at least a dozen times over - a period of at least several minutes before giving up on an SA, but - different environments may require different rules. To be a good - network citizen, retranmission times MUST increase exponentially to - avoid flooding the network and making an existing congestion - situation worse. If there has only been outgoing traffic on all of - the SAs associated with an IKE_SA, it is essential to confirm - liveness of the other endpoint to avoid black holes. If no - cryptographically protected messages have been received on an IKE_SA - or any of its CHILD_SAs recently, the system needs to perform a - liveness check in order to prevent sending messages to a dead peer. - Receipt of a fresh cryptographically protected message on an IKE_SA - or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its - CHILD_SAs. Note that this places requirements on the failure modes - of an IKE endpoint. An implementation MUST NOT continue sending on - any SA if some failure prevents it from receiving on all of the - associated SAs. If CHILD_SAs can fail independently from one another - without the associated IKE_SA being able to send a delete message, - then they MUST be negotiated by separate IKE_SAs. - - There is a Denial of Service attack on the initiator of an IKE_SA - - - -Kaufman, et al. Expires August 27, 2006 [Page 22] - -Internet-Draft IKEv2bis February 2006 - - - that can be avoided if the initiator takes the proper care. Since - the first two messages of an SA setup are not cryptographically - protected, an attacker could respond to the initiator's message - before the genuine responder and poison the connection setup attempt. - To prevent this, the initiator MAY be willing to accept multiple - responses to its first message, treat each as potentially legitimate, - respond to it, and then discard all the invalid half-open connections - when it receives a valid cryptographically protected response to any - one of its requests. Once a cryptographically valid response is - received, all subsequent responses should be ignored whether or not - they are cryptographically valid. - - Note that with these rules, there is no reason to negotiate and agree - upon an SA lifetime. If IKE presumes the partner is dead, based on - repeated lack of acknowledgement to an IKE message, then the IKE SA - and all CHILD_SAs set up through that IKE_SA are deleted. - - An IKE endpoint may at any time delete inactive CHILD_SAs to recover - resources used to hold their state. If an IKE endpoint chooses to - delete CHILD_SAs, it MUST send Delete payloads to the other end - notifying it of the deletion. It MAY similarly time out the IKE_SA. - {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all - associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a - Delete payload indicating that it has closed the IKE_SA unless the - other endpoint is no longer responding. - -2.5. Version Numbers and Forward Compatibility - - This document describes version 2.0 of IKE, meaning the major version - number is 2 and the minor version number is 0. {{ Restated the - relationship to RFC 4306 }} This document is a clarification of - [IKEV2]. It is likely that some implementations will want to support - version 1.0 and version 2.0, and in the future, other versions. - - The major version number should be incremented only if the packet - formats or required actions have changed so dramatically that an - older version node would not be able to interoperate with a newer - version node if it simply ignored the fields it did not understand - and took the actions specified in the older specification. The minor - version number indicates new capabilities, and MUST be ignored by a - node with a smaller minor version number, but used for informational - purposes by the node with the larger minor version number. For - example, it might indicate the ability to process a newly defined - notification message. The node with the larger minor version number - would simply note that its correspondent would not be able to - understand that message and therefore would not send it. - - If an endpoint receives a message with a higher major version number, - - - -Kaufman, et al. Expires August 27, 2006 [Page 23] - -Internet-Draft IKEv2bis February 2006 - - - it MUST drop the message and SHOULD send an unauthenticated - notification message containing the highest version number it - supports. If an endpoint supports major version n, and major version - m, it MUST support all versions between n and m. If it receives a - message with a major version that it supports, it MUST respond with - that version number. In order to prevent two nodes from being - tricked into corresponding with a lower major version number than the - maximum that they both support, IKE has a flag that indicates that - the node is capable of speaking a higher major version number. - - Thus, the major version number in the IKE header indicates the - version number of the message, not the highest version number that - the transmitter supports. If the initiator is capable of speaking - versions n, n+1, and n+2, and the responder is capable of speaking - versions n and n+1, then they will negotiate speaking n+1, where the - initiator will set the flag indicating its ability to speak a higher - version. If they mistakenly (perhaps through an active attacker - sending error messages) negotiate to version n, then both will notice - that the other side can support a higher version number, and they - MUST break the connection and reconnect using version n+1. - - Note that IKEv1 does not follow these rules, because there is no way - in v1 of noting that you are capable of speaking a higher version - number. So an active attacker can trick two v2-capable nodes into - speaking v1. {{ Demoted the SHOULD }} When a v2-capable node - negotiates down to v1, it should note that fact in its logs. - - Also for forward compatibility, all fields marked RESERVED MUST be - set to zero by an implementation running version 2.0 or later, and - their content MUST be ignored by an implementation running version - 2.0 or later ("Be conservative in what you send and liberal in what - you receive"). In this way, future versions of the protocol can use - those fields in a way that is guaranteed to be ignored by - implementations that do not understand them. Similarly, payload - types that are not defined are reserved for future use; - implementations of a version where they are undefined MUST skip over - those payloads and ignore their contents. - - IKEv2 adds a "critical" flag to each payload header for further - flexibility for forward compatibility. If the critical flag is set - and the payload type is unrecognized, the message MUST be rejected - and the response to the IKE request containing that payload MUST - include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an - unsupported critical payload was included. If the critical flag is - not set and the payload type is unsupported, that payload MUST be - ignored. - - {{ Demoted the SHOULD in the second clause }}Although new payload - - - -Kaufman, et al. Expires August 27, 2006 [Page 24] - -Internet-Draft IKEv2bis February 2006 - - - types may be added in the future and may appear interleaved with the - fields defined in this specification, implementations MUST send the - payloads defined in this specification in the order shown in the - figures in Section 2; implementations are explicitly allowed to - reject as invalid a message with those payloads in any other order. - -2.6. Cookies - - The term "cookies" originates with Karn and Simpson [PHOTURIS] in - Photuris, an early proposal for key management with IPsec, and it has - persisted. The Internet Security Association and Key Management - Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- - octet fields titled "cookies", and that syntax is used by both IKEv1 - and IKEv2 though in IKEv2 they are referred to as the IKE SPI and - there is a new separate field in a Notify payload holding the cookie. - The initial two eight-octet fields in the header are used as a - connection identifier at the beginning of IKE packets. {{ Demoted the - SHOULD }} Each endpoint chooses one of the two SPIs and needs to - choose them so as to be unique identifiers of an IKE_SA. An SPI - value of zero is special and indicates that the remote SPI value is - not yet known by the sender. - - Unlike ESP and AH where only the recipient's SPI appears in the - header of a message, in IKE the sender's SPI is also sent in every - message. Since the SPI chosen by the original initiator of the - IKE_SA is always sent first, an endpoint with multiple IKE_SAs open - that wants to find the appropriate IKE_SA using the SPI it assigned - must look at the I(nitiator) Flag bit in the header to determine - whether it assigned the first or the second eight octets. - - In the first message of an initial IKE exchange, the initiator will - not know the responder's SPI value and will therefore set that field - to zero. - - An expected attack against IKE is state and CPU exhaustion, where the - target is flooded with session initiation requests from forged IP - addresses. This attack can be made less effective if an - implementation of a responder uses minimal CPU and commits no state - to an SA until it knows the initiator can receive packets at the - address from which it claims to be sending them. To accomplish this, - a responder SHOULD -- when it detects a large number of half-open - IKE_SAs -- reject initial IKE messages unless they contain a Notify - payload of type COOKIE. {{ Clarified the SHOULD }} If the responder - wants to set up an SA, it SHOULD instead send an unprotected IKE - message as a response and include COOKIE Notify payload with the - cookie data to be returned. 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 - - - -Kaufman, et al. Expires August 27, 2006 [Page 25] - -Internet-Draft IKEv2bis February 2006 - - - and all other payloads unchanged. The initial exchange will then be - as follows: - - Initiator Responder - ------------------------------------------------------------------- - 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, [CERTREQ] - HDR(A,B), SK {IDi, [CERT,] - [CERTREQ,] [IDr,] AUTH, - SAi2, TSi, TSr} --> - <-- HDR(A,B), SK {IDr, [CERT,] - AUTH, SAr2, TSi, TSr} - - The first two messages do not affect any initiator or responder state - except for communicating the cookie. In particular, the message - sequence numbers in the first four messages will all be zero and the - message sequence numbers in the last two messages will be one. 'A' - is the SPI assigned by the initiator, while 'B' is the SPI assigned - by the responder. - - {{ Clarif-2.1 }} Because the responder's SPI identifies security- - related state held by the responder, and in this case no state is - created, the responder sends a zero value for the responder's SPI. - - {{ Demoted the SHOULD }} An IKE implementation should implement its - responder cookie generation in such a way as to not require any saved - state to recognize its valid cookie when the second IKE_SA_INIT - message arrives. The exact algorithms and syntax they use to - generate cookies do not affect interoperability and hence are not - specified here. The following is an example of how an endpoint could - use cookies to implement limited DOS protection. - - A good way to do this is to set the responder cookie to be: - - Cookie = | Hash(Ni | IPi | SPIi | ) - - where is a randomly generated secret known only to the - responder and periodically changed and | indicates concatenation. - should be changed whenever is - regenerated. The cookie can be recomputed when the IKE_SA_INIT - arrives the second time and compared to the cookie in the received - message. If it matches, the responder knows that the cookie was - generated since the last change to and that IPi must be the - same as the source address it saw the first time. Incorporating SPIi - - - -Kaufman, et al. Expires August 27, 2006 [Page 26] - -Internet-Draft IKEv2bis February 2006 - - - into the calculation ensures that if multiple IKE_SAs are being set - up in parallel they will all get different cookies (assuming the - initiator chooses unique SPIi's). Incorporating Ni into the hash - ensures that an attacker who sees only message 2 can't successfully - forge a message 3. - - If a new value for is chosen while there are connections in - the process of being initialized, an IKE_SA_INIT might be returned - with other than the current . The responder in - that case MAY reject the message by sending another response with a - new cookie or it MAY keep the old value of around for a - short time and accept cookies computed from either one. {{ Demoted - the SHOULD NOT }} The responder should not accept cookies - indefinitely after is changed, since that would defeat part - of the denial of service protection. {{ Demoted the SHOULD }} The - responder should change the value of frequently, especially - if under attack. - - {{ Clarif-2.1 }} In addition to cookies, there are several cases - where the IKE_SA_INIT exchange does not result in the creation of an - IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a - case, sending a zero value for the Responder's SPI is correct. If - the responder sends a non-zero responder SPI, the initiator should - not reject the response for only that reason. - - {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request - containing a cookie whose contents do not match the value expected, - that party MUST ignore the cookie and process the message as if no - cookie had been included; usually this means sending a response - containing a new cookie. - -2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD - - {{ This section added by Clarif-2.4 }} - - 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. - If the initiator receives a cookie from the responder, the initiator - needs to decide whether or not to include the cookie in only the next - retry of the IKE_SA_INIT request, or in all subsequent retries as - well. - - If the initiator includes the cookie only in the next retry, one - additional roundtrip may be needed in some cases. An additional - roundtrip is needed also if the initiator includes the cookie in all - retries, but the responder does not support this. For instance, if - the responder includes the SAi1 and KEi payloads in cookie - - - -Kaufman, et al. Expires August 27, 2006 [Page 27] - -Internet-Draft IKEv2bis February 2006 - - - calculation, it will reject the request by sending a new cookie. - - If both peers support including the cookie in all retries, a slightly - shorter exchange can happen. Implementations SHOULD support this - shorter exchange, but MUST NOT fail if other implementations do not - support this shorter exchange. - -2.7. Cryptographic Algorithm Negotiation - - The payload type known as "SA" indicates a proposal for a set of - choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well - as cryptographic algorithms associated with each protocol. - - An SA payload consists of one or more proposals. Each proposal - includes one or more protocols (usually one). Each protocol contains - one or more transforms -- each specifying a cryptographic algorithm. - Each transform contains zero or more attributes (attributes are - needed only if the transform identifier does not completely specify - the cryptographic algorithm). - - This hierarchical structure was designed to efficiently encode - proposals for cryptographic suites when the number of supported - suites is large because multiple values are acceptable for multiple - transforms. The responder MUST choose a single suite, which MAY be - any subset of the SA proposal following the rules below: - - Each proposal contains one or more protocols. If a proposal is - accepted, the SA response MUST contain the same protocols in the same - order as the proposal. The responder MUST accept a single proposal - or reject them all and return an error. (Example: if a single - proposal contains ESP and AH and that proposal is accepted, both ESP - and AH MUST be accepted. If ESP and AH are included in separate - proposals, the responder MUST accept only one of them). - - Each IPsec protocol proposal contains one or more transforms. Each - transform contains a transform type. The accepted cryptographic - suite MUST contain exactly one transform of each type included in the - proposal. For example: if an ESP proposal includes transforms - ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, - AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one - of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six - combinations are acceptable. - - Since the initiator sends its Diffie-Hellman value in the - IKE_SA_INIT, it must guess the Diffie-Hellman group that the - responder will select from its list of supported groups. If the - initiator guesses wrong, the responder will respond with a Notify - payload of type INVALID_KE_PAYLOAD indicating the selected group. In - - - -Kaufman, et al. Expires August 27, 2006 [Page 28] - -Internet-Draft IKEv2bis February 2006 - - - this case, the initiator MUST retry the IKE_SA_INIT with the - corrected Diffie-Hellman group. The initiator MUST again propose its - full set of acceptable cryptographic suites because the rejection - message was unauthenticated and otherwise an active attacker could - trick the endpoints into negotiating a weaker suite than a stronger - one that they both prefer. - -2.8. Rekeying - - {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use - secret keys that should be used only for a limited amount of time and - to protect a limited amount of data. This limits the lifetime of the - entire security association. When the lifetime of a security - association expires, the security association MUST NOT be used. If - there is demand, new security associations MAY be established. - Reestablishment of security associations to take the place of ones - that expire is referred to as "rekeying". - - To allow for minimal IPsec implementations, the ability to rekey SAs - without restarting the entire IKE_SA is optional. An implementation - MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA - has expired or is about to expire and rekeying attempts using the - mechanisms described here fail, an implementation MUST close the - IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ - Demoted the SHOULD }} Implementations may wish to support in-place - rekeying of SAs, since doing so offers better performance and is - likely to reduce the number of packets lost during the transition. - - To rekey a CHILD_SA within an existing IKE_SA, create a new, - equivalent SA (see Section 2.17 below), and when the new one is - established, delete the old one. To rekey an IKE_SA, establish a new - equivalent IKE_SA (see Section 2.18 below) with the peer to whom the - old IKE_SA is shared using a CREATE_CHILD_SA within the existing - IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's - CHILD_SAs. Use the new IKE_SA for all control messages needed to - maintain the CHILD_SAs created by the old IKE_SA, and delete the old - IKE_SA. The Delete payload to delete itself MUST be the last request - sent over an IKE_SA. - - {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the - new SA should be established before the old one expires and becomes - unusable. Enough time should elapse between the time the new SA is - established and the old one becomes unusable so that traffic can be - switched over to the new SA. - - A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes - were negotiated. In IKEv2, each end of the SA is responsible for - enforcing its own lifetime policy on the SA and rekeying the SA when - - - -Kaufman, et al. Expires August 27, 2006 [Page 29] - -Internet-Draft IKEv2bis February 2006 - - - necessary. If the two ends have different lifetime policies, the end - with the shorter lifetime will end up always being the one to request - the rekeying. If an SA bundle has been inactive for a long time and - if an endpoint would not initiate the SA in the absence of traffic, - the endpoint MAY choose to close the SA instead of rekeying it when - its lifetime expires. {{ Demoted the SHOULD }} It should do so if - there has been no traffic since the last time the SA was rekeyed. - - Note that IKEv2 deliberately allows parallel SAs with the same - traffic selectors between common endpoints. One of the purposes of - this is to support traffic quality of service (QoS) differences among - the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of - [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints - and the traffic selectors may not uniquely identify an SA between - those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on - the basis of duplicate traffic selectors SHOULD NOT be used. - - {{ Demoted the SHOULD }} The node that initiated the surviving - rekeyed SA should delete the replaced SA after the new one is - established. - - There are timing windows -- particularly in the presence of lost - packets -- where endpoints may not agree on the state of an SA. The - responder to a CREATE_CHILD_SA MUST be prepared to accept messages on - an SA before sending its response to the creation request, so there - is no ambiguity for the initiator. The initiator MAY begin sending - on an SA as soon as it processes the response. The initiator, - however, cannot receive on a newly created SA until it receives and - processes the response to its CREATE_CHILD_SA request. How, then, is - the responder to know when it is OK to send on the newly created SA? - - From a technical correctness and interoperability perspective, the - responder MAY begin sending on an SA as soon as it sends its response - to the CREATE_CHILD_SA request. In some situations, however, this - could result in packets unnecessarily being dropped, so an - implementation MAY want to defer such sending. - - The responder can be assured that the initiator is prepared to - receive messages on an SA if either (1) it has received a - cryptographically valid message on the new SA, or (2) the new SA - rekeys an existing SA and it receives an IKE request to close the - replaced SA. When rekeying an SA, the responder continues to send - traffic on the old SA until one of those events occurs. When - establishing a new SA, the responder MAY defer sending messages on a - new SA until either it receives one or a timeout has occurred. {{ - Demoted the SHOULD }} If an initiator receives a message on an SA for - which it has not received a response to its CREATE_CHILD_SA request, - it interprets that as a likely packet loss and retransmits the - - - -Kaufman, et al. Expires August 27, 2006 [Page 30] - -Internet-Draft IKEv2bis February 2006 - - - CREATE_CHILD_SA request. An initiator MAY send a dummy message on a - newly created SA if it has no messages queued in order to assure the - responder that the initiator is ready to receive messages. - - {{ Clarif-5.9 }} Throughout this 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. The - "original initiator" always refers to the party who initiated the - exchange which resulted in the current IKE_SA. In other words, if - the the "original responder" starts rekeying the IKE_SA, that party - becomes the "original initiator" of the new IKE_SA. - -2.8.1. Simultaneous CHILD_SA rekeying - - {{ The first two paragraphs were moved, and the rest was added, based - on Clarif-5.11 }} - - 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. {{ Clarif-5.10 }} - "Lowest" means 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. - - The following is an explanation on the impact this has on - implementations. 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 <-- - - - - -Kaufman, et al. Expires August 27, 2006 [Page 31] - -Internet-Draft IKEv2bis February 2006 - - - At this point, A knows there is a simultaneous rekeying going on. - However, it cannot yet know which of the exchanges will have the - lowest nonce, so it will just note the situation and respond as - usual. - - send resp2: SA(..,SPIa3,..), - Nr1,.. --> - --> recv req1 - - Now B also knows that simultaneous rekeying is going on. It responds - as usual. - - <-- send resp1: SA(..,SPIb3,..), - Nr2,.. - recv resp1 <-- - --> recv resp2 - - At this point, there are three CHILD_SA pairs between A and B (the - old one and two new ones). A and B can now compare the nonces. - Suppose that the lowest nonce was Nr1 in message resp2; in this case, - B (the sender of req2) deletes the redundant new SA, and A (the node - that initiated the surviving rekeyed SA), deletes the old one. - - send req3: D(SPIa1) --> - <-- send req4: D(SPIb2) - --> recv req3 - <-- send resp4: D(SPIb1) - recv req4 <-- - send resp4: D(SPIa3) --> - - The rekeying is now finished. - - However, there is a second possible sequence of events that can - happen if some packets are lost in the network, resulting in - retransmissions. The rekeying begins as usual, but A's first packet - (req1) is lost. - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 32] - -Internet-Draft IKEv2bis February 2006 - - - 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 there was - simultaneous rekeying. However, A will continue retransmitting the - message, and eventually it will reach B. - - resend req1 --> - --> recv req1 - - To B, it looks like A is trying to rekey an SA that no longer exists; - thus, B responds to the request with something non-fatal such as - NO_PROPOSAL_CHOSEN. - - <-- 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. - -2.8.2. Rekeying the IKE_SA Versus Reauthentication - - {{ Added this section from Clarif-5.2 }} - - 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). - - Although 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. - - - -Kaufman, et al. Expires August 27, 2006 [Page 33] - -Internet-Draft IKEv2bis February 2006 - - - 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]. - -2.9. Traffic Selector Negotiation - - {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives - an IP packet and matches a "protect" selector in its Security Policy - Database (SPD), the subsystem protects that packet with IPsec. When - no SA exists yet, it is the task of IKE to create it. Maintenance of - a system's SPD is outside the scope of IKE (see [PFKEY] for an - example protocol), though some implementations might update their SPD - in connection with the running of IKE (for an example scenario, see - Section 1.1.3). - - Traffic Selector (TS) payloads allow endpoints to communicate some of - the information from their SPD to their peers. TS payloads specify - the selection criteria for packets that will be forwarded over the - newly set up SA. This can serve as a consistency check in some - scenarios to assure that the SPDs are consistent. In others, it - guides the dynamic update of the SPD. - - Two TS payloads appear in each of the messages in the exchange that - creates a CHILD_SA pair. Each TS payload contains one or more - Traffic Selectors. Each Traffic Selector consists of an address - range (IPv4 or IPv6), a port range, and an IP protocol ID. 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. {{ Clarif-6.1 }} That request is done using - configuration payloads, not traffic selectors. 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 - - - -Kaufman, et al. Expires August 27, 2006 [Page 34] - -Internet-Draft IKEv2bis February 2006 - - - can be performed as agreed for this SA. - - IKEv2 allows the responder to choose a subset of the traffic proposed - by the initiator. This could happen when the configurations of the - two endpoints are being updated but only one end has received the new - information. Since the two endpoints may be configured by different - people, the incompatibility may persist for an extended period even - in the absence of errors. It also allows for intentionally different - configurations, as when one end is configured to tunnel all addresses - and depends on the other end to have the up-to-date list. - - The first of the two TS payloads is known as TSi (Traffic Selector- - initiator). The second is known as TSr (Traffic Selector-responder). - TSi specifies the source address of traffic forwarded from (or the - destination address of traffic forwarded to) the initiator of the - CHILD_SA pair. TSr specifies the destination address of the traffic - forwarded to (or the source address of the traffic forwarded from) - the responder of the CHILD_SA pair. For example, if the original - initiator request the creation of a CHILD_SA pair, and wishes to - tunnel all traffic from subnet 192.0.1.* on the initiator's side to - subnet 192.0.2.* on the responder's side, the initiator would include - a single traffic selector in each TS payload. TSi would specify the - address range (192.0.1.0 - 192.0.1.255) and TSr would specify the - address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was - acceptable to the responder, it would send identical TS payloads - back. (Note: The IP address range 192.0.2.* has been reserved for - use in examples in RFCs and similar documents. This document needed - two such ranges, and so also used 192.0.1.*. This should not be - confused with any actual address.) - - The responder is allowed to narrow the choices by selecting a subset - of the traffic, for instance by eliminating or narrowing the range of - one or more members of the set of traffic selectors, provided the set - does not become the NULL set. - - It is possible for the responder's policy to contain multiple smaller - ranges, all encompassed by the initiator's traffic selector, and with - the responder's policy being that each of those ranges should be sent - over a different SA. Continuing the example above, the responder - might have a policy of being willing to tunnel those addresses to and - from the initiator, but might require that each address pair be on a - separately negotiated CHILD_SA. If the initiator generated its - request in response to an incoming packet from 192.0.1.43 to - 192.0.2.123, there would be no way for the responder to determine - which pair of addresses should be included in this tunnel, and it - would have to make a guess or reject the request with a status of - SINGLE_PAIR_REQUIRED. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 35] - -Internet-Draft IKEv2bis February 2006 - - - {{ Clarif-4.11 }} Few implementations will have policies that require - separate SAs for each address pair. Because of this, if only some - part (or parts) of the TSi/TSr proposed by the initiator is (are) - acceptable to the responder, responders SHOULD narrow TSi/TSr to an - acceptable subset rather than use SINGLE_PAIR_REQUIRED. - - To enable the responder to choose the appropriate range in this case, - if the initiator has requested the SA due to a data packet, the - initiator SHOULD include as the first traffic selector in each of TSi - and TSr a very specific traffic selector including the addresses in - the packet triggering the request. In the example, the initiator - would include in TSi two traffic selectors: the first containing the - address range (192.0.1.43 - 192.0.1.43) and the source port and IP - protocol from the packet and the second containing (192.0.1.0 - - 192.0.1.255) with all ports and IP protocols. The initiator would - similarly include two traffic selectors in TSr. - - If the responder's policy does not allow it to accept the entire set - of traffic selectors in the initiator's request, but does allow him - to accept the first selector of TSi and TSr, then the responder MUST - narrow the traffic selectors to a subset that includes the - initiator's first choices. In this example, the responder might - respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and - IP protocols. - - If the initiator creates the CHILD_SA pair not in response to an - arriving packet, but rather, say, upon startup, then there may be no - specific addresses the initiator prefers for the initial tunnel over - any other. In that case, the first values in TSi and TSr MAY be - ranges rather than specific values, and the responder chooses a - subset of the initiator's TSi and TSr that are acceptable. If more - than one subset is acceptable but their union is not, the responder - MUST accept some subset and MAY include a Notify payload of type - ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to - try again. This case will occur only when the initiator and - responder are configured differently from one another. If the - initiator and responder agree on the granularity of tunnels, the - initiator will never request a tunnel wider than the responder will - accept. {{ Demoted the SHOULD }} Such misconfigurations should be - recorded in error logs. - - {{ Clarif-4.10 }} A concise summary of the narrowing process is: - - 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 - - - -Kaufman, et al. Expires August 27, 2006 [Page 36] - -Internet-Draft IKEv2bis February 2006 - - - 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. - -2.9.1. Traffic Selectors Violating Own Policy - - {{ Clarif-4.12 }} - - When creating a new SA, the initiator needs to avoid proposing - traffic selectors that violate its own policy. If this rule is not - followed, valid traffic may be dropped. - - This is best illustrated by an example. Suppose that host A has a - policy whose effect is that traffic to 192.0.1.66 is sent via host B - encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 - is also sent via B, but must use 3DES. Suppose also that host B - accepts any combination of AES and 3DES. - - If host A now proposes an SA that uses 3DES, and includes TSr - containing (192.0.1.0-192.0.1.0.255), this will be accepted by host - B. Now, host B can also use this SA to send traffic from 192.0.1.66, - but those packets will be dropped by A since it requires the use of - AES for those traffic. Even if host A creates a new SA only for - 192.0.1.66 that uses AES, host B may freely continue to use the first - SA for the traffic. In this situation, when proposing the SA, host A - should have followed its own policy, and included a TSr containing - ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. - - In general, if (1) the initiator makes a proposal "for traffic X - (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator - does not actually accept traffic X' with SA, and (3) the initiator - would be willing to accept traffic X' with some SA' (!=SA), valid - traffic can be unnecessarily dropped since the responder can apply - either SA or SA' to traffic X'. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 37] - -Internet-Draft IKEv2bis February 2006 - - -2.10. Nonces - - The IKE_SA_INIT messages each contain a nonce. These nonces are used - as inputs to cryptographic functions. The CREATE_CHILD_SA request - and the CREATE_CHILD_SA response also contain nonces. These nonces - are used to add freshness to the key derivation technique used to - obtain keys for CHILD_SA, and to ensure creation of strong pseudo- - random bits from the Diffie-Hellman key. 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. ("prf" refers to - "pseudo-random function", one of the cryptographic algorithms - negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the - initiator chooses the nonce before the outcome of the negotiation is - known. Because of that, the nonce has to be long enough for all the - PRFs being proposed. If the same random number source is used for - both keys and nonces, care must be taken to ensure that the latter - use does not compromise the former. - -2.11. Address and Port Agility - - IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and - AH associations for the same IP addresses it runs over. The IP - addresses and ports in the outer header are, however, not themselves - cryptographically protected, and IKE is designed to work even through - Network Address Translation (NAT) boxes. An implementation MUST - accept incoming requests even if the source port is not 500 or 4500, - and MUST respond to the address and port from which the request was - received. It MUST specify the address and port at which the request - was received as the source address and port in the response. IKE - functions identically over IPv4 or IPv6. - -2.12. Reuse of Diffie-Hellman Exponentials - - IKE generates keying material using an ephemeral Diffie-Hellman - exchange in order to gain the property of "perfect forward secrecy". - This means that once a connection is closed and its corresponding - keys are forgotten, even someone who has recorded all of the data - from the connection and gets access to all of the long-term keys of - the two endpoints cannot reconstruct the keys used to protect the - conversation without doing a brute force search of the session key - space. - - Achieving perfect forward secrecy requires that when a connection is - closed, each endpoint MUST forget not only the keys used by the - connection but also any information that could be used to recompute - those keys. In particular, it MUST forget the secrets used in the - Diffie-Hellman calculation and any state that may persist in the - state of a pseudo-random number generator that could be used to - - - -Kaufman, et al. Expires August 27, 2006 [Page 38] - -Internet-Draft IKEv2bis February 2006 - - - recompute the Diffie-Hellman secrets. - - Since the computing of Diffie-Hellman exponentials is computationally - expensive, an endpoint may find it advantageous to reuse those - exponentials for multiple connection setups. There are several - reasonable strategies for doing this. An endpoint could choose a new - exponential only periodically though this could result in less-than- - perfect forward secrecy if some connection lasts for less than the - lifetime of the exponential. Or it could keep track of which - exponential was used for each connection and delete the information - associated with the exponential only when some corresponding - connection was closed. This would allow the exponential to be reused - without losing perfect forward secrecy at the cost of maintaining - more state. - - Decisions as to whether and when to reuse Diffie-Hellman exponentials - is a private decision in the sense that it will not affect - interoperability. An implementation that reuses exponentials MAY - choose to remember the exponential used by the other endpoint on past - exchanges and if one is reused to avoid the second half of the - calculation. - -2.13. Generating Keying Material - - In the context of the IKE_SA, four cryptographic algorithms are - negotiated: an encryption algorithm, an integrity protection - algorithm, a Diffie-Hellman group, and a pseudo-random function - (prf). The pseudo-random function is used for the construction of - keying material for all of the cryptographic algorithms used in both - the IKE_SA and the CHILD_SAs. - - We assume that each encryption algorithm and integrity protection - algorithm uses a fixed-size key and that any randomly chosen value of - that fixed size can serve as an appropriate key. For algorithms that - accept a variable length key, a fixed key size MUST be specified as - part of the cryptographic transform negotiated. For algorithms for - which not all values are valid keys (such as DES or 3DES with key - parity), the algorithm by which keys are derived from arbitrary - values MUST be specified by the cryptographic transform. For - integrity protection functions based on Hashed Message Authentication - Code (HMAC), the fixed key size is the size of the output of the - underlying hash function. When the prf function takes a variable - length key, variable length data, and produces a fixed-length output - (e.g., when using HMAC), the formulas in this document apply. When - the key for the prf function has fixed length, the data provided as a - key is truncated or padded with zeros as necessary unless exceptional - processing is explained following the formula. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 39] - -Internet-Draft IKEv2bis February 2006 - - - Keying material will always be derived as the output of the - negotiated prf algorithm. Since the amount of keying material needed - may be greater than the size of the output of the prf algorithm, we - will use the prf iteratively. We will use the terminology prf+ to - describe the function that outputs a pseudo-random stream based on - the inputs to a prf as follows: (where | indicates concatenation) - - prf+ (K,S) = T1 | T2 | T3 | T4 | ... - - where: - T1 = prf (K, S | 0x01) - T2 = prf (K, T1 | S | 0x02) - T3 = prf (K, T2 | S | 0x03) - T4 = prf (K, T3 | S | 0x04) - - continuing as needed to compute all required keys. The keys are - taken from the output string without regard to boundaries (e.g., if - the required keys are a 256-bit Advanced Encryption Standard (AES) - key and a 160-bit HMAC key, and the prf function generates 160 bits, - the AES key will come from T1 and the beginning of T2, while the HMAC - key will come from the rest of T2 and the beginning of T3). - - The constant concatenated to the end of each string feeding the prf - is a single octet. prf+ in this document is not defined beyond 255 - times the size of the prf output. - -2.14. Generating Keying Material for the IKE_SA - - The shared keys are computed as follows. A quantity called SKEYSEED - is calculated from the nonces exchanged during the IKE_SA_INIT - exchange and the Diffie-Hellman shared secret established during that - exchange. SKEYSEED is used to calculate seven other secrets: SK_d - used for deriving new keys for the CHILD_SAs established with this - IKE_SA; SK_ai and SK_ar used as a key to the integrity protection - algorithm for authenticating the component messages of subsequent - exchanges; SK_ei and SK_er used for encrypting (and of course - decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are - used when generating an AUTH payload. - - SKEYSEED and its derivatives are computed as follows: - - SKEYSEED = prf(Ni | Nr, g^ir) - - {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } - = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) - - (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, - SK_pi, and SK_pr are taken in order from the generated bits of the - - - -Kaufman, et al. Expires August 27, 2006 [Page 40] - -Internet-Draft IKEv2bis February 2006 - - - prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman - exchange. g^ir is represented as a string of octets in big endian - order padded with zeros if necessary to make it the length of the - modulus. Ni and Nr are the nonces, stripped of any headers. If the - negotiated prf takes a fixed-length key and the lengths of Ni and Nr - do not add up to that length, half the bits must come from Ni and - half from Nr, taking the first bits of each. - - The two directions of traffic flow use different keys. The keys used - to protect messages from the original initiator are SK_ai and SK_ei. - The keys used to protect messages in the other direction are SK_ar - and SK_er. Each algorithm takes a fixed number of bits of keying - material, which is specified as part of the algorithm. For integrity - algorithms based on a keyed hash, the key size is always equal to the - length of the output of the underlying hash function. - -2.15. Authentication of the IKE_SA - - When not using extensible authentication (see Section 2.16), the - peers are authenticated by having each sign (or MAC using a shared - secret as the key) a block of data. For the responder, the octets to - be signed start with the first octet of the first SPI in the header - of the second message and end with the last octet of the last payload - in the second message. Appended to this (for purposes of computing - the signature) are the initiator's nonce Ni (just the value, not the - payload containing it), and the value prf(SK_pr,IDr') where IDr' is - the responder's ID payload excluding the fixed header. Note that - neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. - Similarly, the initiator signs the first message, starting with the - first octet of the first SPI in the header and ending with the last - octet of the last payload. Appended to this (for purposes of - computing the signature) are the responder's nonce Nr, and the value - prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the - entire ID payloads excluding the fixed header. It is critical to the - security of the exchange that each side sign the other side's nonce. - - {{ Clarif-3.1 }} - - 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) - - - -Kaufman, et al. Expires August 27, 2006 [Page 41] - -Internet-Draft IKEv2bis February 2006 - - - 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) - - Note that all of the payloads are included under the signature, - including any payload types not defined in this document. If the - first message of the exchange is sent twice (the second time with a - responder cookie and/or a different Diffie-Hellman group), it is the - second version of the message that is signed. - - Optionally, messages 3 and 4 MAY include a certificate, or - certificate chain providing evidence that the key used to compute a - digital signature belongs to the name in the ID payload. The - signature or MAC will be computed using algorithms dictated by the - type of key used by the signer, and specified by the Auth Method - field in the Authentication payload. There is no requirement that - the initiator and responder sign with the same cryptographic - algorithms. The choice of cryptographic algorithms depends on the - type of key each has. In particular, the initiator may be using a - shared key while the responder may have a public signature key and - certificate. It will commonly be the case (but it is not required) - that if a shared secret is used for authentication that the same key - is used in both directions. Note that it is a common but typically - insecure practice to have a shared key derived solely from a user- - chosen password without incorporating another source of randomness. - - This is typically insecure because user-chosen passwords are unlikely - to have sufficient unpredictability to resist dictionary attacks and - these attacks are not prevented in this authentication method. - (Applications using password-based authentication for bootstrapping - and IKE_SA should use the authentication method in Section 2.16, - which is designed to prevent off-line dictionary attacks.) {{ Demoted - the SHOULD }} The pre-shared key needs to contain as much - unpredictability as the strongest key being negotiated. In the case - of a pre-shared key, the AUTH value is computed as: - - AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) - - where the string "Key Pad for IKEv2" is 17 ASCII characters without - null termination. The shared secret can be variable length. The pad - string is added so that if the shared secret is derived from a - - - -Kaufman, et al. Expires August 27, 2006 [Page 42] - -Internet-Draft IKEv2bis February 2006 - - - password, the IKE implementation need not store the password in - cleartext, but rather can store the value prf(Shared Secret,"Key Pad - for IKEv2"), which could not be used as a password equivalent for - protocols other than IKEv2. As noted above, deriving the shared - secret from a password is not secure. This construction is used - because it is anticipated that people will do it anyway. The - management interface by which the Shared Secret is provided MUST - accept ASCII strings of at least 64 octets and MUST NOT add a null - terminator before using them as shared secrets. It MUST also accept - a hex encoding of the Shared Secret. The management interface MAY - accept other encodings if the algorithm for translating the encoding - to a binary string is specified. - - {{ Clarif-3.7 }} If the negotiated prf takes a fixed-size key, the - shared secret MUST be of that fixed size. This requirement means - that it is difficult to use these PRFs with shared key authentication - because it limits the shared secrets that can be used. Thus, PRFs - that require a fixed-size key SHOULD NOT be used with shared key - authentication. For example, PRF_AES128_CBC [PRFAES128CBC] - originally used fixed key sizes; that RFC has been updated to handle - variable key sizes in [PRFAES128CBC-bis]. Note that Section 2.13 - also contains text that is related to PRFs with fixed key size. - However, the text in that section applies only to the prf+ - construction. - -2.16. Extensible Authentication Protocol Methods - - In addition to authentication using public key signatures and shared - secrets, IKE supports authentication using methods defined in RFC - 3748 [EAP]. Typically, these methods are asymmetric (designed for a - user authenticating to a server), and they may not be mutual. {{ In - the next sentence, changed "public key signature based" to "strong" - }} For this reason, these protocols are typically used to - authenticate the initiator to the responder and MUST be used in - conjunction with a strong authentication of the responder to the - initiator. These methods are often associated with mechanisms - referred to as "Legacy Authentication" mechanisms. - - While this memo references [EAP] with the intent that new methods can - be added in the future without updating this specification, some - simpler variations are documented here and in Section 3.16. [EAP] - defines an authentication protocol requiring a variable number of - messages. Extensible Authentication is implemented in IKE as - additional IKE_AUTH exchanges that MUST be completed in order to - initialize the IKE_SA. - - An initiator indicates a desire to use extensible authentication by - leaving out the AUTH payload from message 3. By including an IDi - - - -Kaufman, et al. Expires August 27, 2006 [Page 43] - -Internet-Draft IKEv2bis February 2006 - - - payload but not an AUTH payload, the initiator has declared an - identity but has not proven it. If the responder is willing to use - an extensible authentication method, it will place an Extensible - Authentication Protocol (EAP) payload in message 4 and defer sending - SAr2, TSi, and TSr until initiator authentication is complete in a - subsequent IKE_AUTH exchange. In the case of a minimal extensible - authentication, the initial SA establishment will appear as follows: - - Initiator Responder - ------------------------------------------------------------------- - HDR, SAi1, KEi, Ni --> - <-- HDR, SAr1, KEr, Nr, [CERTREQ] - HDR, SK {IDi, [CERTREQ,] - [IDr,] SAi2, - TSi, TSr} --> - <-- HDR, SK {IDr, [CERT,] AUTH, - EAP } - HDR, SK {EAP} --> - <-- HDR, SK {EAP (success)} - HDR, SK {AUTH} --> - <-- HDR, SK {AUTH, SAr2, TSi, TSr } - - {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each - pair of IKE_SA initial setup messages will have their message numbers - incremented; the first pair of AUTH messages will have an ID of 1, - the second will be 2, and so on. - - For EAP methods that create a shared key as a side effect of - authentication, that shared key MUST be used by both the initiator - and responder to generate AUTH payloads in messages 7 and 8 using the - syntax for shared secrets specified in Section 2.15. The shared key - from EAP is the field from the EAP specification named MSK. The - shared key generated during an IKE exchange MUST NOT be used for any - other purpose. - - EAP methods that do not establish a shared key SHOULD NOT be used, as - they are subject to a number of man-in-the-middle attacks [EAPMITM] - if these EAP methods are used in other protocols that do not use a - server-authenticated tunnel. Please see the Security Considerations - section for more details. If EAP methods that do not generate a - shared key are used, the AUTH payloads in messages 7 and 8 MUST be - generated using SK_pi and SK_pr, respectively. - - {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs - to be capable of extending the initial protocol exchange to at least - ten IKE_AUTH exchanges in the event the responder sends notification - messages and/or retries the authentication prompt. Once the protocol - exchange defined by the chosen EAP authentication method has - - - -Kaufman, et al. Expires August 27, 2006 [Page 44] - -Internet-Draft IKEv2bis February 2006 - - - successfully terminated, the responder MUST send an EAP payload - containing the Success message. Similarly, if the authentication - method has failed, the responder MUST send an EAP payload containing - the Failure message. The responder MAY at any time terminate the IKE - exchange by sending an EAP payload containing the Failure message. - - Following such an extended exchange, the EAP AUTH payloads MUST be - included in the two messages following the one containing the EAP - Success message. - - {{ Clarif-3.5 }} 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. - 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. In this case, the authenticated identity has to be sent - from the AAA server to the IKEv2 responder. - - {{ Clarif-3.8 }} The information in Section 2.17 about PRFs with - fixed-size keys also applies to EAP authentication. For instance, a - PRF that requires a 128-bit key cannot be used with EAP because - specifies that the MSK is at least 512 bits long. - -2.17. Generating Keying Material for CHILD_SAs - - A single CHILD_SA is created by the IKE_AUTH exchange, and additional - CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. - Keying material for them is generated as follows: - - KEYMAT = prf+(SK_d, Ni | Nr) - - Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this - request is the first CHILD_SA created or the fresh Ni and Nr from the - CREATE_CHILD_SA exchange if this is a subsequent creation. - - For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman - exchange, the keying material is defined as: - - KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) - - where g^ir (new) is the shared secret from the ephemeral Diffie- - Hellman exchange of this CREATE_CHILD_SA exchange (represented as an - octet string in big endian order padded with zeros in the high-order - bits if necessary to make it the length of the modulus). - - A single CHILD_SA negotiation may result in multiple security - - - -Kaufman, et al. Expires August 27, 2006 [Page 45] - -Internet-Draft IKEv2bis February 2006 - - - associations. ESP and AH SAs exist in pairs (one in each direction), - and four SAs could be created in a single CHILD_SA negotiation if a - combination of ESP and AH is being negotiated. - - Keying material MUST be taken from the expanded KEYMAT in the - following order: - - o All keys for SAs carrying data from the initiator to the responder - are taken before SAs going in the reverse direction. - - o If multiple IPsec protocols are negotiated, keying material is - taken in the order in which the protocol headers will appear in - the encapsulated packet. - - o If a single protocol has both encryption and authentication keys, - the encryption key is taken from the first octets of KEYMAT and - the authentication key is taken from the next octets. - - Each cryptographic algorithm takes a fixed number of bits of keying - material specified as part of the algorithm. - -2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA - (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs - are supplied in the SPI fields in the Proposal structures inside the - Security Association (SA) payloads (not the SPI fields in the IKE - header). The TS payloads are omitted when rekeying an IKE_SA. - 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) - - where g^ir (new) is the shared secret from the ephemeral Diffie- - Hellman exchange of this CREATE_CHILD_SA exchange (represented as an - octet string in big endian order padded with zeros if necessary to - make it the length of the modulus) and Ni and Nr are the two nonces - stripped of any headers. - - {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different - PRF. Because the rekeying exchange belongs to the old IKE_SA, it is - the old IKE_SA's PRF that is used. Note that this may not work if - the new IKE_SA's PRF has a fixed key size because the output of the - PRF may not be of the correct size. - - The new IKE_SA MUST reset its message counters to 0. - - SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as - - - -Kaufman, et al. Expires August 27, 2006 [Page 46] - -Internet-Draft IKEv2bis February 2006 - - - specified in Section 2.14. - -2.19. Requesting an Internal Address on a Remote Network - - Most commonly occurring in the endpoint-to-security-gateway scenario, - an endpoint may need an IP address in the network protected by the - security gateway and may need to have that address dynamically - assigned. A request for such a temporary address can be included in - any request to create a CHILD_SA (including the implicit request in - message 3) by including a CP payload. - - This function provides address allocation to an IPsec Remote Access - Client (IRAC) trying to tunnel into a network protected by an IPsec - Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an - IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled - address (and optionally other information concerning the protected - network) in the IKE_AUTH exchange. The IRAS may procure an address - for the IRAC from any number of sources such as a DHCP/BOOTP server - or its own address pool. - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK {IDi, [CERT,] - [CERTREQ,] [IDr,] AUTH, - CP(CFG_REQUEST), SAi2, - TSi, TSr} --> - <-- HDR, SK {IDr, [CERT,] AUTH, - CP(CFG_REPLY), SAr2, - TSi, TSr} - - In all cases, the CP payload MUST be inserted before the SA payload. - In variations of the protocol where there are multiple IKE_AUTH - exchanges, the CP payloads MUST be inserted in the messages - containing the SA payloads. - - CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute - (either IPv4 or IPv6) but MAY contain any number of additional - attributes the initiator wants returned in the response. - - For example, message from initiator to responder: - - CP(CFG_REQUEST)= - INTERNAL_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) - - NOTE: Traffic Selectors contain (protocol, port range, address - range). - - - -Kaufman, et al. Expires August 27, 2006 [Page 47] - -Internet-Draft IKEv2bis February 2006 - - - Message from responder to initiator: - - CP(CFG_REPLY)= - INTERNAL_ADDRESS(192.0.2.202) - INTERNAL_NETMASK(255.255.255.0) - INTERNAL_SUBNET(192.0.2.0/255.255.255.0) - TSi = (0, 0-65535,192.0.2.202-192.0.2.202) - TSr = (0, 0-65535,192.0.2.0-192.0.2.255) - - All returned values will be implementation dependent. As can be seen - in the above example, the IRAS MAY also send other attributes that - were not included in CP(CFG_REQUEST) and MAY ignore the non- - mandatory attributes that it does not support. - - The responder MUST NOT send a CFG_REPLY without having first received - a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS - to perform an unnecessary configuration lookup if the IRAC cannot - process the REPLY. In the case where the IRAS's configuration - requires that CP be used for a given identity IDi, but IRAC has - failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and - terminate the IKE exchange with a FAILED_CP_REQUIRED error. - -2.20. Requesting the Peer's Version - - An IKE peer wishing to inquire about the other peer's IKE software - version information MAY use the method below. This is an example of - a configuration request within an INFORMATIONAL exchange, after the - IKE_SA and first CHILD_SA have been created. - - An IKE implementation MAY decline to give out version information - prior to authentication or even after authentication to prevent - trolling in case some implementation is known to have some security - weakness. In that case, it MUST either return an empty string or no - CP payload if CP is not supported. - - Initiator Responder - ------------------------------------------------------------------- - HDR, SK{CP(CFG_REQUEST)} --> - <-- HDR, SK{CP(CFG_REPLY)} - - CP(CFG_REQUEST)= - APPLICATION_VERSION("") - - CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar - Inc.") - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 48] - -Internet-Draft IKEv2bis February 2006 - - -2.21. Error Handling - - There are many kinds of errors that can occur during IKE processing. - If a request is received that is badly formatted or unacceptable for - reasons of policy (e.g., no matching cryptographic algorithms), the - response MUST contain a Notify payload indicating the error. If an - error occurs outside the context of an IKE request (e.g., the node is - getting ESP messages on a nonexistent SPI), the node SHOULD initiate - an INFORMATIONAL exchange with a Notify payload describing the - problem. - - Errors that occur before a cryptographically protected IKE_SA is - established must be handled very carefully. There is a trade-off - between wanting to be helpful in diagnosing a problem and responding - to it and wanting to avoid being a dupe in a denial of service attack - based on forged messages. - - If a node receives a message on UDP port 500 or 4500 outside the - context of an IKE_SA known to it (and not a request to start one), it - may be the result of a recent crash of the node. If the message is - marked as a response, the node MAY audit the suspicious event but - MUST NOT respond. If the message is marked as a request, the node - MAY audit the suspicious event and MAY send a response. 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. The response MUST NOT be cryptographically protected and - MUST contain a Notify payload indicating INVALID_IKE_SPI. - - A node receiving such an unprotected Notify payload MUST NOT respond - and MUST NOT change the state of any existing SAs. The message might - be a forgery or might be a response the genuine correspondent was - tricked into sending. {{ Demoted two SHOULDs }} A node should treat - such a message (and also a network message like ICMP destination - unreachable) as a hint that there might be problems with SAs to that - IP address and should initiate a liveness test for any such IKE_SA. - An implementation SHOULD limit the frequency of such tests to avoid - being tricked into participating in a denial of service attack. - - A node receiving a suspicious message from an IP address with which - it has an IKE_SA MAY send an IKE Notify payload in an IKE - INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The - recipient MUST NOT change the state of any SAs as a result, but may - wish to audit the event to aid in diagnosing malfunctions. A node - MUST limit the rate at which it will send messages in response to - unprotected messages. - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 49] - -Internet-Draft IKEv2bis February 2006 - - -2.22. IPComp - - Use of IP compression [IPCOMP] can be negotiated as part of the setup - of a CHILD_SA. While IP compression involves an extra header in each - packet and a compression parameter index (CPI), the virtual - "compression association" has no life outside the ESP or AH SA that - contains it. Compression associations disappear when the - corresponding ESP or AH SA goes away. It is not explicitly mentioned - in any DELETE payload. - - Negotiation of IP compression is separate from the negotiation of - cryptographic parameters associated with a CHILD_SA. A node - requesting a CHILD_SA MAY advertise its support for one or more - compression algorithms through one or more Notify payloads of type - IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single - compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. - These payloads MUST NOT occur in messages that do not contain SA - payloads. - - Although there has been discussion of allowing multiple compression - algorithms to be accepted and to have different compression - algorithms available for the two directions of a CHILD_SA, - implementations of this specification MUST NOT accept an IPComp - algorithm that was not proposed, MUST NOT accept more than one, and - MUST NOT compress using an algorithm other than one proposed and - accepted in the setup of the CHILD_SA. - - A side effect of separating the negotiation of IPComp from - cryptographic parameters is that it is not possible to propose - multiple cryptographic suites and propose IP compression with some of - them but not others. - -2.23. NAT Traversal - - Network Address Translation (NAT) gateways are a controversial - subject. This section briefly describes what they are and how they - are likely to act on IKE traffic. Many people believe that NATs are - evil and that we should not design our protocols so as to make them - work better. IKEv2 does specify some unintuitive processing rules in - order that NATs are more likely to work. - - NATs exist primarily because of the shortage of IPv4 addresses, - though there are other rationales. IP nodes that are "behind" a NAT - have IP addresses that are not globally unique, but rather are - assigned from some space that is unique within the network behind the - NAT but that are likely to be reused by nodes behind other NATs. - Generally, nodes behind NATs can communicate with other nodes behind - the same NAT and with nodes with globally unique addresses, but not - - - -Kaufman, et al. Expires August 27, 2006 [Page 50] - -Internet-Draft IKEv2bis February 2006 - - - with nodes behind other NATs. There are exceptions to that rule. - When those nodes make connections to nodes on the real Internet, the - NAT gateway "translates" the IP source address to an address that - will be routed back to the gateway. Messages to the gateway from the - Internet have their destination addresses "translated" to the - internal address that will route the packet to the correct endnode. - - NATs are designed to be "transparent" to endnodes. Neither software - on the node behind the NAT nor the node on the Internet requires - modification to communicate through the NAT. Achieving this - transparency is more difficult with some protocols than with others. - Protocols that include IP addresses of the endpoints within the - payloads of the packet will fail unless the NAT gateway understands - the protocol and modifies the internal references as well as those in - the headers. Such knowledge is inherently unreliable, is a network - layer violation, and often results in subtle problems. - - Opening an IPsec connection through a NAT introduces special - problems. If the connection runs in transport mode, changing the IP - addresses on packets will cause the checksums to fail and the NAT - cannot correct the checksums because they are cryptographically - protected. Even in tunnel mode, there are routing problems because - transparently translating the addresses of AH and ESP packets - requires special logic in the NAT and that logic is heuristic and - unreliable in nature. For that reason, IKEv2 can negotiate UDP - encapsulation of IKE and ESP packets. This encoding is slightly less - efficient but is easier for NATs to process. In addition, firewalls - may be configured to pass IPsec traffic over UDP but not ESP/AH or - vice versa. - - It is a common practice of NATs to translate TCP and UDP port numbers - as well as addresses and use the port numbers of inbound packets to - decide which internal node should get a given packet. For this - reason, even though IKE packets MUST be sent from and to UDP port - 500, they MUST be accepted coming from any port and responses MUST be - sent to the port from whence they came. This is because the ports - may be modified as the packets pass through NATs. Similarly, IP - addresses of the IKE endpoints are generally not included in the IKE - payloads because the payloads are cryptographically protected and - could not be transparently modified by NATs. - - Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working - through a NAT, it is generally better to pass IKE packets over port - 4500 because some older NATs handle IKE traffic on port 500 cleverly - in an attempt to transparently establish IPsec connections between - endpoints that don't handle NAT traversal themselves. Such NATs may - interfere with the straightforward NAT traversal envisioned by this - document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT - - - -Kaufman, et al. Expires August 27, 2006 [Page 51] - -Internet-Draft IKEv2bis February 2006 - - - between it and its correspondent MUST send all subsequent traffic - from port 4500, which NATs should not treat specially (as they might - with port 500). - - The specific requirements for supporting NAT traversal [NATREQ] are - listed below. Support for NAT traversal is optional. In this - section only, requirements listed as MUST apply only to - implementations supporting NAT traversal. - - o IKE MUST listen on port 4500 as well as port 500. IKE MUST - respond to the IP address and port from which packets arrived. - - o Both IKE initiator and responder MUST include in their IKE_SA_INIT - packets Notify payloads of type NAT_DETECTION_SOURCE_IP and - NAT_DETECTION_DESTINATION_IP. Those payloads can be used to - detect if there is NAT between the hosts, and which end is behind - the NAT. The location of the payloads in the IKE_SA_INIT packets - are just after the Ni and Nr payloads (before the optional CERTREQ - payload). - - o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches - the hash of the source IP and port found from the IP header of the - packet containing the payload, it means that the other end is - behind NAT (i.e., someone along the route changed the source - address of the original packet to match the address of the NAT - box). In this case, this end should allow dynamic update of the - other ends IP address, as described later. - - o If the NAT_DETECTION_DESTINATION_IP payload received does not - match the hash of the destination IP and port found from the IP - header of the packet containing the payload, it means that this - end is behind a NAT. In this case, this end SHOULD start sending - keepalive packets as explained in [UDPENCAPS]. - - o 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. - - o 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. To tunnel ESP packets over UDP port 4500, the ESP - header immediately follows the UDP header. Since the first four - bytes of the ESP header contain the SPI, and the SPI cannot - validly be zero, it is always possible to distinguish ESP and IKE - messages. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 52] - -Internet-Draft IKEv2bis February 2006 - - - o The original source and destination IP address required for the - transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) - are obtained from the Traffic Selectors associated with the - exchange. In the case of NAT traversal, the Traffic Selectors - MUST contain exactly one IP address, which is then used as the - original IP address. - - o There are cases where a NAT box decides to remove mappings that - are still alive (for example, the keepalive interval is too long, - or the NAT box is rebooted). To recover in these cases, hosts - that are not behind a NAT SHOULD send all packets (including - retransmission packets) to the IP address and port from the last - valid authenticated packet from the other end (i.e., dynamically - update the address). A host behind a NAT SHOULD NOT do this - because it opens a DoS attack possibility. Any authenticated IKE - packet or any authenticated UDP-encapsulated ESP packet can be - used to detect that the IP address or the port has changed. - - Note that similar but probably not identical actions will likely be - needed to make IKE work with Mobile IP, but such processing is not - addressed by this document. - -2.24. Explicit Congestion Notification (ECN) - - When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], - ECN usage is not appropriate for the outer IP headers because tunnel - decapsulation processing discards ECN congestion indications to the - detriment of the network. ECN support for IPsec tunnels for IKEv1- - based IPsec requires multiple operating modes and negotiation (see - [ECN]). IKEv2 simplifies this situation by requiring that ECN be - usable in the outer IP headers of all tunnel-mode IPsec SAs created - by IKEv2. Specifically, tunnel encapsulators and decapsulators for - all tunnel-mode SAs created by IKEv2 MUST support the ECN full- - functionality option for tunnels specified in [ECN] and MUST - implement the tunnel encapsulation and decapsulation processing - specified in [IPSECARCH] to prevent discarding of ECN congestion - indications. - - -3. Header and Payload Formats - -3.1. The IKE Header - - IKE messages use UDP ports 500 and/or 4500, with one IKE message per - UDP datagram. Information from the beginning of the packet through - the UDP header is largely ignored except that the IP addresses and - UDP ports from the headers are reversed and used for return packets. - When sent on UDP port 500, IKE messages begin immediately following - - - -Kaufman, et al. Expires August 27, 2006 [Page 53] - -Internet-Draft IKEv2bis February 2006 - - - the UDP header. When sent on UDP port 4500, IKE messages have - prepended four octets of zero. These four octets of zero are not - part of the IKE message and are not included in any of the length - fields or checksums defined by IKE. Each IKE message begins with the - IKE header, denoted HDR in this memo. Following the header are one - or more IKE payloads each identified by a "Next Payload" field in the - preceding payload. Payloads are processed in the order in which they - appear in an IKE message by invoking the appropriate processing - routine according to the "Next Payload" field in the IKE header and - subsequently according to the "Next Payload" field in the IKE payload - itself until a "Next Payload" field of zero indicates that no - payloads follow. If a payload of type "Encrypted" is found, that - payload is decrypted and its contents parsed as additional payloads. - An Encrypted payload MUST be the last payload in a packet and an - Encrypted payload MUST NOT contain another Encrypted payload. - - The Recipient SPI in the header identifies an instance of an IKE - security association. It is therefore possible for a single instance - of IKE to multiplex distinct sessions with multiple peers. - - All multi-octet fields representing integers are laid out in big - endian order (aka most significant byte first, or network byte - order). - - The format of the IKE header is shown in Figure 4. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! IKE_SA Initiator's SPI ! - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! IKE_SA Responder's SPI ! - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Message ID ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: IKE Header Format - - o Initiator's SPI (8 octets) - A value chosen by the initiator to - identify a unique IKE security association. This value MUST NOT - be zero. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 54] - -Internet-Draft IKEv2bis February 2006 - - - o Responder's SPI (8 octets) - A value chosen by the responder to - identify a unique IKE security association. This value MUST be - zero in the first message of an IKE Initial Exchange (including - repeats of that message including a cookie). {{ The phrase "and - MUST NOT be zero in any other message" was removed; Clarif-2.1 }} - - o Next Payload (1 octet) - Indicates the type of payload that - immediately follows the header. The format and value of each - payload are defined below. - - o Major Version (4 bits) - Indicates the major version of the IKE - protocol in use. Implementations based on this version of IKE - MUST set the Major Version to 2. Implementations based on - previous versions of IKE and ISAKMP MUST set the Major Version to - 1. Implementations based on this version of IKE MUST reject or - ignore messages containing a version number greater than 2. - - o Minor Version (4 bits) - Indicates the minor version of the IKE - protocol in use. Implementations based on this version of IKE - MUST set the Minor Version to 0. They MUST ignore the minor - version number of received messages. - - o Exchange Type (1 octet) - Indicates the type of exchange being - used. This constrains the payloads sent in each message and - orderings of messages in an exchange. - - Exchange Type Value - ---------------------------------- - RESERVED 0-33 - IKE_SA_INIT 34 - IKE_AUTH 35 - CREATE_CHILD_SA 36 - INFORMATIONAL 37 - RESERVED TO IANA 38-239 - Reserved for private use 240-255 - - o Flags (1 octet) - Indicates specific options that are set for the - message. Presence of options are indicated by the appropriate bit - in the flags field being set. The bits are defined LSB first, so - bit 0 would be the least significant bit of the Flags octet. In - the description below, a bit being 'set' means its value is '1', - while 'cleared' means its value is '0'. - - * X(reserved) (bits 0-2) - These bits MUST be cleared when - sending and MUST be ignored on receipt. - - * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages - sent by the original initiator of the IKE_SA and MUST be - - - -Kaufman, et al. Expires August 27, 2006 [Page 55] - -Internet-Draft IKEv2bis February 2006 - - - cleared in messages sent by the original responder. It is used - by the recipient to determine which eight octets of the SPI - were generated by the recipient. - - * V(ersion) (bit 4 of Flags) - This bit indicates that the - transmitter is capable of speaking a higher major version - number of the protocol than the one indicated in the major - version number field. Implementations of IKEv2 must clear this - bit when sending and MUST ignore it in incoming messages. - - * R(esponse) (bit 5 of Flags) - This bit indicates that this - message is a response to a message containing the same message - ID. This bit MUST be cleared in all request messages and MUST - be set in all responses. An IKE endpoint MUST NOT generate a - response to a message that is marked as being a response. - - * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared - when sending and MUST be ignored on receipt. - - o Message ID (4 octets) - Message identifier used to control - retransmission of lost packets and matching of requests and - responses. It is essential to the security of the protocol - because it is used to prevent message replay attacks. See - Section 2.1 and Section 2.2. - - o Length (4 octets) - Length of total message (header + payloads) in - octets. - -3.2. Generic Payload Header - - Each IKE payload defined in Section 3.3 through Section 3.16 begins - with a generic payload header, shown in Figure 5. Figures for each - payload below will include the generic payload header, but for - brevity the description of each field will be omitted. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 5: Generic Payload Header - - The Generic Payload Header fields are defined as follows: - - o Next Payload (1 octet) - Identifier for the payload type of the - next payload in the message. If the current payload is the last - in the message, then this field will be 0. This field provides a - - - -Kaufman, et al. Expires August 27, 2006 [Page 56] - -Internet-Draft IKEv2bis February 2006 - - - "chaining" capability whereby additional payloads can be added to - a message by appending it to the end of the message and setting - the "Next Payload" field of the preceding payload to indicate the - new payload's type. An Encrypted payload, which must always be - the last payload of a message, is an exception. It contains data - structures in the format of additional payloads. In the header of - an Encrypted payload, the Next Payload field is set to the payload - type of the first contained payload (instead of 0). The payload - type values are: - - Next Payload Type Notation Value - -------------------------------------------------- - No Next Payload 0 - RESERVED 1-32 - Security Association SA 33 - Key Exchange KE 34 - Identification - Initiator IDi 35 - Identification - Responder IDr 36 - Certificate CERT 37 - Certificate Request CERTREQ 38 - Authentication AUTH 39 - Nonce Ni, Nr 40 - Notify N 41 - Delete D 42 - Vendor ID V 43 - Traffic Selector - Initiator TSi 44 - Traffic Selector - Responder TSr 45 - Encrypted E 46 - Configuration CP 47 - Extensible Authentication EAP 48 - RESERVED TO IANA 49-127 - PRIVATE USE 128-255 - - (Payload type values 1-32 should not be assigned in the - future so that there is no overlap with the code assignments - for IKEv1.) - - o Critical (1 bit) - MUST be set to zero if the sender wants the - recipient to skip this payload if it does not understand the - payload type code in the Next Payload field of the previous - payload. MUST be set to one if the sender wants the recipient to - reject this entire message if it does not understand the payload - type. MUST be ignored by the recipient if the recipient - understands the payload type code. MUST be set to zero for - payload types defined in this document. Note that the critical - bit applies to the current payload rather than the "next" payload - whose type code appears in the first octet. The reasoning behind - not setting the critical bit for payloads defined in this document - - - -Kaufman, et al. Expires August 27, 2006 [Page 57] - -Internet-Draft IKEv2bis February 2006 - - - is that all implementations MUST understand all payload types - defined in this document and therefore must ignore the Critical - bit's value. Skipped payloads are expected to have valid Next - Payload and Payload Length fields. - - o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on - receipt. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - -3.3. Security Association Payload - - The Security Association Payload, denoted SA in this memo, is used to - negotiate attributes of a security association. Assembly of Security - Association Payloads requires great peace of mind. An SA payload MAY - contain multiple proposals. If there is more than one, they MUST be - ordered from most preferred to least preferred. Each proposal may - contain multiple IPsec protocols (where a protocol is IKE, ESP, or - AH), each protocol MAY contain multiple transforms, and each - transform MAY contain multiple attributes. When parsing an SA, an - implementation MUST check that the total Payload Length is consistent - with the payload's internal lengths and counts. Proposals, - Transforms, and Attributes each have their own variable length - encodings. They are nested such that the Payload Length of an SA - includes the combined contents of the SA, Proposal, Transform, and - Attribute information. The length of a Proposal includes the lengths - of all Transforms and Attributes it contains. The length of a - Transform includes the lengths of all Attributes it contains. - - The syntax of Security Associations, Proposals, Transforms, and - Attributes is based on ISAKMP; however the semantics are somewhat - different. The reason for the complexity and the hierarchy is to - allow for multiple possible combinations of algorithms to be encoded - in a single SA. Sometimes there is a choice of multiple algorithms, - whereas other times there is a combination of algorithms. For - example, an initiator might want to propose using (AH w/MD5 and ESP - w/3DES) OR (ESP w/MD5 and 3DES). - - One of the reasons the semantics of the SA payload has changed from - ISAKMP and IKEv1 is to make the encodings more compact in common - cases. - - The Proposal structure contains within it a Proposal # and an IPsec - protocol ID. Each structure MUST have the same Proposal # as the - previous one or be one (1) greater. The first Proposal MUST have a - Proposal # of one (1). If two successive structures have the same - Proposal number, it means that the proposal consists of the first - - - -Kaufman, et al. Expires August 27, 2006 [Page 58] - -Internet-Draft IKEv2bis February 2006 - - - structure AND the second. So a proposal of AH AND ESP would have two - proposal structures, one for AH and one for ESP and both would have - Proposal #1. A proposal of AH OR ESP would have two proposal - structures, one for AH with Proposal #1 and one for ESP with Proposal - #2. - - Each Proposal/Protocol structure is followed by one or more transform - structures. The number of different transforms is generally - determined by the Protocol. AH generally has a single transform: an - integrity check algorithm. ESP generally has two: an encryption - algorithm and an integrity check algorithm. IKE generally has four - transforms: a Diffie-Hellman group, an integrity check algorithm, a - prf algorithm, and an encryption algorithm. If an algorithm that - combines encryption and integrity protection is proposed, it MUST be - proposed as an encryption algorithm and an integrity protection - algorithm MUST NOT be proposed. For each Protocol, the set of - permissible transforms is assigned transform ID numbers, which appear - in the header of each transform. - - If there are multiple transforms with the same Transform Type, the - proposal is an OR of those transforms. If there are multiple - Transforms with different Transform Types, the proposal is an AND of - the different groups. For example, to propose ESP with (3DES or - IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two - Transform Type 1 candidates (one for 3DES and one for IDEA) and two - Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). - This effectively proposes four combinations of algorithms. If the - initiator wanted to propose only a subset of those, for example (3DES - and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that - as multiple transforms within a single Proposal. Instead, the - initiator would have to construct two different Proposals, each with - two transforms. - - A given transform MAY have one or more Attributes. Attributes are - necessary when the transform can be used in more than one way, as - when an encryption algorithm has a variable key size. The transform - would specify the algorithm and the attribute would specify the key - size. Most transforms do not have attributes. A transform MUST NOT - have multiple attributes of the same type. To propose alternate - values for an attribute (for example, multiple key sizes for the AES - encryption algorithm), and implementation MUST include multiple - Transforms with the same Transform Type each with a single Attribute. - - Note that the semantics of Transforms and Attributes are quite - different from those in IKEv1. In IKEv1, a single Transform carried - multiple algorithms for a protocol with one carried in the Transform - and the others carried in the Attributes. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 59] - -Internet-Draft IKEv2bis February 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: Security Association Payload - - o Proposals (variable) - One or more proposal substructures. - - The payload type for the Security Association Payload is thirty three - (33). - -3.3.1. Proposal Substructure - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 (last) or 2 ! RESERVED ! Proposal Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ SPI (variable) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 7: Proposal Substructure - - o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the - last Proposal Substructure in the SA. This syntax is inherited - from ISAKMP, but is unnecessary because the last Proposal could be - identified from the length of the SA. The value (2) corresponds - to a Payload Type of Proposal in IKEv1, and the first four octets - of the Proposal structure are designed to look somewhat like the - header of a Payload. - - o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on - receipt. - - o Proposal Length (2 octets) - Length of this proposal, including - all transforms and attributes that follow. - - - -Kaufman, et al. Expires August 27, 2006 [Page 60] - -Internet-Draft IKEv2bis February 2006 - - - o Proposal # (1 octet) - When a proposal is made, the first proposal - in an SA payload MUST be #1, and subsequent proposals MUST either - be the same as the previous proposal (indicating an AND of the two - proposals) or one more than the previous proposal (indicating an - OR of the two proposals). When a proposal is accepted, all of the - proposal numbers in the SA payload MUST be the same and MUST match - the number on the proposal sent that was accepted. - - o Protocol ID (1 octet) - Specifies the IPsec protocol identifier - for the current negotiation. The defined values are: - - Protocol Protocol ID - ----------------------------------- - RESERVED 0 - IKE 1 - AH 2 - ESP 3 - RESERVED TO IANA 4-200 - PRIVATE USE 201-255 - - o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field - MUST be zero; the SPI is obtained from the outer header. During - subsequent negotiations, it is equal to the size, in octets, of - the SPI of the corresponding protocol (8 for IKE, 4 for ESP and - AH). - - o # of Transforms (1 octet) - Specifies the number of transforms in - this proposal. - - o SPI (variable) - The sending entity's SPI. Even if the SPI Size - is not a multiple of 4 octets, there is no padding applied to the - payload. When the SPI Size field is zero, this field is not - present in the Security Association payload. - - o Transforms (variable) - One or more transform substructures. - - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 61] - -Internet-Draft IKEv2bis February 2006 - - -3.3.2. Transform Substructure - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 (last) or 3 ! RESERVED ! Transform Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !Transform Type ! RESERVED ! Transform ID ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Transform Attributes ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 8: Transform Substructure - - o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the - last Transform Substructure in the Proposal. This syntax is - inherited from ISAKMP, but is unnecessary because the last - Proposal could be identified from the length of the SA. The value - (3) corresponds to a Payload Type of Transform in IKEv1, and the - first four octets of the Transform structure are designed to look - somewhat like the header of a Payload. - - o RESERVED - MUST be sent as zero; MUST be ignored on receipt. - - o Transform Length - The length (in octets) of the Transform - Substructure including Header and Attributes. - - o Transform Type (1 octet) - The type of transform being specified - in this transform. Different protocols support different - transform types. For some protocols, some of the transforms may - be optional. If a transform is optional and the initiator wishes - to propose that the transform be omitted, no transform of the - given type is included in the proposal. If the initiator wishes - to make use of the transform optional to the responder, it - includes a transform substructure with transform ID = 0 as one of - the options. - - o Transform ID (2 octets) - The specific instance of the transform - type being proposed. - - The tranform type values are: - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 62] - -Internet-Draft IKEv2bis February 2006 - - - Description Trans. Used In - Type - ------------------------------------------------------------------ - RESERVED 0 - Encryption Algorithm (ENCR) 1 IKE and ESP - Pseudo-random Function (PRF) 2 IKE - Integrity Algorithm (INTEG) 3 IKE, AH, optional in ESP - Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP - Extended Sequence Numbers (ESN) 5 AH and ESP - RESERVED TO IANA 6-240 - PRIVATE USE 241-255 - - For Transform Type 1 (Encryption Algorithm), defined Transform IDs - are: - - Name Number Defined In - --------------------------------------------------- - RESERVED 0 - ENCR_DES_IV64 1 (RFC1827) - ENCR_DES 2 (RFC2405), [DES] - ENCR_3DES 3 (RFC2451) - ENCR_RC5 4 (RFC2451) - ENCR_IDEA 5 (RFC2451), [IDEA] - ENCR_CAST 6 (RFC2451) - ENCR_BLOWFISH 7 (RFC2451) - ENCR_3IDEA 8 (RFC2451) - ENCR_DES_IV32 9 - RESERVED 10 - ENCR_NULL 11 (RFC2410) - ENCR_AES_CBC 12 (RFC3602) - ENCR_AES_CTR 13 (RFC3664) - RESERVED TO IANA 14-1023 - PRIVATE USE 1024-65535 - - For Transform Type 2 (Pseudo-random Function), defined Transform IDs - are: - - Name Number Defined In - ------------------------------------------------------ - RESERVED 0 - PRF_HMAC_MD5 1 (RFC2104), [MD5] - PRF_HMAC_SHA1 2 (RFC2104), [SHA] - PRF_HMAC_TIGER 3 (RFC2104) - PRF_AES128_XCBC 4 (RFC3664) - RESERVED TO IANA 5-1023 - PRIVATE USE 1024-65535 - - For Transform Type 3 (Integrity Algorithm), defined Transform IDs - - - -Kaufman, et al. Expires August 27, 2006 [Page 63] - -Internet-Draft IKEv2bis February 2006 - - - are: - - Name Number Defined In - ---------------------------------------- - NONE 0 - AUTH_HMAC_MD5_96 1 (RFC2403) - AUTH_HMAC_SHA1_96 2 (RFC2404) - AUTH_DES_MAC 3 - AUTH_KPDK_MD5 4 (RFC1826) - AUTH_AES_XCBC_96 5 (RFC3566) - RESERVED TO IANA 6-1023 - PRIVATE USE 1024-65535 - - For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs - are: - - Name Number - -------------------------------------- - NONE 0 - Defined in Appendix B 1 - 2 - RESERVED 3 - 4 - Defined in [ADDGROUP] 5 - RESERVED TO IANA 6 - 13 - Defined in [ADDGROUP] 14 - 18 - RESERVED TO IANA 19 - 1023 - PRIVATE USE 1024-65535 - - For Transform Type 5 (Extended Sequence Numbers), defined Transform - IDs are: - - Name Number - -------------------------------------------- - No Extended Sequence Numbers 0 - Extended Sequence Numbers 1 - RESERVED 2 - 65535 - -3.3.3. Valid Transform Types by Protocol - - The number and type of transforms that accompany an SA payload are - dependent on the protocol in the SA itself. An SA payload proposing - the establishment of an SA has the following mandatory and optional - transform types. A compliant implementation MUST understand all - mandatory and optional types for each protocol it supports (though it - need not accept proposals with unacceptable suites). A proposal MAY - omit the optional types if the only value for them it will accept is - NONE. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 64] - -Internet-Draft IKEv2bis February 2006 - - - Protocol Mandatory Types Optional Types - --------------------------------------------------- - IKE ENCR, PRF, INTEG, D-H - ESP ENCR, ESN INTEG, D-H - AH INTEG, ESN D-H - -3.3.4. Mandatory Transform IDs - - The specification of suites that MUST and SHOULD be supported for - interoperability has been removed from this document because they are - likely to change more rapidly than this document evolves. - - An important lesson learned from IKEv1 is that no system should only - implement the mandatory algorithms and expect them to be the best - choice for all customers. For example, at the time that this - document was written, many IKEv1 implementers were starting to - migrate to AES in Cipher Block Chaining (CBC) mode for Virtual - Private Network (VPN) applications. Many IPsec systems based on - IKEv2 will implement AES, additional Diffie-Hellman groups, and - additional hash algorithms, and some IPsec customers already require - these algorithms in addition to the ones listed above. - - It is likely that IANA will add additional transforms in the future, - and some users may want to use private suites, especially for IKE - where implementations should be capable of supporting different - parameters, up to certain size limits. In support of this goal, all - implementations of IKEv2 SHOULD include a management facility that - allows specification (by a user or system administrator) of Diffie- - Hellman (DH) parameters (the generator, modulus, and exponent lengths - and values) for new DH groups. Implementations SHOULD provide a - management interface through which these parameters and the - associated transform IDs may be entered (by a user or system - administrator), to enable negotiating such groups. - - All implementations of IKEv2 MUST include a management facility that - enables a user or system administrator to specify the suites that are - acceptable for use with IKE. Upon receipt of a payload with a set of - transform IDs, the implementation MUST compare the transmitted - transform IDs against those locally configured via the management - controls, to verify that the proposed suite is acceptable based on - local policy. The implementation MUST reject SA proposals that are - not authorized by these IKE suite controls. Note that cryptographic - suites that MUST be implemented need not be configured as acceptable - to local policy. - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 65] - -Internet-Draft IKEv2bis February 2006 - - -3.3.5. Transform Attributes - - Each transform in a Security Association payload may include - attributes that modify or complete the specification of the - transform. These attributes are type/value pairs and are defined - below. For example, if an encryption algorithm has a variable-length - key, the key length to be used may be specified as an attribute. - Attributes can have a value with a fixed two octet length or a - variable-length value. For the latter, the attribute is encoded as - type/length/value. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !A! Attribute Type ! AF=0 Attribute Length ! - !F! ! AF=1 Attribute Value ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! AF=0 Attribute Value ! - ! AF=1 Not Transmitted ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 9: Data Attributes - - o Attribute Type (2 octets) - Unique identifier for each type of - attribute (see below). The most significant bit of this field is - the Attribute Format bit (AF). It indicates whether the data - attributes follow the Type/Length/Value (TLV) format or a - shortened Type/Value (TV) format. If the AF bit is zero (0), then - the Data Attributes are of the Type/Length/Value (TLV) form. If - the AF bit is a one (1), then the Data Attributes are of the Type/ - Value form. - - o Attribute Length (2 octets) - Length in octets of the Attribute - Value. When the AF bit is a one (1), the Attribute Value is only - 2 octets and the Attribute Length field is not present. - - o Attribute Value (variable length) - Value of the Attribute - associated with the Attribute Type. If the AF bit is a zero (0), - this field has a variable length defined by the Attribute Length - field. If the AF bit is a one (1), the Attribute Value has a - length of 2 octets. - - o Key Length - When using an Encryption Algorithm that has a - variable-length key, this attribute specifies the key length in - bits (MUST use network byte order). This attribute MUST NOT be - used when the specified Encryption Algorithm uses a fixed-length - key. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 66] - -Internet-Draft IKEv2bis February 2006 - - - Note that only a single attribute type (Key Length) is defined, and - it is fixed length. The variable-length encoding specification is - included only for future extensions. {{ Clarif-7.11 removed the - sentence that listed, incorrectly, the algorithms defined in the - document that accept attributes. }} - - Attributes described as basic MUST NOT be encoded using the variable- - length encoding. Variable-length attributes MUST NOT be encoded as - basic even if their value can fit into two octets. NOTE: This is a - change from IKEv1, where increased flexibility may have simplified - the composer of messages but certainly complicated the parser. - - Attribute Type Value Attribute Format - ------------------------------------------------------------ - RESERVED 0-13 - Key Length (in bits) 14 TV - RESERVED 15-17 - RESERVED TO IANA 18-16383 - PRIVATE USE 16384-32767 - Values 0-13 and 15-17 were used in a similar context in - IKEv1, and should not be assigned except to matching values. - -3.3.6. Attribute Negotiation - - During security association negotiation initiators present offers to - responders. Responders MUST select a single complete set of - parameters from the offers (or reject all offers if none are - acceptable). If there are multiple proposals, the responder MUST - choose a single proposal number and return all of the Proposal - substructures with that Proposal number. If there are multiple - Transforms with the same type, the responder MUST choose a single - one. Any attributes of a selected transform MUST be returned - unmodified. The initiator of an exchange MUST check that the - accepted offer is consistent with one of its proposals, and if not - that response MUST be rejected. - - Negotiating Diffie-Hellman groups presents some special challenges. - SA offers include proposed attributes and a Diffie-Hellman public - number (KE) in the same message. If in the initial exchange the - initiator offers to use one of several Diffie-Hellman groups, it - SHOULD pick the one the responder is most likely to accept and - include a KE corresponding to that group. If the guess turns out to - be wrong, the responder will indicate the correct group in the - response and the initiator SHOULD pick an element of that group for - its KE value when retrying the first message. It SHOULD, however, - continue to propose its full supported set of groups in order to - prevent a man-in-the-middle downgrade attack. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 67] - -Internet-Draft IKEv2bis February 2006 - - - Implementation Note: - - Certain negotiable attributes can have ranges or could have multiple - acceptable values. These include the key length of a variable key - length symmetric cipher. To further interoperability and to support - upgrading endpoints independently, implementers of this protocol - SHOULD accept values that they deem to supply greater security. For - instance, if a peer is configured to accept a variable-length cipher - with a key length of X bits and is offered that cipher with a larger - key length, the implementation SHOULD accept the offer if it supports - use of the longer key. - - Support of this capability allows an implementation to express a - concept of "at least" a certain level of security-- "a key length of - _at least_ X bits for cipher Y". - -3.4. Key Exchange Payload - - The Key Exchange Payload, denoted KE in this memo, is used to - exchange Diffie-Hellman public numbers as part of a Diffie-Hellman - key exchange. The Key Exchange Payload consists of the IKE generic - payload header followed by the Diffie-Hellman public value itself. - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! DH Group # ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Key Exchange Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 10: Key Exchange Payload Format - - A key exchange payload is constructed by copying one's Diffie-Hellman - public value into the "Key Exchange Data" portion of the payload. - The length of the Diffie-Hellman public value MUST be equal to the - length of the prime modulus over which the exponentiation was - performed, prepending zero bits to the value if necessary. - - The DH Group # identifies the Diffie-Hellman group in which the Key - Exchange Data was computed (see Section 3.3.2). If the selected - proposal uses a different Diffie-Hellman group, the message MUST be - rejected with a Notify payload of type INVALID_KE_PAYLOAD. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 68] - -Internet-Draft IKEv2bis February 2006 - - - The payload type for the Key Exchange payload is thirty four (34). - -3.5. Identification Payloads - - The Identification Payloads, denoted IDi and IDr in this memo, allow - peers to assert an identity to one another. This identity may be - used for policy lookup, but does not necessarily have to match - anything in the CERT payload; both fields may be used by an - implementation to perform access control decisions. {{ Clarif-7.1 }} - 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. - - NOTE: In IKEv1, two ID payloads were used in each direction to hold - Traffic Selector (TS) information for data passing over the SA. In - IKEv2, this information is carried in TS payloads (see Section 3.13). - - The Identification Payload consists of the IKE generic payload header - followed by identification fields as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ID Type ! RESERVED | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Identification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 11: Identification Payload Format - - o ID Type (1 octet) - Specifies the type of Identification being - used. - - o RESERVED - MUST be sent as zero; MUST be ignored on receipt. - - o Identification Data (variable length) - Value, as indicated by the - Identification Type. The length of the Identification Data is - computed from the size in the ID payload header. - - The payload types for the Identification Payload are thirty five (35) - for IDi and thirty six (36) for IDr. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 69] - -Internet-Draft IKEv2bis February 2006 - - - The following table lists the assigned values for the Identification - Type field: - - ID Type Value - ------------------------------------------------------------------- - RESERVED 0 - - ID_IPV4_ADDR 1 - A single four (4) octet IPv4 address. - - ID_FQDN 2 - A fully-qualified domain name string. An example of a ID_FQDN - is, "example.com". The string MUST not contain any terminators - (e.g., NULL, CR, etc.). - - ID_RFC822_ADDR 3 - A fully-qualified RFC822 email address string, An example of a - ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not - contain any terminators. - - RESERVED TO IANA 4 - - ID_IPV6_ADDR 5 - A single sixteen (16) octet IPv6 address. - - RESERVED TO IANA 6 - 8 - - ID_DER_ASN1_DN 9 - The binary Distinguished Encoding Rules (DER) encoding of an - ASN.1 X.500 Distinguished Name [X.501]. - - ID_DER_ASN1_GN 10 - The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. - - ID_KEY_ID 11 - An opaque octet stream which may be used to pass vendor- - specific information necessary to do certain proprietary - types of identification. - - RESERVED TO IANA 12-200 - - PRIVATE USE 201-255 - - Two implementations will interoperate only if each can generate a - type of ID acceptable to the other. To assure maximum - interoperability, implementations MUST be configurable to send at - least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and - MUST be configurable to accept all of these types. Implementations - - - -Kaufman, et al. Expires August 27, 2006 [Page 70] - -Internet-Draft IKEv2bis February 2006 - - - SHOULD be capable of generating and accepting all of these types. - IPv6-capable implementations MUST additionally be configurable to - accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable - to send only ID_IPV6_ADDR. - - {{ Clarif-3.4 }} 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 same as the syntax of email address in [MAILFORMAT]. For those - NAIs that include the realm component, the ID_RFC822_ADDR - identification type SHOULD be used. Responder implementations should - not attempt to verify that the contents actually conform to the exact - syntax given in [MAILFORMAT], but instead should accept any - reasonable-looking NAI. For NAIs that do not include the realm - component,the ID_KEY_ID identification type SHOULD be used. - -3.6. Certificate Payload - - The Certificate Payload, denoted CERT in this memo, provides a means - to transport certificates or other authentication-related information - via IKE. Certificate payloads SHOULD be included in an exchange if - certificates are available to the sender unless the peer has - indicated an ability to retrieve this information from elsewhere - using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the - term "Certificate Payload" is somewhat misleading, because not all - authentication mechanisms use certificates and data other than - certificates may be passed in this payload. - - The Certificate Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert Encoding ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certificate Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 12: Certificate Payload Format - - o Certificate Encoding (1 octet) - This field indicates the type of - certificate or certificate-related information contained in the - Certificate Data field. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 71] - -Internet-Draft IKEv2bis February 2006 - - - Certificate Encoding Value - ------------------------------------------------- - RESERVED 0 - PKCS #7 wrapped X.509 certificate 1 - PGP Certificate 2 - DNS Signed Key 3 - X.509 Certificate - Signature 4 - Kerberos Token 6 - Certificate Revocation List (CRL) 7 - Authority Revocation List (ARL) 8 - SPKI Certificate 9 - X.509 Certificate - Attribute 10 - Raw RSA Key 11 - Hash and URL of X.509 certificate 12 - Hash and URL of X.509 bundle 13 - RESERVED to IANA 14 - 200 - PRIVATE USE 201 - 255 - - o Certificate Data (variable length) - Actual encoding of - certificate data. The type of certificate is indicated by the - Certificate Encoding field. - - The payload type for the Certificate Payload is thirty seven (37). - - Specific syntax is for some of the certificate type codes above is - not defined in this document. The types whose syntax is defined in - this document are: - - o X.509 Certificate - Signature (4) contains a DER encoded X.509 - certificate whose public key is used to validate the sender's AUTH - payload. - - o Certificate Revocation List (7) contains a DER encoded X.509 - certificate revocation list. - - o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} - Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a - DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). - - o Hash and URL encodings (12-13) allow IKE messages to remain short - by replacing long data structures with a 20 octet SHA-1 hash (see - [SHA]) of the replaced value followed by a variable-length URL - that resolves to the DER encoded data structure itself. This - improves efficiency when the endpoints have certificate data - cached and makes IKE less subject to denial of service attacks - that become easier to mount when IKE messages are large enough to - require IP fragmentation [DOSUDPPROT]. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 72] - -Internet-Draft IKEv2bis February 2006 - - - Use the following ASN.1 definition for an X.509 bundle: - - CertBundle - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) - id-mod-cert-bundle(34) } - - DEFINITIONS EXPLICIT TAGS ::= - BEGIN - - IMPORTS - Certificate, CertificateList - FROM PKIX1Explicit88 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) } ; - - CertificateOrCRL ::= CHOICE { - cert [0] Certificate, - crl [1] CertificateList } - - CertificateBundle ::= SEQUENCE OF CertificateOrCRL - - END - - Implementations MUST be capable of being configured to send and - accept up to four X.509 certificates in support of authentication, - and also MUST be capable of being configured to send and accept the - first two Hash and URL formats (with HTTP URLs). Implementations - SHOULD be capable of being configured to send and accept Raw RSA - keys. If multiple certificates are sent, the first certificate MUST - contain the public key used to sign the AUTH payload. The other - certificates may be sent in any order. - - {{ Clarif-3.6 }} Because the contents and use of some of the - certificate types are not defined, they SHOULD NOT be used. In - specific, implementations SHOULD NOT use the following types unless - they are later defined in a standards-track document: - - PKCS #7 wrapped X.509 certificate 1 - PGP Certificate 2 - DNS Signed Key 3 - Kerberos Token 6 - SPKI Certificate 9 - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 73] - -Internet-Draft IKEv2bis February 2006 - - -3.7. Certificate Request Payload - - The Certificate Request Payload, denoted CERTREQ in this memo, - provides a means to request preferred certificates via IKE and can - appear in the IKE_INIT_SA response and/or the IKE_AUTH request. - Certificate Request payloads MAY be included in an exchange when the - sender needs to get the certificate of the receiver. If multiple CAs - are trusted and the cert encoding does not allow a list, then - multiple Certificate Request payloads SHOULD be transmitted. - - The Certificate Request Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert Encoding ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certification Authority ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 13: Certificate Request Payload Format - - o Certificate Encoding (1 octet) - Contains an encoding of the type - or format of certificate requested. Values are listed in - Section 3.6. - - o Certification Authority (variable length) - Contains an encoding - of an acceptable certification authority for the type of - certificate requested. - - The payload type for the Certificate Request Payload is thirty eight - (38). - - The Certificate Encoding field has the same values as those defined - in Section 3.6. The Certification Authority field contains an - indicator of trusted authorities for this certificate type. The - Certification Authority value is a concatenated list of SHA-1 hashes - of the public keys of trusted Certification Authorities (CAs). Each - is encoded as the SHA-1 hash of the Subject Public Key Info element - (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. - The twenty-octet hashes are concatenated and included with no other - formatting. - - {{ Clarif-3.6 }} The contents of the "Certification Authority" field - are defined only for X.509 certificates, which are types 4, 10, 12, - - - -Kaufman, et al. Expires August 27, 2006 [Page 74] - -Internet-Draft IKEv2bis February 2006 - - - and 13. Other values SHOULD NOT be used until standards-track - specifications that specify their use are published. - - Note that the term "Certificate Request" is somewhat misleading, in - that values other than certificates are defined in a "Certificate" - payload and requests for those values can be present in a Certificate - Request Payload. The syntax of the Certificate Request payload in - such cases is not defined in this document. - - The Certificate Request Payload is processed by inspecting the "Cert - Encoding" field to determine whether the processor has any - certificates of this type. If so, the "Certification Authority" - field is inspected to determine if the processor has any certificates - that can be validated up to one of the specified certification - authorities. This can be a chain of certificates. - - If an end-entity certificate exists that satisfies the criteria - specified in the CERTREQ, a certificate or certificate chain SHOULD - be sent back to the certificate requestor if the recipient of the - CERTREQ: - - o is configured to use certificate authentication, - - o is allowed to send a CERT payload, - - o has matching CA trust policy governing the current negotiation, - and - - o has at least one time-wise and usage appropriate end-entity - certificate chaining to a CA provided in the CERTREQ. - - Certificate revocation checking must be considered during the - chaining process used to select a certificate. Note that even if two - peers are configured to use two different CAs, cross-certification - relationships should be supported by appropriate selection logic. - - The intent is not to prevent communication through the strict - adherence of selection of a certificate based on CERTREQ, when an - alternate certificate could be selected by the sender that would - still enable the recipient to successfully validate and trust it - through trust conveyed by cross-certification, CRLs, or other out-of- - band configured means. Thus, the processing of a CERTREQ should be - seen as a suggestion for a certificate to select, not a mandated one. - If no certificates exist, then the CERTREQ is ignored. This is not - an error condition of the protocol. There may be cases where there - is a preferred CA sent in the CERTREQ, but an alternate might be - acceptable (perhaps after prompting a human operator). - - - - -Kaufman, et al. Expires August 27, 2006 [Page 75] - -Internet-Draft IKEv2bis February 2006 - - -3.8. Authentication Payload - - The Authentication Payload, denoted AUTH in this memo, contains data - used for authentication purposes. The syntax of the Authentication - data varies according to the Auth Method as specified below. - - The Authentication Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Auth Method ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Authentication Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 14: Authentication Payload Format - - o Auth Method (1 octet) - Specifies the method of authentication - used. Values defined are: - - * RSA Digital Signature (1) - Computed as specified in - Section 2.15 using an RSA private key over a PKCS#1 padded hash - (see [RSA] and [PKCS1]). {{ Clarif-3.2 }} To promote - interoperability, implementations that support this type SHOULD - support signatures that use SHA-1 as the hash function and - SHOULD use SHA-1 as the default hash function when generating - signatures. {{ Clarif-3.3 }} A newer version of PKCS#1 (v2.1) - defines two different encoding methods (ways of "padding the - hash") for signatures. However, IKEv2 and this document point - specifically to the PKCS#1 v2.0 which has only one encoding - method for signatures (EMSA-PKCS1- v1_5). - - * Shared Key Message Integrity Code (2) - Computed as specified - in Section 2.15 using the shared key associated with the - identity in the ID payload and the negotiated prf function - - * DSS Digital Signature (3) - Computed as specified in - Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 - hash. - - * The values 0 and 4-200 are reserved to IANA. The values 201- - 255 are available for private use. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 76] - -Internet-Draft IKEv2bis February 2006 - - - o Authentication Data (variable length) - see Section 2.15. - - The payload type for the Authentication Payload is thirty nine (39). - -3.9. Nonce Payload - - The Nonce Payload, denoted Ni and Nr in this memo for the initiator's - and responder's nonce respectively, contains random data used to - guarantee liveness during an exchange and protect against replay - attacks. - - The Nonce Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Nonce Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 15: Nonce Payload Format - - o Nonce Data (variable length) - Contains the random data generated - by the transmitting entity. - - The payload type for the Nonce Payload is forty (40). - - The size of a Nonce MUST be between 16 and 256 octets inclusive. - Nonce values MUST NOT be reused. - -3.10. Notify Payload - - The Notify Payload, denoted N in this document, is used to transmit - informational data, such as error conditions and state transitions, - to an IKE peer. A Notify Payload may appear in a response message - (usually specifying why a request was rejected), in an INFORMATIONAL - Exchange (to report an error not in an IKE request), or in any other - message to indicate sender capabilities or to modify the meaning of - the request. - - The Notify Payload is defined as follows: - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 77] - -Internet-Draft IKEv2bis February 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol ID ! SPI Size ! Notify Message Type ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Notification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 16: Notify Payload Format - - o Protocol ID (1 octet) - If this notification concerns an existing - SA, this field indicates the type of that SA. For IKE_SA - notifications, this field MUST be one (1). For notifications - concerning IPsec SAs this field MUST contain either (2) to - indicate AH or (3) to indicate ESP. {{ Clarif-7.8 }} For - notifications that do not relate to an existing SA, this field - MUST be sent as zero and MUST be ignored on receipt; this is - currently only true for the INVALID_SELECTORS and REKEY_SA - notifications. All other values for this field are reserved to - IANA for future assignment. - - o SPI Size (1 octet) - Length in octets of the SPI as defined by the - IPsec protocol ID or zero if no SPI is applicable. For a - notification concerning the IKE_SA, the SPI Size MUST be zero. - - o Notify Message Type (2 octets) - Specifies the type of - notification message. - - o SPI (variable length) - Security Parameter Index. - - o Notification Data (variable length) - Informational or error data - transmitted in addition to the Notify Message Type. Values for - this field are type specific (see below). - - The payload type for the Notify Payload is forty one (41). - -3.10.1. Notify Message Types - - Notification information can be error messages specifying why an SA - could not be established. It can also be status data that a process - - - -Kaufman, et al. Expires August 27, 2006 [Page 78] - -Internet-Draft IKEv2bis February 2006 - - - managing an SA database wishes to communicate with a peer process. - The table below lists the Notification messages and their - corresponding values. The number of different error statuses was - greatly reduced from IKEv1 both for simplification and to avoid - giving configuration information to probers. - - Types in the range 0 - 16383 are intended for reporting errors. An - implementation receiving a Notify payload with one of these types - that it does not recognize in a response MUST assume that the - corresponding request has failed entirely. {{ Demoted the SHOULD }} - Unrecognized error types in a request and status types in a request - or response MUST be ignored, and they should be logged. - - Notify payloads with status types MAY be added to any message and - MUST be ignored if not recognized. They are intended to indicate - capabilities, and as part of SA negotiation are used to negotiate - non-cryptographic parameters. - - NOTIFY messages: error types Value - ------------------------------------------------------------------- - - RESERVED 0 - - UNSUPPORTED_CRITICAL_PAYLOAD 1 - Sent if the payload has the "critical" bit set and the payload - type is not recognized. Notification Data contains the one-octet - payload type. - - INVALID_IKE_SPI 4 - Indicates an IKE message was received with an unrecognized - destination SPI. This usually indicates that the recipient has - rebooted and forgotten the existence of an IKE_SA. - - INVALID_MAJOR_VERSION 5 - Indicates the recipient cannot handle the version of IKE - specified in the header. The closest version number that the - recipient can support will be in the reply header. - - INVALID_SYNTAX 7 - Indicates the IKE message that was received was invalid because - some type, length, or value was out of range or because the - request was rejected for policy reasons. To avoid a denial of - service attack using forged messages, this status may only be - returned for and in an encrypted packet if the message ID and - cryptographic checksum were valid. To avoid leaking information - to someone probing a node, this status MUST be sent in response - to any error not covered by one of the other status types. - {{ Demoted the SHOULD }} To aid debugging, more detailed error - - - -Kaufman, et al. Expires August 27, 2006 [Page 79] - -Internet-Draft IKEv2bis February 2006 - - - information should be written to a console or log. - - INVALID_MESSAGE_ID 9 - Sent when an IKE message ID outside the supported window is - received. This Notify MUST NOT be sent in a response; the invalid - request MUST NOT be acknowledged. Instead, inform the other side - by initiating an INFORMATIONAL exchange with Notification data - containing the four octet invalid message ID. Sending this - notification is optional, and notifications of this type MUST be - rate limited. - - INVALID_SPI 11 - MAY be sent in an IKE INFORMATIONAL exchange when a node receives - an ESP or AH packet with an invalid SPI. The Notification Data - contains the SPI of the invalid packet. This usually indicates a - node has rebooted and forgotten an SA. If this Informational - Message is sent outside the context of an IKE_SA, it should only - be used by the recipient as a "hint" that something might be - wrong (because it could easily be forged). - - NO_PROPOSAL_CHOSEN 14 - None of the proposed crypto suites was acceptable. - - INVALID_KE_PAYLOAD 17 - The D-H Group # field in the KE payload is not the group # - selected by the responder for this exchange. There are two octets - of data associated with this notification: the accepted D-H Group - # in big endian order. - - AUTHENTICATION_FAILED 24 - Sent in the response to an IKE_AUTH message when for some reason - the authentication failed. There is no associated data. - - SINGLE_PAIR_REQUIRED 34 - This error indicates that a CREATE_CHILD_SA request is - unacceptable because its sender is only willing to accept traffic - selectors specifying a single pair of addresses. The requestor is - expected to respond by requesting an SA for only the specific - traffic it is trying to forward. - - NO_ADDITIONAL_SAS 35 - This error indicates that a CREATE_CHILD_SA request is - unacceptable because the responder is unwilling to accept any - more CHILD_SAs on this IKE_SA. Some minimal implementations may - only accept a single CHILD_SA setup in the context of an initial - IKE exchange and reject any subsequent attempts to add more. - - INTERNAL_ADDRESS_FAILURE 36 - - - -Kaufman, et al. Expires August 27, 2006 [Page 80] - -Internet-Draft IKEv2bis February 2006 - - - Indicates an error assigning an internal address (i.e., - INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the - processing of a Configuration Payload by a responder. If this - error is generated within an IKE_AUTH exchange, no CHILD_SA will - be created. - - FAILED_CP_REQUIRED 37 - Sent by responder in the case where CP(CFG_REQUEST) was expected - but not received, and so is a conflict with locally configured - policy. There is no associated data. - - TS_UNACCEPTABLE 38 - Indicates that none of the addresses/protocols/ports in the - supplied traffic selectors is acceptable. - - INVALID_SELECTORS 39 - MAY be sent in an IKE INFORMATIONAL exchange when a node receives - an ESP or AH packet whose selectors do not match those of the SA - on which it was delivered (and that caused the packet to be - dropped). The Notification Data contains the start of the - offending packet (as in ICMP messages) and the SPI field of the - notification is set to match the SPI of the IPsec SA. - - RESERVED TO IANA 40-8191 - - PRIVATE USE 8192-16383 - - - NOTIFY messages: status types Value - ------------------------------------------------------------------- - - INITIAL_CONTACT 16384 - This notification asserts that this IKE_SA is the only IKE_SA - currently active between the authenticated identities. It MAY be - sent when an IKE_SA is established after a crash, and the - recipient MAY use this information to delete any other IKE_SAs it - has to the same authenticated identity without waiting for a - timeout. This notification MUST NOT be sent by an entity that may - be replicated (e.g., a roaming user's credentials where the user - is allowed to connect to the corporate firewall from two remote - systems at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT - notification, if sent, SHOULD be in the first IKE_AUTH request, - not as a separate exchange afterwards; however, receiving - parties need to deal with it in other requests. - - SET_WINDOW_SIZE 16385 - This notification asserts that the sending endpoint is capable of - keeping state for multiple outstanding exchanges, permitting the - - - -Kaufman, et al. Expires August 27, 2006 [Page 81] - -Internet-Draft IKEv2bis February 2006 - - - recipient to send multiple requests before getting a response to - the first. The data associated with a SET_WINDOW_SIZE - notification MUST be 4 octets long and contain the big endian - representation of the number of messages the sender promises to - keep. Window size is always one until the initial exchanges - complete. - - ADDITIONAL_TS_POSSIBLE 16386 - This notification asserts that the sending endpoint narrowed the - proposed traffic selectors but that other traffic selectors would - also have been acceptable, though only in a separate SA (see - section 2.9). There is no data associated with this Notify type. - It may be sent only as an additional payload in a message - including accepted TSs. - - IPCOMP_SUPPORTED 16387 - This notification may be included only in a message containing an - SA payload negotiating a CHILD_SA and indicates a willingness by - its sender to use IPComp on this SA. The data associated with - this notification includes a two-octet IPComp CPI followed by a - one-octet transform ID optionally followed by attributes whose - length and format are defined by that transform ID. A message - proposing an SA may contain multiple IPCOMP_SUPPORTED - notifications to indicate multiple supported algorithms. A - message accepting an SA may contain at most one. - - The transform IDs currently defined are: - - Name Number Defined In - ------------------------------------- - RESERVED 0 - IPCOMP_OUI 1 - IPCOMP_DEFLATE 2 RFC 2394 - IPCOMP_LZS 3 RFC 2395 - IPCOMP_LZJH 4 RFC 3051 - RESERVED TO IANA 5-240 - PRIVATE USE 241-255 - - NAT_DETECTION_SOURCE_IP 16388 - This notification is used by its recipient to determine whether - the source is behind a NAT box. The data associated with this - notification is a SHA-1 digest of the SPIs (in the order they - appear in the header), IP address, and port on which this packet - was sent. There MAY be multiple Notify payloads of this type in a - message if the sender does not know which of several network - attachments will be used to send the packet. The recipient of - this notification MAY compare the supplied value to a SHA-1 hash - of the SPIs, source IP address, and port, and if they don't match - - - -Kaufman, et al. Expires August 27, 2006 [Page 82] - -Internet-Draft IKEv2bis February 2006 - - - it SHOULD enable NAT traversal (see section 2.23). Alternately, - it MAY reject the connection attempt if NAT traversal is not - supported. - - NAT_DETECTION_DESTINATION_IP 16389 - This notification is used by its recipient to determine whether - it is behind a NAT box. The data associated with this - notification is a SHA-1 digest of the SPIs (in the order they - appear in the header), IP address, and port to which this packet - was sent. The recipient of this notification MAY compare the - supplied value to a hash of the SPIs, destination IP address, and - port, and if they don't match it SHOULD invoke NAT traversal (see - section 2.23). If they don't match, it means that this end is - behind a NAT and this end SHOULD start sending keepalive packets - as defined in [UDPENCAPS]. Alternately, it MAY reject the - connection attempt if NAT traversal is not supported. - - COOKIE 16390 - This notification MAY be included in an IKE_SA_INIT response. It - indicates that the request should be retried with a copy of this - notification as the first payload. This notification MUST be - included in an IKE_SA_INIT request retry if a COOKIE notification - was included in the initial response. The data associated with - this notification MUST be between 1 and 64 octets in length - (inclusive). - - USE_TRANSPORT_MODE 16391 - This notification MAY be included in a request message that also - includes an SA payload requesting a CHILD_SA. It requests that - the CHILD_SA use transport mode rather than tunnel mode for the - SA created. If the request is accepted, the response MUST also - include a notification of type USE_TRANSPORT_MODE. If the - responder declines the request, the CHILD_SA will be established - in tunnel mode. If this is unacceptable to the initiator, the - initiator MUST delete the SA. Note: Except when using this option - to negotiate transport mode, all CHILD_SAs will use tunnel mode. - - Note: The ECN decapsulation modifications specified in - [IPSECARCH] MUST be performed for every tunnel mode SA created - by IKEv2. - - HTTP_CERT_LOOKUP_SUPPORTED 16392 - This notification MAY be included in any message that can include - a CERTREQ payload and indicates that the sender is capable of - looking up certificates based on an HTTP-based URL (and hence - presumably would prefer to receive certificate specifications in - that format). - - - - -Kaufman, et al. Expires August 27, 2006 [Page 83] - -Internet-Draft IKEv2bis February 2006 - - - REKEY_SA 16393 - This notification MUST be included in a CREATE_CHILD_SA exchange - if the purpose of the exchange is to replace an existing ESP or - AH SA. The SPI field identifies the SA being rekeyed. - {{ Clarif-5.4 }} The SPI placed in the REKEY_SA - notification is the SPI the exchange initiator would expect in - inbound ESP or AH packets. There is no data. - - ESP_TFC_PADDING_NOT_SUPPORTED 16394 - This notification asserts that the sending endpoint will NOT - accept packets that contain Flow Confidentiality (TFC) padding. - {{ Clarif-4.5 }} The scope of this message 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 SHOULD 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 the other - direction. - - NON_FIRST_FRAGMENTS_ALSO 16395 - Used for fragmentation control. See [IPSECARCH] for explanation. - {{ Clarif-4.6 }} 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. If the peer rejects this proposal, the peer only - omits NON_FIRST_FRAGMENTS_ALSO notification from the response, - but does not reject the whole CHILD_SA creation. - - RESERVED TO IANA 16396-40959 - - PRIVATE USE 40960-65535 - -3.11. Delete Payload - - The Delete Payload, denoted D in this memo, contains a protocol - specific security association identifier that the sender has removed - from its security association database and is, therefore, no longer - valid. Figure 17 shows the format of the Delete Payload. It is - possible to send multiple SPIs in a Delete payload; however, each SPI - MUST be for the same protocol. Mixing of protocol identifiers MUST - NOT be performed in the Delete payload. It is permitted, however, to - include multiple Delete payloads in a single INFORMATIONAL exchange - where each Delete payload lists SPIs for a different protocol. - - Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but - no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the - IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI - - - -Kaufman, et al. Expires August 27, 2006 [Page 84] - -Internet-Draft IKEv2bis February 2006 - - - is the SPI the sending endpoint would expect in inbound ESP or AH - packets. - - The Delete Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol ID ! SPI Size ! # of SPIs ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index(es) (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 17: Delete Payload Format - - o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 - for ESP. - - o SPI Size (1 octet) - Length in octets of the SPI as defined by the - protocol ID. It MUST be zero for IKE (SPI is in message header) - or four for AH and ESP. - - o # of SPIs (2 octets) - The number of SPIs contained in the Delete - payload. The size of each SPI is defined by the SPI Size field. - - o Security Parameter Index(es) (variable length) - Identifies the - specific security association(s) to delete. The length of this - field is determined by the SPI Size and # of SPIs fields. - - The payload type for the Delete Payload is forty two (42). - -3.12. Vendor ID Payload - - The Vendor ID Payload, denoted V in this memo, contains a vendor - defined constant. The constant is used by vendors to identify and - recognize remote instances of their implementations. This mechanism - allows a vendor to experiment with new features while maintaining - backward compatibility. - - A Vendor ID payload MAY announce that the sender is capable to - accepting certain extensions to the protocol, or it MAY simply - identify the implementation as an aid in debugging. A Vendor ID - payload MUST NOT change the interpretation of any information defined - in this specification (i.e., the critical bit MUST be set to 0). - - - -Kaufman, et al. Expires August 27, 2006 [Page 85] - -Internet-Draft IKEv2bis February 2006 - - - Multiple Vendor ID payloads MAY be sent. An implementation is NOT - REQUIRED to send any Vendor ID payload at all. - - A Vendor ID payload may be sent as part of any message. Reception of - a familiar Vendor ID payload allows an implementation to make use of - Private USE numbers described throughout this memo-- private - payloads, private exchanges, private notifications, etc. Unfamiliar - Vendor IDs MUST be ignored. - - Writers of Internet-Drafts who wish to extend this protocol MUST - define a Vendor ID payload to announce the ability to implement the - extension in the Internet-Draft. It is expected that Internet-Drafts - that gain acceptance and are standardized will be given "magic - numbers" out of the Future Use range by IANA, and the requirement to - use a Vendor ID will go away. - - The Vendor ID Payload fields are defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Vendor ID (VID) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 18: Vendor ID Payload Format - - o Vendor ID (variable length) - It is the responsibility of the - person choosing the Vendor ID to assure its uniqueness in spite of - the absence of any central registry for IDs. Good practice is to - include a company name, a person name, or some such. If you want - to show off, you might include the latitude and longitude and time - where you were when you chose the ID and some random input. A - message digest of a long unique string is preferable to the long - unique string itself. - - The payload type for the Vendor ID Payload is forty three (43). - -3.13. Traffic Selector Payload - - The Traffic Selector Payload, denoted TS in this memo, allows peers - to identify packet flows for processing by IPsec security services. - The Traffic Selector Payload consists of the IKE generic payload - header followed by individual traffic selectors as follows: - - - - -Kaufman, et al. Expires August 27, 2006 [Page 86] - -Internet-Draft IKEv2bis February 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Number of TSs ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 19: Traffic Selectors Payload Format - - o Number of TSs (1 octet) - Number of traffic selectors being - provided. - - o RESERVED - This field MUST be sent as zero and MUST be ignored on - receipt. - - o Traffic Selectors (variable length) - One or more individual - traffic selectors. - - The length of the Traffic Selector payload includes the TS header and - all the traffic selectors. - - The payload type for the Traffic Selector payload is forty four (44) - for addresses at the initiator's end of the SA and forty five (45) - for addresses at the responder's end. - - {{ Clarif-4.7 }} 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). - - Thus, some types of policies may require several CHILD_SA pairs. For - - - -Kaufman, et al. Expires August 27, 2006 [Page 87] - -Internet-Draft IKEv2bis February 2006 - - - 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. - -3.13.1. Traffic Selector - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! TS Type !IP Protocol ID*| Selector Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Start Port* | End Port* | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Starting Address* ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Ending Address* ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 20: Traffic Selector - - *Note: All fields other than TS Type and Selector Length depend on - the TS Type. The fields shown are for TS Types 7 and 8, the only two - values currently defined. - - o TS Type (one octet) - Specifies the type of traffic selector. - - o IP protocol ID (1 octet) - Value specifying an associated IP - protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the - protocol ID is not relevant to this traffic selector-- the SA can - carry all protocols. - - o Selector Length - Specifies the length of this Traffic Selector - Substructure including the header. - - o Start Port (2 octets) - Value specifying the smallest port number - allowed by this Traffic Selector. For protocols for which port is - undefined, or if all ports are allowed, this field MUST be zero. - 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. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 88] - -Internet-Draft IKEv2bis February 2006 - - - o End Port (2 octets) - Value specifying the largest port number - allowed by this Traffic Selector. For protocols for which port is - undefined, or if all ports are allowed, this field MUST be 65535. - 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 purposed of filtering based on this - field. - - o Starting Address - The smallest address included in this Traffic - Selector (length determined by TS type). - - o Ending Address - The largest address included in this Traffic - Selector (length determined by TS type). - - Systems that are complying with [IPSECARCH] that wish to indicate - "ANY" ports MUST set the start port to 0 and the end port to 65535; - note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems - working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but - not "ANY" ports, MUST set the start port to 65535 and the end port to - 0. - - {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can - also refer to ICMP type and code fields. Note, however, that ICMP - packets do not have separate source and destination port fields. The - method for specifying the traffic selectors for ICMP is shown by - example in Section 4.4.1.3 of [IPSECARCH]. - - {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID - 135 to match the IPv6 mobility header [MIPV6]. This document does - not specify how to represent the "MH Type" field in traffic - selectors, although it is likely that a different document will - specify this in the future. Note that [IPSECARCH] says that the IPv6 - mobility header (MH) message 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. - - The following table lists the assigned values for the Traffic - Selector Type field and the corresponding Address Selector Data. - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 89] - -Internet-Draft IKEv2bis February 2006 - - - TS Type Value - ------------------------------------------------------------------- - RESERVED 0-6 - - TS_IPV4_ADDR_RANGE 7 - - A range of IPv4 addresses, represented by two four-octet - values. The first value is the beginning IPv4 address - (inclusive) and the second value is the ending IPv4 address - (inclusive). All addresses falling between the two specified - addresses are considered to be within the list. - - TS_IPV6_ADDR_RANGE 8 - - A range of IPv6 addresses, represented by two sixteen-octet - values. The first value is the beginning IPv6 address - (inclusive) and the second value is the ending IPv6 address - (inclusive). All addresses falling between the two specified - addresses are considered to be within the list. - - RESERVED TO IANA 9-240 - PRIVATE USE 241-255 - -3.14. Encrypted Payload - - The Encrypted Payload, denoted SK{...} or E in this memo, contains - other payloads in encrypted form. The Encrypted Payload, if present - in a message, MUST be the last payload in the message. Often, it is - the only payload in the message. - - The algorithms for encryption and integrity protection are negotiated - during IKE_SA setup, and the keys are computed as specified in - Section 2.14 and Section 2.18. - - The encryption and integrity protection algorithms are modeled after - the ESP algorithms described in RFCs 2104 [HMAC], 4303 [ESP], and - 2451 [ESPCBC]. This document completely specifies the cryptographic - processing of IKE data, but those documents should be consulted for - design rationale. We require a block cipher with a fixed block size - and an integrity check algorithm that computes a fixed-length - checksum over a variable size message. - - The payload type for an Encrypted payload is forty six (46). The - Encrypted Payload consists of the IKE generic payload header followed - by individual fields as follows: - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 90] - -Internet-Draft IKEv2bis February 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Initialization Vector ! - ! (length is block size for encryption algorithm) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Encrypted IKE Payloads ~ - + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! Padding (0-255 octets) ! - +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ - ! ! Pad Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Integrity Checksum Data ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 21: Encrypted Payload Format - - o Next Payload - The payload type of the first embedded payload. - Note that this is an exception in the standard header format, - since the Encrypted payload is the last payload in the message and - therefore the Next Payload field would normally be zero. But - because the content of this payload is embedded payloads and there - was no natural place to put the type of the first one, that type - is placed here. - - o Payload Length - Includes the lengths of the header, IV, Encrypted - IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. - - o Initialization Vector - A randomly chosen value whose length is - equal to the block length of the underlying encryption algorithm. - Recipients MUST accept any value. Senders SHOULD either pick this - value pseudo-randomly and independently for each message or use - the final ciphertext block of the previous message sent. Senders - MUST NOT use the same value for each message, use a sequence of - values with low hamming distance (e.g., a sequence number), or use - ciphertext from a received message. - - o IKE Payloads are as specified earlier in this section. This field - is encrypted with the negotiated cipher. - - o Padding MAY contain any value chosen by the sender, and MUST have - a length that makes the combination of the Payloads, the Padding, - and the Pad Length to be a multiple of the encryption block size. - This field is encrypted with the negotiated cipher. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 91] - -Internet-Draft IKEv2bis February 2006 - - - o Pad Length is the length of the Padding field. The sender SHOULD - set the Pad Length to the minimum value that makes the combination - of the Payloads, the Padding, and the Pad Length a multiple of the - block size, but the recipient MUST accept any length that results - in proper alignment. This field is encrypted with the negotiated - cipher. - - o Integrity Checksum Data is the cryptographic checksum of the - entire message starting with the Fixed IKE Header through the Pad - Length. The checksum MUST be computed over the encrypted message. - Its length is determined by the integrity algorithm negotiated. - -3.15. Configuration Payload - - The Configuration payload, denoted CP in this document, is used to - exchange configuration information between IKE peers. The exchange - is for an IRAC to request an internal IP address from an IRAS and to - exchange other information of the sort that one would acquire with - Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly - connected to a LAN. - - Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ - CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST - and CFG_SET payloads may optionally be added to any IKE request. The - IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK - or a Notify payload with an error type indicating why the request - could not be honored. An exception is that a minimal implementation - MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response - message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted - as an indication that the request was not supported. - - "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information - from its peer. If an attribute in the CFG_REQUEST Configuration - Payload is not zero-length, it is taken as a suggestion for that - attribute. The CFG_REPLY Configuration Payload MAY return that - value, or a new one. It MAY also add new attributes and not include - some requested ones. Requestors MUST ignore returned attributes that - they do not recognize. - - Some attributes MAY be multi-valued, in which case multiple attribute - values of the same type are sent and/or returned. Generally, all - values of an attribute are returned when the attribute is requested. - For some attributes (in this version of the specification only - internal addresses), multiple requests indicates a request that - multiple values be assigned. For these attributes, the number of - values returned SHOULD NOT exceed the number requested. - - If the data type requested in a CFG_REQUEST is not recognized or not - - - -Kaufman, et al. Expires August 27, 2006 [Page 92] - -Internet-Draft IKEv2bis February 2006 - - - supported, the responder MUST NOT return an error type but rather - MUST either send a CFG_REPLY that MAY be empty or a reply not - containing a CFG_REPLY payload at all. Error returns are reserved - for cases where the request is recognized but cannot be performed as - requested or the request is badly formatted. - - "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data - to its peer. In this case, the CFG_SET Configuration Payload - contains attributes the initiator wants its peer to alter. The - responder MUST return a Configuration Payload if it accepted any of - the configuration data and it MUST contain the attributes that the - responder accepted with zero-length data. Those attributes that it - did not accept MUST NOT be in the CFG_ACK Configuration Payload. If - no attributes were accepted, the responder MUST return either an - empty CFG_ACK payload or a response message without a CFG_ACK - payload. There are currently no defined uses for the CFG_SET/CFG_ACK - exchange, though they may be used in connection with extensions based - on Vendor IDs. An minimal implementation of this specification MAY - ignore CFG_SET payloads. - - {{ Demoted the SHOULD }} Extensions via the CP payload should not be - used for general purpose management. Its main intent is to provide a - bootstrap mechanism to exchange information within IPsec from IRAS to - IRAC. While it MAY be useful to use such a method to exchange - information between some Security Gateways (SGW) or small networks, - existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], - SNMP, or LDAP [LDAP] should be preferred for enterprise management as - well as subsequent information exchanges. - - The Configuration Payload is defined as follows: - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! CFG Type ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Configuration Attributes ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 22: Configuration Payload Format - - The payload type for the Configuration Payload is forty seven (47). - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 93] - -Internet-Draft IKEv2bis February 2006 - - - o CFG Type (1 octet) - The type of exchange represented by the - Configuration Attributes. - - CFG Type Value - -------------------------- - RESERVED 0 - CFG_REQUEST 1 - CFG_REPLY 2 - CFG_SET 3 - CFG_ACK 4 - RESERVED TO IANA 5-127 - PRIVATE USE 128-255 - - o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on - receipt. - - o Configuration Attributes (variable length) - These are type length - values specific to the Configuration Payload and are defined - below. There may be zero or more Configuration Attributes in this - payload. - -3.15.1. Configuration Attributes - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !R| Attribute Type ! Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Value ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 23: Configuration Attribute Format - - o Reserved (1 bit) - This bit MUST be set to zero and MUST be - ignored on receipt. - - o Attribute Type (15 bits) - A unique identifier for each of the - Configuration Attribute Types. - - o Length (2 octets) - Length in octets of Value. - - o Value (0 or more octets) - The variable-length value of this - Configuration Attribute. The following attribute types have been - defined: - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 94] - -Internet-Draft IKEv2bis February 2006 - - - Multi- - Attribute Type Value Valued Length - ------------------------------------------------------- - RESERVED 0 - INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets - INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets - INTERNAL_IP4_DNS 3 YES 0 or 4 octets - INTERNAL_IP4_NBNS 4 YES 0 or 4 octets - INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets - INTERNAL_IP4_DHCP 6 YES 0 or 4 octets - APPLICATION_VERSION 7 NO 0 or more - INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets - RESERVED 9 - INTERNAL_IP6_DNS 10 YES 0 or 16 octets - INTERNAL_IP6_NBNS 11 YES 0 or 16 octets - INTERNAL_IP6_DHCP 12 YES 0 or 16 octets - INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets - SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 - INTERNAL_IP6_SUBNET 15 YES 17 octets - RESERVED TO IANA 16-16383 - PRIVATE USE 16384-32767 - - * These attributes may be multi-valued on return only if - multiple values were requested. - - o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the - internal network, sometimes called a red node address or private - address and MAY be a private address on the Internet. {{ - Clarif-6.2}} In a request message, the address specified is a - requested address (or a zero-length address if no specific address - is requested). If a specific address is requested, it likely - indicates that a previous connection existed with this address and - the requestor would like to reuse that address. With IPv6, a - requestor MAY supply the low-order address bytes it wants to use. - Multiple internal addresses MAY be requested by requesting - multiple internal address attributes. The responder MAY only send - up to the number of addresses requested. The INTERNAL_IP6_ADDRESS - is made up of two fields: the first is a 16-octet IPv6 address, - and the second is a one-octet prefix-length as defined in - [ADDRIPV6]. - - The requested address is valid until the expiry time defined with - the INTERNAL_ADDRESS_EXPIRY attribute or there are no IKE_SAs - between the peers. - - o INTERNAL_IP4_NETMASK - 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 - - - -Kaufman, et al. Expires August 27, 2006 [Page 95] - -Internet-Draft IKEv2bis February 2006 - - - INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} - 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. 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). Non-empty values - for this attribute in a CFG_REQUEST do not make sense and thus - MUST NOT be included. - - o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS - server within the network. Multiple DNS servers MAY be requested. - The responder MAY respond with zero or more DNS server attributes. - - o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of a - NetBios Name Server (WINS) within the network. Multiple NBNS - servers MAY be requested. The responder MAY respond with zero or - more NBNS server attributes. {{ Clarif-6.6 }} NetBIOS is not - defined for IPv6; therefore, INTERNAL_IP6_NBNS SHOULD NOT be used. - - o INTERNAL_ADDRESS_EXPIRY - 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. {{ Clarif-6.7 }} 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. Further, - supporting renewals is not mandatory. Thus - INTERNAL_ADDRESS_EXPIRY attribute MUST NOT be used. - - o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send - any internal DHCP requests to the address contained within the - attribute. Multiple DHCP servers MAY be requested. The responder - MAY respond with zero or more DHCP server attributes. - - o APPLICATION_VERSION - The version or application information of - the IPsec host. This is a string of printable ASCII characters - that is NOT null terminated. - - o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- - device protects. This attribute is made up of two fields: the - first being an IP address and the second being a netmask. - Multiple sub-networks MAY be requested. The responder MAY respond - with zero or more sub-network attributes. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 96] - -Internet-Draft IKEv2bis February 2006 - - - o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute - MUST be zero-length and specifies a query to the responder to - reply back with all of the attributes that it supports. The - response contains an attribute that contains a set of attribute - identifiers each in 2 octets. The length divided by 2 (octets) - would state the number of supported attributes contained in the - response. - - o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- - device protects. This attribute is made up of two fields: the - first is a 16-octet IPv6 address, and the second is a one-octet - prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY - be requested. The responder MAY respond with zero or more sub- - network attributes. - - Note that no recommendations are made in this document as to how an - implementation actually figures out what information to send in a - reply. That is, we do not recommend any specific method of an IRAS - determining which DNS server should be returned to a requesting IRAC. - -3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET - - {{ Section added based on Clarif-6.3 }} - - INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, - ones that need one or more separate SAs, that can be reached through - the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET - attributes may also 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. Thus, - traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET - attributes should be sent through the gateway that announces the - attributes. If there are no existing IPsec SAs whose traffic - selectors cover the address in question, new SAs need to be created. - - For instance, if there are two subnets, 192.0.1.0/26 and - 192.0.2.0/24, and the client's request contains the following: - - CP(CFG_REQUEST) = - INTERNAL_IP4_ADDRESS() - TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) - TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) - - then a valid response could be the following (in which TSr and - INTERNAL_IP4_SUBNET contain the same information): - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 97] - -Internet-Draft IKEv2bis February 2006 - - - 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. - - A different 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) - - That reply 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) - - then the gateway's reply might be: - - - -Kaufman, et al. Expires August 27, 2006 [Page 98] - -Internet-Draft IKEv2bis February 2006 - - - 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) - - Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in - CFG_REQUESTs is unclear, they cannot be used reliably in - CFG_REQUESTs. - -3.15.3. Configuration payloads for IPv6 - - {{ Added this section from Clarif-6.5 }} - - The configuration payloads for IPv6 are based on the corresponding - IPv4 payloads, and do not fully follow the "normal IPv6 way of doing - things". In particular, IPv6 stateless autoconfiguration or router - advertisement messages are not used; neither is neighbor discovery. - - A client can be assigned an IPv6 address using the - INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might - 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) - - The client MAY 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 attempts to use the interface identifier with some other - prefix; if even that fails, the gateway selects 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. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 99] - -Internet-Draft IKEv2bis February 2006 - - - Although 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 sense [IPV6ADDR]. In particular, they do not - necessarily have link-local addresses, and this may complicate the - use of protocols that assume them, such as [MLDV2]. - -3.15.4. Address Assignment Failures - - {{ Added this section from Clarif-6.8 }} - - If the responder encounters an error while attempting to assign an IP - address to the initiator, it responds with an - INTERNAL_ADDRESS_FAILURE notification. However, there are some more - complex error cases. - - If the responder does not support configuration payloads at all, it - can simply ignore all configuration payloads. This type of - implementation never sends INTERNAL_ADDRESS_FAILURE notifications. - If the initiator requires the assignment of an IP address, it will - treat a response without CFG_REPLY as an error. - - The initiator may request a particular type of address (IPv4 or IPv6) - that the responder does not support, even though the responder - supports configuration payloads. In this case, the responder simply - ignores the type of address it does not support and processes the - rest of the request as usual. - - If the initiator requests multiple addresses of a type that the - responder supports, and some (but not all) of the requests fail, the - responder replies with the successful addresses only. The responder - sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. - -3.16. Extensible Authentication Protocol (EAP) Payload - - The Extensible Authentication Protocol Payload, denoted EAP in this - memo, allows IKE_SAs to be authenticated using the protocol defined - in RFC 3748 [EAP] and subsequent extensions to that protocol. The - full set of acceptable values for the payload is defined elsewhere, - but a short summary of RFC 3748 is included here to make this - document stand alone in the common cases. - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 100] - -Internet-Draft IKEv2bis February 2006 - - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload !C! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ EAP Message ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 24: EAP Payload Format - - The payload type for an EAP Payload is forty eight (48). - - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Code ! Identifier ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Type ! Type_Data... - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - Figure 25: EAP Message Format - - o Code (1 octet) indicates whether this message is a Request (1), - Response (2), Success (3), or Failure (4). - - o Identifier (1 octet) is used in PPP to distinguish replayed - messages from repeated ones. Since in IKE, EAP runs over a - reliable protocol, it serves no function here. In a response - message, this octet MUST be set to match the identifier in the - corresponding request. In other messages, this field MAY be set - to any value. - - o Length (2 octets) is the length of the EAP message and MUST be - four less than the Payload Length of the encapsulating payload. - - o Type (1 octet) is present only if the Code field is Request (1) or - Response (2). For other codes, the EAP message length MUST be - four octets and the Type and Type_Data fields MUST NOT be present. - In a Request (1) message, Type indicates the data being requested. - In a Response (2) message, Type MUST either be Nak or match the - type of the data requested. The following types are defined in - RFC 3748: - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 101] - -Internet-Draft IKEv2bis February 2006 - - - 1 Identity - 2 Notification - 3 Nak (Response Only) - 4 MD5-Challenge - 5 One-Time Password (OTP) - 6 Generic Token Card - - o Type_Data (Variable Length) varies with the Type of Request and - the associated Response. For the documentation of the EAP - methods, see [EAP]. - - {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an - indication of initiator identity in message 3 of the protocol, the - responder should not send EAP Identity requests. The initiator may, - however, respond to such requests if it receives them. - - -4. Conformance Requirements - - In order to assure that all implementations of IKEv2 can - interoperate, there are "MUST support" requirements in addition to - those listed elsewhere. Of course, IKEv2 is a security protocol, and - one of its major functions is to allow only authorized parties to - successfully complete establishment of SAs. So a particular - implementation may be configured with any of a number of restrictions - concerning algorithms and trusted authorities that will prevent - universal interoperability. - - IKEv2 is designed to permit minimal implementations that can - interoperate with all compliant implementations. There are a series - of optional features that can easily be ignored by a particular - implementation if it does not support that feature. Those features - include: - - o Ability to negotiate SAs through a NAT and tunnel the resulting - ESP SA over UDP. - - o Ability to request (and respond to a request for) a temporary IP - address on the remote end of a tunnel. - - o Ability to support various types of legacy authentication. - - o Ability to support window sizes greater than one. - - o Ability to establish multiple ESP and/or AH SAs within a single - IKE_SA. - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 102] - -Internet-Draft IKEv2bis February 2006 - - - o Ability to rekey SAs. - - To assure interoperability, all implementations MUST be capable of - parsing all payload types (if only to skip over them) and to ignore - payload types that it does not support unless the critical bit is set - in the payload header. If the critical bit is set in an unsupported - payload header, all implementations MUST reject the messages - containing those payloads. - - Every implementation MUST be capable of doing four-message - IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, - one for ESP and/or AH). Implementations MAY be initiate-only or - respond-only if appropriate for their platform. Every implementation - MUST be capable of responding to an INFORMATIONAL exchange, but a - minimal implementation MAY respond to any INFORMATIONAL message with - an empty INFORMATIONAL reply (note that within the context of an - IKE_SA, an "empty" message consists of an IKE header followed by an - Encrypted payload with no payloads contained in it). A minimal - implementation MAY support the CREATE_CHILD_SA exchange only in so - far as to recognize requests and reject them with a Notify payload of - type NO_ADDITIONAL_SAS. A minimal implementation need not be able to - initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA - expires (based on locally configured values of either lifetime or - octets passed), and implementation MAY either try to renew it with a - CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and - create a new one. If the responder rejects the CREATE_CHILD_SA - request with a NO_ADDITIONAL_SAS notification, the implementation - MUST be capable of instead deleting the old SA and creating a new - one. - - Implementations are not required to support requesting temporary IP - addresses or responding to such requests. If an implementation does - support issuing such requests, it MUST include a CP payload in - message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or - INTERNAL_IP6_ADDRESS. All other fields are optional. If an - implementation supports responding to such requests, it MUST parse - the CP payload of type CFG_REQUEST in message 3 and recognize a field - of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports - leasing an address of the appropriate type, it MUST return a CP - payload of type CFG_REPLY containing an address of the requested - type. {{ Demoted the SHOULD }} The responder may include any other - related attributes. - - A minimal IPv4 responder implementation will ignore the contents of - the CP payload except to determine that it includes an - INTERNAL_IP4_ADDRESS attribute and will respond with the address and - other related attributes regardless of whether the initiator - requested them. - - - -Kaufman, et al. Expires August 27, 2006 [Page 103] - -Internet-Draft IKEv2bis February 2006 - - - A minimal IPv4 initiator will generate a CP payload containing only - an INTERNAL_IP4_ADDRESS attribute and will parse the response - ignoring attributes it does not know how to use. {{ Clarif-6.7 - removes the sentence about processing INTERNAL_ADDRESS_EXPIRY. }} - Minimal initiators need not be able to request lease renewals and - minimal responders need not respond to them. - - For an implementation to be called conforming to this specification, - it MUST be possible to configure it to accept the following: - - o PKIX Certificates containing and signed by RSA keys of size 1024 - or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, - ID_RFC822_ADDR, or ID_DER_ASN1_DN. - - o Shared key authentication where the ID passes is any of ID_KEY_ID, - ID_FQDN, or ID_RFC822_ADDR. - - o Authentication where the responder is authenticated using PKIX - Certificates and the initiator is authenticated using shared key - authentication. - - -5. Security Considerations - - While this protocol is designed to minimize disclosure of - configuration information to unauthenticated peers, some such - disclosure is unavoidable. One peer or the other must identify - itself first and prove its identity first. To avoid probing, the - initiator of an exchange is required to identify itself first, and - usually is required to authenticate itself first. The initiator can, - however, learn that the responder supports IKE and what cryptographic - protocols it supports. The responder (or someone impersonating the - responder) can probe the initiator not only for its identity, but - using CERTREQ payloads may be able to determine what certificates the - initiator is willing to use. - - Use of EAP authentication changes the probing possibilities somewhat. - When EAP authentication is used, the responder proves its identity - before the initiator does, so an initiator that knew the name of a - valid initiator could probe the responder for both its name and - certificates. - - Repeated rekeying using CREATE_CHILD_SA without additional Diffie- - Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a - single key or overrun of either endpoint. Implementers should take - note of this fact and set a limit on CREATE_CHILD_SA exchanges - between exponentiations. This memo does not prescribe such a limit. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 104] - -Internet-Draft IKEv2bis February 2006 - - - The strength of a key derived from a Diffie-Hellman exchange using - any of the groups defined here depends on the inherent strength of - the group, the size of the exponent used, and the entropy provided by - the random number generator used. Due to these inputs, it is - difficult to determine the strength of a key for any of the defined - groups. Diffie-Hellman group number two, when used with a strong - random number generator and an exponent no less than 200 bits, is - common for use with 3DES. Group five provides greater security than - group two. Group one is for historic purposes only and does not - provide sufficient strength except for use with DES, which is also - for historic use only. Implementations should make note of these - estimates when establishing policy and negotiating security - parameters. - - Note that these limitations are on the Diffie-Hellman groups - themselves. There is nothing in IKE that prohibits using stronger - groups nor is there anything that will dilute the strength obtained - from stronger groups (limited by the strength of the other algorithms - negotiated including the prf function). In fact, the extensible - framework of IKE encourages the definition of more groups; use of - elliptical curve groups may greatly increase strength using much - smaller numbers. - - It is assumed that all Diffie-Hellman exponents are erased from - memory after use. In particular, these exponents MUST NOT be derived - from long-lived secrets like the seed to a pseudo-random generator - that is not erased after use. - - The strength of all keys is limited by the size of the output of the - negotiated prf function. For this reason, a prf function whose - output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with - this protocol. - - The security of this protocol is critically dependent on the - randomness of the randomly chosen parameters. These should be - generated by a strong random or properly seeded pseudo-random source - (see [RANDOMNESS]). Implementers should take care to ensure that use - of random numbers for both keys and nonces is engineered in a fashion - that does not undermine the security of the keys. - - For information on the rationale of many of the cryptographic design - choices in this protocol, see [SIGMA] and [SKEME]. Though the - security of negotiated CHILD_SAs does not depend on the strength of - the encryption and integrity protection negotiated in the IKE_SA, - implementations MUST NOT negotiate NONE as the IKE integrity - protection algorithm or ENCR_NULL as the IKE encryption algorithm. - - When using pre-shared keys, a critical consideration is how to assure - - - -Kaufman, et al. Expires August 27, 2006 [Page 105] - -Internet-Draft IKEv2bis February 2006 - - - the randomness of these secrets. The strongest practice is to ensure - that any pre-shared key contain as much randomness as the strongest - key being negotiated. Deriving a shared secret from a password, - name, or other low-entropy source is not secure. These sources are - subject to dictionary and social engineering attacks, among others. - - The NAT_DETECTION_*_IP notifications contain a hash of the addresses - and ports in an attempt to hide internal IP addresses behind a NAT. - Since the IPv4 address space is only 32 bits, and it is usually very - sparse, it would be possible for an attacker to find out the internal - address used behind the NAT box by trying all possible IP addresses - and trying to find the matching hash. The port numbers are normally - fixed to 500, and the SPIs can be extracted from the packet. This - reduces the number of hash calculations to 2^32. With an educated - guess of the use of private address space, the number of hash - calculations is much smaller. Designers should therefore not assume - that use of IKE will not leak internal address information. - - When using an EAP authentication method that does not generate a - shared key for protecting a subsequent AUTH payload, certain man-in- - the-middle and server impersonation attacks are possible [EAPMITM]. - These vulnerabilities occur when EAP is also used in protocols that - are not protected with a secure tunnel. Since EAP is a general- - purpose authentication protocol, which is often used to provide - single-signon facilities, a deployed IPsec solution that relies on an - EAP authentication method that does not generate a shared key (also - known as a non-key-generating EAP method) can become compromised due - to the deployment of an entirely unrelated application that also - happens to use the same non-key-generating EAP method, but in an - unprotected fashion. Note that this vulnerability is not limited to - just EAP, but can occur in other scenarios where an authentication - infrastructure is reused. For example, if the EAP mechanism used by - IKEv2 utilizes a token authenticator, a man-in-the-middle attacker - could impersonate the web server, intercept the token authentication - exchange, and use it to initiate an IKEv2 connection. For this - reason, use of non-key-generating EAP methods SHOULD be avoided where - possible. Where they are used, it is extremely important that all - usages of these EAP methods SHOULD utilize a protected tunnel, where - the initiator validates the responder's certificate before initiating - the EAP exchange. {{ Demoted the SHOULD }} Implementers should - describe the vulnerabilities of using non-key-generating EAP methods - in the documentation of their implementations so that the - administrators deploying IPsec solutions are aware of these dangers. - - An implementation using EAP MUST also use a public-key-based - authentication of the server to the client before the EAP exchange - begins, even if the EAP method offers mutual authentication. This - avoids having additional IKEv2 protocol variations and protects the - - - -Kaufman, et al. Expires August 27, 2006 [Page 106] - -Internet-Draft IKEv2bis February 2006 - - - EAP data from active attackers. - - If the messages of IKEv2 are long enough that IP-level fragmentation - is necessary, it is possible that attackers could prevent the - exchange from completing by exhausting the reassembly buffers. The - chances of this can be minimized by using the Hash and URL encodings - instead of sending certificates (see Section 3.6). Additional - mitigations are discussed in [DOSUDPPROT]. - -5.1. Traffic selector authorization - - {{ Added this section from Clarif-4.13 }} - - 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 [IPSECARCH] 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 - 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 [IPSECARCH], "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. - - - -Kaufman, et al. Expires August 27, 2006 [Page 107] - -Internet-Draft IKEv2bis February 2006 - - - 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 [H2HIPSEC] for an extensive - discussion about this issue, and the limitations of host-to-host - IPsec in general. - - -6. IANA Considerations - - {{ This section was changed to not re-define any new IANA registries. - }} - - [IKEV2] defined many field types and values. IANA has already - registered those types and values, so the are not listed here again. - No new types or values are registered in this document. - - -7. Acknowledgements - - The acknowledgements from the IKEv2 document were: - - This document is a collaborative effort of the entire IPsec WG. If - there were no limit to the number of authors that could appear on an - RFC, the following, in alphabetical order, would have been listed: - Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt - Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John - Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero - Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer - Reingold, and Michael Richardson. Many other people contributed to - the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, - each of which has its own list of authors. Hugh Daniel suggested the - feature of having the initiator, in message 3, specify a name for the - responder, and gave the feature the cute name "You Tarzan, Me Jane". - David Faucher and Valery Smyzlov helped refine the design of the - traffic selector negotiation. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 108] - -Internet-Draft IKEv2bis February 2006 - - - This paragraph lists references that appear only in figures. The - section is only here to keep the 'xml2rfc' program happy, and will be - removed when the document is published. Feel free to ignore it. - [DES] [IDEA] [MD5] [X.501] [X.509] - - -8. References - -8.1. Normative References - - [ADDGROUP] - Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) - Diffie-Hellman groups for Internet Key Exchange (IKE)", - RFC 3526, May 2003. - - [ADDRIPV6] - Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - [Clarif] "IKEv2 Clarifications and Implementation Guidelines", - draft-eronen-ipsec-ikev2-clarifications (work in - progress). - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. - Levkowetz, "Extensible Authentication Protocol (EAP)", - RFC 3748, June 2004. - - [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", - RFC 3168, September 2001. - - [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [IANACONS] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434. - - [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - RFC 4306, December 2005. - - [IPSECARCH] - Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - - [MUSTSHOULD] - Bradner, S., "Key Words for use in RFCs to indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - -Kaufman, et al. Expires August 27, 2006 [Page 109] - -Internet-Draft IKEv2bis February 2006 - - - [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [UDPENCAPS] - Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. - Stenberg, "UDP Encapsulation of IPsec ESP Packets", - RFC 3948, January 2005. - -8.2. Informative References - - [AH] Kent, S., "IP Authentication Header", RFC 4302, - December 2005. - - [ARCHGUIDEPHIL] - Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3439, December 2002. - - [ARCHPRINC] - Carpenter, B., "Architectural Principles of the Internet", - RFC 1958, June 1996. - - [DES] American National Standards Institute, "American National - Standard for Information Systems-Data Link Encryption", - ANSI X3.106, 1983. - - [DH] Diffie, W. and M. Hellman, "New Directions in - Cryptography", IEEE Transactions on Information Theory, - V.IT-22 n. 6, June 1977. - - [DHCP] Droms, R., "Dynamic Host Configuration Protocol", - RFC 2131, March 1997. - - [DIFFSERVARCH] - Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., - and W. Weiss, "An Architecture for Differentiated - Services", RFC 2475. - - [DIFFSERVFIELD] - Nichols, K., Blake, S., Baker, F., and D. Black, - "Definition of the Differentiated Services Field (DS - Field) in the IPv4 and IPv6 Headers", RFC 2474, - December 1998. - - [DIFFTUNNEL] - Black, D., "Differentiated Services and Tunnels", - RFC 2983, October 2000. - - - -Kaufman, et al. Expires August 27, 2006 [Page 110] - -Internet-Draft IKEv2bis February 2006 - - - [DOI] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [DOSUDPPROT] - C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection - for UDP-based protocols", ACM Conference on Computer and - Communications Security , October 2003. - - [DSS] National Institute of Standards and Technology, U.S. - Department of Commerce, "Digital Signature Standard", - FIPS 186, May 1994. - - [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in - Tunneled Authentication Protocols", November 2002, - . - - [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. - - [EXCHANGEANALYSIS] - R. Perlman and C. Kaufman, "Analysis of the IPsec key - exchange Standard", WET-ICE Security Conference, MIT , - 2001, - . - - [H2HIPSEC] - Aura, T., Roe, M., and A. Mohammed, "Experiences with - Host-to-Host IPsec", 13th International Workshop on - Security Protocols, Cambridge, UK, April 2005. - - [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH - Series in Information Processing, v. 1, Konstanz: Hartung- - Gorre Verlag, 1992. - - [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP - Payload Compression Protocol (IPComp)", RFC 3173, - September 2001. - - [IPSECARCH-OLD] - Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - - -Kaufman, et al. Expires August 27, 2006 [Page 111] - -Internet-Draft IKEv2bis February 2006 - - - [IPV6ADDR] - Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet - Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [MAILFORMAT] - Resnick, P., "Internet Message Format", RFC 2822, - April 2001. - - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support - in IPv6", RFC 3775, June 2004. - - [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery - Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. - - [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", - RFC 2486, January 1999. - - [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation - (NAT) Compatibility Requirements", RFC 3715, March 2004. - - [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", - RFC 2412, November 1998. - - [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key - Management API, Version 2", RFC 2367, July 1998. - - [PHOTURIS] - Karn, P. and W. Simpson, "Photuris: Session-Key Management - Protocol", RFC 2522, March 1999. - - [PKCS1] B. Kaliski and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2", September 1998. - - [PRFAES128CBC] - Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the - Internet Key Exchange Protocol (IKE)", RFC 3664, - January 2004. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 112] - -Internet-Draft IKEv2bis February 2006 - - - [PRFAES128CBC-bis] - Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the - Internet Key Exchange Protocol (IKE)", - draft-hoffman-rfc3664bis (work in progress), October 2005. - - [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, - "Remote Authentication Dial In User Service (RADIUS)", - RFC 2138, April 1997. - - [RANDOMNESS] - Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - - [REAUTH] Nir, Y., ""Repeated Authentication in IKEv2", - draft-nir-ikev2-auth-lt (work in progress), May 2005. - - [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for - Obtaining Digital Signatures and Public-Key - Cryptosystems", February 1978. - - [SHA] National Institute of Standards and Technology, U.S. - Department of Commerce, "Secure Hash Standard", - FIPS 180-1, May 1994. - - [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to - Authenticated Diffie-Hellman and its Use in the IKE - Protocols", Advances in Cryptography - CRYPTO 2003 - Proceedings LNCS 2729, 2003, . - - [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange - Mechanism for Internet", IEEE Proceedings of the 1996 - Symposium on Network and Distributed Systems Security , - 1996. - - [TRANSPARENCY] - Carpenter, B., "Internet Transparency", RFC 2775, - February 2000. - - [X.501] ITU-T, "Recommendation X.501: Information Technology - - Open Systems Interconnection - The Directory: Models", - 1993. - - [X.509] ITU-T, "Recommendation X.509 (1997 E): Information - Technology - Open Systems Interconnection - The Directory: - Authentication Framework", 1997. - - - - -Kaufman, et al. Expires August 27, 2006 [Page 113] - -Internet-Draft IKEv2bis February 2006 - - -Appendix A. Summary of changes from IKEv1 - - The goals of this revision to IKE are: - - 1. To define the entire IKE protocol in a single document, - replacing RFCs 2407, 2408, and 2409 and incorporating subsequent - changes to support NAT Traversal, Extensible Authentication, and - Remote Address acquisition; - - 2. To simplify IKE by replacing the eight different initial - exchanges with a single four-message exchange (with changes in - authentication mechanisms affecting only a single AUTH payload - rather than restructuring the entire exchange) see - [EXCHANGEANALYSIS]; - - 3. To remove the Domain of Interpretation (DOI), Situation (SIT), - and Labeled Domain Identifier fields, and the Commit and - Authentication only bits; - - 4. To decrease IKE's latency in the common case by making the - initial exchange be 2 round trips (4 messages), and allowing the - ability to piggyback setup of a CHILD_SA on that exchange; - - 5. To replace the cryptographic syntax for protecting the IKE - messages themselves with one based closely on ESP to simplify - implementation and security analysis; - - 6. To reduce the number of possible error states by making the - protocol reliable (all messages are acknowledged) and sequenced. - This allows shortening CREATE_CHILD_SA exchanges from 3 messages - to 2; - - 7. To increase robustness by allowing the responder to not do - significant processing until it receives a message proving that - the initiator can receive messages at its claimed IP address, - and not commit any state to an exchange until the initiator can - be cryptographically authenticated; - - 8. To fix cryptographic weaknesses such as the problem with - symmetries in hashes used for authentication documented by Tero - Kivinen; - - 9. To specify Traffic Selectors in their own payloads type rather - than overloading ID payloads, and making more flexible the - Traffic Selectors that may be specified; - - 10. To specify required behavior under certain error conditions or - when data that is not understood is received in order to make it - - - -Kaufman, et al. Expires August 27, 2006 [Page 114] - -Internet-Draft IKEv2bis February 2006 - - - easier to make future revisions in a way that does not break - backwards compatibility; - - 11. To simplify and clarify how shared state is maintained in the - presence of network failures and Denial of Service attacks; and - - 12. To maintain existing syntax and magic numbers to the extent - possible to make it likely that implementations of IKEv1 can be - enhanced to support IKEv2 with minimum effort. - - -Appendix B. Diffie-Hellman Groups - - There are two Diffie-Hellman groups defined here for use in IKE. - These groups were generated by Richard Schroeppel at the University - of Arizona. Properties of these primes are described in [OAKLEY]. - - The strength supplied by group one may not be sufficient for the - mandatory-to-implement encryption algorithm and is here for historic - reasons. - - Additional Diffie-Hellman groups have been defined in [ADDGROUP]. - -B.1. Group 1 - 768 Bit MODP - - This group is assigned id 1 (one). - - The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } - Its hexadecimal value is: - - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - - The generator is 2. - -B.2. Group 2 - 1024 Bit MODP - - This group is assigned id 2 (two). - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 115] - -Internet-Draft IKEv2bis February 2006 - - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its hexadecimal value is: - - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED - EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 - FFFFFFFF FFFFFFFF - - The generator is 2. - - -Appendix C. Exchanges and Payloads - - {{ Clarif-AppA }} - - 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, the - other text is considered correct. - - Vendor-ID (V) payloads may be included in any place in any message. - This sequence here shows what are the most logical places for them. - -C.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+] - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 116] - -Internet-Draft IKEv2bis February 2006 - - -C.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+] - - - - - - - - - - - - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 117] - -Internet-Draft IKEv2bis February 2006 - - -C.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+] - - - - - - - - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 118] - -Internet-Draft IKEv2bis February 2006 - - -C.4. CREATE_CHILD_SA Exchange for Creating or 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)] - -C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA - - request --> SA, Ni, [KEi] - - response <-- SA, Nr, [KEr] - -C.6. INFORMATIONAL Exchange - - request --> [N+], - [D+], - [CP(CFG_REQUEST)] - - response <-- [N+], - [D+], - [CP(CFG_REPLY)] - - -Appendix D. Changes Between Internet Draft Versions - - This section will be removed before publication as an RFC. - -D.1. Changes from IKEv2 to draft -00 - - There were a zillion additions from the Clarifications document. - These are noted with "{{ Clarif-nn }}". The numbers used in the text - of this version are based on - draft-eronen-ipsec-ikev2-clarifications-08.txt, which has different - numbers than earlier versions of that draft. - - Cleaned up many of the figures. Made the table headings consistent. - Made some tables easier to read by removing blank spaces. Removed - the "reserved to IANA" and "private use" text wording and moved it - - - -Kaufman, et al. Expires August 27, 2006 [Page 119] - -Internet-Draft IKEv2bis February 2006 - - - into the tables. - - Changed many SHOULD requirements to better match RFC 2119. These are - also marked with comments such as "{{ Demoted the SHOULD }}". - - In Section 2.16, changed the MUST requirement of authenticating the - responder from "public key signature based" to "strong" because that - is what most current IKEv2 implementations do, and it better matches - the actual security requirement. - - -Authors' Addresses - - Charlie Kaufman - Microsoft - 1 Microsoft Way - Redmond, WA 98052 - US - - Phone: 1-425-707-3335 - Email: charliek@microsoft.com - - - Paul Hoffman - VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 - US - - Phone: 1-831-426-9827 - Email: paul.hoffman@vpnc.org - - - Pasi Eronen - Nokia Research Center - P.O. Box 407 - FIN-00045 Nokia Group - Finland - - Email: pasi.eronen@nokia.com - - -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 - - - -Kaufman, et al. Expires August 27, 2006 [Page 120] - -Internet-Draft IKEv2bis February 2006 - - - 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 currently provided by the - Internet Society. - - - - - - - - - - - -Kaufman, et al. Expires August 27, 2006 [Page 121] - diff --git a/doc/standards/draft-hoffman-ikev2bis-03.txt b/doc/standards/draft-hoffman-ikev2bis-03.txt new file mode 100644 index 000000000..4cf8bf1b6 --- /dev/null +++ b/doc/standards/draft-hoffman-ikev2bis-03.txt @@ -0,0 +1,7224 @@ + + + +Network Working Group C. Kaufman +Internet-Draft Microsoft +Obsoletes: 4306, 4718 P. Hoffman +(if approved) VPN Consortium +Intended status: Standards Track P. Eronen +Expires: August 28, 2008 Nokia + February 25, 2008 + + + Internet Key Exchange Protocol: IKEv2 + draft-hoffman-ikev2bis-03 + +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 August 28, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + This document describes version 2 of the Internet Key Exchange (IKE) + protocol. It is a restatement of RFC 4306, and includes all of the + clarifications from RFC 4718. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 1] + +Internet-Draft IKEv2bis February 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 + 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 6 + 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 + 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 + 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 + 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 + 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 11 + 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA + Exchange . . . . . . . . . . . . . . . . . . . . . . 13 + 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 + 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA + Exchange . . . . . . . . . . . . . . . . . . . . . . 14 + 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 + 1.5. Informational Messages outside of an IKE_SA . . . . . . . 17 + 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 + 1.7. Differences Between RFC 4306 and This Document . . . . . 18 + 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19 + 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20 + 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21 + 2.3. Window Size for Overlapping Requests . . . . . . . . . . 21 + 2.4. State Synchronization and Connection Timeouts . . . . . . 23 + 2.5. Version Numbers and Forward Compatibility . . . . . . . . 25 + 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29 + 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30 + 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31 + 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33 + 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35 + 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36 + 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38 + 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39 + 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39 + 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40 + 2.13. Generating Keying Material . . . . . . . . . . . . . . . 40 + 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42 + 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42 + 2.16. Extensible Authentication Protocol Methods . . . . . . . 44 + 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46 + 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47 + 2.19. Requesting an Internal Address on a Remote Network . . . 48 + 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49 + 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51 + 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 + 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52 + 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 54 + + + +Kaufman, et al. Expires August 28, 2008 [Page 2] + +Internet-Draft IKEv2bis February 2008 + + + 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57 + 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57 + 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 58 + 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 61 + 3.3. Security Association Payload . . . . . . . . . . . . . . 63 + 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 65 + 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66 + 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69 + 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 70 + 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 71 + 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 73 + 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73 + 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74 + 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77 + 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79 + 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81 + 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82 + 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83 + 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84 + 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87 + 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89 + 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90 + 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91 + 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93 + 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95 + 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96 + 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99 + 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101 + 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101 + 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102 + 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 106 + 5.1. Traffic selector authorization . . . . . . . . . . . . . 108 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 110 + 8.2. Informative References . . . . . . . . . . . . . . . . . 112 + Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115 + Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117 + B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117 + B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117 + Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118 + C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118 + C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119 + C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120 + C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying + CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121 + + + +Kaufman, et al. Expires August 28, 2008 [Page 3] + +Internet-Draft IKEv2bis February 2008 + + + C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121 + C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121 + Appendix D. Changes Between Internet Draft Versions . . . . . . 121 + D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121 + D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122 + D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124 + D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124 + D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127 + Intellectual Property and Copyright Statements . . . . . . . . . 129 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 4] + +Internet-Draft IKEv2bis February 2008 + + +1. Introduction + + {{ An introduction to the differences between RFC 4306 [IKEV2] and + this document is given at the end of Section 1. It is put there + (instead of here) to preserve the section numbering of RFC 4306. }} + + IP Security (IPsec) provides confidentiality, data integrity, access + control, and data source authentication to IP datagrams. These + services are provided by maintaining shared state between the source + and the sink of an IP datagram. This state defines, among other + things, the specific services provided to the datagram, which + cryptographic algorithms will be used to provide the services, and + the keys used as input to the cryptographic algorithms. + + Establishing this shared state in a manual fashion does not scale + well. Therefore, a protocol to establish this state dynamically is + needed. This memo describes such a protocol -- the Internet Key + Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], + 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2] and + clarified in [Clarif]. This single document is intended to replace + all of those RFCs. + + IKE performs mutual authentication between two parties and + establishes an IKE security association (SA) that includes shared + secret information that can be used to efficiently establish SAs for + Encapsulating Security Payload (ESP) [ESP] and/or Authentication + Header (AH) [AH] and a set of cryptographic algorithms to be used by + the SAs to protect the traffic that they carry. In this document, + the term "suite" or "cryptographic suite" refers to a complete set of + algorithms used to protect an SA. An initiator proposes one or more + suites by listing supported algorithms that can be combined into + suites in a mix-and-match fashion. IKE can also negotiate use of IP + Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. + We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get + set up through that IKE_SA we call "CHILD_SAs". + + All IKE communications consist of pairs of messages: a request and a + response. The pair is called an "exchange". We call the first + messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges + and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL + exchanges. In the common case, there is a single IKE_SA_INIT + exchange and a single IKE_AUTH exchange (a total of four messages) to + establish the IKE_SA and the first CHILD_SA. In exceptional cases, + there may be more than one of each of these exchanges. In all cases, + all IKE_SA_INIT exchanges MUST complete before any other exchange + type, then all IKE_AUTH exchanges MUST complete, and following that + any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur + in any order. In some scenarios, only a single CHILD_SA is needed + + + +Kaufman, et al. Expires August 28, 2008 [Page 5] + +Internet-Draft IKEv2bis February 2008 + + + between the IPsec endpoints, and therefore there would be no + additional exchanges. Subsequent exchanges MAY be used to establish + additional CHILD_SAs between the same authenticated pair of endpoints + and to perform housekeeping functions. + + IKE message flow always consists of a request followed by a response. + It is the responsibility of the requester to ensure reliability. If + the response is not received within a timeout interval, the requester + needs to retransmit the request (or abandon the connection). + + The first request/response of an IKE session (IKE_SA_INIT) negotiates + security parameters for the IKE_SA, sends nonces, and sends Diffie- + Hellman values. + + The second request/response (IKE_AUTH) transmits identities, proves + knowledge of the secrets corresponding to the two identities, and + sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. + + The types of subsequent exchanges are CREATE_CHILD_SA (which creates + a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error + conditions, or does other housekeeping). Every request requires a + response. An INFORMATIONAL request with no payloads (other than the + empty Encrypted payload required by the syntax) is commonly used as a + check for liveness. These subsequent exchanges cannot be used until + the initial exchanges have completed. + + In the description that follows, we assume that no errors occur. + Modifications to the flow should errors occur are described in + Section 2.21. + +1.1. Usage Scenarios + + IKE is expected to be used to negotiate ESP and/or AH SAs in a number + of different scenarios, each with its own special requirements. + +1.1.1. Security Gateway to Security Gateway Tunnel + + +-+-+-+-+-+ +-+-+-+-+-+ + | | IPsec | | + Protected |Tunnel | tunnel |Tunnel | Protected + Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet + | | | | + +-+-+-+-+-+ +-+-+-+-+-+ + + Figure 1: Security Gateway to Security Gateway Tunnel + + In this scenario, neither endpoint of the IP connection implements + IPsec, but network nodes between them protect traffic for part of the + + + +Kaufman, et al. Expires August 28, 2008 [Page 6] + +Internet-Draft IKEv2bis February 2008 + + + way. Protection is transparent to the endpoints, and depends on + ordinary routing to send packets through the tunnel endpoints for + processing. Each endpoint would announce the set of addresses + "behind" it, and packets would be sent in tunnel mode where the inner + IP header would contain the IP addresses of the actual endpoints. + +1.1.2. Endpoint-to-Endpoint Transport + + +-+-+-+-+-+ +-+-+-+-+-+ + | | IPsec transport | | + |Protected| or tunnel mode SA |Protected| + |Endpoint |<---------------------------------------->|Endpoint | + | | | | + +-+-+-+-+-+ +-+-+-+-+-+ + + Figure 2: Endpoint to Endpoint + + In this scenario, both endpoints of the IP connection implement + IPsec, as required of hosts in [IPSECARCH]. Transport mode will + commonly be used with no inner IP header. If there is an inner IP + header, the inner addresses will be the same as the outer addresses. + A single pair of addresses will be negotiated for packets to be + protected by this SA. These endpoints MAY implement application + layer access controls based on the IPsec authenticated identities of + the participants. This scenario enables the end-to-end security that + has been a guiding principle for the Internet since [ARCHPRINC], + [TRANSPARENCY], and a method of limiting the inherent problems with + complexity in networks noted by [ARCHGUIDEPHIL]. Although this + scenario may not be fully applicable to the IPv4 Internet, it has + been deployed successfully in specific scenarios within intranets + using IKEv1. It should be more broadly enabled during the transition + to IPv6 and with the adoption of IKEv2. + + It is possible in this scenario that one or both of the protected + endpoints will be behind a network address translation (NAT) node, in + which case the tunneled packets will have to be UDP encapsulated so + that port numbers in the UDP headers can be used to identify + individual endpoints "behind" the NAT (see Section 2.23). + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 7] + +Internet-Draft IKEv2bis February 2008 + + +1.1.3. Endpoint to Security Gateway Tunnel + + +-+-+-+-+-+ +-+-+-+-+-+ + | | IPsec | | Protected + |Protected| tunnel |Tunnel | Subnet + |Endpoint |<------------------------>|Endpoint |<--- and/or + | | | | Internet + +-+-+-+-+-+ +-+-+-+-+-+ + + Figure 3: Endpoint to Security Gateway Tunnel + + In this scenario, a protected endpoint (typically a portable roaming + computer) connects back to its corporate network through an IPsec- + protected tunnel. It might use this tunnel only to access + information on the corporate network, or it might tunnel all of its + traffic back through the corporate network in order to take advantage + of protection provided by a corporate firewall against Internet-based + attacks. In either case, the protected endpoint will want an IP + address associated with the security gateway so that packets returned + to it will go to the security gateway and be tunneled back. This IP + address may be static or may be dynamically allocated by the security + gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 + includes a mechanism (namely, configuration payloads) for the + initiator to request an IP address owned by the security gateway for + use for the duration of its SA. + + In this scenario, packets will use tunnel mode. On each packet from + the protected endpoint, the outer IP header will contain the source + IP address associated with its current location (i.e., the address + that will get traffic routed to the endpoint directly), while the + inner IP header will contain the source IP address assigned by the + security gateway (i.e., the address that will get traffic routed to + the security gateway for forwarding to the endpoint). The outer + destination address will always be that of the security gateway, + while the inner destination address will be the ultimate destination + for the packet. + + In this scenario, it is possible that the protected endpoint will be + behind a NAT. In that case, the IP address as seen by the security + gateway will not be the same as the IP address sent by the protected + endpoint, and packets will have to be UDP encapsulated in order to be + routed properly. + +1.1.4. Other Scenarios + + Other scenarios are possible, as are nested combinations of the + above. One notable example combines aspects of 1.1.1 and 1.1.3. A + subnet may make all external accesses through a remote security + + + +Kaufman, et al. Expires August 28, 2008 [Page 8] + +Internet-Draft IKEv2bis February 2008 + + + gateway using an IPsec tunnel, where the addresses on the subnet are + routed to the security gateway by the rest of the Internet. An + example would be someone's home network being virtually on the + Internet with static IP addresses even though connectivity is + provided by an ISP that assigns a single dynamically assigned IP + address to the user's security gateway (where the static IP addresses + and an IPsec relay are provided by a third party located elsewhere). + +1.2. The Initial Exchanges + + Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH + exchanges (known in IKEv1 as Phase 1). These initial exchanges + normally consist of four messages, though in some scenarios that + number can grow. All communications using IKE consist of request/ + response pairs. We'll describe the base exchange first, followed by + variations. The first pair of messages (IKE_SA_INIT) negotiate + cryptographic algorithms, exchange nonces, and do a Diffie-Hellman + exchange [DH]. + + The second pair of messages (IKE_AUTH) authenticate the previous + messages, exchange identities and certificates, and establish the + first CHILD_SA. Parts of these messages are encrypted and integrity + protected with keys established through the IKE_SA_INIT exchange, so + the identities are hidden from eavesdroppers and all fields in all + the messages are authenticated. + + In the following descriptions, the payloads contained in the message + are indicated by names as listed below. + + Notation Payload + ----------------------------------------- + AUTH Authentication + CERT Certificate + CERTREQ Certificate Request + CP Configuration + D Delete + E Encrypted + EAP Extensible Authentication + HDR IKE Header + IDi Identification - Initiator + IDr Identification - Responder + KE Key Exchange + Ni, Nr Nonce + N Notify + SA Security Association + TSi Traffic Selector - Initiator + TSr Traffic Selector - Responder + V Vendor ID + + + +Kaufman, et al. Expires August 28, 2008 [Page 9] + +Internet-Draft IKEv2bis February 2008 + + + The details of the contents of each payload are described in section + 3. Payloads that may optionally appear will be shown in brackets, + such as [CERTREQ], indicate that optionally a certificate request + payload can be included. + + The initial exchanges are as follows: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SAi1, KEi, Ni --> + + HDR contains the Security Parameter Indexes (SPIs), version numbers, + and flags of various sorts. The SAi1 payload states the + cryptographic algorithms the initiator supports for the IKE_SA. The + KE payload sends the initiator's Diffie-Hellman value. Ni is the + initiator's nonce. + + <-- HDR, SAr1, KEr, Nr, [CERTREQ] + + The responder chooses a cryptographic suite from the initiator's + offered choices and expresses that choice in the SAr1 payload, + completes the Diffie-Hellman exchange with the KEr payload, and sends + its nonce in the Nr payload. + + At this point in the negotiation, each party can generate SKEYSEED, + from which all keys are derived for that IKE_SA. All but the headers + of all the messages that follow are encrypted and integrity + protected. The keys used for the encryption and integrity protection + are derived from SKEYSEED and are known as SK_e (encryption) and SK_a + (authentication, a.k.a. integrity protection). A separate SK_e and + SK_a is computed for each direction. In addition to the keys SK_e + and SK_a derived from the DH value for protection of the IKE_SA, + another quantity SK_d is derived and used for derivation of further + keying material for CHILD_SAs. The notation SK { ... } indicates + that these payloads are encrypted and integrity protected using that + direction's SK_e and SK_a. + + HDR, SK {IDi, [CERT,] [CERTREQ,] + [IDr,] AUTH, SAi2, + TSi, TSr} --> + + The initiator asserts its identity with the IDi payload, proves + knowledge of the secret corresponding to IDi and integrity protects + the contents of the first message using the AUTH payload (see + Section 2.15). It might also send its certificate(s) in CERT + payload(s) and a list of its trust anchors in CERTREQ payload(s). If + any CERT payloads are included, the first certificate provided MUST + contain the public key used to verify the AUTH field. The optional + + + +Kaufman, et al. Expires August 28, 2008 [Page 10] + +Internet-Draft IKEv2bis February 2008 + + + payload IDr enables the initiator to specify which of the responder's + identities it wants to talk to. This is useful when the machine on + which the responder is running is hosting multiple identities at the + same IP address. The initiator begins negotiation of a CHILD_SA + using the SAi2 payload. The final fields (starting with SAi2) are + described in the description of the CREATE_CHILD_SA exchange. + + <-- HDR, SK {IDr, [CERT,] AUTH, + SAr2, TSi, TSr} + + The responder asserts its identity with the IDr payload, optionally + sends one or more certificates (again with the certificate containing + the public key used to verify AUTH listed first), authenticates its + identity and protects the integrity of the second message with the + AUTH payload, and completes negotiation of a CHILD_SA with the + additional fields described below in the CREATE_CHILD_SA exchange. + + The recipients of messages 3 and 4 MUST verify that all signatures + and MACs are computed correctly and that the names in the ID payloads + correspond to the keys used to generate the AUTH payload. + + {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange + fails for some reason, the IKE_SA is still created as usual. 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. + + {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr + or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange + cannot contain Transform Type 4 (Diffie-Hellman Group) with any value + other than NONE. Implementations SHOULD omit the whole transform + substructure instead of sending value NONE. + +1.3. The CREATE_CHILD_SA Exchange + + {{ This is a heavy rewrite of most of this section. The major + organization changes are described in Clarif-4.1 and Clarif-5.1. }} + + 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 + + + +Kaufman, et al. Expires August 28, 2008 [Page 11] + +Internet-Draft IKEv2bis February 2008 + + + 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". For both + messages in the CREATE_CHILD_SA, the message following the header is + encrypted and the message including the header is integrity protected + using the cryptographic algorithms negotiated for the IKE_SA. + + The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs. + An SA is rekeyed by creating a new SA and then deleting the old one. + This section describes the first part of rekeying, the creation of + new SAs; Section 2.8 covers the mechanics of rekeying, including + moving traffic from old to new SAs and the deletion of the old SAs. + The two sections must be read together to understand the entire + process of rekeying. + + Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this + section the term initiator refers to the endpoint initiating this + exchange. An implementation MAY refuse all CREATE_CHILD_SA requests + within an IKE_SA. + + The CREATE_CHILD_SA request MAY optionally contain a KE payload for + an additional Diffie-Hellman exchange to enable stronger guarantees + of forward secrecy for the CHILD_SA. The keying material for the + CHILD_SA is a function of SK_d established during the establishment + of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA + exchange, and the Diffie-Hellman value (if KE payloads are included + in the CREATE_CHILD_SA exchange). + + If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of + the SA offers MUST include the Diffie-Hellman group of the KEi. The + Diffie-Hellman group of the KEi MUST be an element of the group the + initiator expects the responder to accept (additional Diffie-Hellman + groups can be proposed). If the responder selects a proposal using a + different Diffie-Hellman group (other than NONE), the responder MUST + reject the request and indicate its preferred Diffie-Hellman group in + the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There + are two octets of data associated with this notification: the + accepted D-H Group number in big endian order. In the case of such a + rejection, the CREATE_CHILD_SA exchange fails, and the initiator will + probably retry the exchange with a Diffie-Hellman proposal and KEi in + the group that the responder gave in the INVALID_KE_PAYLOAD. + + {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification + to indicate that a CREATE_CHILD_SA request is unacceptable because + the responder is unwilling to accept any more CHILD_SAs on this + IKE_SA. Some minimal implementations may only accept a single + CHILD_SA setup in the context of an initial IKE exchange and reject + any subsequent attempts to add more. + + + +Kaufman, et al. Expires August 28, 2008 [Page 12] + +Internet-Draft IKEv2bis February 2008 + + +1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange + + A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The + CREATE_CHILD_SA request for creating a new CHILD_SA is: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {SA, Ni, [KEi], + TSi, TSr} --> + + The initiator sends SA offer(s) in the SA payload, a nonce in the Ni + payload, optionally a Diffie-Hellman value in the KEi payload, and + the proposed traffic selectors for the proposed CHILD_SA in the TSi + and TSr payloads. + + The CREATE_CHILD_SA response for creating a new CHILD_SA is: + + <-- HDR, SK {SA, Nr, [KEr], + TSi, TSr} + + The responder replies (using the same Message ID to respond) with the + accepted offer in an SA payload, and a Diffie-Hellman value in the + KEr payload if KEi was included in the request and the selected + cryptographic suite includes that group. + + The traffic selectors for traffic to be sent on that SA are specified + in the TS payloads in the response, which may be a subset of what the + initiator of the CHILD_SA proposed. + + {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be + included in a request message that also includes an SA payload + requesting a CHILD_SA. It requests that the CHILD_SA use transport + mode rather than tunnel mode for the SA created. If the request is + accepted, the response MUST also include a notification of type + USE_TRANSPORT_MODE. If the responder declines the request, the + CHILD_SA will be established in tunnel mode. If this is unacceptable + to the initiator, the initiator MUST delete the SA. Note: Except + when using this option to negotiate transport mode, all CHILD_SAs + will use tunnel mode. + + {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification + asserts that the sending endpoint will NOT accept packets that + contain Traffic Flow Confidentiality (TFC) padding over the CHILD_SA + being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC + padding, this notification is included in both the request and the + response. If this notification is included in only one of the + messages, TFC padding can still be sent in the other direction. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 13] + +Internet-Draft IKEv2bis February 2008 + + + {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used + for fragmentation control. See [IPSECARCH] for a fuller explanation. + {{ Clarif-4.6 }} 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. If the peer rejects + the proposal of the SA, the peer only omits NON_FIRST_FRAGMENTS_ALSO + notification from the response, but does not reject the whole + CHILD_SA creation. + +1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange + + The CREATE_CHILD_SA request for rekeying an IKE_SA is: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {SA, Ni, [KEi]} --> + + The initiator sends SA offer(s) in the SA payload, a nonce in the Ni + payload, and a Diffie-Hellman value in the KEi payload. The KEi + payload SHOULD be included. New initiator and responder SPIs are + supplied in the SPI fields. + + The CREATE_CHILD_SA response for rekeying an IKE_SA is: + + <-- HDR, SK {SA, Nr,[KEr]} + + The responder replies (using the same Message ID to respond) with the + accepted offer in an SA payload, and a Diffie-Hellman value in the + KEr payload if the selected cryptographic suite includes that group. + + The new IKE_SA has its message counters set to 0, regardless of what + they were in the earlier IKE_SA. The window size starts at 1 for any + new IKE_SA. + +1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange + + The CREATE_CHILD_SA request for rekeying a CHILD_SA is: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {N, SA, Ni, [KEi], + TSi, TSr} --> + + The initiator sends SA offer(s) in the SA payload, a nonce in the Ni + payload, optionally a Diffie-Hellman value in the KEi payload, and + the proposed traffic selectors for the proposed CHILD_SA in the TSi + and TSr payloads. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 14] + +Internet-Draft IKEv2bis February 2008 + + + {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a + CREATE_CHILD_SA exchange if the purpose of the exchange is to replace + an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is + identified by the SPI field in the Notify payload; this is the SPI + the exchange initiator would expect in inbound ESP or AH packets. + There is no data associated with this Notify type. + + The CREATE_CHILD_SA response for rekeying a CHILD_SA is: + + <-- HDR, SK {SA, Nr, [KEr], + Si, TSr} + + The responder replies (using the same Message ID to respond) with the + accepted offer in an SA payload, and a Diffie-Hellman value in the + KEr payload if KEi was included in the request and the selected + cryptographic suite includes that group. + + The traffic selectors for traffic to be sent on that SA are specified + in the TS payloads in the response, which may be a subset of what the + initiator of the CHILD_SA proposed. + +1.4. The INFORMATIONAL Exchange + + At various points during the operation of an IKE_SA, peers may desire + to convey control messages to each other regarding errors or + notifications of certain events. To accomplish this, IKE defines an + INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur + after the initial exchanges and are cryptographically protected with + the negotiated keys. + + Control messages that pertain to an IKE_SA MUST be sent under that + IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent + under the protection of the IKE_SA which generated them (or its + successor if the IKE_SA was replaced for the purpose of rekeying). + + Messages in an INFORMATIONAL exchange contain zero or more + Notification, Delete, and Configuration payloads. The Recipient of + an INFORMATIONAL exchange request MUST send some response (else the + Sender will assume the message was lost in the network and will + retransmit it). That response MAY be a message with no payloads. + The request message in an INFORMATIONAL exchange MAY also contain no + payloads. This is the expected way an endpoint can ask the other + endpoint to verify that it is alive. + + {{ Clarif-5.6 }} 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 (that is, deleted). Each endpoint MUST close its incoming + SAs and allow the other endpoint to close the other SA in each pair. + + + +Kaufman, et al. Expires August 28, 2008 [Page 15] + +Internet-Draft IKEv2bis February 2008 + + + 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. {{ Clarif-5.7 }} Note that one never + sends delete payloads for the two sides of an SA in a single message. + If there are many SAs to delete at the same time, one includes delete + payloads for in inbound half of each SA pair in your Informational + exchange. + + Normally, the reply in the INFORMATIONAL exchange will contain delete + payloads for the paired SAs going in the other direction. There is + one exception. If by chance both ends of a set of SAs independently + decide to close them, each may send a delete payload and the two + requests may cross in the network. If a node receives a delete + request for SAs for which it has already issued a delete request, it + MUST delete the outgoing SAs while processing the request and the + incoming SAs while processing the response. In that case, the + responses MUST NOT include delete payloads for the deleted SAs, since + that would result in duplicate deletion and could in theory delete + the wrong SA. + + {{ Demoted the SHOULD }} Half-closed ESP or AH connections are + anomalous, and a node with auditing capability should probably audit + their existence if they persist. Note that this specification + nowhere specifies time periods, so it is up to individual endpoints + to decide how long to wait. A node MAY refuse to accept incoming + data on half-closed connections but MUST NOT unilaterally close them + and reuse the SPIs. If connection state becomes sufficiently messed + up, a node MAY close the IKE_SA; doing so will implicitly close all + SAs negotiated under it. It can then rebuild the SAs it needs on a + clean base under a new IKE_SA. {{ Clarif-5.8 }} The response to a + request that deletes the IKE_SA is an empty Informational response. + + The INFORMATIONAL exchange is defined as: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {[N,] [D,] + [CP,] ...} --> + <-- HDR, SK {[N,] [D,] + [CP], ...} + + The processing of an INFORMATIONAL exchange is determined by its + component payloads. + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 16] + +Internet-Draft IKEv2bis February 2008 + + +1.5. Informational Messages outside of an IKE_SA + + If an encrypted IKE request packet arrives on port 500 or 4500 with + an unrecognized SPI, it could be because the receiving node has + recently crashed and lost state or because of some other system + malfunction or attack. If the receiving node has an active IKE_SA to + the IP address from whence the packet came, it MAY send a + notification of the wayward packet over that IKE_SA in an + INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY + send an Informational message without cryptographic protection to the + source IP address. Such a message is not part of an informational + exchange, and the receiving node MUST NOT respond to it. Doing so + could cause a message loop. + + {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE + INFORMATIONAL exchange when a node receives an ESP or AH packet with + an invalid SPI. The Notification Data contains the SPI of the + invalid packet. This usually indicates a node has rebooted and + forgotten an SA. If this Informational Message is sent outside the + context of an IKE_SA, it should only be used by the recipient as a + "hint" that something might be wrong (because it could easily be + forged). + + {{ Clarif-7.7 }} There are two cases when such a one-way notification + is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are + sent outside of an IKE_SA. Note that such notifications are + explicitly not Informational exchanges; these are one-way messages + that must not be responded to. In case of INVALID_IKE_SPI, the + message sent is a response message, and thus it is 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. Using zero values or random values are both + acceptable. + +1.6. Requirements Terminology + + Definitions of the primitive terms in this document (such as Security + Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It + should be noted that parts of IKEv2 rely on some of the processing + rules in [IPSECARCH], as described in various sections of this + document. + + Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and + "MAY" that appear in this document are to be interpreted as described + in [MUSTSHOULD]. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 17] + +Internet-Draft IKEv2bis February 2008 + + +1.7. Differences Between RFC 4306 and This Document + + {{ Added this entire section, including this recursive remark. }} + + This document contains clarifications and amplifications to IKEv2 + [IKEV2]. The clarifications are mostly based on [Clarif]. The + changes listed in that document were discussed in the IPsec Working + Group and, after the Working Group was disbanded, on the IPsec + mailing list. That document contains detailed explanations of areas + that were unclear in IKEv2, and is thus useful to implementers of + IKEv2. + + The protocol described in this document retains the same major + version number (2) and minor version number (0) as was used in RFC + 4306. + + This document makes the figures and references a bit more regular + than in [IKEV2]. + + IKEv2 developers have noted that the SHOULD-level requirements are + often unclear in that they don't say when it is OK to not obey the + requirements. They also have noted that there are MUST-level + requirements that are not related to interoperability. This document + has more explanation of some of these requirements. All non- + capitalized uses of the words SHOULD and MUST now mean their normal + English sense, not the interoperability sense of [MUSTSHOULD]. + + IKEv2 (and IKEv1) developers have noted that there is a great deal of + material in the tables of codes in Section 3.10.1. This leads to + implementers not having all the needed information in the main body + of the docment. Much of the material from those tables has been + moved into the associated parts of the main body of the document. + + In the body of this document, notes that are enclosed in double curly + braces {{ such as this }} point out changes from IKEv2. Changes that + come from [Clarif] are marked with the section from that document, + such as "{{ Clarif-2.10 }}". Changes that come from moving + descriptive text out of the tables in Section 3.10.1 are marked with + that number and the message type that contained the text, such as "{{ + 3.10.1-16384 }}". + + This document removes discussion of nesting AH and ESP. This was a + mistake in RFC 4306 caused by the lag between finishing RFC 4306 and + RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not + include "SA bundles" that were part of RFC 2401. 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 + + + +Kaufman, et al. Expires August 28, 2008 [Page 18] + +Internet-Draft IKEv2bis February 2008 + + + using a separate CREATE_CHILD_SA exchange. + + This document removes discussion of the INTERNAL_ADDRESS_EXPIRY + configuration attribute because its implementation was very + problematic. Implementations that conform to this document MUST + ignore proposals that have configuration attribute type 5, the old + value for INTERNAL_ADDRESS_EXPIRY. + + This document adds the restriction in Section 2.13 that all PRFs used + with IKEv2 MUST take variable-sized keys. This should not affect any + implementations because there were no standardized PRFs that have + fixed-size keys. + + A later version of this document may have all the {{ }} comments + removed from the body of the document and instead appear in an + appendix. + + +2. IKE Protocol Details and Variations + + IKE normally listens and sends on UDP port 500, though IKE messages + may also be received on UDP port 4500 with a slightly different + format (see Section 2.23). Since UDP is a datagram (unreliable) + protocol, IKE includes in its definition recovery from transmission + errors, including packet loss, packet replay, and packet forgery. + IKE is designed to function so long as (1) at least one of a series + of retransmitted packets reaches its destination before timing out; + and (2) the channel is not so full of forged and replayed packets so + as to exhaust the network or CPU capacities of either endpoint. Even + in the absence of those minimum performance requirements, IKE is + designed to fail cleanly (as though the network were broken). + + Although IKEv2 messages are intended to be short, they contain + structures with no hard upper bound on size (in particular, X.509 + certificates), and IKEv2 itself does not have a mechanism for + fragmenting large messages. IP defines a mechanism for fragmentation + of oversize UDP messages, but implementations vary in the maximum + message size supported. Furthermore, use of IP fragmentation opens + an implementation to denial of service attacks [DOSUDPPROT]. + Finally, some NAT and/or firewall implementations may block IP + fragments. + + All IKEv2 implementations MUST be able to send, receive, and process + IKE messages that are up to 1280 octets long, and they SHOULD be able + to send, receive, and process messages that are up to 3000 octets + long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware + of the maximum UDP message size supported and MAY shorten messages by + leaving out some certificates or cryptographic suite proposals if + + + +Kaufman, et al. Expires August 28, 2008 [Page 19] + +Internet-Draft IKEv2bis February 2008 + + + that will keep messages below the maximum. Use of the "Hash and URL" + formats rather than including certificates in exchanges where + possible can avoid most problems. {{ Demoted the SHOULD }} + Implementations and configuration need to keep in mind, however, that + if the URL lookups are possible only after the IPsec SA is + established, recursion issues could prevent this technique from + working. + + {{ Clarif-7.5 }} The UDP payload of all packets containing IKE + messages sent on port 4500 MUST begin with the prefix of four zeros; + otherwise, the receiver won't know how to handle them. + +2.1. Use of Retransmission Timers + + All messages in IKE exist in pairs: a request and a response. The + setup of an IKE_SA normally consists of two request/response pairs. + Once the IKE_SA is set up, either end of the security association may + initiate requests at any time, and there can be many requests and + responses "in flight" at any given moment. But each message is + labeled as either a request or a response, and for each request/ + response pair one end of the security association is the initiator + and the other is the responder. + + For every pair of IKE messages, the initiator is responsible for + retransmission in the event of a timeout. The responder MUST never + retransmit a response unless it receives a retransmission of the + request. In that event, the responder MUST ignore the retransmitted + request except insofar as it triggers a retransmission of the + response. The initiator MUST remember each request until it receives + the corresponding response. The responder MUST remember each + response until it receives a request whose sequence number is larger + than or equal to the sequence number in the response plus its window + size (see Section 2.3). + + IKE is a reliable protocol, in the sense that the initiator MUST + retransmit a request until either it receives a corresponding reply + OR it deems the IKE security association to have failed and it + discards all state associated with the IKE_SA and any CHILD_SAs + negotiated using that IKE_SA. + + {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require + some special handling. When a responder receives an IKE_SA_INIT + request, it has to determine whether the packet is 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), + or it belongs to an existing IKE_SA where the IKE_AUTH request has + been already received (in which case the responder ignores it). + + + +Kaufman, et al. Expires August 28, 2008 [Page 20] + +Internet-Draft IKEv2bis February 2008 + + + It is not sufficient to use the initiator's SPI and/or IP address to + differentiate between these three cases because two different peers + behind a single NAT could choose the same initiator SPI. Instead, a + robust responder will do the IKE_SA lookup using the whole packet, + its hash, or the Ni payload. + +2.2. Use of Sequence Numbers for Message ID + + Every IKE message contains a Message ID as part of its fixed header. + This Message ID is used to match up requests and responses, and to + identify retransmissions of messages. + + The Message ID is a 32-bit quantity, which is zero for the + IKE_SA_INIT messages (including retries of the message due to + responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), + and incremented for each subsequent exchange. Thus, the first pair + of IKE_AUTH messages will have ID of 1, the second (when EAP is used) + will be 2, and so on. {{ Clarif-3.10 }} + + Each endpoint in the IKE Security Association maintains two "current" + Message IDs: the next one to be used for a request it initiates and + the next one it expects to see in a request from the other end. + These counters increment as requests are generated and received. + Responses always contain the same message ID as the corresponding + request. That means that after the initial exchange, each integer n + may appear as the message ID in four distinct messages: the nth + request from the original IKE initiator, the corresponding response, + the nth request from the original IKE responder, and the + corresponding response. If the two ends make very different numbers + of requests, the Message IDs in the two directions can be very + different. There is no ambiguity in the messages, however, because + the (I)nitiator and (R)esponse bits in the message header specify + which of the four messages a particular one is. + + Note that Message IDs are cryptographically protected and provide + protection against message replays. In the unlikely event that + Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be + closed. Rekeying an IKE_SA resets the sequence numbers. + +2.3. Window Size for Overlapping Requests + + In order to maximize IKE throughput, an IKE endpoint MAY issue + multiple requests before getting a response to any of them if the + other endpoint has indicated its ability to handle such requests. + For simplicity, an IKE implementation MAY choose to process requests + strictly in order and/or wait for a response to one request before + issuing another. Certain rules must be followed to ensure + interoperability between implementations using different strategies. + + + +Kaufman, et al. Expires August 28, 2008 [Page 21] + +Internet-Draft IKEv2bis February 2008 + + + After an IKE_SA is set up, either end can initiate one or more + requests. These requests may pass one another over the network. An + IKE endpoint MUST be prepared to accept and process a request while + it has a request outstanding in order to avoid a deadlock in this + situation. {{ Downgraded the SHOULD }} An IKE endpoint may also + accept and process multiple requests while it has a request + outstanding. + + {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the + sending endpoint is capable of keeping state for multiple outstanding + exchanges, permitting the recipient to send multiple requests before + getting a response to the first. The data associated with a + SET_WINDOW_SIZE notification MUST be 4 octets long and contain the + big endian representation of the number of messages the sender + promises to keep. The window size is always one until the initial + exchanges complete. + + An IKE endpoint MUST wait for a response to each of its messages + before sending a subsequent message unless it has received a + SET_WINDOW_SIZE Notify message from its peer informing it that the + peer is prepared to maintain state for multiple outstanding messages + in order to allow greater throughput. + + An IKE endpoint MUST NOT exceed the peer's stated window size for + transmitted IKE requests. In other words, if the responder stated + its window size is N, then when the initiator needs to make a request + X, it MUST wait until it has received responses to all requests up + through request X-N. An IKE endpoint MUST keep a copy of (or be able + to regenerate exactly) each request it has sent until it receives the + corresponding response. An IKE endpoint MUST keep a copy of (or be + able to regenerate exactly) the number of previous responses equal to + its declared window size in case its response was lost and the + initiator requests its retransmission by retransmitting the request. + + An IKE endpoint supporting a window size greater than one ought to be + capable of processing incoming requests out of order to maximize + performance in the event of network failures or packet reordering. + + {{ Clarif-7.3 }} The window size is normally a (possibly + configurable) property of a particular implementation, and is not + related to congestion control (unlike the window size in TCP, for + example). 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; you can only + increase it. 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. + + + +Kaufman, et al. Expires August 28, 2008 [Page 22] + +Internet-Draft IKEv2bis February 2008 + + + {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE + message ID outside the supported window is received. This Notify + MUST NOT be sent in a response; the invalid request MUST NOT be + acknowledged. Instead, inform the other side by initiating an + INFORMATIONAL exchange with Notification data containing the four + octet invalid message ID. Sending this notification is optional, and + notifications of this type MUST be rate limited. + +2.4. State Synchronization and Connection Timeouts + + An IKE endpoint is allowed to forget all of its state associated with + an IKE_SA and the collection of corresponding CHILD_SAs at any time. + This is the anticipated behavior in the event of an endpoint crash + and restart. It is important when an endpoint either fails or + reinitializes its state that the other endpoint detect those + conditions and not continue to waste network bandwidth by sending + packets over discarded SAs and having them fall into a black hole. + + {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this + IKE_SA is the only IKE_SA currently active between the authenticated + identities. It MAY be sent when an IKE_SA is established after a + crash, and the recipient MAY use this information to delete any other + IKE_SAs it has to the same authenticated identity without waiting for + a timeout. This notification MUST NOT be sent by an entity that may + be replicated (e.g., a roaming user's credentials where the user is + allowed to connect to the corporate firewall from two remote systems + at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, + if sent, MUST be in the first IKE_AUTH request, not as a separate + exchange afterwards; however, receiving parties need to deal with it + in other requests. + + Since IKE is designed to operate in spite of Denial of Service (DoS) + attacks from the network, an endpoint MUST NOT conclude that the + other endpoint has failed based on any routing information (e.g., + ICMP messages) or IKE messages that arrive without cryptographic + protection (e.g., Notify messages complaining about unknown SPIs). + An endpoint MUST conclude that the other endpoint has failed only + when repeated attempts to contact it have gone unanswered for a + timeout period or when a cryptographically protected INITIAL_CONTACT + notification is received on a different IKE_SA to the same + authenticated identity. {{ Demoted the SHOULD }} An endpoint should + suspect that the other endpoint has failed based on routing + information and initiate a request to see whether the other endpoint + is alive. To check whether the other side is alive, IKE specifies an + empty INFORMATIONAL message that (like all IKE requests) requires an + acknowledgement (note that within the context of an IKE_SA, an + "empty" message consists of an IKE header followed by an Encrypted + payload that contains no payloads). If a cryptographically protected + + + +Kaufman, et al. Expires August 28, 2008 [Page 23] + +Internet-Draft IKEv2bis February 2008 + + + message has been received from the other side recently, unprotected + notifications MAY be ignored. Implementations MUST limit the rate at + which they take actions based on unprotected messages. + + Numbers of retries and lengths of timeouts are not covered in this + specification because they do not affect interoperability. It is + suggested that messages be retransmitted at least a dozen times over + a period of at least several minutes before giving up on an SA, but + different environments may require different rules. To be a good + network citizen, retranmission times MUST increase exponentially to + avoid flooding the network and making an existing congestion + situation worse. If there has only been outgoing traffic on all of + the SAs associated with an IKE_SA, it is essential to confirm + liveness of the other endpoint to avoid black holes. If no + cryptographically protected messages have been received on an IKE_SA + or any of its CHILD_SAs recently, the system needs to perform a + liveness check in order to prevent sending messages to a dead peer. + Receipt of a fresh cryptographically protected message on an IKE_SA + or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its + CHILD_SAs. Note that this places requirements on the failure modes + of an IKE endpoint. An implementation MUST NOT continue sending on + any SA if some failure prevents it from receiving on all of the + associated SAs. If CHILD_SAs can fail independently from one another + without the associated IKE_SA being able to send a delete message, + then they MUST be negotiated by separate IKE_SAs. + + There is a Denial of Service attack on the initiator of an IKE_SA + that can be avoided if the initiator takes the proper care. Since + the first two messages of an SA setup are not cryptographically + protected, an attacker could respond to the initiator's message + before the genuine responder and poison the connection setup attempt. + To prevent this, the initiator MAY be willing to accept multiple + responses to its first message, treat each as potentially legitimate, + respond to it, and then discard all the invalid half-open connections + when it receives a valid cryptographically protected response to any + one of its requests. Once a cryptographically valid response is + received, all subsequent responses should be ignored whether or not + they are cryptographically valid. + + Note that with these rules, there is no reason to negotiate and agree + upon an SA lifetime. If IKE presumes the partner is dead, based on + repeated lack of acknowledgement to an IKE message, then the IKE SA + and all CHILD_SAs set up through that IKE_SA are deleted. + + An IKE endpoint may at any time delete inactive CHILD_SAs to recover + resources used to hold their state. If an IKE endpoint chooses to + delete CHILD_SAs, it MUST send Delete payloads to the other end + notifying it of the deletion. It MAY similarly time out the IKE_SA. + + + +Kaufman, et al. Expires August 28, 2008 [Page 24] + +Internet-Draft IKEv2bis February 2008 + + + {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all + associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a + Delete payload indicating that it has closed the IKE_SA unless the + other endpoint is no longer responding. + +2.5. Version Numbers and Forward Compatibility + + This document describes version 2.0 of IKE, meaning the major version + number is 2 and the minor version number is 0. {{ Restated the + relationship to RFC 4306 }} This document is a clarification of + [IKEV2]. It is likely that some implementations will want to support + version 1.0 and version 2.0, and in the future, other versions. + + The major version number should be incremented only if the packet + formats or required actions have changed so dramatically that an + older version node would not be able to interoperate with a newer + version node if it simply ignored the fields it did not understand + and took the actions specified in the older specification. The minor + version number indicates new capabilities, and MUST be ignored by a + node with a smaller minor version number, but used for informational + purposes by the node with the larger minor version number. For + example, it might indicate the ability to process a newly defined + notification message. The node with the larger minor version number + would simply note that its correspondent would not be able to + understand that message and therefore would not send it. + + {{ 3.10.1-5 }} If an endpoint receives a message with a higher major + version number, it MUST drop the message and SHOULD send an + unauthenticated notification message of type INVALID_MAJOR_VERSION + containing the highest (closest) version number it supports. If an + endpoint supports major version n, and major version m, it MUST + support all versions between n and m. If it receives a message with + a major version that it supports, it MUST respond with that version + number. In order to prevent two nodes from being tricked into + corresponding with a lower major version number than the maximum that + they both support, IKE has a flag that indicates that the node is + capable of speaking a higher major version number. + + Thus, the major version number in the IKE header indicates the + version number of the message, not the highest version number that + the transmitter supports. If the initiator is capable of speaking + versions n, n+1, and n+2, and the responder is capable of speaking + versions n and n+1, then they will negotiate speaking n+1, where the + initiator will set a flag indicating its ability to speak a higher + version. If they mistakenly (perhaps through an active attacker + sending error messages) negotiate to version n, then both will notice + that the other side can support a higher version number, and they + MUST break the connection and reconnect using version n+1. + + + +Kaufman, et al. Expires August 28, 2008 [Page 25] + +Internet-Draft IKEv2bis February 2008 + + + Note that IKEv1 does not follow these rules, because there is no way + in v1 of noting that you are capable of speaking a higher version + number. So an active attacker can trick two v2-capable nodes into + speaking v1. {{ Demoted the SHOULD }} When a v2-capable node + negotiates down to v1, it should note that fact in its logs. + + Also for forward compatibility, all fields marked RESERVED MUST be + set to zero by an implementation running version 2.0, and their + content MUST be ignored by an implementation running version 2.0 ("Be + conservative in what you send and liberal in what you receive"). In + this way, future versions of the protocol can use those fields in a + way that is guaranteed to be ignored by implementations that do not + understand them. Similarly, payload types that are not defined are + reserved for future use; implementations of a version where they are + undefined MUST skip over those payloads and ignore their contents. + + IKEv2 adds a "critical" flag to each payload header for further + flexibility for forward compatibility. If the critical flag is set + and the payload type is unrecognized, the message MUST be rejected + and the response to the IKE request containing that payload MUST + include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an + unsupported critical payload was included. {{ 3.10.1-1 }} In that + Notify payload, the notification data contains the one-octet payload + type. If the critical flag is not set and the payload type is + unsupported, that payload MUST be ignored. Payloads sent in IKE + response messages MUST NOT have the critical flag set. Note that the + critical flag applies only to the payload type, not the contents. If + the payload type is recognized, but the payload contains something + which is not (such as an unknown transform inside an SA payload, or + an unknown Notify Message Type inside a Notify payload), the critical + flag is ignored. + + NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the + order shown in the figures in Section 2? Can we eliminate the + requirement in the following paragraph? If not, we will probably + have to add a new appendix with the order, but there is no reason to + do that if no one actually cares. {{ Remove this paragraph before the + document is finalized, of course. }} + + {{ Demoted the SHOULD in the second clause }}Although new payload + types may be added in the future and may appear interleaved with the + fields defined in this specification, implementations MUST send the + payloads defined in this specification in the order shown in the + figures in Section 2; implementations are explicitly allowed to + reject as invalid a message with those payloads in any other order. + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 26] + +Internet-Draft IKEv2bis February 2008 + + +2.6. Cookies + + The term "cookies" originates with Karn and Simpson [PHOTURIS] in + Photuris, an early proposal for key management with IPsec, and it has + persisted. The Internet Security Association and Key Management + Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- + octet fields titled "cookies", and that syntax is used by both IKEv1 + and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" + and there is a new separate field in a Notify payload holding the + cookie. The initial two eight-octet fields in the header are used as + a connection identifier at the beginning of IKE packets. {{ Demoted + the SHOULD }} Each endpoint chooses one of the two SPIs and needs to + choose them so as to be unique identifiers of an IKE_SA. An SPI + value of zero is special and indicates that the remote SPI value is + not yet known by the sender. + + Unlike ESP and AH where only the recipient's SPI appears in the + header of a message, in IKE the sender's SPI is also sent in every + message. Since the SPI chosen by the original initiator of the + IKE_SA is always sent first, an endpoint with multiple IKE_SAs open + that wants to find the appropriate IKE_SA using the SPI it assigned + must look at the I(nitiator) Flag bit in the header to determine + whether it assigned the first or the second eight octets. + + In the first message of an initial IKE exchange, the initiator will + not know the responder's SPI value and will therefore set that field + to zero. + + An expected attack against IKE is state and CPU exhaustion, where the + target is flooded with session initiation requests from forged IP + addresses. This attack can be made less effective if an + implementation of a responder uses minimal CPU and commits no state + to an SA until it knows the initiator can receive packets at the + address from which it claims to be sending them. + + When a responder detects a large number of half-open IKE_SAs, it + SHOULD reply to IKE_SA_INIT requests with a response containing the + COOKIE notification. {{ 3.10.1-16390 }} The data associated with this + notification MUST be between 1 and 64 octets in length (inclusive), + and its generation is described later in this section. If the + IKE_SA_INIT response includes the COOKIE notification, the initiator + MUST then retry the IKE_SA_INIT request, and include the COOKIE + notification containing the received data as the first payload, and + all other payloads unchanged. The initial exchange will then be as + follows: + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 27] + +Internet-Draft IKEv2bis February 2008 + + + Initiator Responder + ------------------------------------------------------------------- + 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, [CERTREQ] + HDR(A,B), SK {IDi, [CERT,] + [CERTREQ,] [IDr,] AUTH, + SAi2, TSi, TSr} --> + <-- HDR(A,B), SK {IDr, [CERT,] + AUTH, SAr2, TSi, TSr} + + The first two messages do not affect any initiator or responder state + except for communicating the cookie. In particular, the message + sequence numbers in the first four messages will all be zero and the + message sequence numbers in the last two messages will be one. 'A' + is the SPI assigned by the initiator, while 'B' is the SPI assigned + by the responder. + + {{ Demoted the SHOULD }} An IKE implementation should implement its + responder cookie generation in such a way as to not require any saved + state to recognize its valid cookie when the second IKE_SA_INIT + message arrives. The exact algorithms and syntax they use to + generate cookies do not affect interoperability and hence are not + specified here. The following is an example of how an endpoint could + use cookies to implement limited DOS protection. + + A good way to do this is to set the responder cookie to be: + + Cookie = | Hash(Ni | IPi | SPIi | ) + + where is a randomly generated secret known only to the + responder and periodically changed and | indicates concatenation. + should be changed whenever is + regenerated. The cookie can be recomputed when the IKE_SA_INIT + arrives the second time and compared to the cookie in the received + message. If it matches, the responder knows that the cookie was + generated since the last change to and that IPi must be the + same as the source address it saw the first time. Incorporating SPIi + into the calculation ensures that if multiple IKE_SAs are being set + up in parallel they will all get different cookies (assuming the + initiator chooses unique SPIi's). Incorporating Ni into the hash + ensures that an attacker who sees only message 2 can't successfully + forge a message 3. + + If a new value for is chosen while there are connections in + + + +Kaufman, et al. Expires August 28, 2008 [Page 28] + +Internet-Draft IKEv2bis February 2008 + + + the process of being initialized, an IKE_SA_INIT might be returned + with other than the current . The responder in + that case MAY reject the message by sending another response with a + new cookie or it MAY keep the old value of around for a + short time and accept cookies computed from either one. {{ Demoted + the SHOULD NOT }} The responder should not accept cookies + indefinitely after is changed, since that would defeat part + of the denial of service protection. {{ Demoted the SHOULD }} The + responder should change the value of frequently, especially + if under attack. + + {{ Clarif-2.1 }} In addition to cookies, there are several cases + where the IKE_SA_INIT exchange does not result in the creation of an + IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a + case, sending a zero value for the Responder's SPI is correct. If + the responder sends a non-zero responder SPI, the initiator should + not reject the response for only that reason. + + {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request + containing a cookie whose contents do not match the value expected, + that party MUST ignore the cookie and process the message as if no + cookie had been included; usually this means sending a response + containing a new cookie. + +2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD + + {{ This section added by Clarif-2.4 }} + + 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. + If the initiator receives a cookie from the responder, the initiator + needs to decide whether or not to include the cookie in only the next + retry of the IKE_SA_INIT request, or in all subsequent retries as + well. + + If the initiator includes the cookie only in the next retry, one + additional roundtrip may be needed in some cases. An additional + roundtrip is needed also if the initiator includes the cookie in all + retries, but the responder does not support this. For instance, if + the responder includes the SAi1 and KEi payloads in cookie + calculation, it will reject the request by sending a new cookie. + + If both peers support including the cookie in all retries, a slightly + shorter exchange can happen. Implementations SHOULD support this + shorter exchange, but MUST NOT fail if other implementations do not + support this shorter exchange. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 29] + +Internet-Draft IKEv2bis February 2008 + + +2.7. Cryptographic Algorithm Negotiation + + The payload type known as "SA" indicates a proposal for a set of + choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well + as cryptographic algorithms associated with each protocol. + + An SA payload consists of one or more proposals. {{ Clarif-7.13 }} + Each proposal includes one protocol. Each protocol contains one or + more transforms -- each specifying a cryptographic algorithm. Each + transform contains zero or more attributes (attributes are needed + only if the transform identifier does not completely specify the + cryptographic algorithm). + + This hierarchical structure was designed to efficiently encode + proposals for cryptographic suites when the number of supported + suites is large because multiple values are acceptable for multiple + transforms. The responder MUST choose a single suite, which may be + any subset of the SA proposal following the rules below: + + {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal + is accepted, the SA response MUST contain the same protocol. The + responder MUST accept a single proposal or reject them all and return + an error. {{ 3.10.1-14 }} The error is given in a notification of + type NO_PROPOSAL_CHOSEN. + + Each IPsec protocol proposal contains one or more transforms. Each + transform contains a transform type. The accepted cryptographic + suite MUST contain exactly one transform of each type included in the + proposal. For example: if an ESP proposal includes transforms + ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, + AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one + of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six + combinations are acceptable. + + Since the initiator sends its Diffie-Hellman value in the + IKE_SA_INIT, it must guess the Diffie-Hellman group that the + responder will select from its list of supported groups. If the + initiator guesses wrong, the responder will respond with a Notify + payload of type INVALID_KE_PAYLOAD indicating the selected group. In + this case, the initiator MUST retry the IKE_SA_INIT with the + corrected Diffie-Hellman group. The initiator MUST again propose its + full set of acceptable cryptographic suites because the rejection + message was unauthenticated and otherwise an active attacker could + trick the endpoints into negotiating a weaker suite than a stronger + one that they both prefer. + + {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the + creation of an IKE_SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, + + + +Kaufman, et al. Expires August 28, 2008 [Page 30] + +Internet-Draft IKEv2bis February 2008 + + + or COOKIE (see Section 2.6), the responder's SPI will be zero. + However, if the responder sends a non-zero responder SPI, the + initiator should not reject the response for only that reason. + +2.8. Rekeying + + {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use + secret keys that should be used only for a limited amount of time and + to protect a limited amount of data. This limits the lifetime of the + entire security association. When the lifetime of a security + association expires, the security association MUST NOT be used. If + there is demand, new security associations MAY be established. + Reestablishment of security associations to take the place of ones + that expire is referred to as "rekeying". + + To allow for minimal IPsec implementations, the ability to rekey SAs + without restarting the entire IKE_SA is optional. An implementation + MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA + has expired or is about to expire and rekeying attempts using the + mechanisms described here fail, an implementation MUST close the + IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ + Demoted the SHOULD }} Implementations may wish to support in-place + rekeying of SAs, since doing so offers better performance and is + likely to reduce the number of packets lost during the transition. + + To rekey a CHILD_SA within an existing IKE_SA, create a new, + equivalent SA (see Section 2.17 below), and when the new one is + established, delete the old one. To rekey an IKE_SA, establish a new + equivalent IKE_SA (see Section 2.18 below) with the peer to whom the + old IKE_SA is shared using a CREATE_CHILD_SA within the existing + IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's + CHILD_SAs, and the new IKE_SA is used for all control messages needed + to maintain those CHILD_SAs. The old IKE_SA is then deleted, and the + Delete payload to delete itself MUST be the last request sent over + the old IKE_SA. + + {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the + new SA should be established before the old one expires and becomes + unusable. Enough time should elapse between the time the new SA is + established and the old one becomes unusable so that traffic can be + switched over to the new SA. + + A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes + were negotiated. In IKEv2, each end of the SA is responsible for + enforcing its own lifetime policy on the SA and rekeying the SA when + necessary. If the two ends have different lifetime policies, the end + with the shorter lifetime will end up always being the one to request + the rekeying. If an SA has been inactive for a long time and if an + + + +Kaufman, et al. Expires August 28, 2008 [Page 31] + +Internet-Draft IKEv2bis February 2008 + + + endpoint would not initiate the SA in the absence of traffic, the + endpoint MAY choose to close the SA instead of rekeying it when its + lifetime expires. {{ Demoted the SHOULD }} It should do so if there + has been no traffic since the last time the SA was rekeyed. + + Note that IKEv2 deliberately allows parallel SAs with the same + traffic selectors between common endpoints. One of the purposes of + this is to support traffic quality of service (QoS) differences among + the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of + [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints + and the traffic selectors may not uniquely identify an SA between + those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on + the basis of duplicate traffic selectors SHOULD NOT be used. + + {{ Demoted the SHOULD }} The node that initiated the surviving + rekeyed SA should delete the replaced SA after the new one is + established. + + There are timing windows -- particularly in the presence of lost + packets -- where endpoints may not agree on the state of an SA. The + responder to a CREATE_CHILD_SA MUST be prepared to accept messages on + an SA before sending its response to the creation request, so there + is no ambiguity for the initiator. The initiator MAY begin sending + on an SA as soon as it processes the response. The initiator, + however, cannot receive on a newly created SA until it receives and + processes the response to its CREATE_CHILD_SA request. How, then, is + the responder to know when it is OK to send on the newly created SA? + + From a technical correctness and interoperability perspective, the + responder MAY begin sending on an SA as soon as it sends its response + to the CREATE_CHILD_SA request. In some situations, however, this + could result in packets unnecessarily being dropped, so an + implementation MAY defer such sending. + + The responder can be assured that the initiator is prepared to + receive messages on an SA if either (1) it has received a + cryptographically valid message on the new SA, or (2) the new SA + rekeys an existing SA and it receives an IKE request to close the + replaced SA. When rekeying an SA, the responder continues to send + traffic on the old SA until one of those events occurs. When + establishing a new SA, the responder MAY defer sending messages on a + new SA until either it receives one or a timeout has occurred. {{ + Demoted the SHOULD }} If an initiator receives a message on an SA for + which it has not received a response to its CREATE_CHILD_SA request, + it interprets that as a likely packet loss and retransmits the + CREATE_CHILD_SA request. An initiator MAY send a dummy message on a + newly created SA if it has no messages queued in order to assure the + responder that the initiator is ready to receive messages. + + + +Kaufman, et al. Expires August 28, 2008 [Page 32] + +Internet-Draft IKEv2bis February 2008 + + + {{ Clarif-5.9 }} Throughout this 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. The + "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 initiator" of the new IKE_SA. + +2.8.1. Simultaneous CHILD_SA rekeying + + {{ The first two paragraphs were moved, and the rest was added, based + on Clarif-5.11 }} + + 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. {{ Clarif-5.10 }} + "Lowest" means 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. + + The following is an explanation on the impact this has on + implementations. 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. + + + +Kaufman, et al. Expires August 28, 2008 [Page 33] + +Internet-Draft IKEv2bis February 2008 + + + send resp2: SA(..,SPIa3,..), + Nr1,.. --> + --> recv req1 + + Now B also knows that simultaneous rekeying is going on. It responds + as usual. + + <-- send resp1: SA(..,SPIb3,..), + Nr2,.. + recv resp1 <-- + --> recv resp2 + + At this point, there are three CHILD_SA pairs between A and B (the + old one and two new ones). A and B can now compare the nonces. + Suppose that the lowest nonce was Nr1 in message resp2; in this case, + B (the sender of req2) deletes the redundant new SA, and A (the node + that initiated the surviving rekeyed SA), deletes the old one. + + send req3: D(SPIa1) --> + <-- send req4: D(SPIb2) + --> recv req3 + <-- send resp3: 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 + + + + +Kaufman, et al. Expires August 28, 2008 [Page 34] + +Internet-Draft IKEv2bis February 2008 + + + 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 there was + simultaneous rekeying. However, A will continue retransmitting the + message, and eventually it will reach B. + + resend req1 --> + --> recv req1 + + To B, it looks like A is trying to rekey an SA that no longer exists; + thus, B responds to the request with something non-fatal such as + NO_PROPOSAL_CHOSEN. + + <-- 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. + +2.8.2. Rekeying the IKE_SA Versus Reauthentication + + {{ Added this section from Clarif-5.2 }} + + 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). + + Although 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 + + + +Kaufman, et al. Expires August 28, 2008 [Page 35] + +Internet-Draft IKEv2bis February 2008 + + + request reauthentication in this case; however, there are extensions + that add this functionality such as [REAUTH]. + +2.9. Traffic Selector Negotiation + + {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives + an IP packet and matches a "protect" selector in its Security Policy + Database (SPD), the subsystem protects that packet with IPsec. When + no SA exists yet, it is the task of IKE to create it. Maintenance of + a system's SPD is outside the scope of IKE (see [PFKEY] for an + example protocol), though some implementations might update their SPD + in connection with the running of IKE (for an example scenario, see + Section 1.1.3). + + Traffic Selector (TS) payloads allow endpoints to communicate some of + the information from their SPD to their peers. TS payloads specify + the selection criteria for packets that will be forwarded over the + newly set up SA. This can serve as a consistency check in some + scenarios to assure that the SPDs are consistent. In others, it + guides the dynamic update of the SPD. + + Two TS payloads appear in each of the messages in the exchange that + creates a CHILD_SA pair. Each TS payload contains one or more + Traffic Selectors. Each Traffic Selector consists of an address + range (IPv4 or IPv6), a port range, and an IP protocol ID. + + The first of the two TS payloads is known as TSi (Traffic Selector- + initiator). The second is known as TSr (Traffic Selector-responder). + TSi specifies the source address of traffic forwarded from (or the + destination address of traffic forwarded to) the initiator of the + CHILD_SA pair. TSr specifies the destination address of the traffic + forwarded to (or the source address of the traffic forwarded from) + the responder of the CHILD_SA pair. For example, if the original + initiator requests the creation of a CHILD_SA pair, and wishes to + tunnel all traffic from subnet 192.0.1.* on the initiator's side to + subnet 192.0.2.* on the responder's side, the initiator would include + a single traffic selector in each TS payload. TSi would specify the + address range (192.0.1.0 - 192.0.1.255) and TSr would specify the + address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was + acceptable to the responder, it would send identical TS payloads + back. (Note: The IP address range 192.0.2.* has been reserved for + use in examples in RFCs and similar documents. This document needed + two such ranges, and so also used 192.0.1.*. This should not be + confused with any actual address.) + + IKEv2 allows the responder to choose a subset of the traffic proposed + by the initiator. This could happen when the configurations of the + two endpoints are being updated but only one end has received the new + + + +Kaufman, et al. Expires August 28, 2008 [Page 36] + +Internet-Draft IKEv2bis February 2008 + + + information. Since the two endpoints may be configured by different + people, the incompatibility may persist for an extended period even + in the absence of errors. It also allows for intentionally different + configurations, as when one end is configured to tunnel all addresses + and depends on the other end to have the up-to-date list. + + When the responder chooses a subset of the traffic proposed by the + initiator, it narrows the traffic selectors to some subset of the + initiator's proposal (provided the set does not become the null set). + + To enable the responder to choose the appropriate range in this case, + if the initiator has requested the SA due to a data packet, the + initiator SHOULD include as the first traffic selector in each of TSi + and TSr a very specific traffic selector including the addresses in + the packet triggering the request. In the example, the initiator + would include in TSi two traffic selectors: the first containing the + address range (192.0.1.43 - 192.0.1.43) and the source port and IP + protocol from the packet and the second containing (192.0.1.0 - + 192.0.1.255) with all ports and IP protocols. The initiator would + similarly include two traffic selectors in TSr. If the initiator + creates the CHILD_SA pair not in response to an arriving packet, but + rather, say, upon startup, then there may be no specific addresses + the initiator prefers for the initial tunnel over any other. In that + case, the first values in TSi and TSr can be ranges rather than + specific values. + + The responder performs the narrowing as follows: {{ Clarif-4.10 }} + + o If the responder's policy does not allow it to accept any part of + the proposed traffic selectors, it responds with TS_UNACCEPTABLE. + + o If the responder's policy allows the entire set of traffic covered + by TSi and TSr, no narrowing is necessary, and the responder can + return the same TSi and TSr values. + + o If the responder's policy allows it to accept the first selector + of TSi and TSr, then the responder MUST narrow the traffic + selectors to a subset that includes the initiator's first choices. + In this example above, the responder might respond with TSi being + (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. + + o If the responder's policy does not allow it to accept the first + selector of TSi and TSr, the responder narrows to an acceptable + subset of TSi and TSr. + + When narrowing is done, there may be several subsets that are + acceptable but their union is not. In this case, the responder + arbitrarily chooses one of them, and MAY include an + + + +Kaufman, et al. Expires August 28, 2008 [Page 37] + +Internet-Draft IKEv2bis February 2008 + + + ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 + }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder + narrowed the proposed traffic selectors but that other traffic + selectors would also have been acceptable, though only in a separate + SA. There is no data associated with this Notify type. This case + will occur only when the initiator and responder are configured + differently from one another. If the initiator and responder agree + on the granularity of tunnels, the initiator will never request a + tunnel wider than the responder will accept. {{ Demoted the SHOULD }} + Such misconfigurations should be recorded in error logs. + + It is possible for the responder's policy to contain multiple smaller + ranges, all encompassed by the initiator's traffic selector, and with + the responder's policy being that each of those ranges should be sent + over a different SA. Continuing the example above, the responder + might have a policy of being willing to tunnel those addresses to and + from the initiator, but might require that each address pair be on a + separately negotiated CHILD_SA. If the initiator generated its + request in response to an incoming packet from 192.0.1.43 to + 192.0.2.123, there would be no way for the responder to determine + which pair of addresses should be included in this tunnel, and it + would have to make a guess or reject the request with a status of + SINGLE_PAIR_REQUIRED. + + {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a + CREATE_CHILD_SA request is unacceptable because its sender is only + willing to accept traffic selectors specifying a single pair of + addresses. The requestor is expected to respond by requesting an SA + for only the specific traffic it is trying to forward. + + {{ Clarif-4.11 }} Few implementations will have policies that require + separate SAs for each address pair. Because of this, if only some + parts of the TSi and TSr proposed by the initiator are acceptable to + the responder, responders SHOULD narrow the selectors to an + acceptable subset rather than use SINGLE_PAIR_REQUIRED. + +2.9.1. Traffic Selectors Violating Own Policy + + {{ Clarif-4.12 }} + + When creating a new SA, the initiator needs to avoid proposing + traffic selectors that violate its own policy. If this rule is not + followed, valid traffic may be dropped. + + This is best illustrated by an example. Suppose that host A has a + policy whose effect is that traffic to 192.0.1.66 is sent via host B + encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 + is also sent via B, but must use 3DES. Suppose also that host B + + + +Kaufman, et al. Expires August 28, 2008 [Page 38] + +Internet-Draft IKEv2bis February 2008 + + + 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.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'. + +2.10. Nonces + + The IKE_SA_INIT messages each contain a nonce. These nonces are used + as inputs to cryptographic functions. The CREATE_CHILD_SA request + and the CREATE_CHILD_SA response also contain nonces. These nonces + are used to add freshness to the key derivation technique used to + obtain keys for CHILD_SA, and to ensure creation of strong pseudo- + random bits from the Diffie-Hellman key. 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. ("prf" refers to + "pseudo-random function", one of the cryptographic algorithms + negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the + initiator chooses the nonce before the outcome of the negotiation is + known. Because of that, the nonce has to be long enough for all the + PRFs being proposed. If the same random number source is used for + both keys and nonces, care must be taken to ensure that the latter + use does not compromise the former. + +2.11. Address and Port Agility + + IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and + AH associations for the same IP addresses it runs over. The IP + addresses and ports in the outer header are, however, not themselves + cryptographically protected, and IKE is designed to work even through + Network Address Translation (NAT) boxes. An implementation MUST + accept incoming requests even if the source port is not 500 or 4500, + and MUST respond to the address and port from which the request was + received. It MUST specify the address and port at which the request + was received as the source address and port in the response. IKE + + + +Kaufman, et al. Expires August 28, 2008 [Page 39] + +Internet-Draft IKEv2bis February 2008 + + + functions identically over IPv4 or IPv6. + +2.12. Reuse of Diffie-Hellman Exponentials + + IKE generates keying material using an ephemeral Diffie-Hellman + exchange in order to gain the property of "perfect forward secrecy". + This means that once a connection is closed and its corresponding + keys are forgotten, even someone who has recorded all of the data + from the connection and gets access to all of the long-term keys of + the two endpoints cannot reconstruct the keys used to protect the + conversation without doing a brute force search of the session key + space. + + Achieving perfect forward secrecy requires that when a connection is + closed, each endpoint MUST forget not only the keys used by the + connection but also any information that could be used to recompute + those keys. In particular, it MUST forget the secrets used in the + Diffie-Hellman calculation and any state that may persist in the + state of a pseudo-random number generator that could be used to + recompute the Diffie-Hellman secrets. + + Since the computing of Diffie-Hellman exponentials is computationally + expensive, an endpoint may find it advantageous to reuse those + exponentials for multiple connection setups. There are several + reasonable strategies for doing this. An endpoint could choose a new + exponential only periodically though this could result in less-than- + perfect forward secrecy if some connection lasts for less than the + lifetime of the exponential. Or it could keep track of which + exponential was used for each connection and delete the information + associated with the exponential only when some corresponding + connection was closed. This would allow the exponential to be reused + without losing perfect forward secrecy at the cost of maintaining + more state. + + Decisions as to whether and when to reuse Diffie-Hellman exponentials + is a private decision in the sense that it will not affect + interoperability. An implementation that reuses exponentials MAY + choose to remember the exponential used by the other endpoint on past + exchanges and if one is reused to avoid the second half of the + calculation. + +2.13. Generating Keying Material + + In the context of the IKE_SA, four cryptographic algorithms are + negotiated: an encryption algorithm, an integrity protection + algorithm, a Diffie-Hellman group, and a pseudo-random function + (prf). The pseudo-random function is used for the construction of + keying material for all of the cryptographic algorithms used in both + + + +Kaufman, et al. Expires August 28, 2008 [Page 40] + +Internet-Draft IKEv2bis February 2008 + + + the IKE_SA and the CHILD_SAs. + + We assume that each encryption algorithm and integrity protection + algorithm uses a fixed-size key and that any randomly chosen value of + that fixed size can serve as an appropriate key. For algorithms that + accept a variable length key, a fixed key size MUST be specified as + part of the cryptographic transform negotiated (see Section 3.3.5 for + the defintion of the Key Length transform attribute). For algorithms + for which not all values are valid keys (such as DES or 3DES with key + parity), the algorithm by which keys are derived from arbitrary + values MUST be specified by the cryptographic transform. For + integrity protection functions based on Hashed Message Authentication + Code (HMAC), the fixed key size is the size of the output of the + underlying hash function. + + It is assumed that pseudo-random functions (PRFs) accept keys of any + length, but have a preferred key size. The preferred key size is + used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For + PRFs based on the HMAC construction, the preferred key size is equal + to the length of the output of the underlying hash function. Other + types of PRFs MUST specify their preferred key size. + + Keying material will always be derived as the output of the + negotiated prf algorithm. Since the amount of keying material needed + may be greater than the size of the output of the prf algorithm, we + will use the prf iteratively. We will use the terminology prf+ to + describe the function that outputs a pseudo-random stream based on + the inputs to a prf as follows: (where | indicates concatenation) + + prf+ (K,S) = T1 | T2 | T3 | T4 | ... + + where: + T1 = prf (K, S | 0x01) + T2 = prf (K, T1 | S | 0x02) + T3 = prf (K, T2 | S | 0x03) + T4 = prf (K, T3 | S | 0x04) + + continuing as needed to compute all required keys. The keys are + taken from the output string without regard to boundaries (e.g., if + the required keys are a 256-bit Advanced Encryption Standard (AES) + key and a 160-bit HMAC key, and the prf function generates 160 bits, + the AES key will come from T1 and the beginning of T2, while the HMAC + key will come from the rest of T2 and the beginning of T3). + + The constant concatenated to the end of each string feeding the prf + is a single octet. prf+ in this document is not defined beyond 255 + times the size of the prf output. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 41] + +Internet-Draft IKEv2bis February 2008 + + +2.14. Generating Keying Material for the IKE_SA + + The shared keys are computed as follows. A quantity called SKEYSEED + is calculated from the nonces exchanged during the IKE_SA_INIT + exchange and the Diffie-Hellman shared secret established during that + exchange. SKEYSEED is used to calculate seven other secrets: SK_d + used for deriving new keys for the CHILD_SAs established with this + IKE_SA; SK_ai and SK_ar used as a key to the integrity protection + algorithm for authenticating the component messages of subsequent + exchanges; SK_ei and SK_er used for encrypting (and of course + decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are + used when generating an AUTH payload. The lengths of SK_d, SK_pi, + and SK_pr are the preferred key length of the agreed-to PRF. + + SKEYSEED and its derivatives are computed as follows: + + SKEYSEED = prf(Ni | Nr, g^ir) + + {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } + = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) + + (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, + SK_pi, and SK_pr are taken in order from the generated bits of the + prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman + exchange. g^ir is represented as a string of octets in big endian + order padded with zeros if necessary to make it the length of the + modulus. Ni and Nr are the nonces, stripped of any headers. For + historical backwards-compatibility reasons, there are two PRFs that + are treated specially in this calculation. If the negotiated PRF is + AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the + first 64 bits of Ni and the first 64 bits of Nr are used in the + calculation. + + The two directions of traffic flow use different keys. The keys used + to protect messages from the original initiator are SK_ai and SK_ei. + The keys used to protect messages in the other direction are SK_ar + and SK_er. + +2.15. Authentication of the IKE_SA + + When not using extensible authentication (see Section 2.16), the + peers are authenticated by having each sign (or MAC using a shared + secret as the key) a block of data. For the responder, the octets to + be signed start with the first octet of the first SPI in the header + of the second message (IKE_SA_INIT response) and end with the last + octet of the last payload in the second message. Appended to this + (for purposes of computing the signature) are the initiator's nonce + Ni (just the value, not the payload containing it), and the value + + + +Kaufman, et al. Expires August 28, 2008 [Page 42] + +Internet-Draft IKEv2bis February 2008 + + + prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding + the fixed header. Note that neither the nonce Ni nor the value + prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the + first message (IKE_SA_INIT request), starting with the first octet of + the first SPI in the header and ending with the last octet of the + last payload. Appended to this (for purposes of computing the + signature) are the responder's nonce Nr, and the value + prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the + entire ID payloads excluding the fixed header. It is critical to the + security of the exchange that each side sign the other side's nonce. + + {{ Clarif-3.1 }} + + 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) + + Note that all of the payloads are included under the signature, + including any payload types not defined in this document. If the + first message of the exchange is sent twice (the second time with a + responder cookie and/or a different Diffie-Hellman group), it is the + second version of the message that is signed. + + Optionally, messages 3 and 4 MAY include a certificate, or + certificate chain providing evidence that the key used to compute a + digital signature belongs to the name in the ID payload. The + signature or MAC will be computed using algorithms dictated by the + type of key used by the signer, and specified by the Auth Method + field in the Authentication payload. There is no requirement that + the initiator and responder sign with the same cryptographic + + + +Kaufman, et al. Expires August 28, 2008 [Page 43] + +Internet-Draft IKEv2bis February 2008 + + + algorithms. The choice of cryptographic algorithms depends on the + type of key each has. In particular, the initiator may be using a + shared key while the responder may have a public signature key and + certificate. It will commonly be the case (but it is not required) + that if a shared secret is used for authentication that the same key + is used in both directions. + + Note that it is a common but typically insecure practice to have a + shared key derived solely from a user-chosen password without + incorporating another source of randomness. This is typically + insecure because user-chosen passwords are unlikely to have + sufficient unpredictability to resist dictionary attacks and these + attacks are not prevented in this authentication method. + (Applications using password-based authentication for bootstrapping + and IKE_SA should use the authentication method in Section 2.16, + which is designed to prevent off-line dictionary attacks.) {{ Demoted + the SHOULD }} The pre-shared key needs to contain as much + unpredictability as the strongest key being negotiated. In the case + of a pre-shared key, the AUTH value is computed as: + + AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), ) + + where the string "Key Pad for IKEv2" is 17 ASCII characters without + null termination. The shared secret can be variable length. The pad + string is added so that if the shared secret is derived from a + password, the IKE implementation need not store the password in + cleartext, but rather can store the value prf(Shared Secret,"Key Pad + for IKEv2"), which could not be used as a password equivalent for + protocols other than IKEv2. As noted above, deriving the shared + secret from a password is not secure. This construction is used + because it is anticipated that people will do it anyway. The + management interface by which the Shared Secret is provided MUST + accept ASCII strings of at least 64 octets and MUST NOT add a null + terminator before using them as shared secrets. It MUST also accept + a hex encoding of the Shared Secret. The management interface MAY + accept other encodings if the algorithm for translating the encoding + to a binary string is specified. + +2.16. Extensible Authentication Protocol Methods + + In addition to authentication using public key signatures and shared + secrets, IKE supports authentication using methods defined in RFC + 3748 [EAP]. Typically, these methods are asymmetric (designed for a + user authenticating to a server), and they may not be mutual. {{ In + the next sentence, changed "public key signature based" to "strong" + }} For this reason, these protocols are typically used to + authenticate the initiator to the responder and MUST be used in + conjunction with a strong authentication of the responder to the + + + +Kaufman, et al. Expires August 28, 2008 [Page 44] + +Internet-Draft IKEv2bis February 2008 + + + initiator. These methods are often associated with mechanisms + referred to as "Legacy Authentication" mechanisms. + + While this memo references [EAP] with the intent that new methods can + be added in the future without updating this specification, some + simpler variations are documented here and in Section 3.16. [EAP] + defines an authentication protocol requiring a variable number of + messages. Extensible Authentication is implemented in IKE as + additional IKE_AUTH exchanges that MUST be completed in order to + initialize the IKE_SA. + + An initiator indicates a desire to use extensible authentication by + leaving out the AUTH payload from message 3. By including an IDi + payload but not an AUTH payload, the initiator has declared an + identity but has not proven it. If the responder is willing to use + an extensible authentication method, it will place an Extensible + Authentication Protocol (EAP) payload in message 4 and defer sending + SAr2, TSi, and TSr until initiator authentication is complete in a + subsequent IKE_AUTH exchange. In the case of a minimal extensible + authentication, the initial SA establishment will appear as follows: + + Initiator Responder + ------------------------------------------------------------------- + HDR, SAi1, KEi, Ni --> + <-- HDR, SAr1, KEr, Nr, [CERTREQ] + HDR, SK {IDi, [CERTREQ,] + [IDr,] SAi2, + TSi, TSr} --> + <-- HDR, SK {IDr, [CERT,] AUTH, + EAP } + HDR, SK {EAP} --> + <-- HDR, SK {EAP (success)} + HDR, SK {AUTH} --> + <-- HDR, SK {AUTH, SAr2, TSi, TSr } + + {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each + pair of IKE_SA initial setup messages will have their message numbers + incremented; the first pair of AUTH messages will have an ID of 1, + the second will be 2, and so on. + + For EAP methods that create a shared key as a side effect of + authentication, that shared key MUST be used by both the initiator + and responder to generate AUTH payloads in messages 7 and 8 using the + syntax for shared secrets specified in Section 2.15. The shared key + from EAP is the field from the EAP specification named MSK. The + shared key generated during an IKE exchange MUST NOT be used for any + other purpose. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 45] + +Internet-Draft IKEv2bis February 2008 + + + EAP methods that do not establish a shared key SHOULD NOT be used, as + they are subject to a number of man-in-the-middle attacks [EAPMITM] + if these EAP methods are used in other protocols that do not use a + server-authenticated tunnel. Please see the Security Considerations + section for more details. If EAP methods that do not generate a + shared key are used, the AUTH payloads in messages 7 and 8 MUST be + generated using SK_pi and SK_pr, respectively. + + {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs + to be capable of extending the initial protocol exchange to at least + ten IKE_AUTH exchanges in the event the responder sends notification + messages and/or retries the authentication prompt. Once the protocol + exchange defined by the chosen EAP authentication method has + successfully terminated, the responder MUST send an EAP payload + containing the Success message. Similarly, if the authentication + method has failed, the responder MUST send an EAP payload containing + the Failure message. The responder MAY at any time terminate the IKE + exchange by sending an EAP payload containing the Failure message. + + Following such an extended exchange, the EAP AUTH payloads MUST be + included in the two messages following the one containing the EAP + Success message. + + {{ Clarif-3.5 }} 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. + 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. In this case, the authenticated identity has to be sent + from the AAA server to the IKEv2 responder. + +2.17. Generating Keying Material for CHILD_SAs + + A single CHILD_SA is created by the IKE_AUTH exchange, and additional + CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. + Keying material for them is generated as follows: + + KEYMAT = prf+(SK_d, Ni | Nr) + + Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this + request is the first CHILD_SA created or the fresh Ni and Nr from the + CREATE_CHILD_SA exchange if this is a subsequent creation. + + For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman + exchange, the keying material is defined as: + + + + +Kaufman, et al. Expires August 28, 2008 [Page 46] + +Internet-Draft IKEv2bis February 2008 + + + KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) + + where g^ir (new) is the shared secret from the ephemeral Diffie- + Hellman exchange of this CREATE_CHILD_SA exchange (represented as an + octet string in big endian order padded with zeros in the high-order + bits if necessary to make it the length of the modulus). + + For ESP and AH, a single CHILD_SA negotiation results in two security + associations (one in each direction). Keying material MUST be taken + from the expanded KEYMAT in the following order: + + o The encryption key (if any) for the SA carrying data from the + initiator to the responder. + + o The authentication key (if any) for the SA carrying data from the + initiator to the responder. + + o The encryption key (if any) for the SA carrying data from the + responder to the initiator. + + o The authentication key (if any) for the SA carrying data from the + responder to the initiator. + + Each cryptographic algorithm takes a fixed number of bits of keying + material specified as part of the algorithm, or negotiated in SA + payloads (see Section 2.13 for description of key lengths, and + Section 3.3.5 for the definition of the Key Length transform + attribute). + +2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange + + The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA + (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs + are supplied in the SPI fields in the Proposal structures inside the + Security Association (SA) payloads (not the SPI fields in the IKE + header). The TS payloads are omitted when rekeying an IKE_SA. + 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) + + where g^ir (new) is the shared secret from the ephemeral Diffie- + Hellman exchange of this CREATE_CHILD_SA exchange (represented as an + octet string in big endian order padded with zeros if necessary to + make it the length of the modulus) and Ni and Nr are the two nonces + stripped of any headers. + + {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different + + + +Kaufman, et al. Expires August 28, 2008 [Page 47] + +Internet-Draft IKEv2bis February 2008 + + + PRF. Because the rekeying exchange belongs to the old IKE_SA, it is + the old IKE_SA's PRF that is used. + + {{ Clarif-5.12}} 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. Therefore, + implementations SHOULD perform a new Diffie-Hellman exchange when + rekeying the IKE_SA. In other words, an initiator SHOULD NOT propose + the value "NONE" for the D-H transform, and a responder SHOULD NOT + accept such a proposal. This means that a succesful exchange + rekeying the IKE_SA always includes the KEi/KEr payloads. + + The new IKE_SA MUST reset its message counters to 0. + + SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as + specified in Section 2.14. + +2.19. Requesting an Internal Address on a Remote Network + + Most commonly occurring in the endpoint-to-security-gateway scenario, + an endpoint may need an IP address in the network protected by the + security gateway and may need to have that address dynamically + assigned. A request for such a temporary address can be included in + any request to create a CHILD_SA (including the implicit request in + message 3) by including a CP payload. + + This function provides address allocation to an IPsec Remote Access + Client (IRAC) trying to tunnel into a network protected by an IPsec + Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an + IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled + address (and optionally other information concerning the protected + network) in the IKE_AUTH exchange. The IRAS may procure an address + for the IRAC from any number of sources such as a DHCP/BOOTP server + or its own address pool. + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK {IDi, [CERT,] + [CERTREQ,] [IDr,] AUTH, + CP(CFG_REQUEST), SAi2, + TSi, TSr} --> + <-- HDR, SK {IDr, [CERT,] AUTH, + CP(CFG_REPLY), SAr2, + TSi, TSr} + + In all cases, the CP payload MUST be inserted before the SA payload. + In variations of the protocol where there are multiple IKE_AUTH + exchanges, the CP payloads MUST be inserted in the messages + + + +Kaufman, et al. Expires August 28, 2008 [Page 48] + +Internet-Draft IKEv2bis February 2008 + + + containing the SA payloads. + + CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute + (either IPv4 or IPv6) but MAY contain any number of additional + attributes the initiator wants returned in the response. + + {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by + responder in the case where CP(CFG_REQUEST) was expected but not + received, and so is a conflict with locally configured policy. There + is no associated data. + + For example, message from initiator to responder: + + CP(CFG_REQUEST)= + INTERNAL_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) + + NOTE: Traffic Selectors contain (protocol, port range, address + range). + + Message from responder to initiator: + + CP(CFG_REPLY)= + INTERNAL_ADDRESS(192.0.2.202) + INTERNAL_NETMASK(255.255.255.0) + INTERNAL_SUBNET(192.0.2.0/255.255.255.0) + TSi = (0, 0-65535,192.0.2.202-192.0.2.202) + TSr = (0, 0-65535,192.0.2.0-192.0.2.255) + + All returned values will be implementation dependent. As can be seen + in the above example, the IRAS MAY also send other attributes that + were not included in CP(CFG_REQUEST) and MAY ignore the non- + mandatory attributes that it does not support. + + The responder MUST NOT send a CFG_REPLY without having first received + a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS + to perform an unnecessary configuration lookup if the IRAC cannot + process the REPLY. In the case where the IRAS's configuration + requires that CP be used for a given identity IDi, but IRAC has + failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and + terminate the IKE exchange with a FAILED_CP_REQUIRED error. + +2.19.1. Configuration Payloads + + Editor's note: some of this sub-section is redundant and will go away + in the next version of the document. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 49] + +Internet-Draft IKEv2bis February 2008 + + + 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. {{ Clarif-6.1 }} That request is done using + configuration payloads, not traffic selectors. 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. + + Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ + CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST + and CFG_SET payloads may optionally be added to any IKE request. The + IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK + or a Notify payload with an error type indicating why the request + could not be honored. An exception is that a minimal implementation + MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response + message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted + as an indication that the request was not supported. + + "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information + from its peer. If an attribute in the CFG_REQUEST Configuration + Payload is not zero-length, it is taken as a suggestion for that + attribute. The CFG_REPLY Configuration Payload MAY return that + value, or a new one. It MAY also add new attributes and not include + some requested ones. Requestors MUST ignore returned attributes that + they do not recognize. + + Some attributes MAY be multi-valued, in which case multiple attribute + values of the same type are sent and/or returned. Generally, all + values of an attribute are returned when the attribute is requested. + For some attributes (in this version of the specification only + internal addresses), multiple requests indicates a request that + multiple values be assigned. For these attributes, the number of + values returned SHOULD NOT exceed the number requested. + + If the data type requested in a CFG_REQUEST is not recognized or not + supported, the responder MUST NOT return an error type but rather + MUST either send a CFG_REPLY that MAY be empty or a reply not + containing a CFG_REPLY payload at all. Error returns are reserved + for cases where the request is recognized but cannot be performed as + requested or the request is badly formatted. + + "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data + to its peer. In this case, the CFG_SET Configuration Payload + contains attributes the initiator wants its peer to alter. The + responder MUST return a Configuration Payload if it accepted any of + the configuration data and it MUST contain the attributes that the + responder accepted with zero-length data. Those attributes that it + + + +Kaufman, et al. Expires August 28, 2008 [Page 50] + +Internet-Draft IKEv2bis February 2008 + + + did not accept MUST NOT be in the CFG_ACK Configuration Payload. If + no attributes were accepted, the responder MUST return either an + empty CFG_ACK payload or a response message without a CFG_ACK + payload. There are currently no defined uses for the CFG_SET/CFG_ACK + exchange, though they may be used in connection with extensions based + on Vendor IDs. An minimal implementation of this specification MAY + ignore CFG_SET payloads. + + {{ Demoted the SHOULD }} Extensions via the CP payload should not be + used for general purpose management. Its main intent is to provide a + bootstrap mechanism to exchange information within IPsec from IRAS to + IRAC. While it MAY be useful to use such a method to exchange + information between some Security Gateways (SGW) or small networks, + existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], + SNMP, or LDAP [LDAP] should be preferred for enterprise management as + well as subsequent information exchanges. + +2.20. Requesting the Peer's Version + + An IKE peer wishing to inquire about the other peer's IKE software + version information MAY use the method below. This is an example of + a configuration request within an INFORMATIONAL exchange, after the + IKE_SA and first CHILD_SA have been created. + + An IKE implementation MAY decline to give out version information + prior to authentication or even after authentication to prevent + trolling in case some implementation is known to have some security + weakness. In that case, it MUST either return an empty string or no + CP payload if CP is not supported. + + Initiator Responder + ------------------------------------------------------------------- + HDR, SK{CP(CFG_REQUEST)} --> + <-- HDR, SK{CP(CFG_REPLY)} + + CP(CFG_REQUEST)= + APPLICATION_VERSION("") + + CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar + Inc.") + +2.21. Error Handling + + There are many kinds of errors that can occur during IKE processing. + If a request is received that is badly formatted or unacceptable for + reasons of policy (e.g., no matching cryptographic algorithms), the + response MUST contain a Notify payload indicating the error. If an + error occurs outside the context of an IKE request (e.g., the node is + + + +Kaufman, et al. Expires August 28, 2008 [Page 51] + +Internet-Draft IKEv2bis February 2008 + + + getting ESP messages on a nonexistent SPI), the node SHOULD initiate + an INFORMATIONAL exchange with a Notify payload describing the + problem. + + Errors that occur before a cryptographically protected IKE_SA is + established must be handled very carefully. There is a trade-off + between wanting to be helpful in diagnosing a problem and responding + to it and wanting to avoid being a dupe in a denial of service attack + based on forged messages. + + If a node receives a message on UDP port 500 or 4500 outside the + context of an IKE_SA known to it (and not a request to start one), it + may be the result of a recent crash of the node. If the message is + marked as a response, the node MAY audit the suspicious event but + MUST NOT respond. If the message is marked as a request, the node + MAY audit the suspicious event and MAY send a response. 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. The response MUST NOT be cryptographically protected and + MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 + }} The INVALID_IKE_SPI notification indicates an IKE message was + received with an unrecognized destination SPI; this usually indicates + that the recipient has rebooted and forgotten the existence of an + IKE_SA. + + A node receiving such an unprotected Notify payload MUST NOT respond + and MUST NOT change the state of any existing SAs. The message might + be a forgery or might be a response the genuine correspondent was + tricked into sending. {{ Demoted two SHOULDs }} A node should treat + such a message (and also a network message like ICMP destination + unreachable) as a hint that there might be problems with SAs to that + IP address and should initiate a liveness test for any such IKE_SA. + An implementation SHOULD limit the frequency of such tests to avoid + being tricked into participating in a denial of service attack. + + A node receiving a suspicious message from an IP address with which + it has an IKE_SA MAY send an IKE Notify payload in an IKE + INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The + recipient MUST NOT change the state of any SAs as a result, but may + wish to audit the event to aid in diagnosing malfunctions. A node + MUST limit the rate at which it will send messages in response to + unprotected messages. + +2.22. IPComp + + Use of IP compression [IPCOMP] can be negotiated as part of the setup + of a CHILD_SA. While IP compression involves an extra header in each + packet and a compression parameter index (CPI), the virtual + + + +Kaufman, et al. Expires August 28, 2008 [Page 52] + +Internet-Draft IKEv2bis February 2008 + + + "compression association" has no life outside the ESP or AH SA that + contains it. Compression associations disappear when the + corresponding ESP or AH SA goes away. It is not explicitly mentioned + in any DELETE payload. + + Negotiation of IP compression is separate from the negotiation of + cryptographic parameters associated with a CHILD_SA. A node + requesting a CHILD_SA MAY advertise its support for one or more + compression algorithms through one or more Notify payloads of type + IPCOMP_SUPPORTED. This notification may be included only in a + message containing an SA payload negotiating a CHILD_SA and indicates + a willingness by its sender to use IPComp on this SA. The response + MAY indicate acceptance of a single compression algorithm with a + Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT + occur in messages that do not contain SA payloads. + + {{ 3.10.1-16387 }}The data associated with this notification includes + a two-octet IPComp CPI followed by a one-octet transform ID + optionally followed by attributes whose length and format are defined + by that transform ID. A message proposing an SA may contain multiple + IPCOMP_SUPPORTED notifications to indicate multiple supported + algorithms. A message accepting an SA may contain at most one. + + The transform IDs currently defined are: + + Name Number Defined In + ------------------------------------- + RESERVED 0 + IPCOMP_OUI 1 + IPCOMP_DEFLATE 2 RFC 2394 + IPCOMP_LZS 3 RFC 2395 + IPCOMP_LZJH 4 RFC 3051 + RESERVED TO IANA 5-240 + PRIVATE USE 241-255 + + Although there has been discussion of allowing multiple compression + algorithms to be accepted and to have different compression + algorithms available for the two directions of a CHILD_SA, + implementations of this specification MUST NOT accept an IPComp + algorithm that was not proposed, MUST NOT accept more than one, and + MUST NOT compress using an algorithm other than one proposed and + accepted in the setup of the CHILD_SA. + + A side effect of separating the negotiation of IPComp from + cryptographic parameters is that it is not possible to propose + multiple cryptographic suites and propose IP compression with some of + them but not others. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 53] + +Internet-Draft IKEv2bis February 2008 + + +2.23. NAT Traversal + + Network Address Translation (NAT) gateways are a controversial + subject. This section briefly describes what they are and how they + are likely to act on IKE traffic. Many people believe that NATs are + evil and that we should not design our protocols so as to make them + work better. IKEv2 does specify some unintuitive processing rules in + order that NATs are more likely to work. + + NATs exist primarily because of the shortage of IPv4 addresses, + though there are other rationales. IP nodes that are "behind" a NAT + have IP addresses that are not globally unique, but rather are + assigned from some space that is unique within the network behind the + NAT but that are likely to be reused by nodes behind other NATs. + Generally, nodes behind NATs can communicate with other nodes behind + the same NAT and with nodes with globally unique addresses, but not + with nodes behind other NATs. There are exceptions to that rule. + When those nodes make connections to nodes on the real Internet, the + NAT gateway "translates" the IP source address to an address that + will be routed back to the gateway. Messages to the gateway from the + Internet have their destination addresses "translated" to the + internal address that will route the packet to the correct endnode. + + NATs are designed to be "transparent" to endnodes. Neither software + on the node behind the NAT nor the node on the Internet requires + modification to communicate through the NAT. Achieving this + transparency is more difficult with some protocols than with others. + Protocols that include IP addresses of the endpoints within the + payloads of the packet will fail unless the NAT gateway understands + the protocol and modifies the internal references as well as those in + the headers. Such knowledge is inherently unreliable, is a network + layer violation, and often results in subtle problems. + + Opening an IPsec connection through a NAT introduces special + problems. If the connection runs in transport mode, changing the IP + addresses on packets will cause the checksums to fail and the NAT + cannot correct the checksums because they are cryptographically + protected. Even in tunnel mode, there are routing problems because + transparently translating the addresses of AH and ESP packets + requires special logic in the NAT and that logic is heuristic and + unreliable in nature. For that reason, IKEv2 can negotiate UDP + encapsulation of IKE and ESP packets. This encoding is slightly less + efficient but is easier for NATs to process. In addition, firewalls + may be configured to pass IPsec traffic over UDP but not ESP/AH or + vice versa. + + It is a common practice of NATs to translate TCP and UDP port numbers + as well as addresses and use the port numbers of inbound packets to + + + +Kaufman, et al. Expires August 28, 2008 [Page 54] + +Internet-Draft IKEv2bis February 2008 + + + decide which internal node should get a given packet. For this + reason, even though IKE packets MUST be sent from and to UDP port + 500, they MUST be accepted coming from any port and responses MUST be + sent to the port from whence they came. This is because the ports + may be modified as the packets pass through NATs. Similarly, IP + addresses of the IKE endpoints are generally not included in the IKE + payloads because the payloads are cryptographically protected and + could not be transparently modified by NATs. + + Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working + through a NAT, it is generally better to pass IKE packets over port + 4500 because some older NATs handle IKE traffic on port 500 cleverly + in an attempt to transparently establish IPsec connections between + endpoints that don't handle NAT traversal themselves. Such NATs may + interfere with the straightforward NAT traversal envisioned by this + document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT + between it and its correspondent MUST send all subsequent traffic + from port 4500, which NATs should not treat specially (as they might + with port 500). + + The specific requirements for supporting NAT traversal [NATREQ] are + listed below. Support for NAT traversal is optional. In this + section only, requirements listed as MUST apply only to + implementations supporting NAT traversal. + + o IKE MUST listen on port 4500 as well as port 500. IKE MUST + respond to the IP address and port from which packets arrived. + + o Both IKE initiator and responder MUST include in their IKE_SA_INIT + packets Notify payloads of type NAT_DETECTION_SOURCE_IP and + NAT_DETECTION_DESTINATION_IP. Those payloads can be used to + detect if there is NAT between the hosts, and which end is behind + the NAT. The location of the payloads in the IKE_SA_INIT packets + are just after the Ni and Nr payloads (before the optional CERTREQ + payload). + + o {{ 3.10.1-16388 }} The data associated with the + NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs + (in the order they appear in the header), IP address, and port on + which this packet was sent. There MAY be multiple + NAT_DETECTION_SOURCE_IP payloads in a message if the sender does + not know which of several network attachments will be used to send + the packet. + + o {{ 3.10.1-16389 }} The data associated with the + NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the + SPIs (in the order they appear in the header), IP address, and + port to which this packet was sent. + + + +Kaufman, et al. Expires August 28, 2008 [Page 55] + +Internet-Draft IKEv2bis February 2008 + + + o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the + NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP + notification MAY compare the supplied value to a SHA-1 hash of the + SPIs, source IP address, and port, and if they don't match it + SHOULD enable NAT traversal. In the case of a mismatching + NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the + connection attempt if NAT traversal is not supported. In the case + of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that + the system receiving the NAT_DETECTION_DESTINATION_IP payload is + behind a NAT and that system SHOULD start sending keepalive + packets as defined in [UDPENCAPS]; alternately, it MAY reject the + connection attempt if NAT traversal is not supported. + + o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches + the expected value of the source IP and port found from the IP + header of the packet containing the payload, it means that the + system sending those payloads is behind NAT (i.e., someone along + the route changed the source address of the original packet to + match the address of the NAT box). In this case, the system + receiving the payloads should allow dynamic update of the other + systems' IP address, as described later. + + o If the NAT_DETECTION_DESTINATION_IP payload received does not + match the hash of the destination IP and port found from the IP + header of the packet containing the payload, it means that the + system receiving the NAT_DETECTION_DESTINATION_IP payload is + behind a NAT. In this case, that system SHOULD start sending + keepalive packets as explained in [UDPENCAPS]. + + o 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. + + o 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. To tunnel ESP packets over UDP port 4500, the ESP + header immediately follows the UDP header. Since the first four + octets of the ESP header contain the SPI, and the SPI cannot + validly be zero, it is always possible to distinguish ESP and IKE + messages. + + o Implementations MUST process received UDP-encapsulated ESP packets + even when no NAT was detected. + + o The original source and destination IP address required for the + transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) + are obtained from the Traffic Selectors associated with the + + + +Kaufman, et al. Expires August 28, 2008 [Page 56] + +Internet-Draft IKEv2bis February 2008 + + + exchange. In the case of NAT traversal, the Traffic Selectors + MUST contain exactly one IP address, which is then used as the + original IP address. + + o There are cases where a NAT box decides to remove mappings that + are still alive (for example, the keepalive interval is too long, + or the NAT box is rebooted). To recover in these cases, hosts + that are not behind a NAT SHOULD send all packets (including + retransmission packets) to the IP address and port from the last + valid authenticated packet from the other end (i.e., dynamically + update the address). A host behind a NAT SHOULD NOT do this + because it opens a DoS attack possibility. Any authenticated IKE + packet or any authenticated UDP-encapsulated ESP packet can be + used to detect that the IP address or the port has changed. + + Note that similar but probably not identical actions will likely be + needed to make IKE work with Mobile IP, but such processing is not + addressed by this document. + +2.24. Explicit Congestion Notification (ECN) + + When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], + ECN usage is not appropriate for the outer IP headers because tunnel + decapsulation processing discards ECN congestion indications to the + detriment of the network. ECN support for IPsec tunnels for IKEv1- + based IPsec requires multiple operating modes and negotiation (see + [ECN]). IKEv2 simplifies this situation by requiring that ECN be + usable in the outer IP headers of all tunnel-mode IPsec SAs created + by IKEv2. Specifically, tunnel encapsulators and decapsulators for + all tunnel-mode SAs created by IKEv2 MUST support the ECN full- + functionality option for tunnels specified in [ECN] and MUST + implement the tunnel encapsulation and decapsulation processing + specified in [IPSECARCH] to prevent discarding of ECN congestion + indications. + + +3. Header and Payload Formats + + In the tables in this section, some cryptographic primitives and + configuation attributes are marked as "UNSPECIFIED". These are items + for which there are no known specifications and therefore + interoperability is currently impossible. A future specification may + describe their use, but until such specification is made, + implementations SHOULD NOT attempt to use items marked as + "UNSPECIFIED" in implementations that are meant to be interoperable. + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 57] + +Internet-Draft IKEv2bis February 2008 + + +3.1. The IKE Header + + IKE messages use UDP ports 500 and/or 4500, with one IKE message per + UDP datagram. Information from the beginning of the packet through + the UDP header is largely ignored except that the IP addresses and + UDP ports from the headers are reversed and used for return packets. + When sent on UDP port 500, IKE messages begin immediately following + the UDP header. When sent on UDP port 4500, IKE messages have + prepended four octets of zero. These four octets of zero are not + part of the IKE message and are not included in any of the length + fields or checksums defined by IKE. Each IKE message begins with the + IKE header, denoted HDR in this memo. Following the header are one + or more IKE payloads each identified by a "Next Payload" field in the + preceding payload. Payloads are processed in the order in which they + appear in an IKE message by invoking the appropriate processing + routine according to the "Next Payload" field in the IKE header and + subsequently according to the "Next Payload" field in the IKE payload + itself until a "Next Payload" field of zero indicates that no + payloads follow. If a payload of type "Encrypted" is found, that + payload is decrypted and its contents parsed as additional payloads. + An Encrypted payload MUST be the last payload in a packet and an + Encrypted payload MUST NOT contain another Encrypted payload. + + The Recipient SPI in the header identifies an instance of an IKE + security association. It is therefore possible for a single instance + of IKE to multiplex distinct sessions with multiple peers. + + All multi-octet fields representing integers are laid out in big + endian order (also known as "most significant byte first", or + "network byte order"). + + The format of the IKE header is shown in Figure 4. + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 58] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IKE_SA Initiator's SPI | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IKE_SA Responder's SPI | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload | MjVer | MnVer | Exchange Type | Flags | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: IKE Header Format + + o Initiator's SPI (8 octets) - A value chosen by the initiator to + identify a unique IKE security association. This value MUST NOT + be zero. + + o Responder's SPI (8 octets) - A value chosen by the responder to + identify a unique IKE security association. This value MUST be + zero in the first message of an IKE Initial Exchange (including + repeats of that message including a cookie). {{ The phrase "and + MUST NOT be zero in any other message" was removed; Clarif-2.1 }} + + o Next Payload (1 octet) - Indicates the type of payload that + immediately follows the header. The format and value of each + payload are defined below. + + o Major Version (4 bits) - Indicates the major version of the IKE + protocol in use. Implementations based on this version of IKE + MUST set the Major Version to 2. Implementations based on + previous versions of IKE and ISAKMP MUST set the Major Version to + 1. Implementations based on this version of IKE MUST reject or + ignore messages containing a version number greater than 2. + + o Minor Version (4 bits) - Indicates the minor version of the IKE + protocol in use. Implementations based on this version of IKE + MUST set the Minor Version to 0. They MUST ignore the minor + version number of received messages. + + o Exchange Type (1 octet) - Indicates the type of exchange being + used. This constrains the payloads sent in each message and + orderings of messages in an exchange. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 59] + +Internet-Draft IKEv2bis February 2008 + + + Exchange Type Value + ---------------------------------- + RESERVED 0-33 + IKE_SA_INIT 34 + IKE_AUTH 35 + CREATE_CHILD_SA 36 + INFORMATIONAL 37 + RESERVED TO IANA 38-239 + PRIVATE USE 240-255 + + o Flags (1 octet) - Indicates specific options that are set for the + message. Presence of options are indicated by the appropriate bit + in the flags field being set. The bits are defined LSB first, so + bit 0 would be the least significant bit of the Flags octet. In + the description below, a bit being 'set' means its value is '1', + while 'cleared' means its value is '0'. + + * X(reserved) (bits 0-2) - These bits MUST be cleared when + sending and MUST be ignored on receipt. + + * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages + sent by the original initiator of the IKE_SA and MUST be + cleared in messages sent by the original responder. It is used + by the recipient to determine which eight octets of the SPI + were generated by the recipient. + + * V(ersion) (bit 4 of Flags) - This bit indicates that the + transmitter is capable of speaking a higher major version + number of the protocol than the one indicated in the major + version number field. Implementations of IKEv2 must clear this + bit when sending and MUST ignore it in incoming messages. + + * R(esponse) (bit 5 of Flags) - This bit indicates that this + message is a response to a message containing the same message + ID. This bit MUST be cleared in all request messages and MUST + be set in all responses. An IKE endpoint MUST NOT generate a + response to a message that is marked as being a response. + + * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared + when sending and MUST be ignored on receipt. + + o Message ID (4 octets) - Message identifier used to control + retransmission of lost packets and matching of requests and + responses. It is essential to the security of the protocol + because it is used to prevent message replay attacks. See + Section 2.1 and Section 2.2. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 60] + +Internet-Draft IKEv2bis February 2008 + + + o Length (4 octets) - Length of total message (header + payloads) in + octets. + +3.2. Generic Payload Header + + Each IKE payload defined in Section 3.3 through Section 3.16 begins + with a generic payload header, shown in Figure 5. Figures for each + payload below will include the generic payload header, but for + brevity the description of each field will be omitted. + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Generic Payload Header + + The Generic Payload Header fields are defined as follows: + + o Next Payload (1 octet) - Identifier for the payload type of the + next payload in the message. If the current payload is the last + in the message, then this field will be 0. This field provides a + "chaining" capability whereby additional payloads can be added to + a message by appending it to the end of the message and setting + the "Next Payload" field of the preceding payload to indicate the + new payload's type. An Encrypted payload, which must always be + the last payload of a message, is an exception. It contains data + structures in the format of additional payloads. In the header of + an Encrypted payload, the Next Payload field is set to the payload + type of the first contained payload (instead of 0). The payload + type values are: + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 61] + +Internet-Draft IKEv2bis February 2008 + + + Next Payload Type Notation Value + -------------------------------------------------- + No Next Payload 0 + RESERVED 1-32 + Security Association SA 33 + Key Exchange KE 34 + Identification - Initiator IDi 35 + Identification - Responder IDr 36 + Certificate CERT 37 + Certificate Request CERTREQ 38 + Authentication AUTH 39 + Nonce Ni, Nr 40 + Notify N 41 + Delete D 42 + Vendor ID V 43 + Traffic Selector - Initiator TSi 44 + Traffic Selector - Responder TSr 45 + Encrypted E 46 + Configuration CP 47 + Extensible Authentication EAP 48 + RESERVED TO IANA 49-127 + PRIVATE USE 128-255 + + (Payload type values 1-32 should not be assigned in the + future so that there is no overlap with the code assignments + for IKEv1.) + + o Critical (1 bit) - MUST be set to zero if the sender wants the + recipient to skip this payload if it does not understand the + payload type code in the Next Payload field of the previous + payload. MUST be set to one if the sender wants the recipient to + reject this entire message if it does not understand the payload + type. MUST be ignored by the recipient if the recipient + understands the payload type code. MUST be set to zero for + payload types defined in this document. Note that the critical + bit applies to the current payload rather than the "next" payload + whose type code appears in the first octet. The reasoning behind + not setting the critical bit for payloads defined in this document + is that all implementations MUST understand all payload types + defined in this document and therefore must ignore the Critical + bit's value. Skipped payloads are expected to have valid Next + Payload and Payload Length fields. + + o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on + receipt. + + o Payload Length (2 octets) - Length in octets of the current + payload, including the generic payload header. + + + +Kaufman, et al. Expires August 28, 2008 [Page 62] + +Internet-Draft IKEv2bis February 2008 + + + {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". + Some payloads in IKEv2 (and historically in IKEv1) are not aligned to + 4-octet boundaries. + +3.3. Security Association Payload + + The Security Association Payload, denoted SA in this memo, is used to + negotiate attributes of a security association. Assembly of Security + Association Payloads requires great peace of mind. An SA payload MAY + contain multiple proposals. If there is more than one, they MUST be + ordered from most preferred to least preferred. Each proposal + contains a single IPsec protocol (where a protocol is IKE, ESP, or + AH), each protocol MAY contain multiple transforms, and each + transform MAY contain multiple attributes. When parsing an SA, an + implementation MUST check that the total Payload Length is consistent + with the payload's internal lengths and counts. Proposals, + Transforms, and Attributes each have their own variable length + encodings. They are nested such that the Payload Length of an SA + includes the combined contents of the SA, Proposal, Transform, and + Attribute information. The length of a Proposal includes the lengths + of all Transforms and Attributes it contains. The length of a + Transform includes the lengths of all Attributes it contains. + + The syntax of Security Associations, Proposals, Transforms, and + Attributes is based on ISAKMP; however the semantics are somewhat + different. The reason for the complexity and the hierarchy is to + allow for multiple possible combinations of algorithms to be encoded + in a single SA. Sometimes there is a choice of multiple algorithms, + whereas other times there is a combination of algorithms. For + example, an initiator might want to propose using ESP with either + (3DES and HMAC_MD5) or (AES and HMAC_SHA1). + + One of the reasons the semantics of the SA payload has changed from + ISAKMP and IKEv1 is to make the encodings more compact in common + cases. + + The Proposal structure contains within it a Proposal # and an IPsec + protocol ID. Each structure MUST have a proposal number one (1) + greater than the previous structure. The first Proposal in the + initiator's SA payload MUST have a Proposal # of one (1). A proposal + of AH or ESP would have two proposal structures, one for AH with + Proposal #1 and one for ESP with Proposal #2. + + Each Proposal/Protocol structure is followed by one or more transform + structures. The number of different transforms is generally + determined by the Protocol. AH generally has two transforms: + Extended Sequence Numbers (ESN) and an integrity check algorithm. + ESP generally has three: ESN, an encryption algorithm and an + + + +Kaufman, et al. Expires August 28, 2008 [Page 63] + +Internet-Draft IKEv2bis February 2008 + + + integrity check algorithm. IKE generally has four transforms: a + Diffie-Hellman group, an integrity check algorithm, a prf algorithm, + and an encryption algorithm. If an algorithm that combines + encryption and integrity protection is proposed, it MUST be proposed + as an encryption algorithm and an integrity protection algorithm MUST + NOT be proposed. For each Protocol, the set of permissible + transforms is assigned transform ID numbers, which appear in the + header of each transform. + + If there are multiple transforms with the same Transform Type, the + proposal is an OR of those transforms. If there are multiple + Transforms with different Transform Types, the proposal is an AND of + the different groups. For example, to propose ESP with (3DES or AES- + CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two + Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and + two Transform Type 3 candidates (one for HMAC_MD5 and one for + HMAC_SHA). This effectively proposes four combinations of + algorithms. If the initiator wanted to propose only a subset of + those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there + is no way to encode that as multiple transforms within a single + Proposal. Instead, the initiator would have to construct two + different Proposals, each with two transforms. + + A given transform MAY have one or more Attributes. Attributes are + necessary when the transform can be used in more than one way, as + when an encryption algorithm has a variable key size. The transform + would specify the algorithm and the attribute would specify the key + size. Most transforms do not have attributes. A transform MUST NOT + have multiple attributes of the same type. To propose alternate + values for an attribute (for example, multiple key sizes for the AES + encryption algorithm), and implementation MUST include multiple + Transforms with the same Transform Type each with a single Attribute. + + Note that the semantics of Transforms and Attributes are quite + different from those in IKEv1. In IKEv1, a single Transform carried + multiple algorithms for a protocol with one carried in the Transform + and the others carried in the Attributes. + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Kaufman, et al. Expires August 28, 2008 [Page 64] + +Internet-Draft IKEv2bis February 2008 + + + Figure 6: Security Association Payload + + o Proposals (variable) - One or more proposal substructures. + + The payload type for the Security Association Payload is thirty three + (33). + +3.3.1. Proposal Substructure + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 (last) or 2 | RESERVED | Proposal Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Proposal # | Protocol ID | SPI Size |# of Transforms| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ SPI (variable) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Proposal Substructure + + o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the + last Proposal Substructure in the SA. This syntax is inherited + from ISAKMP, but is unnecessary because the last Proposal could be + identified from the length of the SA. The value (2) corresponds + to a Payload Type of Proposal in IKEv1, and the first four octets + of the Proposal structure are designed to look somewhat like the + header of a Payload. + + o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on + receipt. + + o Proposal Length (2 octets) - Length of this proposal, including + all transforms and attributes that follow. + + o Proposal # (1 octet) - When a proposal is made, the first proposal + in an SA payload MUST be #1, and subsequent proposals MUST be one + more than the previous proposal (indicating an OR of the two + proposals). When a proposal is accepted, the proposal number in + the SA payload MUST match the number on the proposal sent that was + accepted. + + o Protocol ID (1 octet) - Specifies the IPsec protocol identifier + for the current negotiation. The defined values are: + + + +Kaufman, et al. Expires August 28, 2008 [Page 65] + +Internet-Draft IKEv2bis February 2008 + + + Protocol Protocol ID + ----------------------------------- + RESERVED 0 + IKE 1 + AH 2 + ESP 3 + RESERVED TO IANA 4-200 + PRIVATE USE 201-255 + + o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field + MUST be zero; the SPI is obtained from the outer header. During + subsequent negotiations, it is equal to the size, in octets, of + the SPI of the corresponding protocol (8 for IKE, 4 for ESP and + AH). + + o # of Transforms (1 octet) - Specifies the number of transforms in + this proposal. + + o SPI (variable) - The sending entity's SPI. Even if the SPI Size + is not a multiple of 4 octets, there is no padding applied to the + payload. When the SPI Size field is zero, this field is not + present in the Security Association payload. + + o Transforms (variable) - One or more transform substructures. + +3.3.2. Transform Substructure + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 (last) or 3 | RESERVED | Transform Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Transform Type | RESERVED | Transform ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Transform Attributes ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Transform Substructure + + o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the + last Transform Substructure in the Proposal. This syntax is + inherited from ISAKMP, but is unnecessary because the last + Proposal could be identified from the length of the SA. The value + (3) corresponds to a Payload Type of Transform in IKEv1, and the + first four octets of the Transform structure are designed to look + somewhat like the header of a Payload. + + + +Kaufman, et al. Expires August 28, 2008 [Page 66] + +Internet-Draft IKEv2bis February 2008 + + + o RESERVED - MUST be sent as zero; MUST be ignored on receipt. + + o Transform Length - The length (in octets) of the Transform + Substructure including Header and Attributes. + + o Transform Type (1 octet) - The type of transform being specified + in this transform. Different protocols support different + transform types. For some protocols, some of the transforms may + be optional. If a transform is optional and the initiator wishes + to propose that the transform be omitted, no transform of the + given type is included in the proposal. If the initiator wishes + to make use of the transform optional to the responder, it + includes a transform substructure with transform ID = 0 as one of + the options. + + o Transform ID (2 octets) - The specific instance of the transform + type being proposed. + + The tranform type values are: + + Description Trans. Used In + Type + ------------------------------------------------------------------ + RESERVED 0 + Encryption Algorithm (ENCR) 1 IKE and ESP + Pseudo-random Function (PRF) 2 IKE + Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP + Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP + Extended Sequence Numbers (ESN) 5 AH and ESP + RESERVED TO IANA 6-240 + PRIVATE USE 241-255 + + (*) Negotiating an integrity algorithm is mandatory for the + Encrypted payload format specified in this document. Future + documents may specify additional formats based on authenticated + encryption, in which case a separate integrity algorithm is not + negotiated. + + For Transform Type 1 (Encryption Algorithm), defined Transform IDs + are: + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 67] + +Internet-Draft IKEv2bis February 2008 + + + Name Number Defined In + --------------------------------------------------- + RESERVED 0 + ENCR_DES_IV64 1 (UNSPECIFIED) + ENCR_DES 2 (RFC2405), [DES] + ENCR_3DES 3 (RFC2451) + ENCR_RC5 4 (RFC2451) + ENCR_IDEA 5 (RFC2451), [IDEA] + ENCR_CAST 6 (RFC2451) + ENCR_BLOWFISH 7 (RFC2451) + ENCR_3IDEA 8 (UNSPECIFIED) + ENCR_DES_IV32 9 (UNSPECIFIED) + RESERVED 10 + ENCR_NULL 11 (RFC2410) + ENCR_AES_CBC 12 (RFC3602) + ENCR_AES_CTR 13 (RFC3686) + RESERVED TO IANA 14-1023 + PRIVATE USE 1024-65535 + + For Transform Type 2 (Pseudo-random Function), defined Transform IDs + are: + + Name Number Defined In + ------------------------------------------------------ + RESERVED 0 + PRF_HMAC_MD5 1 (RFC2104), [MD5] + PRF_HMAC_SHA1 2 (RFC2104), [SHA] + PRF_HMAC_TIGER 3 (UNSPECIFIED) + PRF_AES128_XCBC 4 (RFC4434) + RESERVED TO IANA 5-1023 + PRIVATE USE 1024-65535 + + For Transform Type 3 (Integrity Algorithm), defined Transform IDs + are: + + Name Number Defined In + ---------------------------------------- + NONE 0 + AUTH_HMAC_MD5_96 1 (RFC2403) + AUTH_HMAC_SHA1_96 2 (RFC2404) + AUTH_DES_MAC 3 (UNSPECIFIED) + AUTH_KPDK_MD5 4 (UNSPECIFIED) + AUTH_AES_XCBC_96 5 (RFC3566) + RESERVED TO IANA 6-1023 + PRIVATE USE 1024-65535 + + For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs + are: + + + +Kaufman, et al. Expires August 28, 2008 [Page 68] + +Internet-Draft IKEv2bis February 2008 + + + Name Number Defined in + ---------------------------------------- + NONE 0 + 768 Bit MODP 1 Appendix B + 1024 Bit MODP 2 Appendix B + RESERVED TO IANA 3-4 + 1536-bit MODP 5 [ADDGROUP] + RESERVED TO IANA 6-13 + 2048-bit MODP 14 [ADDGROUP] + 3072-bit MODP 15 [ADDGROUP] + 4096-bit MODP 16 [ADDGROUP] + 6144-bit MODP 17 [ADDGROUP] + 8192-bit MODP 18 [ADDGROUP] + RESERVED TO IANA 19-1023 + PRIVATE USE 1024-65535 + + For Transform Type 5 (Extended Sequence Numbers), defined Transform + IDs are: + + Name Number + -------------------------------------------- + No Extended Sequence Numbers 0 + Extended Sequence Numbers 1 + RESERVED 2 - 65535 + + {{ Clarif-4.4 }} Note that an initiator who supports ESNs will + usually include two ESN transforms, with values "0" and "1", in its + proposals. A proposal containing a single ESN transform with value + "1" means that using normal (non-extended) sequence numbers is not + acceptable. + +3.3.3. Valid Transform Types by Protocol + + The number and type of transforms that accompany an SA payload are + dependent on the protocol in the SA itself. An SA payload proposing + the establishment of an SA has the following mandatory and optional + transform types. A compliant implementation MUST understand all + mandatory and optional types for each protocol it supports (though it + need not accept proposals with unacceptable suites). A proposal MAY + omit the optional types if the only value for them it will accept is + NONE. + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 69] + +Internet-Draft IKEv2bis February 2008 + + + Protocol Mandatory Types Optional Types + --------------------------------------------------- + IKE ENCR, PRF, INTEG*, D-H + ESP ENCR, ESN INTEG, D-H + AH INTEG, ESN D-H + + (*) Negotiating an integrity algorithm is mandatory for the + Encrypted payload format specified in this document. Future + documents may specify additional formats based on authenticated + encryption, in which case a separate integrity algorithm is not + negotiated. + +3.3.4. Mandatory Transform IDs + + The specification of suites that MUST and SHOULD be supported for + interoperability has been removed from this document because they are + likely to change more rapidly than this document evolves. + + An important lesson learned from IKEv1 is that no system should only + implement the mandatory algorithms and expect them to be the best + choice for all customers. For example, at the time that this + document was written, many IKEv1 implementers were starting to + migrate to AES in Cipher Block Chaining (CBC) mode for Virtual + Private Network (VPN) applications. Many IPsec systems based on + IKEv2 will implement AES, additional Diffie-Hellman groups, and + additional hash algorithms, and some IPsec customers already require + these algorithms in addition to the ones listed above. + + It is likely that IANA will add additional transforms in the future, + and some users may want to use private suites, especially for IKE + where implementations should be capable of supporting different + parameters, up to certain size limits. In support of this goal, all + implementations of IKEv2 SHOULD include a management facility that + allows specification (by a user or system administrator) of Diffie- + Hellman (DH) parameters (the generator, modulus, and exponent lengths + and values) for new DH groups. Implementations SHOULD provide a + management interface through which these parameters and the + associated transform IDs may be entered (by a user or system + administrator), to enable negotiating such groups. + + All implementations of IKEv2 MUST include a management facility that + enables a user or system administrator to specify the suites that are + acceptable for use with IKE. Upon receipt of a payload with a set of + transform IDs, the implementation MUST compare the transmitted + transform IDs against those locally configured via the management + controls, to verify that the proposed suite is acceptable based on + local policy. The implementation MUST reject SA proposals that are + not authorized by these IKE suite controls. Note that cryptographic + + + +Kaufman, et al. Expires August 28, 2008 [Page 70] + +Internet-Draft IKEv2bis February 2008 + + + suites that MUST be implemented need not be configured as acceptable + to local policy. + +3.3.5. Transform Attributes + + Each transform in a Security Association payload may include + attributes that modify or complete the specification of the + transform. The set of valid attributes depends on the transform. + Currently, only a single attribute type is defined: the Key Length + attribute is used by certain encryption transforms with variable- + length keys (see below for details). + + The attributes are type/value pairs and are defined below. + Attributes can have a value with a fixed two-octet length or a + variable-length value. For the latter, the attribute is encoded as + type/length/value. + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A| Attribute Type | AF=0 Attribute Length | + |F| | AF=1 Attribute Value | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AF=0 Attribute Value | + | AF=1 Not Transmitted | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Data Attributes + + o Attribute Format (AF) (1 bit) - Indicates whether the data + attribute follow the Type/Length/Value (TLV) format or a shortened + Type/Value (TV) format. If the AF bit is zero (0), then the + attribute uses TLV format; if the AF bit is one (1), the TV format + (with two-byte value) is used. + + o Attribute Type (15 bits) - Unique identifier for each type of + attribute (see below). + + o Attribute Value (variable length) - Value of the Attribute + associated with the Attribute Type. If the AF bit is a zero (0), + this field has a variable length defined by the Attribute Length + field. If the AF bit is a one (1), the Attribute Value has a + length of 2 octets. + + Note that the only currently defined attribute type (Key Length) is + fixed length; the variable-length encoding specification is included + only for future extensions. Attributes described as fixed length + MUST NOT be encoded using the variable-length encoding. Variable- + + + +Kaufman, et al. Expires August 28, 2008 [Page 71] + +Internet-Draft IKEv2bis February 2008 + + + length attributes MUST NOT be encoded as fixed-length even if their + value can fit into two octets. NOTE: This is a change from IKEv1, + where increased flexibility may have simplified the composer of + messages but certainly complicated the parser. + + Attribute Type Value Attribute Format + ------------------------------------------------------------ + RESERVED 0-13 + Key Length (in bits) 14 TV + RESERVED 15-17 + RESERVED TO IANA 18-16383 + PRIVATE USE 16384-32767 + + Values 0-13 and 15-17 were used in a similar context in IKEv1, and + should not be assigned except to matching values. + + The Key Length attribute specifies the key length in bits (MUST use + network byte order) for certain transforms as follows: {{ Clarif-7.11 + }} + + o The Key Length attribute MUST NOT be used with transforms that use + a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and + all the Type 2 (Pseudo-random function) and Type 3 (Integrity + Algorithm) transforms specified in this document. It is + recommended that future Type 2 or 3 transforms do not use this + attribute. + + o Some transforms specify that the Key Length attribute MUST be + always included (omitting the attribute is not allowed, and + proposals not containing it MUST be rejected). This includes, + e.g., ENCR_AES_CBC and ENCR_AES_CTR. + + o Some transforms allow variable-length keys, but also specify a + default key length if the attribute is not included. These + transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. + + Implementation note: To further interoperability and to support + upgrading endpoints independently, implementers of this protocol + SHOULD accept values that they deem to supply greater security. For + instance, if a peer is configured to accept a variable-length cipher + with a key length of X bits and is offered that cipher with a larger + key length, the implementation SHOULD accept the offer if it supports + use of the longer key. + + Support of this capability allows a responder to express a concept of + "at least" a certain level of security -- "a key length of _at least_ + X bits for cipher Y". However, as the attribute is always returned + unchanged (see Section 3.3.6), an initiator willing to accept + + + +Kaufman, et al. Expires August 28, 2008 [Page 72] + +Internet-Draft IKEv2bis February 2008 + + + multiple key lengths has to include multiple transforms with the same + Transform Type, each with different Key Length attribute. + +3.3.6. Attribute Negotiation + + During security association negotiation initiators present offers to + responders. Responders MUST select a single complete set of + parameters from the offers (or reject all offers if none are + acceptable). If there are multiple proposals, the responder MUST + choose a single proposal. If the selected proposal has multiple + Transforms with the same type, the responder MUST choose a single + one. Any attributes of a selected transform MUST be returned + unmodified. The initiator of an exchange MUST check that the + accepted offer is consistent with one of its proposals, and if not + that response MUST be rejected. + + If the responder receives a proposal that contains a Transform Type + it does not understand, or a proposal that is missing a mandatory + Transform Type, it MUST consider this proposal unacceptable; however, + other proposals in the same SA payload are processed as usual. + Similarly, if the responder receives a transform that contains a + Transform Attribute it does not understand, it MUST consider this + transform unacceptable; other transforms with the same Transform Type + are processed as usual. This allows new Transform Types and + Transform Attributes to be defined in the future. + + Negotiating Diffie-Hellman groups presents some special challenges. + SA offers include proposed attributes and a Diffie-Hellman public + number (KE) in the same message. If in the initial exchange the + initiator offers to use one of several Diffie-Hellman groups, it + SHOULD pick the one the responder is most likely to accept and + include a KE corresponding to that group. If the guess turns out to + be wrong, the responder will indicate the correct group in the + response and the initiator SHOULD pick an element of that group for + its KE value when retrying the first message. It SHOULD, however, + continue to propose its full supported set of groups in order to + prevent a man-in-the-middle downgrade attack. + +3.4. Key Exchange Payload + + The Key Exchange Payload, denoted KE in this memo, is used to + exchange Diffie-Hellman public numbers as part of a Diffie-Hellman + key exchange. The Key Exchange Payload consists of the IKE generic + payload header followed by the Diffie-Hellman public value itself. + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 73] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DH Group # | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Key Exchange Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Key Exchange Payload Format + + A key exchange payload is constructed by copying one's Diffie-Hellman + public value into the "Key Exchange Data" portion of the payload. + The length of the Diffie-Hellman public value MUST be equal to the + length of the prime modulus over which the exponentiation was + performed, prepending zero bits to the value if necessary. + + The DH Group # identifies the Diffie-Hellman group in which the Key + Exchange Data was computed (see Section 3.3.2). If the selected + proposal uses a different Diffie-Hellman group (other than NONE), the + message MUST be rejected with a Notify payload of type + INVALID_KE_PAYLOAD. + + The payload type for the Key Exchange payload is thirty four (34). + +3.5. Identification Payloads + + The Identification Payloads, denoted IDi and IDr in this memo, allow + peers to assert an identity to one another. This identity may be + used for policy lookup, but does not necessarily have to match + anything in the CERT payload; both fields may be used by an + implementation to perform access control decisions. {{ Clarif-7.1 }} + 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. + + NOTE: In IKEv1, two ID payloads were used in each direction to hold + Traffic Selector (TS) information for data passing over the SA. In + IKEv2, this information is carried in TS payloads (see Section 3.13). + + The Identification Payload consists of the IKE generic payload header + followed by identification fields as follows: + + + + +Kaufman, et al. Expires August 28, 2008 [Page 74] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID Type | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Identification Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Identification Payload Format + + o ID Type (1 octet) - Specifies the type of Identification being + used. + + o RESERVED - MUST be sent as zero; MUST be ignored on receipt. + + o Identification Data (variable length) - Value, as indicated by the + Identification Type. The length of the Identification Data is + computed from the size in the ID payload header. + + The payload types for the Identification Payload are thirty five (35) + for IDi and thirty six (36) for IDr. + + The following table lists the assigned values for the Identification + Type field: + + + + + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 75] + +Internet-Draft IKEv2bis February 2008 + + + ID Type Value + ------------------------------------------------------------------- + RESERVED 0 + + ID_IPV4_ADDR 1 + A single four (4) octet IPv4 address. + + ID_FQDN 2 + A fully-qualified domain name string. An example of a ID_FQDN + is, "example.com". The string MUST not contain any terminators + (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; + for an "internationalized domain name", the syntax is as defined + in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". + + ID_RFC822_ADDR 3 + A fully-qualified RFC822 email address string, An example of a + ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not + contain any terminators. + + RESERVED TO IANA 4 + + ID_IPV6_ADDR 5 + A single sixteen (16) octet IPv6 address. + + RESERVED TO IANA 6 - 8 + + ID_DER_ASN1_DN 9 + The binary Distinguished Encoding Rules (DER) encoding of an + ASN.1 X.500 Distinguished Name [X.501]. + + ID_DER_ASN1_GN 10 + The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. + + ID_KEY_ID 11 + An opaque octet stream which may be used to pass vendor- + specific information necessary to do certain proprietary + types of identification. + + RESERVED TO IANA 12-200 + + PRIVATE USE 201-255 + + Two implementations will interoperate only if each can generate a + type of ID acceptable to the other. To assure maximum + interoperability, implementations MUST be configurable to send at + least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and + MUST be configurable to accept all of these types. Implementations + SHOULD be capable of generating and accepting all of these types. + + + +Kaufman, et al. Expires August 28, 2008 [Page 76] + +Internet-Draft IKEv2bis February 2008 + + + IPv6-capable implementations MUST additionally be configurable to + accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable + to send only ID_IPV6_ADDR. + + {{ Clarif-3.4 }} 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 same as the syntax of email address in [MAILFORMAT]. For those + NAIs that include the realm component, the ID_RFC822_ADDR + identification type SHOULD be used. Responder implementations should + not attempt to verify that the contents actually conform to the exact + syntax given in [MAILFORMAT], but instead should accept any + reasonable-looking NAI. For NAIs that do not include the realm + component,the ID_KEY_ID identification type SHOULD be used. + +3.6. Certificate Payload + + The Certificate Payload, denoted CERT in this memo, provides a means + to transport certificates or other authentication-related information + via IKE. Certificate payloads SHOULD be included in an exchange if + certificates are available to the sender unless the peer has + indicated an ability to retrieve this information from elsewhere + using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the + term "Certificate Payload" is somewhat misleading, because not all + authentication mechanisms use certificates and data other than + certificates may be passed in this payload. + + The Certificate Payload is defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cert Encoding | | + +-+-+-+-+-+-+-+-+ | + ~ Certificate Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: Certificate Payload Format + + o Certificate Encoding (1 octet) - This field indicates the type of + certificate or certificate-related information contained in the + Certificate Data field. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 77] + +Internet-Draft IKEv2bis February 2008 + + + Certificate Encoding Value + ---------------------------------------------------- + RESERVED 0 + PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED + PGP Certificate 2 UNSPECIFIED + DNS Signed Key 3 UNSPECIFIED + X.509 Certificate - Signature 4 + Kerberos Token 6 UNSPECIFIED + Certificate Revocation List (CRL) 7 + Authority Revocation List (ARL) 8 + SPKI Certificate 9 UNSPECIFIED + X.509 Certificate - Attribute 10 + Raw RSA Key 11 + Hash and URL of X.509 certificate 12 + Hash and URL of X.509 bundle 13 + RESERVED to IANA 14 - 200 + PRIVATE USE 201 - 255 + + o Certificate Data (variable length) - Actual encoding of + certificate data. The type of certificate is indicated by the + Certificate Encoding field. + + The payload type for the Certificate Payload is thirty seven (37). + + Specific syntax for some of the certificate type codes above is not + defined in this document. The types whose syntax is defined in this + document are: + + o X.509 Certificate - Signature (4) contains a DER encoded X.509 + certificate whose public key is used to validate the sender's AUTH + payload. + + o Certificate Revocation List (7) contains a DER encoded X.509 + certificate revocation list. + + o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} + Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a + DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). + + o Hash and URL encodings (12-13) allow IKE messages to remain short + by replacing long data structures with a 20 octet SHA-1 hash (see + [SHA]) of the replaced value followed by a variable-length URL + that resolves to the DER encoded data structure itself. This + improves efficiency when the endpoints have certificate data + cached and makes IKE less subject to denial of service attacks + that become easier to mount when IKE messages are large enough to + require IP fragmentation [DOSUDPPROT]. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 78] + +Internet-Draft IKEv2bis February 2008 + + + Use the following ASN.1 definition for an X.509 bundle: + + CertBundle + { iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-cert-bundle(34) } + + DEFINITIONS EXPLICIT TAGS ::= + BEGIN + + IMPORTS + Certificate, CertificateList + FROM PKIX1Explicit88 + { iso(1) identified-organization(3) dod(6) + internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-explicit(18) } ; + + CertificateOrCRL ::= CHOICE { + cert [0] Certificate, + crl [1] CertificateList } + + CertificateBundle ::= SEQUENCE OF CertificateOrCRL + + END + + Implementations MUST be capable of being configured to send and + accept up to four X.509 certificates in support of authentication, + and also MUST be capable of being configured to send and accept the + two Hash and URL formats (with HTTP URLs). Implementations SHOULD be + capable of being configured to send and accept Raw RSA keys. If + multiple certificates are sent, the first certificate MUST contain + the public key used to sign the AUTH payload. The other certificates + may be sent in any order. + +3.7. Certificate Request Payload + + The Certificate Request Payload, denoted CERTREQ in this memo, + provides a means to request preferred certificates via IKE and can + appear in the IKE_INIT_SA response and/or the IKE_AUTH request. + Certificate Request payloads MAY be included in an exchange when the + sender needs to get the certificate of the receiver. If multiple CAs + are trusted and the cert encoding does not allow a list, then + multiple Certificate Request payloads SHOULD be transmitted. + + The Certificate Request Payload is defined as follows: + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 79] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cert Encoding | | + +-+-+-+-+-+-+-+-+ | + ~ Certification Authority ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Certificate Request Payload Format + + o Certificate Encoding (1 octet) - Contains an encoding of the type + or format of certificate requested. Values are listed in + Section 3.6. + + o Certification Authority (variable length) - Contains an encoding + of an acceptable certification authority for the type of + certificate requested. + + The payload type for the Certificate Request Payload is thirty eight + (38). + + The Certificate Encoding field has the same values as those defined + in Section 3.6. The Certification Authority field contains an + indicator of trusted authorities for this certificate type. The + Certification Authority value is a concatenated list of SHA-1 hashes + of the public keys of trusted Certification Authorities (CAs). Each + is encoded as the SHA-1 hash of the Subject Public Key Info element + (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. + The twenty-octet hashes are concatenated and included with no other + formatting. + + {{ Clarif-3.6 }} The contents of the "Certification Authority" field + are defined only for X.509 certificates, which are types 4, 10, 12, + and 13. Other values SHOULD NOT be used until standards-track + specifications that specify their use are published. + + Note that the term "Certificate Request" is somewhat misleading, in + that values other than certificates are defined in a "Certificate" + payload and requests for those values can be present in a Certificate + Request Payload. The syntax of the Certificate Request payload in + such cases is not defined in this document. + + The Certificate Request Payload is processed by inspecting the "Cert + Encoding" field to determine whether the processor has any + certificates of this type. If so, the "Certification Authority" + + + +Kaufman, et al. Expires August 28, 2008 [Page 80] + +Internet-Draft IKEv2bis February 2008 + + + field is inspected to determine if the processor has any certificates + that can be validated up to one of the specified certification + authorities. This can be a chain of certificates. + + If an end-entity certificate exists that satisfies the criteria + specified in the CERTREQ, a certificate or certificate chain SHOULD + be sent back to the certificate requestor if the recipient of the + CERTREQ: + + o is configured to use certificate authentication, + + o is allowed to send a CERT payload, + + o has matching CA trust policy governing the current negotiation, + and + + o has at least one time-wise and usage appropriate end-entity + certificate chaining to a CA provided in the CERTREQ. + + Certificate revocation checking must be considered during the + chaining process used to select a certificate. Note that even if two + peers are configured to use two different CAs, cross-certification + relationships should be supported by appropriate selection logic. + + The intent is not to prevent communication through the strict + adherence of selection of a certificate based on CERTREQ, when an + alternate certificate could be selected by the sender that would + still enable the recipient to successfully validate and trust it + through trust conveyed by cross-certification, CRLs, or other out-of- + band configured means. Thus, the processing of a CERTREQ should be + seen as a suggestion for a certificate to select, not a mandated one. + If no certificates exist, then the CERTREQ is ignored. This is not + an error condition of the protocol. There may be cases where there + is a preferred CA sent in the CERTREQ, but an alternate might be + acceptable (perhaps after prompting a human operator). + + {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be + included in any message that can include a CERTREQ payload and + indicates that the sender is capable of looking up certificates based + on an HTTP-based URL (and hence presumably would prefer to receive + certificate specifications in that format). + +3.8. Authentication Payload + + The Authentication Payload, denoted AUTH in this memo, contains data + used for authentication purposes. The syntax of the Authentication + data varies according to the Auth Method as specified below. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 81] + +Internet-Draft IKEv2bis February 2008 + + + The Authentication Payload is defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Auth Method | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Authentication Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: Authentication Payload Format + + o Auth Method (1 octet) - Specifies the method of authentication + used. Values defined are: + + * RSA Digital Signature (1) - Computed as specified in + Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 + signature scheme specified in [PKCS1] (implementors should note + that IKEv1 used a different method for RSA signatures) {{ + Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, + implementations that support this type SHOULD support + signatures that use SHA-1 as the hash function and SHOULD use + SHA-1 as the default hash function when generating signatures. + + * Shared Key Message Integrity Code (2) - Computed as specified + in Section 2.15 using the shared key associated with the + identity in the ID payload and the negotiated prf function + + * DSS Digital Signature (3) - Computed as specified in + Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 + hash. + + * The values 0 and 4-200 are reserved to IANA. The values 201- + 255 are available for private use. + + o Authentication Data (variable length) - see Section 2.15. + + The payload type for the Authentication Payload is thirty nine (39). + +3.9. Nonce Payload + + The Nonce Payload, denoted Ni and Nr in this memo for the initiator's + and responder's nonce respectively, contains random data used to + guarantee liveness during an exchange and protect against replay + + + +Kaufman, et al. Expires August 28, 2008 [Page 82] + +Internet-Draft IKEv2bis February 2008 + + + attacks. + + The Nonce Payload is defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Nonce Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 15: Nonce Payload Format + + o Nonce Data (variable length) - Contains the random data generated + by the transmitting entity. + + The payload type for the Nonce Payload is forty (40). + + The size of a Nonce MUST be between 16 and 256 octets inclusive. + Nonce values MUST NOT be reused. + +3.10. Notify Payload + + The Notify Payload, denoted N in this document, is used to transmit + informational data, such as error conditions and state transitions, + to an IKE peer. A Notify Payload may appear in a response message + (usually specifying why a request was rejected), in an INFORMATIONAL + Exchange (to report an error not in an IKE request), or in any other + message to indicate sender capabilities or to modify the meaning of + the request. + + The Notify Payload is defined as follows: + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 83] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol ID | SPI Size | Notify Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Security Parameter Index (SPI) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Notification Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 16: Notify Payload Format + + o Protocol ID (1 octet) - If this notification concerns an existing + SA whose SPI is given the SPI field, this field indicates the type + of that SA. For notifications concerning IPsec SAs this field + MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ + Clarif-7.8 }} Of the notifications defined in this document, the + SPI is included only with INVALID_SELECTORS and REKEY_SA. If the + SPI field is empty, this field MUST be sent as zero and MUST be + ignored on receipt. All other values for this field are reserved + to IANA for future assignment. + + o SPI Size (1 octet) - Length in octets of the SPI as defined by the + IPsec protocol ID or zero if no SPI is applicable. For a + notification concerning the IKE_SA, the SPI Size MUST be zero. + + o Notify Message Type (2 octets) - Specifies the type of + notification message. + + o SPI (variable length) - Security Parameter Index. + + o Notification Data (variable length) - Informational or error data + transmitted in addition to the Notify Message Type. Values for + this field are type specific (see below). + + The payload type for the Notify Payload is forty one (41). + +3.10.1. Notify Message Types + + Notification information can be error messages specifying why an SA + could not be established. It can also be status data that a process + managing an SA database wishes to communicate with a peer process. + + + +Kaufman, et al. Expires August 28, 2008 [Page 84] + +Internet-Draft IKEv2bis February 2008 + + + The table below lists the Notification messages and their + corresponding values. The number of different error statuses was + greatly reduced from IKEv1 both for simplification and to avoid + giving configuration information to probers. + + Types in the range 0 - 16383 are intended for reporting errors. An + implementation receiving a Notify payload with one of these types + that it does not recognize in a response MUST assume that the + corresponding request has failed entirely. {{ Demoted the SHOULD }} + Unrecognized error types in a request and status types in a request + or response MUST be ignored, and they should be logged. + + Notify payloads with status types MAY be added to any message and + MUST be ignored if not recognized. They are intended to indicate + capabilities, and as part of SA negotiation are used to negotiate + non-cryptographic parameters. + + NOTIFY messages: error types Value + ------------------------------------------------------------------- + + RESERVED 0 + + UNSUPPORTED_CRITICAL_PAYLOAD 1 + See Section 2.5. + + INVALID_IKE_SPI 4 + See Section 2.21. + + INVALID_MAJOR_VERSION 5 + See Section 2.5. + + INVALID_SYNTAX 7 + Indicates the IKE message that was received was invalid because + some type, length, or value was out of range or because the + request was rejected for policy reasons. To avoid a denial of + service attack using forged messages, this status may only be + returned for and in an encrypted packet if the message ID and + cryptographic checksum were valid. To avoid leaking information + to someone probing a node, this status MUST be sent in response + to any error not covered by one of the other status types. + {{ Demoted the SHOULD }} To aid debugging, more detailed error + information should be written to a console or log. + + INVALID_MESSAGE_ID 9 + See Section 2.3. + + INVALID_SPI 11 + See Section 1.5. + + + +Kaufman, et al. Expires August 28, 2008 [Page 85] + +Internet-Draft IKEv2bis February 2008 + + + NO_PROPOSAL_CHOSEN 14 + See Section 2.7. + + INVALID_KE_PAYLOAD 17 + See Section 1.3. + + AUTHENTICATION_FAILED 24 + Sent in the response to an IKE_AUTH message when for some reason + the authentication failed. There is no associated data. + + SINGLE_PAIR_REQUIRED 34 + See Section 2.9. + + NO_ADDITIONAL_SAS 35 + See Section 1.3. + + INTERNAL_ADDRESS_FAILURE 36 + See Section 3.15.4. + + FAILED_CP_REQUIRED 37 + See Section 2.19. + + TS_UNACCEPTABLE 38 + See Section 2.9. + + INVALID_SELECTORS 39 + MAY be sent in an IKE INFORMATIONAL exchange when a node receives + an ESP or AH packet whose selectors do not match those of the SA + on which it was delivered (and that caused the packet to be + dropped). The Notification Data contains the start of the + offending packet (as in ICMP messages) and the SPI field of the + notification is set to match the SPI of the IPsec SA. + + RESERVED TO IANA 40-8191 + + PRIVATE USE 8192-16383 + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 86] + +Internet-Draft IKEv2bis February 2008 + + + NOTIFY messages: status types Value + ------------------------------------------------------------------- + + INITIAL_CONTACT 16384 + See Section 2.4. + + SET_WINDOW_SIZE 16385 + See Section 2.3. + + ADDITIONAL_TS_POSSIBLE 16386 + See Section 2.9. + + IPCOMP_SUPPORTED 16387 + See Section 2.22. + + NAT_DETECTION_SOURCE_IP 16388 + See Section 2.23. + + NAT_DETECTION_DESTINATION_IP 16389 + See Section 2.23. + + COOKIE 16390 + See Section 2.6. + + USE_TRANSPORT_MODE 16391 + See Section 1.3.1. + + HTTP_CERT_LOOKUP_SUPPORTED 16392 + See Section 3.6. + + REKEY_SA 16393 + See Section 1.3.3. + + ESP_TFC_PADDING_NOT_SUPPORTED 16394 + See Section 1.3.1. + + NON_FIRST_FRAGMENTS_ALSO 16395 + See Section 1.3.1. + + RESERVED TO IANA 16396-40959 + + PRIVATE USE 40960-65535 + +3.11. Delete Payload + + The Delete Payload, denoted D in this memo, contains a protocol + specific security association identifier that the sender has removed + from its security association database and is, therefore, no longer + + + +Kaufman, et al. Expires August 28, 2008 [Page 87] + +Internet-Draft IKEv2bis February 2008 + + + valid. Figure 17 shows the format of the Delete Payload. It is + possible to send multiple SPIs in a Delete payload; however, each SPI + MUST be for the same protocol. Mixing of protocol identifiers MUST + NOT be performed in the Delete payload. It is permitted, however, to + include multiple Delete payloads in a single INFORMATIONAL exchange + where each Delete payload lists SPIs for a different protocol. + + Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but + no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the + IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI + is the SPI the sending endpoint would expect in inbound ESP or AH + packets. + + The Delete Payload is defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol ID | SPI Size | # of SPIs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Security Parameter Index(es) (SPI) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 17: Delete Payload Format + + o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 + for ESP. + + o SPI Size (1 octet) - Length in octets of the SPI as defined by the + protocol ID. It MUST be zero for IKE (SPI is in message header) + or four for AH and ESP. + + o # of SPIs (2 octets) - The number of SPIs contained in the Delete + payload. The size of each SPI is defined by the SPI Size field. + + o Security Parameter Index(es) (variable length) - Identifies the + specific security association(s) to delete. The length of this + field is determined by the SPI Size and # of SPIs fields. + + The payload type for the Delete Payload is forty two (42). + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 88] + +Internet-Draft IKEv2bis February 2008 + + +3.12. Vendor ID Payload + + The Vendor ID Payload, denoted V in this memo, contains a vendor + defined constant. The constant is used by vendors to identify and + recognize remote instances of their implementations. This mechanism + allows a vendor to experiment with new features while maintaining + backward compatibility. + + A Vendor ID payload MAY announce that the sender is capable of + accepting certain extensions to the protocol, or it MAY simply + identify the implementation as an aid in debugging. A Vendor ID + payload MUST NOT change the interpretation of any information defined + in this specification (i.e., the critical bit MUST be set to 0). + Multiple Vendor ID payloads MAY be sent. An implementation is NOT + REQUIRED to send any Vendor ID payload at all. + + A Vendor ID payload may be sent as part of any message. Reception of + a familiar Vendor ID payload allows an implementation to make use of + Private USE numbers described throughout this memo-- private + payloads, private exchanges, private notifications, etc. Unfamiliar + Vendor IDs MUST be ignored. + + Writers of Internet-Drafts who wish to extend this protocol MUST + define a Vendor ID payload to announce the ability to implement the + extension in the Internet-Draft. It is expected that Internet-Drafts + that gain acceptance and are standardized will be given "magic + numbers" out of the Future Use range by IANA, and the requirement to + use a Vendor ID will go away. + + The Vendor ID Payload fields are defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Vendor ID (VID) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 18: Vendor ID Payload Format + + o Vendor ID (variable length) - It is the responsibility of the + person choosing the Vendor ID to assure its uniqueness in spite of + the absence of any central registry for IDs. Good practice is to + include a company name, a person name, or some such. If you want + to show off, you might include the latitude and longitude and time + + + +Kaufman, et al. Expires August 28, 2008 [Page 89] + +Internet-Draft IKEv2bis February 2008 + + + where you were when you chose the ID and some random input. A + message digest of a long unique string is preferable to the long + unique string itself. + + The payload type for the Vendor ID Payload is forty three (43). + +3.13. Traffic Selector Payload + + The Traffic Selector Payload, denoted TS in this memo, allows peers + to identify packet flows for processing by IPsec security services. + The Traffic Selector Payload consists of the IKE generic payload + header followed by individual traffic selectors as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Number of TSs | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 19: Traffic Selectors Payload Format + + o Number of TSs (1 octet) - Number of traffic selectors being + provided. + + o RESERVED - This field MUST be sent as zero and MUST be ignored on + receipt. + + o Traffic Selectors (variable length) - One or more individual + traffic selectors. + + The length of the Traffic Selector payload includes the TS header and + all the traffic selectors. + + The payload type for the Traffic Selector payload is forty four (44) + for addresses at the initiator's end of the SA and forty five (45) + for addresses at the responder's end. + + {{ Clarif-4.7 }} 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. + + + +Kaufman, et al. Expires August 28, 2008 [Page 90] + +Internet-Draft IKEv2bis February 2008 + + + 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). + + Thus, 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. + +3.13.1. Traffic Selector + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TS Type |IP Protocol ID*| Selector Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Start Port* | End Port* | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Starting Address* ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Ending Address* ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 20: Traffic Selector + + *Note: All fields other than TS Type and Selector Length depend on + the TS Type. The fields shown are for TS Types 7 and 8, the only two + values currently defined. + + o TS Type (one octet) - Specifies the type of traffic selector. + + o IP protocol ID (1 octet) - Value specifying an associated IP + protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the + protocol ID is not relevant to this traffic selector-- the SA can + carry all protocols. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 91] + +Internet-Draft IKEv2bis February 2008 + + + o Selector Length - Specifies the length of this Traffic Selector + Substructure including the header. + + o Start Port (2 octets) - Value specifying the smallest port number + allowed by this Traffic Selector. For protocols for which port is + undefined, or if all ports are allowed, this field MUST be zero. + 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. + + o End Port (2 octets) - Value specifying the largest port number + allowed by this Traffic Selector. For protocols for which port is + undefined, or if all ports are allowed, this field MUST be 65535. + 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 purposed of filtering based on this + field. + + o Starting Address - The smallest address included in this Traffic + Selector (length determined by TS type). + + o Ending Address - The largest address included in this Traffic + Selector (length determined by TS type). + + Systems that are complying with [IPSECARCH] that wish to indicate + "ANY" ports MUST set the start port to 0 and the end port to 65535; + note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems + working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but + not "ANY" ports, MUST set the start port to 65535 and the end port to + 0. + + {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can + also refer to ICMP type and code fields. Note, however, that ICMP + packets do not have separate source and destination port fields. The + method for specifying the traffic selectors for ICMP is shown by + example in Section 4.4.1.3 of [IPSECARCH]. + + {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID + 135 to match the IPv6 mobility header [MIPV6]. This document does + not specify how to represent the "MH Type" field in traffic + selectors, although it is likely that a different document will + specify this in the future. Note that [IPSECARCH] says that the IPv6 + mobility header (MH) message 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. + + + +Kaufman, et al. Expires August 28, 2008 [Page 92] + +Internet-Draft IKEv2bis February 2008 + + + The following table lists the assigned values for the Traffic + Selector Type field and the corresponding Address Selector Data. + + TS Type Value + ------------------------------------------------------------------- + RESERVED 0-6 + + TS_IPV4_ADDR_RANGE 7 + + A range of IPv4 addresses, represented by two four-octet + values. The first value is the beginning IPv4 address + (inclusive) and the second value is the ending IPv4 address + (inclusive). All addresses falling between the two specified + addresses are considered to be within the list. + + TS_IPV6_ADDR_RANGE 8 + + A range of IPv6 addresses, represented by two sixteen-octet + values. The first value is the beginning IPv6 address + (inclusive) and the second value is the ending IPv6 address + (inclusive). All addresses falling between the two specified + addresses are considered to be within the list. + + RESERVED TO IANA 9-240 + PRIVATE USE 241-255 + +3.14. Encrypted Payload + + The Encrypted Payload, denoted SK{...} or E in this memo, contains + other payloads in encrypted form. The Encrypted Payload, if present + in a message, MUST be the last payload in the message. Often, it is + the only payload in the message. + + The algorithms for encryption and integrity protection are negotiated + during IKE_SA setup, and the keys are computed as specified in + Section 2.14 and Section 2.18. + + This document specifies the cryptographic processing of Encrypted + payloads using a block cipher in CBC mode and an integrity check + algorithm that computes a fixed-length checksum over a variable size + message. The design is modeled after the ESP algorithms described in + RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document + completely specifies the cryptographic processing of IKE data, but + those documents should be consulted for design rationale. Future + documents may specify the processing of Encrypted payloads for other + types of transforms, such as counter mode encryption and + authenticated encryption algorithms. Peers MUST NOT negotiate + transforms for which no such specification exists. + + + +Kaufman, et al. Expires August 28, 2008 [Page 93] + +Internet-Draft IKEv2bis February 2008 + + + The payload type for an Encrypted payload is forty six (46). The + Encrypted Payload consists of the IKE generic payload header followed + by individual fields as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Initialization Vector | + | (length is block size for encryption algorithm) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Encrypted IKE Payloads ~ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Padding (0-255 octets) | + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + | | Pad Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Integrity Checksum Data ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 21: Encrypted Payload Format + + o Next Payload - The payload type of the first embedded payload. + Note that this is an exception in the standard header format, + since the Encrypted payload is the last payload in the message and + therefore the Next Payload field would normally be zero. But + because the content of this payload is embedded payloads and there + was no natural place to put the type of the first one, that type + is placed here. + + o Payload Length - Includes the lengths of the header, IV, Encrypted + IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. + + o Initialization Vector - The length of the initialization vector + (IV) is equal to the block length of the underlying encryption + algorithm. Senders MUST select a new unpredictable IV for every + message; recipients MUST accept any value. The reader is + encouraged to consult [MODES] for advice on IV generation. In + particular, using the final ciphertext block of the previous + message is not considered unpredictable. + + o IKE Payloads are as specified earlier in this section. This field + is encrypted with the negotiated cipher. + + o Padding MAY contain any value chosen by the sender, and MUST have + a length that makes the combination of the Payloads, the Padding, + and the Pad Length to be a multiple of the encryption block size. + + + +Kaufman, et al. Expires August 28, 2008 [Page 94] + +Internet-Draft IKEv2bis February 2008 + + + This field is encrypted with the negotiated cipher. + + o Pad Length is the length of the Padding field. The sender SHOULD + set the Pad Length to the minimum value that makes the combination + of the Payloads, the Padding, and the Pad Length a multiple of the + block size, but the recipient MUST accept any length that results + in proper alignment. This field is encrypted with the negotiated + cipher. + + o Integrity Checksum Data is the cryptographic checksum of the + entire message starting with the Fixed IKE Header through the Pad + Length. The checksum MUST be computed over the encrypted message. + Its length is determined by the integrity algorithm negotiated. + +3.15. Configuration Payload + + The Configuration payload, denoted CP in this document, is used to + exchange configuration information between IKE peers. The exchange + is for an IRAC to request an internal IP address from an IRAS and to + exchange other information of the sort that one would acquire with + Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly + connected to a LAN. + + The Configuration Payload is defined as follows: + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CFG Type | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Configuration Attributes ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 22: Configuration Payload Format + + The payload type for the Configuration Payload is forty seven (47). + + o CFG Type (1 octet) - The type of exchange represented by the + Configuration Attributes. + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 95] + +Internet-Draft IKEv2bis February 2008 + + + CFG Type Value + -------------------------- + RESERVED 0 + CFG_REQUEST 1 + CFG_REPLY 2 + CFG_SET 3 + CFG_ACK 4 + RESERVED TO IANA 5-127 + PRIVATE USE 128-255 + + o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on + receipt. + + o Configuration Attributes (variable length) - These are type length + values specific to the Configuration Payload and are defined + below. There may be zero or more Configuration Attributes in this + payload. + +3.15.1. Configuration Attributes + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R| Attribute Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Value ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 23: Configuration Attribute Format + + o Reserved (1 bit) - This bit MUST be set to zero and MUST be + ignored on receipt. + + o Attribute Type (15 bits) - A unique identifier for each of the + Configuration Attribute Types. + + o Length (2 octets) - Length in octets of Value. + + o Value (0 or more octets) - The variable-length value of this + Configuration Attribute. The following attribute types have been + defined: + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 96] + +Internet-Draft IKEv2bis February 2008 + + + Multi- + Attribute Type Value Valued Length + ------------------------------------------------------- + RESERVED 0 + INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets + INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets + INTERNAL_IP4_DNS 3 YES 0 or 4 octets + INTERNAL_IP4_NBNS 4 YES 0 or 4 octets + RESERVED 5 + INTERNAL_IP4_DHCP 6 YES 0 or 4 octets + APPLICATION_VERSION 7 NO 0 or more + INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets + RESERVED 9 + INTERNAL_IP6_DNS 10 YES 0 or 16 octets + INTERNAL_IP6_NBNS 11 YES 0 or 16 octets + INTERNAL_IP6_DHCP 12 YES 0 or 16 octets + INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets + SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 + INTERNAL_IP6_SUBNET 15 YES 17 octets + RESERVED TO IANA 16-16383 + PRIVATE USE 16384-32767 + + * These attributes may be multi-valued on return only if + multiple values were requested. + + o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the + internal network, sometimes called a red node address or private + address and MAY be a private address on the Internet. {{ + Clarif-6.2}} In a request message, the address specified is a + requested address (or a zero-length address if no specific address + is requested). If a specific address is requested, it likely + indicates that a previous connection existed with this address and + the requestor would like to reuse that address. With IPv6, a + requestor MAY supply the low-order address octets it wants to use. + Multiple internal addresses MAY be requested by requesting + multiple internal address attributes. The responder MAY only send + up to the number of addresses requested. The INTERNAL_IP6_ADDRESS + is made up of two fields: the first is a 16-octet IPv6 address, + and the second is a one-octet prefix-length as defined in + [ADDRIPV6]. The requested address is valid until there are no + IKE_SAs between the peers. + + o INTERNAL_IP4_NETMASK - 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. {{ Clarif-6.4 }} + INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing + as INTERNAL_IP4_SUBNET containing the same information ("send + + + +Kaufman, et al. Expires August 28, 2008 [Page 97] + +Internet-Draft IKEv2bis February 2008 + + + 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. 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). Non-empty values + for this attribute in a CFG_REQUEST do not make sense and thus + MUST NOT be included. + + o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS + server within the network. Multiple DNS servers MAY be requested. + The responder MAY respond with zero or more DNS server attributes. + + o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server + (WINS) within the network. Multiple NBNS servers MAY be + requested. The responder MAY respond with zero or more NBNS + server attributes. + + o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for + IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only + retained for compatibility with RFC 4306. + + o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send + any internal DHCP requests to the address contained within the + attribute. Multiple DHCP servers MAY be requested. The responder + MAY respond with zero or more DHCP server attributes. + + o APPLICATION_VERSION - The version or application information of + the IPsec host. This is a string of printable ASCII characters + that is NOT null terminated. + + o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- + device protects. This attribute is made up of two fields: the + first being an IP address and the second being a netmask. + Multiple sub-networks MAY be requested. The responder MAY respond + with zero or more sub-network attributes. + + o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute + MUST be zero-length and specifies a query to the responder to + reply back with all of the attributes that it supports. The + response contains an attribute that contains a set of attribute + identifiers each in 2 octets. The length divided by 2 (octets) + would state the number of supported attributes contained in the + response. + + o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- + device protects. This attribute is made up of two fields: the + first is a 16-octet IPv6 address, and the second is a one-octet + + + +Kaufman, et al. Expires August 28, 2008 [Page 98] + +Internet-Draft IKEv2bis February 2008 + + + prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY + be requested. The responder MAY respond with zero or more sub- + network attributes. + + Note that no recommendations are made in this document as to how an + implementation actually figures out what information to send in a + reply. That is, we do not recommend any specific method of an IRAS + determining which DNS server should be returned to a requesting IRAC. + +3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET + + {{ Section added based on Clarif-6.3 }} + + INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, + ones that need one or more separate SAs, that can be reached through + the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET + attributes may also 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. Thus, + traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET + attributes should be sent through the gateway that announces the + attributes. If there are no existing IPsec SAs whose traffic + selectors cover the address in question, new SAs need to be created. + + For instance, if there are two subnets, 192.0.1.0/26 and + 192.0.2.0/24, and the client's request contains the following: + + CP(CFG_REQUEST) = + INTERNAL_IP4_ADDRESS() + TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) + TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) + + then a valid response could be the following (in which TSr and + INTERNAL_IP4_SUBNET contain the same information): + + CP(CFG_REPLY) = + INTERNAL_IP4_ADDRESS(192.0.1.234) + INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) + INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) + TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) + TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), + (0, 0-65535, 192.0.2.0-192.0.2.255)) + + In these cases, the INTERNAL_IP4_SUBNET does not really carry any + useful information. + + A different possible reply would have been this: + + + +Kaufman, et al. Expires August 28, 2008 [Page 99] + +Internet-Draft IKEv2bis February 2008 + + + 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) + + That reply 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) + + then the gateway's reply might be: + + 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) + + Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in + CFG_REQUESTs is unclear, they cannot be used reliably in + CFG_REQUESTs. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 100] + +Internet-Draft IKEv2bis February 2008 + + +3.15.3. Configuration payloads for IPv6 + + {{ Added this section from Clarif-6.5 }} + + The configuration payloads for IPv6 are based on the corresponding + IPv4 payloads, and do not fully follow the "normal IPv6 way of doing + things". In particular, IPv6 stateless autoconfiguration or router + advertisement messages are not used; neither is neighbor discovery. + + A client can be assigned an IPv6 address using the + INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might + 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) + + The client MAY 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 attempts to use the interface identifier with some other + prefix; if even that fails, the gateway selects 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. + + Although 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 sense [IPV6ADDR]. In particular, they do not + necessarily have link-local addresses, and this may complicate the + use of protocols that assume them, such as [MLDV2]. + +3.15.4. Address Assignment Failures + + {{ Added this section from Clarif-6.8 }} + + + + +Kaufman, et al. Expires August 28, 2008 [Page 101] + +Internet-Draft IKEv2bis February 2008 + + + If the responder encounters an error while attempting to assign an IP + address to the initiator during the processing of a Configuration + Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. + {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH + exchange, no CHILD_SA will be created. However, there are some more + complex error cases. + + If the responder does not support configuration payloads at all, it + can simply ignore all configuration payloads. This type of + implementation never sends INTERNAL_ADDRESS_FAILURE notifications. + If the initiator requires the assignment of an IP address, it will + treat a response without CFG_REPLY as an error. + + The initiator may request a particular type of address (IPv4 or IPv6) + that the responder does not support, even though the responder + supports configuration payloads. In this case, the responder simply + ignores the type of address it does not support and processes the + rest of the request as usual. + + If the initiator requests multiple addresses of a type that the + responder supports, and some (but not all) of the requests fail, the + responder replies with the successful addresses only. The responder + sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. + +3.16. Extensible Authentication Protocol (EAP) Payload + + The Extensible Authentication Protocol Payload, denoted EAP in this + memo, allows IKE_SAs to be authenticated using the protocol defined + in RFC 3748 [EAP] and subsequent extensions to that protocol. The + full set of acceptable values for the payload is defined elsewhere, + but a short summary of RFC 3748 is included here to make this + document stand alone in the common cases. + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Payload |C| RESERVED | Payload Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ EAP Message ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 24: EAP Payload Format + + The payload type for an EAP Payload is forty eight (48). + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 102] + +Internet-Draft IKEv2bis February 2008 + + + 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Type_Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Figure 25: EAP Message Format + + o Code (1 octet) indicates whether this message is a Request (1), + Response (2), Success (3), or Failure (4). + + o Identifier (1 octet) is used in PPP to distinguish replayed + messages from repeated ones. Since in IKE, EAP runs over a + reliable protocol, it serves no function here. In a response + message, this octet MUST be set to match the identifier in the + corresponding request. In other messages, this field MAY be set + to any value. + + o Length (2 octets) is the length of the EAP message and MUST be + four less than the Payload Length of the encapsulating payload. + + o Type (1 octet) is present only if the Code field is Request (1) or + Response (2). For other codes, the EAP message length MUST be + four octets and the Type and Type_Data fields MUST NOT be present. + In a Request (1) message, Type indicates the data being requested. + In a Response (2) message, Type MUST either be Nak or match the + type of the data requested. The following types are defined in + RFC 3748: + + 1 Identity + 2 Notification + 3 Nak (Response Only) + 4 MD5-Challenge + 5 One-Time Password (OTP) + 6 Generic Token Card + + o Type_Data (Variable Length) varies with the Type of Request and + the associated Response. For the documentation of the EAP + methods, see [EAP]. + + {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an + indication of initiator identity in message 3 of the protocol, the + responder should not send EAP Identity requests. The initiator may, + however, respond to such requests if it receives them. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 103] + +Internet-Draft IKEv2bis February 2008 + + +4. Conformance Requirements + + In order to assure that all implementations of IKEv2 can + interoperate, there are "MUST support" requirements in addition to + those listed elsewhere. Of course, IKEv2 is a security protocol, and + one of its major functions is to allow only authorized parties to + successfully complete establishment of SAs. So a particular + implementation may be configured with any of a number of restrictions + concerning algorithms and trusted authorities that will prevent + universal interoperability. + + IKEv2 is designed to permit minimal implementations that can + interoperate with all compliant implementations. There are a series + of optional features that can easily be ignored by a particular + implementation if it does not support that feature. Those features + include: + + o Ability to negotiate SAs through a NAT and tunnel the resulting + ESP SA over UDP. + + o Ability to request (and respond to a request for) a temporary IP + address on the remote end of a tunnel. + + o Ability to support various types of legacy authentication. + + o Ability to support window sizes greater than one. + + o Ability to establish multiple ESP and/or AH SAs within a single + IKE_SA. + + o Ability to rekey SAs. + + To assure interoperability, all implementations MUST be capable of + parsing all payload types (if only to skip over them) and to ignore + payload types that it does not support unless the critical bit is set + in the payload header. If the critical bit is set in an unsupported + payload header, all implementations MUST reject the messages + containing those payloads. + + Every implementation MUST be capable of doing four-message + IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, + one for ESP and/or AH). Implementations MAY be initiate-only or + respond-only if appropriate for their platform. Every implementation + MUST be capable of responding to an INFORMATIONAL exchange, but a + minimal implementation MAY respond to any INFORMATIONAL message with + an empty INFORMATIONAL reply (note that within the context of an + IKE_SA, an "empty" message consists of an IKE header followed by an + Encrypted payload with no payloads contained in it). A minimal + + + +Kaufman, et al. Expires August 28, 2008 [Page 104] + +Internet-Draft IKEv2bis February 2008 + + + implementation MAY support the CREATE_CHILD_SA exchange only in so + far as to recognize requests and reject them with a Notify payload of + type NO_ADDITIONAL_SAS. A minimal implementation need not be able to + initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA + expires (based on locally configured values of either lifetime or + octets passed), and implementation MAY either try to renew it with a + CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and + create a new one. If the responder rejects the CREATE_CHILD_SA + request with a NO_ADDITIONAL_SAS notification, the implementation + MUST be capable of instead deleting the old SA and creating a new + one. + + Implementations are not required to support requesting temporary IP + addresses or responding to such requests. If an implementation does + support issuing such requests, it MUST include a CP payload in + message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or + INTERNAL_IP6_ADDRESS. All other fields are optional. If an + implementation supports responding to such requests, it MUST parse + the CP payload of type CFG_REQUEST in message 3 and recognize a field + of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports + leasing an address of the appropriate type, it MUST return a CP + payload of type CFG_REPLY containing an address of the requested + type. {{ Demoted the SHOULD }} The responder may include any other + related attributes. + + A minimal IPv4 responder implementation will ignore the contents of + the CP payload except to determine that it includes an + INTERNAL_IP4_ADDRESS attribute and will respond with the address and + other related attributes regardless of whether the initiator + requested them. + + A minimal IPv4 initiator will generate a CP payload containing only + an INTERNAL_IP4_ADDRESS attribute and will parse the response + ignoring attributes it does not know how to use. + + For an implementation to be called conforming to this specification, + it MUST be possible to configure it to accept the following: + + o PKIX Certificates containing and signed by RSA keys of size 1024 + or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, + ID_RFC822_ADDR, or ID_DER_ASN1_DN. + + o Shared key authentication where the ID passed is any of ID_KEY_ID, + ID_FQDN, or ID_RFC822_ADDR. + + o Authentication where the responder is authenticated using PKIX + Certificates and the initiator is authenticated using shared key + authentication. + + + +Kaufman, et al. Expires August 28, 2008 [Page 105] + +Internet-Draft IKEv2bis February 2008 + + +5. Security Considerations + + While this protocol is designed to minimize disclosure of + configuration information to unauthenticated peers, some such + disclosure is unavoidable. One peer or the other must identify + itself first and prove its identity first. To avoid probing, the + initiator of an exchange is required to identify itself first, and + usually is required to authenticate itself first. The initiator can, + however, learn that the responder supports IKE and what cryptographic + protocols it supports. The responder (or someone impersonating the + responder) can probe the initiator not only for its identity, but + using CERTREQ payloads may be able to determine what certificates the + initiator is willing to use. + + Use of EAP authentication changes the probing possibilities somewhat. + When EAP authentication is used, the responder proves its identity + before the initiator does, so an initiator that knew the name of a + valid initiator could probe the responder for both its name and + certificates. + + Repeated rekeying using CREATE_CHILD_SA without additional Diffie- + Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a + single key or overrun of either endpoint. Implementers should take + note of this fact and set a limit on CREATE_CHILD_SA exchanges + between exponentiations. This memo does not prescribe such a limit. + + The strength of a key derived from a Diffie-Hellman exchange using + any of the groups defined here depends on the inherent strength of + the group, the size of the exponent used, and the entropy provided by + the random number generator used. Due to these inputs, it is + difficult to determine the strength of a key for any of the defined + groups. Diffie-Hellman group number two, when used with a strong + random number generator and an exponent no less than 200 bits, is + common for use with 3DES. Group five provides greater security than + group two. Group one is for historic purposes only and does not + provide sufficient strength except for use with DES, which is also + for historic use only. Implementations should make note of these + estimates when establishing policy and negotiating security + parameters. + + Note that these limitations are on the Diffie-Hellman groups + themselves. There is nothing in IKE that prohibits using stronger + groups nor is there anything that will dilute the strength obtained + from stronger groups (limited by the strength of the other algorithms + negotiated including the prf function). In fact, the extensible + framework of IKE encourages the definition of more groups; use of + elliptical curve groups may greatly increase strength using much + smaller numbers. + + + +Kaufman, et al. Expires August 28, 2008 [Page 106] + +Internet-Draft IKEv2bis February 2008 + + + It is assumed that all Diffie-Hellman exponents are erased from + memory after use. In particular, these exponents MUST NOT be derived + from long-lived secrets like the seed to a pseudo-random generator + that is not erased after use. + + The strength of all keys is limited by the size of the output of the + negotiated prf function. For this reason, a prf function whose + output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with + this protocol. + + The security of this protocol is critically dependent on the + randomness of the randomly chosen parameters. These should be + generated by a strong random or properly seeded pseudo-random source + (see [RANDOMNESS]). Implementers should take care to ensure that use + of random numbers for both keys and nonces is engineered in a fashion + that does not undermine the security of the keys. + + For information on the rationale of many of the cryptographic design + choices in this protocol, see [SIGMA] and [SKEME]. Though the + security of negotiated CHILD_SAs does not depend on the strength of + the encryption and integrity protection negotiated in the IKE_SA, + implementations MUST NOT negotiate NONE as the IKE integrity + protection algorithm or ENCR_NULL as the IKE encryption algorithm. + + When using pre-shared keys, a critical consideration is how to assure + the randomness of these secrets. The strongest practice is to ensure + that any pre-shared key contain as much randomness as the strongest + key being negotiated. Deriving a shared secret from a password, + name, or other low-entropy source is not secure. These sources are + subject to dictionary and social engineering attacks, among others. + + The NAT_DETECTION_*_IP notifications contain a hash of the addresses + and ports in an attempt to hide internal IP addresses behind a NAT. + Since the IPv4 address space is only 32 bits, and it is usually very + sparse, it would be possible for an attacker to find out the internal + address used behind the NAT box by trying all possible IP addresses + and trying to find the matching hash. The port numbers are normally + fixed to 500, and the SPIs can be extracted from the packet. This + reduces the number of hash calculations to 2^32. With an educated + guess of the use of private address space, the number of hash + calculations is much smaller. Designers should therefore not assume + that use of IKE will not leak internal address information. + + When using an EAP authentication method that does not generate a + shared key for protecting a subsequent AUTH payload, certain man-in- + the-middle and server impersonation attacks are possible [EAPMITM]. + These vulnerabilities occur when EAP is also used in protocols that + are not protected with a secure tunnel. Since EAP is a general- + + + +Kaufman, et al. Expires August 28, 2008 [Page 107] + +Internet-Draft IKEv2bis February 2008 + + + purpose authentication protocol, which is often used to provide + single-signon facilities, a deployed IPsec solution that relies on an + EAP authentication method that does not generate a shared key (also + known as a non-key-generating EAP method) can become compromised due + to the deployment of an entirely unrelated application that also + happens to use the same non-key-generating EAP method, but in an + unprotected fashion. Note that this vulnerability is not limited to + just EAP, but can occur in other scenarios where an authentication + infrastructure is reused. For example, if the EAP mechanism used by + IKEv2 utilizes a token authenticator, a man-in-the-middle attacker + could impersonate the web server, intercept the token authentication + exchange, and use it to initiate an IKEv2 connection. For this + reason, use of non-key-generating EAP methods SHOULD be avoided where + possible. Where they are used, it is extremely important that all + usages of these EAP methods SHOULD utilize a protected tunnel, where + the initiator validates the responder's certificate before initiating + the EAP exchange. {{ Demoted the SHOULD }} Implementers should + describe the vulnerabilities of using non-key-generating EAP methods + in the documentation of their implementations so that the + administrators deploying IPsec solutions are aware of these dangers. + + An implementation using EAP MUST also use strong authentication of + the server to the client before the EAP exchange begins, even if the + EAP method offers mutual authentication. This avoids having + additional IKEv2 protocol variations and protects the EAP data from + active attackers. + + If the messages of IKEv2 are long enough that IP-level fragmentation + is necessary, it is possible that attackers could prevent the + exchange from completing by exhausting the reassembly buffers. The + chances of this can be minimized by using the Hash and URL encodings + instead of sending certificates (see Section 3.6). Additional + mitigations are discussed in [DOSUDPPROT]. + +5.1. Traffic selector authorization + + {{ Added this section from Clarif-4.13 }} + + 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 [IPSECARCH] 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 + + + +Kaufman, et al. Expires August 28, 2008 [Page 108] + +Internet-Draft IKEv2bis February 2008 + + + 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 [IPSECARCH], "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 [H2HIPSEC] for an extensive + discussion about this issue, and the limitations of host-to-host + IPsec in general. + + +6. IANA Considerations + + {{ This section was changed to not re-define any new IANA registries. + + + +Kaufman, et al. Expires August 28, 2008 [Page 109] + +Internet-Draft IKEv2bis February 2008 + + + }} + + [IKEV2] defined many field types and values. IANA has already + registered those types and values, so the are not listed here again. + No new types or values are registered in this document. However, + IANA should update all references to RFC 4306 to point to this + document. + + +7. Acknowledgements + + The individuals on the IPsec mailing list was very helpful in both + pointing out where clarifications and changes were needed, as well as + in reviewing the clarifications suggested by others. + + The acknowledgements from the IKEv2 document were: + + This document is a collaborative effort of the entire IPsec WG. If + there were no limit to the number of authors that could appear on an + RFC, the following, in alphabetical order, would have been listed: + Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt + Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John + Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero + Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer + Reingold, and Michael Richardson. Many other people contributed to + the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, + each of which has its own list of authors. Hugh Daniel suggested the + feature of having the initiator, in message 3, specify a name for the + responder, and gave the feature the cute name "You Tarzan, Me Jane". + David Faucher and Valery Smyzlov helped refine the design of the + traffic selector negotiation. + + This paragraph lists references that appear only in figures. The + section is only here to keep the 'xml2rfc' program happy, and needs + to be removed when the document is published. Feel free to ignore + it. [DES] [IDEA] [MD5] [X.501] [X.509] + + +8. References + +8.1. Normative References + + [ADDGROUP] + Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [ADDRIPV6] + + + +Kaufman, et al. Expires August 28, 2008 [Page 110] + +Internet-Draft IKEv2bis February 2008 + + + Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 4291, February 2006. + + [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, "Extensible Authentication Protocol (EAP)", + RFC 3748, June 2004. + + [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, September 2001. + + [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [IPSECARCH] + Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [MUSTSHOULD] + Bradner, S., "Key Words for use in RFCs to indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the + Internet Key Exchange Protocol (IKE)", RFC 4434, + February 2006. + + [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The + Advanced Encryption Standard-Cipher-based Message + Authentication Code-Pseudo-Random Function-128 (AES-CMAC- + PRF-128) Algorithm for the Internet Key Exchange Protocol + (IKE)", RFC 4615, August 2006. + + [UDPENCAPS] + Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", + RFC 3948, January 2005. + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 111] + +Internet-Draft IKEv2bis February 2008 + + +8.2. Informative References + + [AH] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [ARCHGUIDEPHIL] + Bush, R. and D. Meyer, "Some Internet Architectural + Guidelines and Philosophy", RFC 3439, December 2002. + + [ARCHPRINC] + Carpenter, B., "Architectural Principles of the Internet", + RFC 1958, June 1996. + + [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and + Implementation Guidelines", RFC 4718, October 2006. + + [DES] American National Standards Institute, "American National + Standard for Information Systems-Data Link Encryption", + ANSI X3.106, 1983. + + [DH] Diffie, W. and M. Hellman, "New Directions in + Cryptography", IEEE Transactions on Information Theory, + V.IT-22 n. 6, June 1977. + + [DHCP] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [DIFFSERVARCH] + Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Services", RFC 2475. + + [DIFFSERVFIELD] + Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + [DIFFTUNNEL] + Black, D., "Differentiated Services and Tunnels", + RFC 2983, October 2000. + + [DOI] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [DOSUDPPROT] + C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection + for UDP-based protocols", ACM Conference on Computer and + + + +Kaufman, et al. Expires August 28, 2008 [Page 112] + +Internet-Draft IKEv2bis February 2008 + + + Communications Security , October 2003. + + [DSS] National Institute of Standards and Technology, U.S. + Department of Commerce, "Digital Signature Standard", + FIPS 186, May 1994. + + [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in + Tunneled Authentication Protocols", November 2002, + . + + [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [EXCHANGEANALYSIS] + R. Perlman and C. Kaufman, "Analysis of the IPsec key + exchange Standard", WET-ICE Security Conference, MIT , + 2001, + . + + [H2HIPSEC] + Aura, T., Roe, M., and A. Mohammed, "Experiences with + Host-to-Host IPsec", 13th International Workshop on + Security Protocols, Cambridge, UK, April 2005. + + [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + + [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH + Series in Information Processing, v. 1, Konstanz: Hartung- + Gorre Verlag, 1992. + + [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", + RFC 3490, March 2003. + + [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange + (IKE)", RFC 2409, November 1998. + + [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP + Payload Compression Protocol (IPComp)", RFC 3173, + September 2001. + + [IPSECARCH-OLD] + Kent, S. and R. Atkinson, "Security Architecture for the + + + +Kaufman, et al. Expires August 28, 2008 [Page 113] + +Internet-Draft IKEv2bis February 2008 + + + Internet Protocol", RFC 2401, November 1998. + + [IPV6ADDR] + Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet + Security Association and Key Management Protocol + (ISAKMP)", RFC 2408, November 1998. + + [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [MAILFORMAT] + Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support + in IPv6", RFC 3775, June 2004. + + [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [MODES] National Institute of Standards and Technology, U.S. + Department of Commerce, "Recommendation for Block Cipher + Modes of Operation", SP 800-38A, 2001. + + [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", + RFC 2486, January 1999. + + [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation + (NAT) Compatibility Requirements", RFC 3715, March 2004. + + [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", + RFC 2412, November 1998. + + [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key + Management API, Version 2", RFC 2367, July 1998. + + [PHOTURIS] + Karn, P. and W. Simpson, "Photuris: Session-Key Management + Protocol", RFC 2522, March 1999. + + [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, + "Remote Authentication Dial In User Service (RADIUS)", + + + +Kaufman, et al. Expires August 28, 2008 [Page 114] + +Internet-Draft IKEv2bis February 2008 + + + RFC 2138, April 1997. + + [RANDOMNESS] + Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange + (IKEv2) Protocol", RFC 4478, April 2006. + + [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for + Obtaining Digital Signatures and Public-Key + Cryptosystems", February 1978. + + [SHA] National Institute of Standards and Technology, U.S. + Department of Commerce, "Secure Hash Standard", + FIPS 180-1, May 1994. + + [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to + Authenticated Diffie-Hellman and its Use in the IKE + Protocols", Advances in Cryptography - CRYPTO 2003 + Proceedings LNCS 2729, 2003, . + + [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange + Mechanism for Internet", IEEE Proceedings of the 1996 + Symposium on Network and Distributed Systems Security , + 1996. + + [TRANSPARENCY] + Carpenter, B., "Internet Transparency", RFC 2775, + February 2000. + + [X.501] ITU-T, "Recommendation X.501: Information Technology - + Open Systems Interconnection - The Directory: Models", + 1993. + + [X.509] ITU-T, "Recommendation X.509 (1997 E): Information + Technology - Open Systems Interconnection - The Directory: + Authentication Framework", 1997. + + +Appendix A. Summary of changes from IKEv1 + + The goals of this revision to IKE are: + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 115] + +Internet-Draft IKEv2bis February 2008 + + + 1. To define the entire IKE protocol in a single document, + replacing RFCs 2407, 2408, and 2409 and incorporating subsequent + changes to support NAT Traversal, Extensible Authentication, and + Remote Address acquisition; + + 2. To simplify IKE by replacing the eight different initial + exchanges with a single four-message exchange (with changes in + authentication mechanisms affecting only a single AUTH payload + rather than restructuring the entire exchange) see + [EXCHANGEANALYSIS]; + + 3. To remove the Domain of Interpretation (DOI), Situation (SIT), + and Labeled Domain Identifier fields, and the Commit and + Authentication only bits; + + 4. To decrease IKE's latency in the common case by making the + initial exchange be 2 round trips (4 messages), and allowing the + ability to piggyback setup of a CHILD_SA on that exchange; + + 5. To replace the cryptographic syntax for protecting the IKE + messages themselves with one based closely on ESP to simplify + implementation and security analysis; + + 6. To reduce the number of possible error states by making the + protocol reliable (all messages are acknowledged) and sequenced. + This allows shortening CREATE_CHILD_SA exchanges from 3 messages + to 2; + + 7. To increase robustness by allowing the responder to not do + significant processing until it receives a message proving that + the initiator can receive messages at its claimed IP address; + + 8. To fix cryptographic weaknesses such as the problem with + symmetries in hashes used for authentication documented by Tero + Kivinen; + + 9. To specify Traffic Selectors in their own payloads type rather + than overloading ID payloads, and making more flexible the + Traffic Selectors that may be specified; + + 10. To specify required behavior under certain error conditions or + when data that is not understood is received in order to make it + easier to make future revisions in a way that does not break + backwards compatibility; + + 11. To simplify and clarify how shared state is maintained in the + presence of network failures and Denial of Service attacks; and + + + + +Kaufman, et al. Expires August 28, 2008 [Page 116] + +Internet-Draft IKEv2bis February 2008 + + + 12. To maintain existing syntax and magic numbers to the extent + possible to make it likely that implementations of IKEv1 can be + enhanced to support IKEv2 with minimum effort. + + +Appendix B. Diffie-Hellman Groups + + There are two Diffie-Hellman groups defined here for use in IKE. + These groups were generated by Richard Schroeppel at the University + of Arizona. Properties of these primes are described in [OAKLEY]. + + The strength supplied by group one may not be sufficient for the + mandatory-to-implement encryption algorithm and is here for historic + reasons. + + Additional Diffie-Hellman groups have been defined in [ADDGROUP]. + +B.1. Group 1 - 768 Bit MODP + + This group is assigned id 1 (one). + + The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } + Its hexadecimal value is: + + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF + + The generator is 2. + +B.2. Group 2 - 1024 Bit MODP + + This group is assigned id 2 (two). + + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + Its hexadecimal value is: + + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + FFFFFFFF FFFFFFFF + + The generator is 2. + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 117] + +Internet-Draft IKEv2bis February 2008 + + +Appendix C. Exchanges and Payloads + + {{ Clarif-AppA }} + + 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, the + other text is considered correct. + + Vendor-ID (V) payloads may be included in any place in any message. + This sequence here shows what are the most logical places for them. + +C.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+] + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 118] + +Internet-Draft IKEv2bis February 2008 + + +C.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+] + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 119] + +Internet-Draft IKEv2bis February 2008 + + +C.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+] + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 120] + +Internet-Draft IKEv2bis February 2008 + + +C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs + + request --> [N(REKEY_SA)], + [CP(CFG_REQUEST)], + [N(IPCOMP_SUPPORTED)+], + [N(USE_TRANSPORT_MODE)], + [N(ESP_TFC_PADDING_NOT_SUPPORTED)], + [N(NON_FIRST_FRAGMENTS_ALSO)], + SA, Ni, [KEi], TSi, TSr + + response <-- [CP(CFG_REPLY)], + [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)] + +C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA + + request --> SA, Ni, [KEi] + + response <-- SA, Nr, [KEr] + +C.6. INFORMATIONAL Exchange + + request --> [N+], + [D+], + [CP(CFG_REQUEST)] + + response <-- [N+], + [D+], + [CP(CFG_REPLY)] + + +Appendix D. Changes Between Internet Draft Versions + + This section will be removed before publication as an RFC, but should + be left intact until then so that reviewers can follow what has + changed. + +D.1. Changes from IKEv2 to draft -00 + + There were a zillion additions from RFC 4718. These are noted with + "{{ Clarif-nn }}". + + Cleaned up many of the figures. Made the table headings consistent. + Made some tables easier to read by removing blank spaces. Removed + + + +Kaufman, et al. Expires August 28, 2008 [Page 121] + +Internet-Draft IKEv2bis February 2008 + + + the "reserved to IANA" and "private use" text wording and moved it + into the tables. + + Changed many SHOULD requirements to better match RFC 2119. These are + also marked with comments such as "{{ Demoted the SHOULD }}". + + In Section 2.16, changed the MUST requirement of authenticating the + responder from "public key signature based" to "strong" because that + is what most current IKEv2 implementations do, and it better matches + the actual security requirement. + +D.2. Changes from draft -00 to draft -01 + + The most significant technical change was to make KE optional but + strongly recommended in Section 1.3.2. + + Updated all references to the IKEv2 Clarifications document to RFC + 4718. + + Moved a lot of the protocol description out of the long tables in + Section 3.10.1 into the body of the document. These are noted with + "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. + + Made some table changes based on suggestions from Alfred Hoenes. + + Changed "byte" to "octet" in many places. + + Removed discussion of ESP+AH bundles in many places, and added a + paragraph about it in Section 1.7. + + Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and + added a paragraph about it in Section 1.7. + + Moved Clarif-7.10 from Section 1.2 to Section 3.2. + + In the figure in Section 1.3.2, made KEi optional, and added text + saying "The KEi payload SHOULD be included." + + In the figure in Section 1.3.2, maked KEr optional, and removed text + saying "KEi and KEr are required for rekeying an IKE_SA." + + In Section 1.4, clarified that the half-closed connections being + discussed are AH and ESP. + + Rearranged the end of Section 1.7, and added the new notation for + moving text out of 3.10.1. + + Clarified the wording in the second paragraph of Section 2.2. This + + + +Kaufman, et al. Expires August 28, 2008 [Page 122] + +Internet-Draft IKEv2bis February 2008 + + + allowd the removal of the fourth paragraph, which previously had + Clarif-2.2 in it. + + In section 2.5, removed "or later" from "version 2.0". + + Added the question for implementers about payload order at the end of + Section 2.5. + + Corrected Section 2.7 based on Clarif-7-13 to say that you can't do + ESP and AH at one time. + + In Section 2.8, clarified the wording about how to replace an IKE_SA. + + Clarified the text in the last many paragraphs in Section 2.9. Also + moved some text from near the beginning of 2.9 to the beginning of + 2.9.1. + + Removed some redundant text in Section 2.9 concerning creating a + CHILD_SA pair not in response to an arriving packet. + + Added the following to the end of the first paragraph of Section + 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of + the agreed-to PRF." + + Added the restriction in Section 2.15 that all PRFs used with IKEv2 + MUST take variable-sized keys. + + In Section 2.17, removed "If multiple IPsec protocols are negotiated, + keying material is taken in the order in which the protocol headers + will appear in the encapsulated packet" because multiple IPsec + protocols cannot be negotiated at one time. + + Added the material from Clarif-5.12 to Section 2.18. + + Changed "hash of" to "expected value of" in Section 2.23. + + In the bulleted list in Section 2.23, replaced "this end" with a + clearer description of which system is being discussed. + + Added the paragraph at the beginning of Section 3 about + interoperability and UNSPECIFIED values ("In the tables in this + section..."). + + Fixed Section 3.3 to not include proposal that include both AH and + ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. + + In the description of ID_FQDN in Section 3.5, added "All characters + in the ID_FQDN are ASCII; this follows that for an "internationalized + + + +Kaufman, et al. Expires August 28, 2008 [Page 123] + +Internet-Draft IKEv2bis February 2008 + + + domain name" as defined in [IDNA]." + + In Section 3.8, shortened and clarified the description of "RSA + Digital Signature". + + In Section 3.10, shortened and clarified the description of "Protocol + ID". + + In Section 3.15, "The requested address is valid until the expiry + time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are + no IKE_SAs between the peers" is shortened to just "The requested + address is valid until there are no IKE_SAs between the peers." + + In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. + + Made [ADDRIPV6] an informative reference instead of a normative + reference and updated it. + + Made [PKCS1] a normative reference instead of an informative + reference and changed the pointer to RFC 3447. + +D.3. Changes from draft -00 to draft -01 + + In Section 1.5, added "request" to first sentence to make it "If an + encrypted IKE request packet arrives on port 500 or 4500 with an + unrecognized SPI...". + + In Section 3.3, fifth paragraph, upped the number of transforms for + AH and ESP by one each to account for ESN, which is now mandatory. + + In Section 2.1, added "or equal to" in "The responder MUST remember + each response until it receives a request whose sequence number is + larger than or equal to the sequence number in the response plus its + window size." + + In Section 2.18, removed " Note that this may not work if the new + IKE_SA's PRF has a fixed key size because the output of the PRF may + not be of the correct size." because it is no longer relevant. + +D.4. Changes from draft -01 to draft -02 + + Many grammatical fixes. + + In Section 1.2, reworded Clarif-4.3 to be clearer. + + In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove + redundant text. + + + + +Kaufman, et al. Expires August 28, 2008 [Page 124] + +Internet-Draft IKEv2bis February 2008 + + + In Section 2.13, replaced text about variable length keys with + clearer explanation and requirement on non-HMAC PRFs. Also added + "preferred" to Section 2.14 for the key length, and removed redundant + text. + + In Section 2.14, removed the "half and half" description and replaced + it with exceptions for RFC4434 and RFC4615. + + Removed the now-redundant "All PRFs used with IKEv2 MUST take + variable-sized keys" from Section 2.15. + + In Section 2.15, added "(IKE_SA_INIT response)" after "of the second + message" and "(IKE_SA_INIT request)" after "the first message". + + In Section 2.17, simplified because there are no more bundles. "A + single CHILD_SA negotiation may result in multiple security + associations. ESP and AH SAs exist in pairs (one in each + direction)." becomes "For ESP and AH, a single CHILD_SA negotiation + results in two security associations (one in each direction)." + + In section 3.3, made the example of combinations of algorithms and + the contents of the first proposal clearer. + + Added Clarif-4.4 to the ned of Section 3.3.2. + + Reordered Section 3.3.5 and added Clarif-7.11. + + Clarified Section 3.3.6 about choosing a single proposal. Also added + second paragraph about transforms not understood, and clarified third + paragraph about picking D-H groups. + + Moved 3.10.1-16392 from Section 3.6 to 3.7. + + In Section 3.10, clarified 3.10.1-16394. + + Updated Section 6 to indicate that there is nothing new for IANA in + this spec. Also removed the definition of "Expert Review" from + Section 1.6 for the same reason. + + In Appendix A, removed "and not commit any state to an exchange until + the initiator can be cryptographically authenticated" because that + was only true in an earlier version of IKEv2. + +D.5. Changes from draft -02 to draft -03 + + In Section 1.3, changed "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 + + + +Kaufman, et al. Expires August 28, 2008 [Page 125] + +Internet-Draft IKEv2bis February 2008 + + + Notification payload." to "If the responder selects a proposal using + a different Diffie-Hellman group (other than NONE), the responder + MUST reject the request and indicate its preferred Diffie-Hellman + group in the INVALID_KE_PAYLOAD Notification payload. + + In Section 2.3, added the last two paragraphs covering why you + initiator's SPI and/or IP to differentiate if this is a "half-open" + IKE_SA or a new request. Also removed similar text from Section 2.2. + + In Section 2.5, added "Payloads sent in IKE response messages MUST + NOT have the critical flag set. Note that the critical flag applies + only to the payload type, not the contents. If the payload type is + recognized, but the payload contains something which is not (such as + an unknown transform inside an SA payload, or an unknown Notify + Message Type inside a Notify payload), the critical flag is ignored." + + In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the + section. Also reworded the text to make it clearer what the COOKIE + is for. + + Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. + + In Section 2.13, added "(see Section 3.3.5 for the defintion of the + Key Length transform attribute)". + + In Section 2.17, change the description of the keying material from + the list with two bullets to a clearer list. + + In Section 2.23, added "Implementations MUST process received UDP- + encapsulated ESP packets even when no NAT was detected." + + In Section 3.3, changed "Each proposal may contain a" to "Each + proposal contains a". + + Added the asterisks to the tranform type table in Section 3.3.2 and + the types table in 3.3.3 to foreshadow future developments. + + In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) + because the RFCs listed didn't really specify how to implement them + in an interoperable fashion: + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 126] + +Internet-Draft IKEv2bis February 2008 + + + Encryption Algorithms + ENCR_DES_IV64 1 (RFC1827) + ENCR_3IDEA 8 (RFC2451) + ENCR_DES_IV32 9 + Pseudo-random Functions + PRF_HMAC_TIGER 3 (RFC2104) + Integrity Algorithms + AUTH_DES_MAC 3 + AUTH_KPDK_MD5 4 (RFC1826) + + In Section 3.4, added "(other than NONE)" to the second-to-last + paragraph. + + Rewrote the third paragraph of Section 3.14 to talk about other + modes, and to clarify which encryption and integrity protection we + are talking about. + + Changed the "Initialization Vector" bullet in Section 3.14 to specify + better what is needed for the IV. Upgraded the SHOULDs to MUSTs. + Also added the reference for [MODES]. + + In Section 5, in the second-to-last paragraph, changed "a public-key- + based" to "strong" to match the wording in Section 2.16. + + +Authors' Addresses + + Charlie Kaufman + Microsoft + 1 Microsoft Way + Redmond, WA 98052 + US + + Phone: 1-425-707-3335 + Email: charliek@microsoft.com + + + Paul Hoffman + VPN Consortium + 127 Segre Place + Santa Cruz, CA 95060 + US + + Phone: 1-831-426-9827 + Email: paul.hoffman@vpnc.org + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 127] + +Internet-Draft IKEv2bis February 2008 + + + Pasi Eronen + Nokia Research Center + P.O. Box 407 + FIN-00045 Nokia Group + Finland + + Email: pasi.eronen@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 128] + +Internet-Draft IKEv2bis February 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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). + + + + + +Kaufman, et al. Expires August 28, 2008 [Page 129] + diff --git a/doc/standards/draft-myers-ikev2-ocsp-03.txt b/doc/standards/draft-myers-ikev2-ocsp-03.txt deleted file mode 100644 index fb59fc958..000000000 --- a/doc/standards/draft-myers-ikev2-ocsp-03.txt +++ /dev/null @@ -1,785 +0,0 @@ - - - -Network Working Group M. Myers -Internet-Draft TraceRoute Security LLC -Expires: January 12, 2007 H. Tschofenig - Siemens - July 11, 2006 - - - OCSP Extensions to IKEv2 - draft-myers-ikev2-ocsp-03.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 12, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - While IKEv2 supports public key based authentication (PKI), the - corresponding use of in-band CRLs is problematic due to unbounded CRL - size. The size of an OCSP response is however well-bounded and - small. This document defines the "OCSP Content" extension to IKEv2. - A CERTREQ payload with "OCSP Content" identifies one or more trusted - OCSP responders and is a request for inclusion of an OCSP response in - the IKEv2 handshake. A cooperative recipient of such a request - - - -Myers & Tschofenig Expires January 12, 2007 [Page 1] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - - responds with a CERT payload containing the appropriate OCSP - response. This content is recognizable via the same "OCSP Content" - identifier. - - When certificates are used with IKEv2, the communicating peers need a - mechanism to determine the revocation status of the peer's - certificate. OCSP is one such mechanism. This document applies when - OCSP is desired and security policy prevents one of the IKEv2 peers - from accessing the relevant OCSP responder directly. Firewalls are - often deployed in a manner that prevents such access by IKEv2 peers - outside of an enterprise network. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6 - 4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 - 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . . . . 14 - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 2] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -1. Introduction - - Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] - supports a range of authentication mechanisms, including the use of - public key based authentication. Confirmation of certificate - reliability is essential to achieve the security assurances public - key cryptography provides. One fundamental element of such - confirmation is reference to certificate revocation status (see - [RFC3280] for additional detail). - - The historic means of determining certificate revocation status is - through the use of Certificate Revocation Lists (CRLs). IKEv2 allows - CRLs to be exchanged in-band via the CERT payload. - - CRLs can however grow unbounded in size. Many real-world examples - exist to demonstrate the impracticality of including a multi-megabyte - file in an IKE exchange. This constraint is particularly acute in - bandwidth limited environments (e.g., mobile communications). The - net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) - acquisition of these data, should they even be used at all. - - Reliance on OOB methods can be further complicated if access to - revocation data requires use of IPsec (and therefore IKE) to - establish secure and authorized access to the CRLs of an IKE - participant. Such network access deadlock further contributes to a - reduced reliance on certificate revocation status in favor of blind - trust. - - OCSP [RFC2560] offers a useful alternative. The size of an OCSP - response is bounded and small and therefore suitable for in-band - IKEv2 signaling of a certificate's revocation status. - - This document defines an extension to IKEv2 that enables the use of - OCSP for in-band signaling of certificate revocation status. A new - content encoding is defined for use in the CERTREQ and CERT payloads. - A CERTREQ payload with "OCSP Content" identifies one or more trusted - OCSP responders and is a request for inclusion of an OCSP response in - the IKEv2 handshake. A cooperative recipient of such a request - responds with a CERT payload containing the appropriate OCSP - response. This content is recognizable via the same "OCSP Content" - identifier. - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 3] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 4] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -3. Extension Definition - - With reference to Section 3.6 of [IKEv2], the values for the Cert - Encoding field of the CERT payload are extended as follows (see also - the IANA Considerations section of this document): - - Certificate Encoding Value - -------------------- ----- - OCSP Content 14 - -3.1. OCSP Request - - A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ - Payload indicates the presence of one or more OCSP Responder - certificate hashes in the Certificate Authority field of the CERTREQ - payload. - - The presence of OCSP Content (14) in a CERTREQ message: - - 1. identifies one or more OCSP responders trusted by the sender; - - 2. notifies the recipient of sender's support for the OCSP extension - to IKEv2; and - - 3. notifies the recipient of sender's desire to receive OCSP - confirmation in a subsequent CERT payload. - -3.2. OCSP Response - - A value of OCSP Content (14) in the Cert Encoding field of a CERT - Payload indicates the presence of an OCSP Response in the Certificate - Data field of the CERT payload. - - Correlation between an OCSP Response CERT payload and a corresponding - CERT payload carrying a certificate can be achieved by matching the - OCSP response CertID field to the certificate. See [RFC2560] for the - definition of OCSP response content. - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 5] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -4. Extension Requirements - -4.1. OCSP Request - - Section 3.7 of [IKEv2] allows for the concatenation of trust anchor - hashes as the Certification Authority value of a single CERTREQ - message. There is no means however to indicate which among those - hashes relates to the certificate of a trusted OCSP responder. - - Therefore an OCSP Request as defined in Section 3.1 above SHALL be - transmitted separate from any other CERTREQ payloads in an IKEv2 - exchange. - - Where it is useful to identify more than one trusted OCSP responder, - each such identification SHALL be concatenated in a manner identical - to the method documented in Section 3.7 of [IKEv2] regarding the - assembly of multiple trust anchor hashes. - - The Certification Authority value in an OCSP Request CERTREQ SHALL be - computed and produced in a manner identical to that of trust anchor - hashes as documented in Section 3.7 of [IKEv2]. - - Upon receipt of an OCSP Response CERT payload corresponding to a - prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the - OCSP response into path validation logic defined by [RFC3280]. - - The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if - either: - - 1. the corresponding OCSP Response CERT payload indicates that the - subject certificate is revoked; OR - - 2. the corresponding OCSP Response CERT payload indicates an OCSP - error (e.g., malformedRequest, internalError, tryLater, - sigRequired, unauthorized, etc.). - - The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange - if a corresponding OCSP Response CERT payload is not received. This - might be an indication that this OCSP extension is not supported. - -4.2. OCSP Response - - Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD - acquire the related OCSP-based assertion and produce and transmit an - OCSP Response CERT payload corresponding to the certificate needed to - verify its signature on IKEv2 payloads. - - An OCSP Response CERT payload SHALL be transmitted separate from any - - - -Myers & Tschofenig Expires January 12, 2007 [Page 6] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - - other CERT payload in an IKEv2 exchange. - - The means by which an OCSP response may be acquired for production of - an OCSP Response CERT payload is out of scope of this document. - - The structure and encoding of the Certificate Data field of an OCSP - Response CERT payload SHALL be identical to that defined in - [RFC2560]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 7] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -5. Examples and Discussion - - This section shows the standard IKEv2 message examples with both - peers, the initiator and the responder, using public key based - authentication, CERTREQ and CERT payloads. The first instance - corresponds to Section 1.2 of [IKEv2], the illustrations of which are - reproduced below for reference. - -5.1. Peer to Peer - - Application of the IKEv2 extensions defined in this document to the - peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as - follows. Messages are numbered for ease of reference. - - - Initiator Responder - ----------- ----------- - (1) HDR, SAi1, KEi, Ni --> - - (2) <-- HDR, SAr1, KEr, Nr, - CERTREQ(OCSP Request) - (3) HDR, SK {IDi, CERT(certificate),--> - CERT(OCSP Response), - CERTREQ(OCSP Request), - [IDr,] AUTH, SAi2, TSi, TSr} - - (4) <-- HDR, SK {IDr, - CERT(certificate), - CERT(OCSP Response), - AUTH, SAr2, TSi, TSr} - - In (2) Responder sends an OCSP Request CERTREQ payload identifying - one or more OCSP responders trusted by Responder. In response, - Initiator sends in (3) both a CERT payload carrying its certificate - and an OCSP Response CERT payload covering that certificate. In (3) - Initiator also requests an OCSP response via the OCSP Request CERTREQ - payload. In (4) Responder returns its certificate and a separate - OCSP Response CERT payload covering that certificate. - - It is important to note that in this scenario, the Responder in (2) - does not yet possess the Initiator's certificate and therefore cannot - form an OCSP request. [RFC2560] allows for pre-produced responses. - It is thus easily inferred that OCSP responses can be produced in the - absence of a corresponding request (OCSP nonces notwithstanding). In - such instances OCSP Requests are simply index values into these data. - - It is also important in extending IKEv2 towards OCSP in this scenario - that the Initiator has certain knowledge that the Responder is - - - -Myers & Tschofenig Expires January 12, 2007 [Page 8] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - - capable of and willing to participate in the extension. Yet the - Responder will only trust one or more OCSP responder signatures. - These factors motivate the definition of OCSP Responder Hash - extension. - -5.2. Extended Authentication Protocol (EAP) - - Another scenario of pressing interest is the use of EAP to - accommodate multiple end users seeking enterprise access to an IPsec - gateway. As with the preceding section, the following illustration - is extracted from [IKEv2]. In the event of a conflict between this - document and[IKEv2] regarding these illustrations, [IKEv2] SHALL - dominate. - - - Initiator Responder - ----------- ----------- - (1) HDR, SAi1, KEi, Ni --> - (2) <-- HDR, SAr1, KEr, Nr - (3) HDR, SK {IDi, --> - CERTREQ(OCSP Request), - [IDr,] AUTH, SAi2, TSi, TSr} - (4) <-- HDR, SK {IDr, - CERT(certificate), - CERT(OCSP Response), - AUTH, EAP} - (5) HDR, SK {EAP} --> - - (6) <-- HDR, SK {EAP (success)} - - (7) HDR, SK {AUTH} --> - - (8) <-- HDR, SK {AUTH, SAr2, TSi, - TSr } - - In the EAP scenario, messages (5) through (8) are not relevant to - this document. Note that while [IKEv2] allows for the optional - inclusion of a CERTREQ in (2), this document asserts no need of its - use. It is assumed that environments including this optional payload - and yet wishing to implement the OCSP extension to IKEv2 are - sufficiently robust as to accommodate this redundant payload. - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 9] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -6. Security Considerations - - For the reasons noted above, OCSP request as defined in Section 3.1 - is used in place of OCSP request syntax to trigger production and - transmission of an OCSP response. OCSP as defined in [RFC2560] may - contain a nonce request extension to improve security against replay - attacks (see Section 4.4.1 of [RFC2560] for further details). The - OCSP Request defined by this document cannot accommodate nonces. - [RFC2560] deals with this aspect by allowing pre-produced responses. - - [RFC2560] points to this replay vulnerability and indicates: "The use - of precomputed responses allows replay attacks in which an old (good) - response is replayed prior to its expiration date but after the - certificate has been revoked. Deployments of OCSP should carefully - evaluate the benefit of precomputed responses against the probability - of a replay attack and the costs associated with its successful - execution." Nodes SHOULD make the required freshness of an OCSP - Response configurable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 10] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -7. IANA Considerations - - This document defines one new field type for use in the IKEv2 Cert - Encoding field of the Certificate Payload format. Official - assignment of the "OCSP Content" extension to the Cert Encoding table - of Section 3.6 of [IKEv2] needs to be acquired from IANA. - - Certificate Encoding Value - -------------------- ----- - OCSP Content 14 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 11] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -8. Acknowledgements - - The authors would like to thank Russ Housley for his support. - Additionally, we would like to thank Pasi Eronen, Nicolas Williams, - Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their - review. - -9. Normative References - - [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", - RFC 4306, December 2005. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. - Adams, "X.509 Internet Public Key Infrastructure Online - Certificate Status Protocol - OCSP", RFC 2560, June 1999. - - [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 12] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -Authors' Addresses - - Michael Myers - TraceRoute Security LLC - - - Email: mmyers@fastq.com - - - Hannes Tschofenig - Siemens - Otto-Hahn-Ring 6 - Munich, Bavaria 81739 - Germany - - Email: Hannes.Tschofenig@siemens.com - URI: http://www.tschofenig.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 13] - -Internet-Draft OCSP Extensions to IKEv2 July 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (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. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Myers & Tschofenig Expires January 12, 2007 [Page 14] - - diff --git a/doc/standards/draft-sheffer-ipsec-failover-03.txt b/doc/standards/draft-sheffer-ipsec-failover-03.txt new file mode 100644 index 000000000..e624a95cd --- /dev/null +++ b/doc/standards/draft-sheffer-ipsec-failover-03.txt @@ -0,0 +1,1401 @@ + + + +Network Working Group Y. Sheffer +Internet-Draft Check Point +Intended status: Experimental H. Tschofenig +Expires: September 20, 2008 Nokia Siemens Networks + L. Dondeti + V. Narayanan + QUALCOMM, Inc. + March 19, 2008 + + + IPsec Gateway Failover Protocol + draft-sheffer-ipsec-failover-03.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 September 20, 2008. + +Abstract + + The Internet Key Exchange version 2 (IKEv2) protocol has + computational and communication overhead with respect to the number + of round-trips required and cryptographic operations involved. In + remote access situations, the Extensible Authentication Protocol is + used for authentication, which adds several more round trips and + therefore latency. + + To re-establish security associations (SA) upon a failure recovery + + + +Sheffer, et al. Expires September 20, 2008 [Page 1] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + condition is time consuming, especially when an IPsec peer, such as a + VPN gateway, needs to re-establish a large number of SAs with various + end points. A high number of concurrent sessions might cause + additional problems for an IPsec peer during SA re-establishment. + + In many failure cases it would be useful to provide an efficient way + to resume an interrupted IKE/IPsec session. This document proposes + an extension to IKEv2 that allows a client to re-establish an IKE SA + with a gateway in a highly efficient manner, utilizing a previously + established IKE SA. + + A client can reconnect to a gateway from which it was disconnected, + or alternatively migrate to another gateway that is associated with + the previous one. The proposed approach conveys IKEv2 state + information, in the form of an encrypted ticket, to a VPN client that + is later presented to the VPN gateway for re-authentication. The + encrypted ticket can only be decrypted by the VPN gateway in order to + restore state for faster session setup. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 2] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6 + 3.2. Recovering from an Application Server Failover . . . . . . 8 + 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9 + 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10 + 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12 + 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 12 + 4.2.3. Requesting a ticket during resumption . . . . . . . . 13 + 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13 + 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14 + 4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14 + 4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15 + 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16 + 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17 + 5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18 + 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19 + 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19 + 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19 + 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19 + 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20 + 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20 + 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22 + Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22 + B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . . . 25 + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 3] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +1. Introduction + + The Internet Key Exchange version 2 (IKEv2) protocol has + computational and communication overhead with respect to the number + of round-trips required and cryptographic operations involved. In + particular the Extensible Authentication Protocol is used for + authentication in remote access cases, which increases latency. + + To re-establish security associations (SA) upon a failure recovery + condition is time-consuming, especially when an IPsec peer, such as a + VPN gateway, needs to re-establish a large number of SAs with various + end points. A high number of concurrent sessions might cause + additional problems for an IPsec peer. + + In many failure cases it would be useful to provide an efficient way + to resume an interrupted IKE/IPsec session. This document proposes + an extension to IKEv2 that allows a client to re-establish an IKE SA + with a gateway in a highly efficient manner, utilizing a previously + established IKE SA. + + A client can reconnect to a gateway from which it was disconnected, + or alternatively migrate to another gateway that is associated with + the previous one. This document proposes to maintain IKEv2 state in + a "ticket", an opaque data structure created and used by a server and + stored by a client, which the client cannot understand or tamper + with. The IKEv2 protocol is extended to allow a client to request + and present a ticket. When two gateways mutually trust each other, + one can accept a ticket generated by the other. + + This approach is similar to the one taken by TLS session resumption + [RFC4507] with the required adaptations for IKEv2, e.g., to + accommodate the two-phase protocol structure. We have borrowed + heavily from that specification. + +1.1. Goals + + The high-level goal of this extension is to provide an IPsec failover + solution, according to the requirements defined in + [I-D.vidya-ipsec-failover-ps]. + + Specifically, the proposed extension should allow IPsec sessions to + be recovered from failures in remote access scenarios, in a more + efficient manner than the basic IKE solution. This efficiency is + primarily on the gateway side, since the gateway might have to deal + with many thousands of concurrent requests. We should enable the + following cases: + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 4] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + o Failover from one gateway to another, where the two gateways do + not share state but do have mutual trust. For example, the + gateways may be operated by the same provider and share the same + keying materials to access an encrypted ticket. + o Recovery from an intermittent connectivity, where clients + reconnect into the same gateway. In this case, the gateway would + typically have detected the clients' absence and removed the state + associated with them. + o Recovery from a gateway restart, where clients reconnect into the + same gateway. + + The proposed solution should additionally meet the following goals: + + o Using only symmetric cryptography to minimize CPU consumption. + o Allowing a gateway to push state to clients. + o Providing cryptographic agility. + o Having no negative impact on IKEv2 security features. + +1.2. Non-Goals + + The following are non-goals of this solution: + o Providing load balancing among gateways. + o Specifying how a client detects the need for a failover. + + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document uses terminology defined in [RFC4301], [RFC4306], and + [RFC4555]. In addition, this document uses the following terms: + + Secure domain: A secure domain comprises a set of gateways that are + able to resume an IKEv2 session that may have been established by + any other gateway within the domain. All gateways in the secure + domain are expected to share some secrets, so that they can + generate an IKEv2 ticket, verify the validity of the ticket and + extract the IKEv2 policy and session key material from the ticket. + IKEv2 ticket: An IKEv2 ticket is a data structure that contains all + the necessary information that allows any gateway within the same + secure domain as the gateway that created the ticket to verify the + validity of the ticket and extract IKEv2 policy and session keys + to re-establish an IKEv2 session. + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 5] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + Stateless failover: When the IKEv2 session state is stored at the + client, the IKEv2 responder is "stateless" until the client + restores the SA with one of the gateways within the secure domain; + thus, we refer to SA resumption with SA storage at the client as + stateless session resumption. + Stateful failover: When the infrastructure maintains IKEv2 session + state, we refer to the process of IKEv2 SA re-establishment as + stateful session resumption. + + +3. Usage Scenarios + + This specification envisions two usage scenarios for efficient IKEv2 + and IPsec SA session re-establishment. + + The first is similar to the use case specified in Section 1.1.3 of + the IKEv2 specification [RFC4306], where the IPsec tunnel mode is + used to establish a secure channel between a remote access client and + a gateway; the traffic flow may be between the client and entities + beyond the gateway. + + The second use case focuses on the usage of transport (or tunnel) + mode to secure the communicate between two end points (e.g., two + servers). The two endpoints have a client-server relationship with + respect to a protocol that runs using the protections afforded by the + IPsec SA. + +3.1. Recovering from a Remote Access Gateway Failover + + + + + + + + + + + + + + + + + + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 6] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + (a) + + +-+-+-+-+-+ +-+-+-+-+-+ + ! ! IKEv2/IKEv2-EAP ! ! Protected + ! Remote !<------------------------>! Remote ! Subnet + ! Access ! ! Access !<--- and/or + ! Client !<------------------------>! Gateway ! Internet + ! ! IPsec tunnel ! ! + +-+-+-+-+-+ +-+-+-+-+-+ + + + (b) + + +-+-+-+-+-+ +-+-+-+-+-+ + ! ! IKE_SESSION_RESUME ! ! + ! Remote !<------------------------>! New/Old ! + ! Access ! ! Gateway ! + ! Client !<------------------------>! ! + ! ! IPsec tunnel ! ! + +-+-+-+-+-+ +-+-+-+-+-+ + + + + Figure 1: Remote Access Gateway Failure + + In this scenario, an end-host (an entity with a host implementation + of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a + gateway in a remote network using IKEv2. The end-host in this + scenario is sometimes referred to as a remote access client. When + the remote gateway fails, all the clients associated with the gateway + either need to re-establish IKEv2 sessions with another gateway + within the same secure domain of the original gateway, or with the + original gateway if the server is back online soon. + + The clients may choose to establish IPsec SAs using a full IKEv2 + exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1). + + In this scenario, the client needs to get an IP address from the + remote network so that traffic can be encapsulated by the remote + access gateway before reaching the client. In the initial exchange, + the gateway may acquire IP addresses from the address pool of a local + DHCP server. The new gateway that a client gets associated may not + receive addresses from the same address pool. Thus, the session + resumption protocol needs to support the assignment of a new IP + address. + + The protocol defined in this document supports the re-allocation of + an IP address to the client, if this capability is provided by the + + + +Sheffer, et al. Expires September 20, 2008 [Page 7] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + network. For example, if routing tables are modified so that traffic + is rerouted through the new gateway. This capability is implicit in + the use of the IKE Config mechanism, which allows the client to + present its existing IP address and receive the same address back, if + allowed by the gateway. + + The protocol defined here supports both stateful and stateless + scenarios. In other words, tickets can be stored wholly on the + client, or the ticket can be stored on the gateway (or in a database + shared between multiple gateways), with the client only presenting a + handle that identifies a particular ticket. In fact these scenarios + are transparent to the protocols, with the only change being the non- + mandatory ticket format. + +3.2. Recovering from an Application Server Failover + + + (a) + + +-+-+-+-+-+ +-+-+-+-+-+ + ! App. ! IKEv2/IKEv2-EAP ! App. ! + ! Client !<------------------------>! Server ! + ! & ! ! & ! + ! IPsec !<------------------------>! IPsec ! + ! host ! IPsec transport/ ! host ! + +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ + + + (b) + + +-+-+-+-+-+ +-+-+-+-+-+ + ! App. ! IKE_SESSION_RESUME ! New ! + ! Client !<------------------------>! Server ! + ! & ! ! & ! + ! IPsec !<------------------------>! IPsec ! + ! host ! IPsec transport/ ! host ! + +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+ + + + Figure 2: Application Server Failover + + The second usage scenario is as follows: two entities with IPsec host + implementations establish an IPsec transport or tunnel mode SA + between themselves; this is similar to the model described in Section + 1.1.2. of [RFC4306]. At the application level, one of the entities + is always the client and the other is a server. From that view + point, the IKEv2 exchange is always initiated by the client. This + allows the Initiator (the client) to authenticate itself using EAP, + + + +Sheffer, et al. Expires September 20, 2008 [Page 8] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + as long as the Responder (or the application server) allows it. + + If the application server fails, the client may find other servers + within the same secure domain for service continuity. It may use a + full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re- + establish the IPsec SAs for secure communication required by the + application layer signaling. + + The client-server relationship at the application layer ensures that + one of the entities in this usage scenario is unambiguously always + the Initiator and the other the Responder. This role determination + also allows the Initiator to request an address in the Responder's + network using the Configuration Payload mechanism of the IKEv2 + protocol. If the client has thus received an address during the + initial IKEv2 exchange, when it associates with a new server upon + failure of the original server, it needs to request an address, + specifying its assigned address. The server may allow the client to + use the original address or if it is not permitted to use that + address, assign a new address. + + +4. Protocol Details + + This section provides protocol details and contains the normative + parts. This document defines two protocol exchanges, namely + requesting a ticket and presenting a ticket. Section 4.1 describes + the procedure to request a ticket and Section 4.2 illustrates how to + present a ticket. + +4.1. Requesting a Ticket + + A client MAY request a ticket in the following exchanges: + + o In an IKE_AUTH exchange, as shown in the example message exchange + in Figure 3 below. + o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed. + o In an Informational exchange, if the gateway previously replied + with an N(TICKET_ACK) instead of providing a ticket. + o In an Informational exchange, when the ticket lifetime is about to + expire. + o In an IKE_SESSION_RESUME exchange, see Section 4.2.3. + + Normally, a client requests a ticket in the third message of an IKEv2 + exchange (the first of IKE_AUTH). Figure 3 shows the message + exchange for this typical case. + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 9] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + Initiator Responder + ----------- ----------- + HDR, SAi1, KEi, Ni --> + + <-- HDR, SAr1, KEr, Nr, [CERTREQ] + + HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] + AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> + + Figure 3: Example Message Exchange for Requesting a Ticket + + The notification payloads are described in Section 4.3. The above is + an example, and IKEv2 allows a number of variants on these messages. + A complete description of IKEv2 can be found in [RFC4718]. + + When an IKEv2 responder receives a request for a ticket using the + N(TICKET_REQUEST) payload it MUST perform one of the following + operations if it supports the extension defined in this document: + o it creates a ticket and returns it with the N(TICKET_OPAQUE) + payload in a subsequent message towards the IKEv2 initiator. This + is shown in Figure 4. + o it returns an N(TICKET_NACK) payload, if it refuses to grant a + ticket for some reason. + o it returns an N(TICKET_ACK), if it cannot grant a ticket + immediately, e.g., due to packet size limitations. In this case + the client MAY request a ticket later using an Informational + exchange, at any time during the lifetime of the IKE SA. + + Provided the IKEv2 exchange was successful, the IKEv2 initiator can + accept the requested ticket. The ticket may be used later with an + IKEv2 responder which supports this extension. Figure 4 shows how + the initiator receives the ticket. + + + + Initiator Responder + ----------- ----------- + <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, + TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]} + + + Figure 4: Receiving a Ticket + +4.2. Presenting a Ticket + + Following a communication failure, a client re-initiates an IKE + exchange to the same gateway or to a different one, and includes a + ticket in the first message. A client MAY initiate a regular (non- + + + +Sheffer, et al. Expires September 20, 2008 [Page 10] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + ticket-based) IKEv2 exchange even if it is in possession of a valid + ticket. A client MUST NOT present a ticket after the ticket's + lifetime has expired. + + It is up to the client's local policy to decide when the + communication with the IKEv2 responder is seen as interrupted and a + new exchange needs to be initiated and the session resumption + procedure to be initiated. + + Tickets are intended for one-time use: a client MUST NOT reuse a + ticket, either with the same or with a different gateway. A gateway + SHOULD reject a reused ticket. Note however that a gateway can elect + not to retain a list of already-used tickets. Potential replay + attacks on such gateways are mitigated by the cookie mechanism + described in Section 4.2.2. + + This document specifies a new IKEv2 exchange type called + IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is + somewhat similar to the IKE_AUTH exchange, and results in the + creation of a Child SA. The client SHOULD NOT use this exchange type + unless it knows that the gateway supports it, either through + configuration, by out-of-band means or by using the Gateway List + provision. + + + + Initiator Responder + ----------- ----------- + HDR, Ni, N(TICKET_OPAQUE), [N+,] + SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> + + The exchange type in HDR is set to 'IKE_SESSION_RESUME'. + + See Section 4.2.1 for details on computing the protected (SK) + payload. + + When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE) + payload it MUST perform one of the following steps if it supports the + extension defined in this document: + o If it is willing to accept the ticket, it responds as shown in + Figure 5. + o It responds with an unprotected N(TICKET_NACK) notification, if it + rejects the ticket for any reason. In that case, the initiator + should re-initiate a regular IKE exchange. One such case is when + the responder receives a ticket for an IKE SA that has previously + been terminated on the responder itself, which may indicate + inconsistent state between the IKEv2 initiator and the responder. + However, a responder is not required to maintain the state for + + + +Sheffer, et al. Expires September 20, 2008 [Page 11] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + terminated sessions. + o When the responder receives a ticket for an IKE SA that is still + active and if the responder accepts it, then the old SAs SHOULD be + silently deleted without sending a DELETE informational exchange. + + + + Initiator Responder + ----------- ----------- + <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr], + [CP(CFG_REPLY)]} + + Figure 5: IKEv2 Responder accepts the ticket + + Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'. + + The SK payload is protected using the cryptographic parameters + derived from the ticket, see Section 4.2.1 below. + + At this point a new IKE SA is created by both parties, see + Section 4.6. This is followed by normal derivation of a child SA, + per Sec. 2.17 of [RFC4306]. + +4.2.1. Protection of the IKE_SESSION_RESUME Exchange + + The two messages of this exchange are protected by a "subset" IKE SA. + The key material is derived from the ticket, as follows: + + + {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni) + + where SK_d_old is the SK_d value of the original IKE SA, as retrieved + from the ticket. Ni guarantees freshness of the key material. SK_d2 + is used later to derive the new IKE SA, see Section 4.6. + + See [RFC4306] for the notation. "prf" is determined from the SA value + in the ticket. + +4.2.2. Presenting a Ticket: The DoS Case + + When receiving the first message of the IKE_SESSION_RESUME exchange, + the gateway may decide that it is under a denial-of-service attack. + In such a case, the gateway SHOULD defer the establishment of session + state until it has verified the identity of the client. We use a + variation of the IKEv2 Cookie mechanism, where the cookie is + protected. + + In the two messages that follow, the gateway responds that it is + + + +Sheffer, et al. Expires September 20, 2008 [Page 12] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + unwilling to resume the session until the client is verified, and the + client resubmits its first message, this time with the cookie: + + + + Initiator Responder + ----------- ----------- + <-- HDR, SK{N(COOKIE)} +HDR, Ni, N(TICKET_OPAQUE), [N+,] + SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} --> + + Assuming the cookie is correct, the gateway now replies normally. + + This now becomes a 4-message exchange. The entire exchange is + protected as defined in Section 4.2.1. + + See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding + the usage and syntax of the cookie. Note that the cookie is + completely independent of the IKEv2 ticket. + +4.2.3. Requesting a ticket during resumption + + When resuming a session, a client will typically request a new ticket + immediately, so it is able to resume the session again in the case of + a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE) + and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as + protected payloads to the IKE_SESSION_RESUME exchange. + + The returned ticket (if any) will correspond to the IKE SA created + per the rules described in Section 4.6. + +4.3. IKE Notifications + + This document defines a number of notifications. The notification + numbers are TBA by IANA. + + +---------------------+--------+-----------------+ + | Notification Name | Number | Data | + +---------------------+--------+-----------------+ + | TICKET_OPAQUE | TBA1 | See Section 4.4 | + | TICKET_REQUEST | TBA2 | None | + | TICKET_ACK | TBA3 | None | + | TICKET_NACK | TBA4 | None | + | TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 | + +---------------------+--------+-----------------+ + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 13] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +4.4. TICKET_OPAQUE Notify Payload + + The data for the TICKET_OPAQUE Notify payload consists of the Notify + message header, a lifetime field and the ticket itself. The four + octet lifetime field contains the number of seconds until the ticket + expires as an unsigned integer. Section 5.2 describes a possible + ticket format, and Section 5.3 offers further guidelines regarding + the ticket's lifetime. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Next Payload !C! Reserved ! Payload Length ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Lifetime ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! + ~ Ticket ~ + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Figure 6: TICKET_OPAQUE Notify Payload + +4.5. TICKET_GATEWAY_LIST Notify Payload + + The TICKET_GATEWAY_LIST Notify payload contains the Notify payload + header followed by a sequence of one or more gateway identifiers, + each of the format depicted in Figure 8. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Next Payload !C! Reserved ! Payload Length ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! Protocol ID ! SPI Size = 0 ! Notify Message Type ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! + ~ Gateway Identifier List ~ + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Figure 7: TICKET_GATEWAY_LIST Notify Payload + + + +Sheffer, et al. Expires September 20, 2008 [Page 14] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ID Type ! Reserved ! Length ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ! ! + ~ Identification Data ~ + ! ! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Figure 8: Gateway Identifier for One Gateway + + ID Type: + + The ID Type contains a restricted set of the IKEv2 ID payloads + (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR, + ID_IPV6_ADDR, ID_FQDN and the various reserved values. + + Reserved: + + This field must be sent as 0 and must be ignored when received. + + Length: + + The length field indicates the total size of the Identification + data. + + Identification Data: + + The Identification Data field is of variable length and depends on + the ID type. The length is not necessarily a multiple of 4. + +4.6. Processing Guidelines for IKE SA Establishment + + When a ticket is presented, the gateway parses the ticket to retrieve + the state of the old IKE SA, and the client retrieves this state from + its local store. Both peers now create state for the new IKE SA as + follows: + + o The SA value (transforms etc.) is taken directly from the ticket. + o The sequence numbers are reset to 0. + o The IDi value is obtained from the ticket. + o The IDr value is obtained from the new exchange. The gateway MAY + make policy decisions based on the IDr value encoded in the + ticket. + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 15] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + o The SPI values are created anew, similarly to a regular IKE + exchange. SPI values from the ticket SHOULD NOT be reused. This + restriction is to avoid problems caused by collisions with other + SPI values used already by the initiator/responder. The SPI value + should only be reused if collision avoidance can be ensured + through other means. + + The cryptographic material is refreshed based on the ticket and the + nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED + value is derived as follows: + + + SKEYSEED = prf(SK_d2, Ni | Nr) + + where SK_d2 was computed earlier (Section 4.2.1). + + The keys are derived as follows, unchanged from IKEv2: + + + {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = + prf+(SKEYSEED, Ni | Nr | SPIi | SPIr) + + where SPIi, SPIr are the SPI values created in the new IKE exchange. + + See [RFC4306] for the notation. "prf" is determined from the SA value + in the ticket. + + +5. The IKE Ticket + + This section lists the required contents of the ticket, and + recommends a non-normative format. This is followed by a discussion + of the ticket's lifecycle. + +5.1. Ticket Contents + + The ticket MUST encode at least the following state from an IKE SA. + These values MUST be encrypted and authenticated. + + o IDi, IDr. + o SPIi, SPIr. + o SAr (the accepted proposal). + o SK_d. + + In addition, the ticket MUST encode a protected ticket expiration + value. + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 16] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +5.2. Ticket Format + + This document does not specify a mandatory-to-implement or a + mandatory-to-use ticket format. The following format is RECOMMENDED, + if interoperability between gateways is desired. + + + struct { + [authenticated] struct { + octet format_version; // 1 for this version of the protocol + octet reserved[3]; // sent as 0, ignored by receiver. + octet key_id[8]; // arbitrary byte string + opaque IV[0..255]; // actual length (possibly 0) depends + // on the encryption algorithm + + [encrypted] struct { + opaque IDi, IDr; // the full payloads + octet SPIi[8], SPIr[8]; + opaque SA; // the full SAr payload + octet SK_d[0..255]; // actual length depends on SA value + int32 expiration; // an absolute time value, seconds + // since Jan. 1, 1970 + } ikev2_state; + } protected_part; + opaque MAC[0..255]; // the length (possibly 0) depends + // on the integrity algorithm + } ticket; + + Note that the key defined by "key_id" determines the encryption and + authentication algorithms used for this ticket. Those algorithms are + unrelated to the transforms defined by the SA payload. + + The reader is referred to a recent draft + [I-D.rescorla-stateless-tokens] that recommends a similar (but not + identical) ticket format, and discusses related security + considerations in depth. + +5.3. Ticket Identity and Lifecycle + + Each ticket is associated with a single IKE SA. In particular, when + an IKE SA is deleted, the client MUST delete its stored ticket. + + A ticket is therefore associated with the tuple (IDi, IDr). The + client MAY however use a ticket to approach other gateways that are + willing to accept it. How a client discovers such gateways is + outside the scope of this document. + + The lifetime of the ticket carried in the N(TICKET_OPAQUE) + + + +Sheffer, et al. Expires September 20, 2008 [Page 17] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + notification should be the minimum of the IKE SA lifetime (per the + gateway's local policy) and its re-authentication time, according to + [RFC4478]. Even if neither of these are enforced by the gateway, a + finite lifetime MUST be specified for the ticket. + +5.4. Exchange of Ticket-Protecting Keys + + This document does not define an interoperable mechanism for the + generation and distribution of the keys that protect IKE keys. Such + a mechanism can be developed, based on the GDOI group key exchange + protocol [RFC3547]. There is on-going work to enable the generation + of non-IPsec keys by means of GDOI, e.g. to provide RSVP router + groups with a single key [I-D.weis-gdoi-for-rsvp]. This work can be + generalized for our purposes. We note that there are no significant + performance requirements on such a protocol, as key rollover can be + at a daily or even more leisurely rate. + + +6. IANA Considerations + + This document requires a number of IKEv2 notification status types in + Section 4.3, to be registered by IANA. The corresponding registry + was established by IANA. + + The document defines a new IKEv2 exchange in Section 4.2. The + corresponding registry was established by IANA. + + +7. Security Considerations + + This section addresses security issues related to the usage of a + ticket. + +7.1. Stolen Tickets + + An eavesdropper or man-in-the-middle may try to obtain a ticket and + use it to establish a session with the IKEv2 responder. This can + happen in different ways: by eavesdropping on the initial + communication and copying the ticket when it is granted and before it + is used, or by listening in on a client's use of the ticket to resume + a session. However, since the ticket's contents is encrypted and the + attacker does not know the corresponding secret key (specifically, + SK_d), a stolen ticket cannot be used by an attacker to resume a + session. An IKEv2 responder MUST use strong encryption and integrity + protection of the ticket to prevent an attacker from obtaining the + ticket's contents, e.g., by using a brute force attack. + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 18] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +7.2. Forged Tickets + + A malicious user could forge or alter a ticket in order to resume a + session, to extend its lifetime, to impersonate as another user, or + to gain additional privileges. This attack is not possible if the + ticket is protected using a strong integrity protection algorithm. + +7.3. Denial of Service Attacks + + The key_id field defined in the recommended ticket format helps the + server efficiently reject tickets that it did not issue. However, an + adversary could generate and send a large number of tickets to a + gateway for verification. To minimize the possibility of such denial + of service, ticket verification should be lightweight (e.g., using + efficient symmetric key cryptographic algorithms). + +7.4. Ticket Protection Key Management + + A full description of the management of the keys used to protect the + ticket is beyond the scope of this document. A list of RECOMMENDED + practices is given below. + o The keys should be generated securely following the randomness + recommendations in [RFC4086]. + o The keys and cryptographic protection algorithms should be at + least 128 bits in strength. + o The keys should not be used for any other purpose than generating + and verifying tickets. + o The keys should be changed regularly. + o The keys should be changed if the ticket format or cryptographic + protection algorithms change. + +7.5. Ticket Lifetime + + An IKEv2 responder controls the lifetime of a ticket, based on the + operational and security requirements of the environment in which it + is deployed. The responder provides information about the ticket + lifetime to the IKEv2 initiator, allowing it to manage its tickets. + + An IKEv2 client may present a ticket in its possession to a gateway, + even if the IKE SA associated with this ticket had previously been + terminated by another gateway (the gateway that originally provided + the ticket). Where such usage is against the local security policy, + an Invalid Ticket List (ITL) may be used, see + [I-D.rescorla-stateless-tokens]. Management of such lists is outside + the scope of the current document. Note that a policy that requires + tickets to have shorter lifetimes (e.g., 1 hour) significantly + mitigates this risk. + + + + +Sheffer, et al. Expires September 20, 2008 [Page 19] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +7.6. Alternate Ticket Formats and Distribution Schemes + + If the ticket format or distribution scheme defined in this document + is not used, then great care must be taken in analyzing the security + of the solution. In particular, if confidential information, such as + a secret key, is transferred to the client, it MUST be done using + secure communication to prevent attackers from obtaining or modifying + the key. Also, the ticket MUST have its integrity and + confidentiality protected with strong cryptographic techniques to + prevent a breach in the security of the system. + +7.7. Identity Privacy, Anonymity, and Unlinkability + + This document mandates that the content of the ticket MUST be + encrypted in order to avoid leakage of information, such as the + identities of an IKEv2 initiator and a responder. Thus, it prevents + the disclosure of potentially sensitive information carried within + the ticket. + + When an IKEv2 initiator presents the ticket as part of the + IKE_SESSION_RESUME exchange, confidentiality is not provided for the + exchange. Although the ticket itself is encrypted there might still + be a possibility for an on-path adversary to observe multiple + exchange handshakes where the same ticket is used and therefore to + conclude that they belong to the same communication end points. + Administrators that use the ticket mechanism described in this + document should be aware that unlinkability may not be provided by + this mechanism. Note, however, that IKEv2 does not provide active + user identity confidentiality for the IKEv2 initiator either. + +7.8. Replay Protection in the IKE_SESSION_RESUME Exchange + + A major design goal of this protocol extension has been the two- + message exchange for session resumption. There is a tradeoff between + this abbreviated exchange and replay protection. It is RECOMMENDED + that the gateway should cache tickets, and reject replayed ones. + However some gateways may not do that in order to reduce state size. + In addition, an adversary may replay a ticket last presented to + gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2) + mitigates both scenarios by ensuring that the client presenting the + ticket is indeed its "owner": the client can be required by the + gateway to prove that it knows the ticket's secret, before any state + is committed on the gateway. Note that this is a stronger guarantee + than the regular IKE cookie mechanism, which only proves IP return + routability of the client. This is enabled by including the cookie + in the protected portion of the message. + + For performance reasons, the cookie mechanism is optional, and + + + +Sheffer, et al. Expires September 20, 2008 [Page 20] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + invoked by the gateway only when it suspects that it is the subject + of a denial-of-service attack. + + In any case, a ticket replayed by an adversary only causes partial + IKE state to be created on the gateway. The IKE exchange cannot be + completed and an IKE SA cannot be created unless the client knows the + ticket's secret values. + + +8. Acknowledgements + + We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler, + Yoav Nir and Tero Kivinen for their many helpful comments. + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + +9.2. Informative References + + [I-D.friedman-ike-short-term-certs] + Friedman, A., "Short-Term Certificates", + draft-friedman-ike-short-term-certs-02 (work in progress), + June 2007. + + [I-D.rescorla-stateless-tokens] + Rescorla, E., "How to Implement Secure (Mostly) Stateless + Tokens", draft-rescorla-stateless-tokens-01 (work in + progress), March 2007. + + [I-D.vidya-ipsec-failover-ps] + Narayanan, V., "IPsec Gateway Failover and Redundancy - + Problem Statement and Goals", + draft-vidya-ipsec-failover-ps-02 (work in progress), + December 2007. + + [I-D.weis-gdoi-for-rsvp] + Weis, B., "Group Domain of Interpretation (GDOI) support + for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress), + February 2008. + + + + +Sheffer, et al. Expires September 20, 2008 [Page 21] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The + Group Domain of Interpretation", RFC 3547, July 2003. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange + (IKEv2) Protocol", RFC 4478, April 2006. + + [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, + "Transport Layer Security (TLS) Session Resumption without + Server-Side State", RFC 4507, May 2006. + + [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol + (MOBIKE)", RFC 4555, June 2006. + + [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and + Implementation Guidelines", RFC 4718, October 2006. + + +Appendix A. Related Work + + [I-D.friedman-ike-short-term-certs] is on-going work that discusses + the use of short-term certificates for client re-authentication. It + is similar to the ticket approach described in this document in that + they both require enhancements to IKEv2 to allow information request, + e.g., for a certificate or a ticket. However, the changes required + by the former are fewer since an obtained certificate is valid for + any IKE responder that is able to verify them. On the other hand, + short-term certificates, while eliminating the usability issues of + user re-authentication, do not reduce the amount of effort performed + by the gateway in failover situations. + + +Appendix B. Change Log + +B.1. -03 + + Removed counter mechanism. Added an optional anti-DoS mechanism, + based on IKEv2 cookies (removed previous discussion of cookies). + Clarified that gateways may support reallocation of same IP address, + if provided by network. Proposed a solution outline to the problem + of key exchange for the keys that protect tickets. Added fields to + the ticket to enable interoperability. Removed incorrect MOBIKE + notification. + + + +Sheffer, et al. Expires September 20, 2008 [Page 22] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +B.2. -02 + + Clarifications on generation of SPI values, on the ticket's lifetime + and on the integrity protection of the anti-replay counter. + Eliminated redundant SPIs from the notification payloads. + +B.3. -01 + + Editorial review. Removed 24-hour limitation on ticket lifetime, + lifetime is up to local policy. + +B.4. -00 + + Initial version. This draft is a selective merge of + draft-sheffer-ike-session-resumption-00 and + draft-dondeti-ipsec-failover-sol-00. + + +Authors' Addresses + + Yaron Sheffer + Check Point Software Technologies Ltd. + 5 Hasolelim St. + Tel Aviv 67897 + Israel + + Email: yaronf@checkpoint.com + + + Hannes Tschofenig + Nokia Siemens Networks + Otto-Hahn-Ring 6 + Munich, Bavaria 81739 + Germany + + Email: Hannes.Tschofenig@nsn.com + URI: http://www.tschofenig.priv.at + + + Lakshminath Dondeti + QUALCOMM, Inc. + 5775 Morehouse Dr + San Diego, CA + USA + + Phone: +1 858-845-1267 + Email: ldondeti@qualcomm.com + + + + +Sheffer, et al. Expires September 20, 2008 [Page 23] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + + Vidya Narayanan + QUALCOMM, Inc. + 5775 Morehouse Dr + San Diego, CA + USA + + Phone: +1 858-845-2483 + Email: vidyan@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 24] + +Internet-Draft IPsec Gateway Failover Protocol March 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + + + + + + + + + + + +Sheffer, et al. Expires September 20, 2008 [Page 25] + + diff --git a/doc/standards/rfc4806.txt b/doc/standards/rfc4806.txt new file mode 100644 index 000000000..ab1c34f2c --- /dev/null +++ b/doc/standards/rfc4806.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group M. Myers +Request for Comments: 4806 TraceRoute Security LLC +Category: Standards Track H. Tschofenig + Siemens Networks GmbH & Co KG + February 2007 + + + Online Certificate Status Protocol (OCSP) Extensions to IKEv2 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Abstract + + While the Internet Key Exchange Protocol version 2 (IKEv2) supports + public key based authentication, the corresponding use of in-band + Certificate Revocation Lists (CRL) is problematic due to unbounded + CRL size. The size of an Online Certificate Status Protocol (OCSP) + response is however well-bounded and small. This document defines + the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP + Content" identifies zero or more trusted OCSP responders and is a + request for inclusion of an OCSP response in the IKEv2 handshake. A + cooperative recipient of such a request responds with a CERT payload + containing the appropriate OCSP response. This content is + recognizable via the same "OCSP Content" identifier. + + When certificates are used with IKEv2, the communicating peers need a + mechanism to determine the revocation status of the peer's + certificate. OCSP is one such mechanism. This document applies when + OCSP is desired and security policy prevents one of the IKEv2 peers + from accessing the relevant OCSP responder directly. Firewalls are + often deployed in a manner that prevents such access by IKEv2 peers + outside of an enterprise network. + + + + + + + + + +Myers & Tschofenig Standards Track [Page 1] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5 + 4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6 + 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6 + 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 + +1. Introduction + + Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] + supports a range of authentication mechanisms, including the use of + public key based authentication. Confirmation of certificate + reliability is essential in order to achieve the security assurances + public key cryptography provides. One fundamental element of such + confirmation is reference to certificate revocation status (see + [RFC3280] for additional detail). + + The traditional means of determining certificate revocation status is + through the use of Certificate Revocation Lists (CRLs). IKEv2 allows + CRLs to be exchanged in-band via the CERT payload. + + However, CRLs can grow unbounded in size. Many real-world examples + exist to demonstrate the impracticality of including a multi-megabyte + file in an IKE exchange. This constraint is particularly acute in + bandwidth-limited environments (e.g., mobile communications). The + net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) + acquisition of these data, should they even be used at all. + + Reliance on OOB methods can be further complicated if access to + revocation data requires use of IPsec (and therefore IKE) to + establish secure and authorized access to the CRLs of an IKE + participant. Such network access deadlock further contributes to a + reduced reliance on the status of certificate revocations in favor of + blind trust. + + + + + + +Myers & Tschofenig Standards Track [Page 2] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + + OCSP [RFC2560] offers a useful alternative. The size of an OCSP + response is bounded and small and therefore suitable for in-band + IKEv2 signaling of a certificate's revocation status. + + This document defines an extension to IKEv2 that enables the use of + OCSP for in-band signaling of certificate revocation status. A new + content encoding is defined for use in the CERTREQ and CERT payloads. + A CERTREQ payload with "OCSP Content" identifies zero or more trusted + OCSP responders and is a request for inclusion of an OCSP response in + the IKEv2 handshake. A cooperative recipient of such a request + responds with a CERT payload containing the appropriate OCSP + response. This content is recognizable via the same "OCSP Content" + identifier. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + This document defines the following terms: + + OCSP request: + + An OCSP request refers to the CERTREQ payload that contains a new + content encoding, referred to as OCSP Content, that conforms to + the definition and behavior specified in Section 3.1. + + OCSP response: + + An OCSP response refers to the CERT payload that contains a new + content encoding, referred to as OCSP Content, that conforms to + the definition and behavior specified in Section 3.2. + + OCSP responder: + + The term OCSP responder refers to the entity that accepts requests + from an OCSP client and returns responses as defined in [RFC2560]. + Note that the OCSP responder does not refer to the party that + sends the CERT message. + + + + + + + + + + + +Myers & Tschofenig Standards Track [Page 3] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +3. Extension Definition + + With reference to Section 3.6 of [IKEv2], the values for the Cert + Encoding field of the CERT payload are extended as follows (see also + the IANA Considerations section of this document): + + Certificate Encoding Value + -------------------- ----- + OCSP Content 14 + +3.1. OCSP Request + + A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ + Payload indicates the presence of zero or more OCSP responder + certificate hashes in the Certificate Authority field of the CERTREQ + payload. Section 2.2 of [RFC2560] defines responses, which belong to + one of the following three groups: + + (a) the CA who issued the certificate + + (b) a Trusted Responder whose public key is trusted by the requester + + (c) a CA Designated Responder (Authorized Responder) who holds a + specially marked certificate issued directly by the CA, + indicating that the responder may issue OCSP responses for that + CA + + In case of (a), the use of hashes in the CERTREQ message is not + needed since the OCSP response is signed by the CA who issued the + certificate. In case of (c), the OCSP response is signed by the CA + Designated Responder whereby the sender of the CERTREQ message does + not know the public key in advance. The presence of OCSP Content in + a CERTREQ message will identify one or more OCSP responders trusted + by the sender in case of (b). + + The presence of OCSP Content (14) in a CERTREQ message: + + 1. identifies zero or more OCSP responders trusted by the sender; + + 2. notifies the recipient of sender's support for the OCSP extension + to IKEv2; and + + 3. notifies the recipient of sender's desire to receive OCSP + confirmation in a subsequent CERT payload. + + + + + + + +Myers & Tschofenig Standards Track [Page 4] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +3.2. OCSP Response + + A value of OCSP Content (14) in the Cert Encoding field of a CERT + Payload indicates the presence of an OCSP response in the Certificate + Data field of the CERT payload. + + Correlation between an OCSP response CERT payload and a corresponding + CERT payload carrying a certificate can be achieved by matching the + OCSP response CertID field to the certificate. See [RFC2560] for the + definition of OCSP response content. + +4. Extension Requirements + +4.1. Request for OCSP Support + + Section 3.7 of [IKEv2] allows for the concatenation of trust anchor + hashes as the Certification Authority value of a single CERTREQ + message. There is no means however to indicate which among those + hashes, if present, relates to the certificate of a trusted OCSP + responder. + + Therefore, an OCSP request, as defined in Section 3.1 above, is + transmitted separate from any other CERTREQ payloads in an IKEv2 + exchange. + + Where it is useful to identify more than one trusted OCSP responder, + each such identification SHALL be concatenated in a manner identical + to the method documented in Section 3.7 of [IKEv2] regarding the + assembly of multiple trust anchor hashes. + + The Certification Authority value in an OCSP request CERTREQ SHALL be + computed and produced in a manner identical to that of trust anchor + hashes as documented in Section 3.7 of [IKEv2]. + + Upon receipt of an OCSP response CERT payload corresponding to a + prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the + OCSP response into path validation logic defined by [RFC3280]. + + Note that the lack of an OCSP response CERT payload after sending an + OCSP request CERT payload might be an indication that this OCSP + extension is not supported. As a result, it is recommended that + nodes be configured to require a response only if it is known that + all peers do in fact support this extension. Otherwise, it is + recommended that the nodes be configured to try OCSP and, if there is + no response, attempt to determine certificate revocation status by + some other means. + + + + + +Myers & Tschofenig Standards Track [Page 5] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +4.2. Response to OCSP Support + + Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD + acquire the related OCSP-based assertion and produce and transmit an + OCSP response CERT payload corresponding to the certificate needed to + verify its signature on IKEv2 payloads. + + An OCSP response CERT payload is transmitted separate from any other + CERT payload in an IKEv2 exchange. + + The means by which an OCSP response may be acquired for production of + an OCSP response CERT payload is out of scope of this document. + + The Certificate Data field of an OCSP response CERT payload SHALL + contain a DER-encoded OCSPResponse structure as defined in [RFC2560]. + +5. Examples and Discussion + + This section shows the standard IKEv2 message examples with both + peers, the initiator and the responder, using public key based + authentication, CERTREQ and CERT payloads. The first instance + corresponds to Section 1.2 of [IKEv2], the illustrations of which are + reproduced below for reference. + +5.1. Peer to Peer + + Application of the IKEv2 extensions defined in this document to the + peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as + follows. Messages are numbered for ease of reference. + + Initiator Responder + ----------- ----------- + (1) HDR, SAi1, KEi, Ni --> + + (2) <-- HDR, SAr1, KEr, Nr, + CERTREQ(OCSP Request) + (3) HDR, SK {IDi, CERT(certificate),--> + CERT(OCSP Response), + CERTREQ(OCSP Request), + [IDr,] AUTH, SAi2, TSi, TSr} + + (4) <-- HDR, SK {IDr, + CERT(certificate), + CERT(OCSP Response), + AUTH, SAr2, TSi, TSr} + + OCSP Extensions to Baseline IKEv2 + + + + +Myers & Tschofenig Standards Track [Page 6] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + + In (2), Responder sends an OCSP request CERTREQ payload identifying + zero or more OCSP responders trusted by the Responder. In response, + Initiator sends in (3) both a CERT payload carrying its certificate + and an OCSP response CERT payload covering that certificate. In (3), + Initiator also requests an OCSP response via the OCSP request CERTREQ + payload. In (4), the Responder returns its certificate and a + separate OCSP response CERT payload covering that certificate. + + It is important to note that in this scenario, the Responder in (2) + does not yet possess the Initiator's certificate and therefore cannot + form an OCSP request as defined in [RFC2560]. To bypass this + problem, hashes are used as defined in Section 4.1. In such + instances, OCSP Requests are simply index values into these data. + Thus, it is easily inferred that OCSP responses can be produced in + the absence of a corresponding request (provided that OCSP nonces are + not used, see Section 6). + + It is also important in extending IKEv2 toward OCSP in this scenario + that the Initiator has certain knowledge that the Responder is + capable of and willing to participate in the extension. Yet the + Responder will only trust one or more OCSP responder signatures. + These factors motivate the definition of OCSP responder hash + extension. + +5.2. Extended Authentication Protocol (EAP) + + Another scenario of pressing interest is the use of EAP to + accommodate multiple end users seeking enterprise access to an IPsec + gateway. Note that OCSP is used for the certificate status check of + the server side IKEv2 certificate and not for certificates that may + be used within EAP methods (either by the EAP peer or the EAP + server). As with the preceding section, the following illustration + is extracted from [IKEv2]. In the event of a conflict between this + document and [IKEv2] regarding these illustrations, [IKEv2] SHALL + dominate. + + + + + + + + + + + + + + + + +Myers & Tschofenig Standards Track [Page 7] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + + Initiator Responder + ----------- ----------- + (1) HDR, SAi1, KEi, Ni --> + (2) <-- HDR, SAr1, KEr, Nr + (3) HDR, SK {IDi, --> + CERTREQ(OCSP Request), + [IDr,] AUTH, SAi2, TSi, TSr} + (4) <-- HDR, SK {IDr, + CERT(certificate), + CERT(OCSP Response), + AUTH, EAP} + (5) HDR, SK {EAP} --> + + (6) <-- HDR, SK {EAP (success)} + + (7) HDR, SK {AUTH} --> + + (8) <-- HDR, SK {AUTH, SAr2, TSi, + TSr } + + OCSP Extensions to EAP in IKEv2 + + In the EAP scenario, messages (5) through (8) are not relevant to + this document. + +6. Security Considerations + + For the reasons noted above, an OCSP request, as defined in Section + 3.1, is used in place of an OCSP request syntax to trigger production + and transmission of an OCSP response. OCSP, as defined in [RFC2560], + may contain a nonce request extension to improve security against + replay attacks (see Section 4.4.1 of [RFC2560] for further details). + The OCSP request defined by this document cannot accommodate nonces. + [RFC2560] deals with this aspect by allowing pre-produced responses. + + [RFC2560] points to this replay vulnerability and indicates: "The use + of precomputed responses allows replay attacks in which an old (good) + response is replayed prior to its expiration date but after the + certificate has been revoked. Deployments of OCSP should carefully + evaluate the benefit of precomputed responses against the probability + of a replay attack and the costs associated with its successful + execution." Nodes SHOULD make the required freshness of an OCSP + response configurable. + + + + + + + + +Myers & Tschofenig Standards Track [Page 8] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +7. IANA Considerations + + This document defines one new field type for use in the IKEv2 Cert + Encoding field of the Certificate Payload format. Official + assignment of the "OCSP Content" extension to the Cert Encoding table + of Section 3.6 of [IKEv2] has been acquired from IANA. + + Certificate Encoding Value + -------------------- ----- + OCSP Content 14 + +8. Acknowledgements + + The authors would like to thank Russ Housley for his support. + Additionally, we would like to thank Pasi Eronen, Nicolas Williams, + Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their + review. Pasi gave us invaluable last-call comments. We would also + like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us + IESG review comments. + +9. Normative References + + [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. + Adams, "X.509 Internet Public Key Infrastructure Online + Certificate Status Protocol - OCSP", RFC 2560, June 1999. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + + + + + + + + + + + + + + +Myers & Tschofenig Standards Track [Page 9] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +Authors' Addresses + + Michael Myers + TraceRoute Security LLC + + EMail: mmyers@fastq.com + + + Hannes Tschofenig + Siemens Networks GmbH & Co KG + Otto-Hahn-Ring 6 + Munich, Bavaria 81739 + Germany + + EMail: Hannes.Tschofenig@siemens.com + URI: http://www.tschofenig.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Tschofenig Standards Track [Page 10] + +RFC 4806 OCSP Extensions to IKEv2 February 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Myers & Tschofenig Standards Track [Page 11] + -- cgit v1.2.3