diff options
Diffstat (limited to 'doc/ikev2')
20 files changed, 0 insertions, 56353 deletions
diff --git a/doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf b/doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf Binary files differdeleted file mode 100644 index 496421eb5..000000000 --- a/doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf +++ /dev/null diff --git a/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf b/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf Binary files differdeleted file mode 100644 index aa2cded2e..000000000 --- a/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf +++ /dev/null diff --git a/doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf b/doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf Binary files differdeleted file mode 100644 index d5d3b43cc..000000000 --- a/doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf +++ /dev/null diff --git a/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt b/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt deleted file mode 100644 index d4c67b161..000000000 --- a/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt +++ /dev/null @@ -1,3248 +0,0 @@ - - - -Network Working Group P. Eronen -Internet-Draft Nokia -Expires: August 6, 2006 P. Hoffman - VPN Consortium - February 2, 2006 - - - IKEv2 Clarifications and Implementation Guidelines - draft-eronen-ipsec-ikev2-clarifications-07.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 6, 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 August 6, 2006 [Page 1] - -Internet-Draft IKEv2 Clarifications February 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. (Section removed) . . . . . . . . . . . . . . . . . . . . 11 - 3.7. Certificate encoding types . . . . . . . . . . . . . . . . 11 - 3.8. Shared key authentication and fixed PRF key size . . . . . 12 - 3.9. EAP authentication and fixed PRF key size . . . . . . . . 13 - 3.10. Matching ID payloads to certificate contents . . . . . . . 13 - 3.11. Message IDs for IKE_AUTH messages . . . . . . . . . . . . 13 - 4. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1. Creating SAs with the CREATE_CHILD_SA exchange . . . . . . 14 - 4.2. Creating an IKE_SA without a CHILD_SA . . . . . . . . . . 16 - 4.3. Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 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 - 5. Rekeying and deleting SAs . . . . . . . . . . . . . . . . . . 21 - 5.1. Rekeying SAs with the CREATE_CHILD_SA exchange . . . . . . 21 - 5.2. Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 23 - 5.3. SPIs when rekeying the IKE_SA . . . . . . . . . . . . . . 23 - 5.4. SPI when rekeying a CHILD_SA . . . . . . . . . . . . . . . 24 - 5.5. Changing PRFs when rekeying the IKE_SA . . . . . . . . . . 24 - 5.6. Deleting vs. closing SAs . . . . . . . . . . . . . . . . . 24 - 5.7. Deleting a CHILD_SA pair . . . . . . . . . . . . . . . . . 25 - 5.8. Deleting an IKE_SA . . . . . . . . . . . . . . . . . . . . 25 - 5.9. Who is the original initiator of IKE_SA . . . . . . . . . 25 - 5.10. (Section removed) . . . . . . . . . . . . . . . . . . . . 25 - 5.11. Comparing nonces . . . . . . . . . . . . . . . . . . . . . 26 - 5.12. Exchange collisions . . . . . . . . . . . . . . . . . . . 26 - 5.13. Diffie-Hellman and rekeying the IKE_SA . . . . . . . . . . 34 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 2] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 6. Configuration payloads . . . . . . . . . . . . . . . . . . . . 35 - 6.1. Assigning IP addresses . . . . . . . . . . . . . . . . . . 35 - 6.2. (Section removed) . . . . . . . . . . . . . . . . . . . . 36 - 6.3. Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 36 - 6.4. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 36 - 6.5. INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 39 - 6.6. Configuration payloads for IPv6 . . . . . . . . . . . . . 40 - 6.7. INTERNAL_IP6_NBNS . . . . . . . . . . . . . . . . . . . . 42 - 6.8. INTERNAL_ADDRESS_EXPIRY . . . . . . . . . . . . . . . . . 42 - 6.9. Address assignment failures . . . . . . . . . . . . . . . 42 - 7. Miscellaneous issues . . . . . . . . . . . . . . . . . . . . . 43 - 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR . . . . . . . . . . 43 - 7.2. Relationship of IKEv2 to RFC4301 . . . . . . . . . . . . . 43 - 7.3. Reducing the window size . . . . . . . . . . . . . . . . . 44 - 7.4. Minimum size of nonces . . . . . . . . . . . . . . . . . . 44 - 7.5. Initial zero octets on port 4500 . . . . . . . . . . . . . 44 - 7.6. Destination port for NAT traversal . . . . . . . . . . . . 45 - 7.7. SPI values for messages outside of an IKE_SA . . . . . . . 45 - 7.8. Protocol ID/SPI fields in Notify payloads . . . . . . . . 46 - 7.9. Which message should contain INITIAL_CONTACT . . . . . . . 46 - 7.10. Alignment of payloads . . . . . . . . . . . . . . . . . . 46 - 7.11. Key length transform attribute . . . . . . . . . . . . . . 47 - 7.12. IPsec IANA considerations . . . . . . . . . . . . . . . . 47 - 7.13. Combining ESP and AH . . . . . . . . . . . . . . . . . . . 48 - 8. Status of the clarifications . . . . . . . . . . . . . . . . . 48 - 9. Implementation mistakes . . . . . . . . . . . . . . . . . . . 50 - 10. Security considerations . . . . . . . . . . . . . . . . . . . 51 - 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 51 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 51 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 52 - Appendix A. Exchanges and payloads . . . . . . . . . . . . . . . 53 - A.1. IKE_SA_INIT exchange . . . . . . . . . . . . . . . . . . . 54 - 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 . . . . . . . . . . . . . . . . . . . . . . . . 57 - Intellectual Property and Copyright Statements . . . . . . . . . . 58 - - - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 3] - -Internet-Draft IKEv2 Clarifications February 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. - - Readers are advised that this document is work-in-progress, and may - contain incorrect interpretations. Issues where the clarification is - known to be incomplete, or there is no consensus on what the the - interpretation should be, are marked as such. - - IKEv2/IPsec can be used for several different purposes, including - IPsec-based remote access (sometimes called the "road warrior" case), - site-to-site virtual private networks (VPNs), and host-to-host - protection of application traffic. While this document attempts to - consider all of these uses, the remote access scenario has perhaps - received more attention here than the other uses. - - This document does not place any requirements on anyone, and does not - use [RFC2119] keywords such as "MUST" and "SHOULD", except in - quotations from the original IKEv2 documents. The requirements are - given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic - algorithms document [IKEv2ALG]. - - In this document, references to a numbered section (such as "Section - 2.15") mean that section in [IKEv2]. References to mailing list - messages refer to the IPsec WG mailing list at ipsec@ietf.org. - Archives of the mailing list can be found at - <http://www.ietf.org/mail-archive/web/ipsec/index.html>. - - -2. Creating the IKE_SA - -2.1. SPI values in IKE_SA_INIT exchange - - Normal IKE messages include the initiator's and responder's SPIs, - both of which are non-zero, in the IKE header. However, there are - some corner cases where the IKEv2 specification is not fully - consistent about what values should be used. - - First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero - in any other message" (than the first message of the IKE_SA_INIT - exchange). However, the figure in Section 2.6 shows the second - IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text - in 3.1. - - - -Eronen & Hoffman Expires August 6, 2006 [Page 4] - -Internet-Draft IKEv2 Clarifications February 2006 - - - Since the responder's SPI identifies security-related state held by - the responder, and in this case no state is created, sending a zero - value seems reasonable. - - Second, in addition to cookies, there are several other cases when - the IKE_SA_INIT exchange does not result in the creation of an IKE_SA - (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What - responder SPI value should be used in the IKE_SA_INIT response in - this case? - - Since the IKE_SA_INIT request always has a zero responder SPI, the - value will not be actually used by the initiator. Thus, we think - sending a zero value is correct also in this case. - - If the responder sends a non-zero responder SPI, the initiator should - not reject the response only for that reason. However, when retrying - the IKE_SA_INIT request, the initiator will use a zero responder SPI, - as described in Section 3.1: "Responder's SPI [...] This value MUST - be zero in the first message of an IKE Initial Exchange (including - repeats of that message including a cookie) [...]". We believe the - intent was to cover repeats of that message due to other reasons, - such as INVALID_KE_PAYLOAD, as well. - - (References: "INVALID_KE_PAYLOAD and clarifications document" thread, - Sep-Oct 2005.) - -2.2. Message IDs for IKE_SA_INIT messages - - The Message ID for IKE_SA_INIT messages is always zero. This - includes retries of the message due to responses such as COOKIE and - INVALID_KE_PAYLOAD. - - This is because Message IDs are part of the IKE_SA state, and when - the responder replies to IKE_SA_INIT request with N(COOKIE) or - N(INVALID_KE_PAYLOAD), the responder does not allocate any state. - - (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD) - combination" thread, Oct 2004. Tero Kivinen's mail "Comments of - draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.) - -2.3. Retransmissions of IKE_SA_INIT requests - - When a responder receives an IKE_SA_INIT request, it has to determine - whether the packet is a retransmission belonging to an existing - "half-open" IKE_SA (in which case the responder retransmits the same - response), or a new request (in which case the responder creates a - new IKE_SA and sends a fresh response). - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 5] - -Internet-Draft IKEv2 Clarifications February 2006 - - - The specification does not describe in detail how this determination - is done. In particular, it is not sufficient to use the initiator's - SPI and/or IP address for this purpose: two different peers behind a - single NAT could choose the same initiator SPI (and the probability - of this happening is not necessarily small, since IKEv2 does not - require SPIs to be chosen randomly). Instead, the responder should - do the IKE_SA lookup using the whole packet or its hash (or at the - minimum, the Ni payload which is always chosen randomly). - - For all other packets than IKE_SA_INIT requests, looking up right - IKE_SA is of course done based on the the recipient's SPI (either the - initiator or responder SPI depending on the value of the Initiator - bit in the IKE header). - -2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD - - There are two common reasons why the initiator may have to retry the - IKE_SA_INIT exchange: the responder requests a cookie or wants a - different Diffie-Hellman group than was included in the KEi payload. - Both of these cases are quite simple alone, but it is not totally - obvious what happens when they occur at the same time, that is, the - IKE_SA_INIT exchange is retried several times. - - The main question seems to be the following: if the initiator - receives a cookie from the responder, should it include the cookie in - only the next retry of the IKE_SA_INIT request, or in all subsequent - retries as well? Section 3.10.1 says that: - - "This notification MUST be included in an IKE_SA_INIT request - retry if a COOKIE notification was included in the initial - response." - - This could be interpreted as saying that when a cookie is received in - the initial response, it is included in all retries. On the other - hand, Section 2.6 says that: - - "Initiators who receive such responses MUST retry the - IKE_SA_INIT with a Notify payload of type COOKIE containing - the responder supplied cookie data as the first payload and - all other payloads unchanged." - - Including the same cookie in later retries makes sense only if the - "all other payloads unchanged" restriction applies only to the first - retry, but not to subsequent retries. - - It seems that both interpretations can peacefully co-exist. If the - initiator includes the cookie only in the next retry, one additional - roundtrip may be needed in some cases: - - - -Eronen & Hoffman Expires August 6, 2006 [Page 6] - -Internet-Draft IKEv2 Clarifications February 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. For - instance, if the responder includes the SAi1 and KEi payloads in - cookie calculation, it will reject the request by sending a new - cookie (see also Section 2.5 of this document for more text about - invalid cookies): - - Initiator Responder - ----------- ----------- - HDR(A,0), SAi1, KEi, Ni --> - <-- HDR(A,0), N(COOKIE) - HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> - <-- HDR(A,0), N(INVALID_KE_PAYLOAD) - HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> - <-- HDR(A,0), N(COOKIE') - HDR(A,0), N(COOKIE'), SAi1, KEi',Ni --> - <-- HDR(A,B), SAr1, KEr, Nr - - If both peers support including the cookie in all retries, a slightly - shorter exchange can happen: - - Initiator Responder - ----------- ----------- - HDR(A,0), SAi1, KEi, Ni --> - <-- HDR(A,0), N(COOKIE) - HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> - <-- HDR(A,0), N(INVALID_KE_PAYLOAD) - HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> - <-- HDR(A,B), SAr1, KEr, Nr - - This document recommends that implementations should support this - shorter exchange, but it must not be assumed the other peer also - supports this. - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 7] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 8] - -Internet-Draft IKEv2 Clarifications February 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 other end 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 semi-reasonable choice would be to use the hash function that - - - -Eronen & Hoffman Expires August 6, 2006 [Page 9] - -Internet-Draft IKEv2 Clarifications February 2006 - - - was 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, since it does not necessarily check the certificate - signature. 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 other algorithm 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 Alstrom'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 - same as the syntax of email address in [RFC822]. This raises the - question of which identification type should be used. - - - -Eronen & Hoffman Expires August 6, 2006 [Page 10] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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. (Section removed) - - (This issue was corrected in RFC 4306.) - -3.7. Certificate encoding types - - Section 3.6 defines a total of twelve different certificate encoding - types, and continues that "Specific syntax is for some of the - certificate type codes above is not defined in this document." - However, the text does not provide references to other documents that - would contain information about the exact contents and use of those - values. - - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 11] - -Internet-Draft IKEv2 Clarifications February 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 - - (Future versions of this document may also contain clarifications - about how these values are to be used.) - - This document recommends that most implementations should use only - those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e., - "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and - URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle" - (13). - - Furthermore, Section 3.7 says that the "Certificate Encoding" field - for the Certificate Request payload uses the same values as for - Certificate payload. However, the contents of the "Certification - Authority" field are defined only for X.509 certificates (presumably - covering at least types 4, 10, 12, and 13). This document recommends - that other values should not be used before new specifications that - specify their use are available. - - The "Raw RSA Key" type needs one additional clarification. Section - 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is - a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21]. - -3.8. Shared key authentication and fixed PRF key size - - Section 2.15 says that "If the negotiated prf takes a fixed-size key, - the shared secret MUST be of that fixed size". This statement is - correct: the shared secret must be of the correct size. If it is - not, it cannot be used; there is no padding, truncation, or other - processing involved to force it to that correct size. - - This requirement means that it is difficult to use these PRFs with - shared key authentication. The authors think this part of the - specification was very poorly thought out, and using PRFs with a - fixed key size is likely to result in interoperability problems. - Thus, we recommend that such PRFs should not be used with shared key - authentication. PRF_AES128_XCBC [RFC3664] originally used fixed key - sizes; that RFC has been updated to handle variable key sizes in - [RFC3664bis]. - - - -Eronen & Hoffman Expires August 6, 2006 [Page 12] - -Internet-Draft IKEv2 Clarifications February 2006 - - - Note that Section 2.13 also contains text that is related to PRFs - with fixed key size: "When the key for the prf function has fixed - length, the data provided as a key is truncated or padded with zeros - as necessary unless exceptional processing is explained following the - formula". However, this text applies only to the prf+ construction, - so it does not contradict the text in Section 2.15. - - (References: Paul Hoffman's mail "Re: ikev2-07: last nits", - 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question - about PRFs with fixed size key", Jan 2005.) - -3.9. EAP authentication and fixed PRF key size - - As described in the previous section, PRFs with a fixed key size - require a shared secret of exactly that size. This restriction - applies also to EAP authentication. For instance, a PRF that - requires a 128-bit key cannot be used with EAP since [EAP] specifies - that the MSK is at least 512 bits long. - - (References: Thread "Question about PRFs with fixed size key", Jan - 2005.) - -3.10. Matching ID payloads to certificate contents - - In IKEv1, there was some confusion about whether or not the - identities in certificates used to authenticate IKE were required to - match the contents of the ID payloads. There has been some work done - on this in the PKI4IPSEC Working Group, but that work is not finished - at this time. However, Section 3.5 explicitly says that the ID - payload "does not necessarily have to match anything in the CERT - payload". - -3.11. Message IDs for IKE_AUTH messages - - According to Section 2.2, "The IKE_SA initial setup messages will - always be numbered 0 and 1." That is true when the IKE_AUTH exchange - does not use EAP. When EAP is used, each pair of messages have their - message numbers incremented. The first pair of AUTH messages will - have an ID of 1, the second will be 2, and so on. - - (References: "Question about MsgID in AUTH exchange" thread, April - 2005.) - - -4. Creating CHILD_SAs - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 13] - -Internet-Draft IKEv2 Clarifications February 2006 - - -4.1. Creating SAs with the CREATE_CHILD_SA exchange - - Section 1.3's organization does not lead to clear understanding of - what is needed in which environment. The section can be reorganized - with subsections for each use of the CREATE_CHILD_SA exchange - (creating child SAs, rekeying IKE SAs, and rekeying child SAs.) - - The new Section 1.3 with subsections and the above changes might look - like this. - - NEW-1.3 The CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and - to rekey both IKE_SAs and CHILD_SAs. This exchange consists of - a single request/response pair, and some of its function was - referred to as a phase 2 exchange in IKEv1. It MAY be initiated - by either end of the IKE_SA after the initial exchanges are - completed. - - All messages following the initial exchange are - cryptographically protected using the cryptographic algorithms - 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. - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 14] - -Internet-Draft IKEv2 Clarifications February 2006 - - - If a CREATE_CHILD_SA exchange includes a KEi payload, at least - one of the SA offers MUST include the Diffie-Hellman group of - the KEi. The Diffie-Hellman group of the KEi MUST be an element - of the group the initiator expects the responder to accept - (additional Diffie-Hellman groups can be proposed). If the - responder rejects the Diffie-Hellman group of the KEi payload, - the responder MUST reject the request and indicate its preferred - Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification - payload. In the case of such a rejection, the CREATE_CHILD_SA - exchange fails, and the initiator SHOULD retry the exchange with - a Diffie-Hellman proposal and KEi in the group that the - responder gave in the INVALID_KE_PAYLOAD. - - NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange - - A CHILD_SA may be created by sending a CREATE_CHILD_SA request. - The CREATE_CHILD_SA request for creating a new CHILD_SA is: - - 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 August 6, 2006 [Page 15] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 16] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 17] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 18] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 19] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 20] - -Internet-Draft IKEv2 Clarifications February 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 must use 3DES. Suppose also that host B - accepts any combination of AES and 3DES. - - If host A now proposes an SA that uses 3DES, and includes TSr - containing (192.0.1.0-192.0.1.0.255), this will be accepted by host - B. Now, host B can also use this SA to send traffic from 192.0.1.66, - but those packets will be dropped by A since it requires the use of - AES for those traffic. Even if host A creates a new SA only for - 192.0.1.66 that uses AES, host B may freely continue to use the first - SA for the traffic. In this situation, when proposing the SA, host A - should have followed its own policy, and included a TSr containing - ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. - - In general, if (1) the initiator makes a proposal "for traffic X - (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator - does not actually accept traffic X' with SA, and (3) the initiator - would be willing to accept traffic X' with some SA' (!=SA), valid - traffic can be unnecessarily dropped since the responder can apply - either SA or SA' to traffic X'. - - (References: "Question about "narrowing" ..." thread, Feb 2005. - "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 - Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector - negotiation examples", 2004-08-08.) - - -5. Rekeying and deleting SAs - -5.1. Rekeying SAs with the CREATE_CHILD_SA exchange - - Continued from Section 4.1 of this document. - - NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange - - The CREATE_CHILD_SA request for rekeying an IKE_SA is: - - Initiator Responder - - - -Eronen & Hoffman Expires August 6, 2006 [Page 21] - -Internet-Draft IKEv2 Clarifications February 2006 - - - ----------- ----------- - 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. - - 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. - - - -Eronen & Hoffman Expires August 6, 2006 [Page 22] - -Internet-Draft IKEv2 Clarifications February 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. - -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.) - -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.) - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 23] - -Internet-Draft IKEv2 Clarifications February 2006 - - -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 - 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." - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 24] - -Internet-Draft IKEv2 Clarifications February 2006 - - -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 the "original - responder" starts rekeying the IKE_SA, that party becomes the - "original initiator" of the new IKE_SA. - - (References: Paul Hoffman's mail "Original initiator in IKEv2", 2005- - 04-21.) - -5.10. (Section removed) - - (This issue was corrected in RFC 4306.) - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 25] - -Internet-Draft IKEv2 Clarifications February 2006 - - -5.11. Comparing nonces - - Section 2.8 about rekeying says that "If redundant SAs are created - though such a collision, the SA created with the lowest of the four - nonces used in the two exchanges SHOULD be closed by the endpoint - that created it." - - Here "lowest" uses an octet-by-octet (lexicographical) comparison - (instead of, for instance, comparing the nonces as large integers). - In other words, start by comparing the first octet; if they're equal, - move to the next octet, and so on. If you reach the end of one - nonce, that nonce is the lower one. - - (References: "IKEv2 rekeying question" thread, July 2005.) - -5.12. 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 out - of sync, 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.12.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: - - Host A Host B - -------- -------- - send req1: D(SPIa) --> - <-- send req2: D(SPIb) - --> recv req1 - <-- send resp1: () - recv resp1 - recv req2 - send resp2: () --> - --> recv resp2 - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 26] - -Internet-Draft IKEv2 Clarifications February 2006 - - - This case is described in Section 1.4, and is handled by omitting the - Delete payloads from the response messages. - -5.12.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.12.3. Simultaneous CHILD_SA rekeying - - Another case that is described in the specification is simultaneous - rekeying. Section 2.8 says - - "If the two ends have the same lifetime policies, it is possible - that both will initiate a rekeying at the same time (which will - result in redundant SAs). To reduce the probability of this - happening, the timing of rekeying requests SHOULD be jittered - (delayed by a random amount of time after the need for rekeying is - noticed). - - This form of rekeying may temporarily result in multiple similar - SAs between the same pairs of nodes. When there are two SAs - eligible to receive packets, a node MUST accept incoming packets - through either SA. If redundant SAs are created though such a - collision, the SA created with the lowest of the four nonces used - in the two exchanges SHOULD be closed by the endpoint that created - - - -Eronen & Hoffman Expires August 6, 2006 [Page 27] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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. - - 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 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 28] - -Internet-Draft IKEv2 Clarifications February 2006 - - - (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. - -5.12.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 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 29] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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.12.5. Closing and rekeying a CHILD_SA - - A case similar to simultaneous rekeying can occur if one peers - 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: - - <-- 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 - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 30] - -Internet-Draft IKEv2 Clarifications February 2006 - - -5.12.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 - 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. - - Currently, this document recommends the first alternative. - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 31] - -Internet-Draft IKEv2 Clarifications February 2006 - - -5.12.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.12.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 - 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 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 32] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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.12.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. - - <-- 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.12.10. Summary - - If a host receives a request to rekey: - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 33] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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 - 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.13. 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. - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 34] - -Internet-Draft IKEv2 Clarifications February 2006 - - - It seems that this case is allowed by the IKEv2 specification. - Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets, and - the change history appendix in the draft mentioned this as one change - between draft versions -00 and -01. 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. - 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 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 35] - -Internet-Draft IKEv2 Clarifications February 2006 - - - stack with the address and use it as its source address. - - In other words, IKEv2 does not have two different mechanisms for - assigning addresses, but only one: configuration payloads. In the - scenario described in Section 1.1.3, both configuration and traffic - selector payloads are usually included in the same message, and often - contain the same information in the response message (see Section 6.4 - of this document for some examples). However, their semantics are - still different. - -6.2. (Section removed) - - (This issue was corrected in RFC 4306.) - -6.3. Requesting any INTERNAL_IP4/IP6_ADDRESS - - When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section - 3.15.1 says that "In a request message, the address specified is a - requested address (or zero if no specific address is requested)". - The question here is that does "zero" mean an address "0.0.0.0" or a - zero length string? - - Earlier, the same section also says that "If an attribute in the - CFG_REQUEST Configuration Payload is not zero-length, it is taken as - a suggestion for that attribute". Also, the table of configuration - attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 - or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 - octets". - - Thus, if the client does not request a specific address, it includes - a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute - containing an all-zeroes address. The example in 2.19 is thus - incorrect, since it shows the attribute as - "INTERNAL_ADDRESS(0.0.0.0)". - - However, since the value is only a suggestion, implementations are - recommended to ignore suggestions they do not accept; or in other - words, treat the same way a zero-length INTERNAL_IP4_ADDRESS, - "0.0.0.0", and any other addresses the implementation does not - recognize as a reasonable suggestion. - -6.4. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET - - Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected - sub-networks that this edge-device protects. This attribute is made - up of two fields: the first 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." - - - -Eronen & Hoffman Expires August 6, 2006 [Page 36] - -Internet-Draft IKEv2 Clarifications February 2006 - - - INTERNAL_IP6_SUBNET is defined in a similar manner. - - This raises two questions: first, since this information is usually - included in the TSr payload, what functionality does this attribute - add? And second, what does this attribute mean in CFG_REQUESTs? - - For the first question, there seem to be two sensible - interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA - response) indicates which subnets are accessible through the SA that - was just created. - - The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is - that they indicate additional subnets that can be reached through - this gateway, but need a separate SA. According to this - interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful - mainly when they contain addresses not included in TSr. - - The second interpretation is that the INTERNAL_IP4/6_SUBNET - attributes express the gateway's policy about what traffic should be - sent through the gateway. The client can choose whether other - traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent - through the gateway or directly the destination. According to this - interpretation, the attributes are useful mainly when TSr contains - addresses not included in the INTERNAL_IP4/6_SUBNET attributes. - - It turns out that these two interpretations are not incompatible, but - rather two sides of the same principle: traffic to the addresses - listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via - this gateway. If there are no existing IPsec SAs whose traffic - selectors cover the address in question, new SAs have to be created. - - A couple of examples are given below. For instance, if there are two - subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request - contains the following: - - CP(CFG_REQUEST) = - INTERNAL_IP4_ADDRESS() - TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) - TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) - - Then a valid response could be the following (in which TSr and - INTERNAL_IP4_SUBNET contain the same information): - - - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 37] - -Internet-Draft IKEv2 Clarifications 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. 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) - - Then the gateway's reply could be this: - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 38] - -Internet-Draft IKEv2 Clarifications 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) - - 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.5. INTERNAL_IP4_NETMASK - - Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute, and says - that "The internal network's netmask. Only one netmask is allowed in - the request and reply messages (e.g., 255.255.255.0) and it MUST be - used only with an INTERNAL_IP4_ADDRESS attribute". - - However, it is not clear what exactly this attribute means, as the - concept of "netmask" is not very well defined for point-to-point - links (unlike multi-access links, where it means "you can reach hosts - inside this netmask directly using layer 2, instead of sending - packets via a router"). Even if the operating system's TCP/IP stack - requires a netmask to be configured, for point-to-point links it - could be just set to 255.255.255.255. So, why is this information - - - -Eronen & Hoffman Expires August 6, 2006 [Page 39] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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.6. Configuration payloads for IPv6 - - IKEv2 also defines configuration payloads for IPv6. However, they - are based on the corresponding IPv4 payloads, and do not fully follow - the "normal IPv6 way of doing things". - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 40] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 41] - -Internet-Draft IKEv2 Clarifications February 2006 - - -6.7. INTERNAL_IP6_NBNS - - Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending - the IPv6 address of NetBIOS name servers. - - However, NetBIOS is not defined for IPv6, and probably never will be. - Thus, this attribute most likely does not make much sense. - - (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) - BoF at IETF62.) - -6.8. INTERNAL_ADDRESS_EXPIRY - - Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as - "Specifies the number of seconds that the host can use the internal - IP address. The host MUST renew the IP address before this expiry - time. Only one of these attributes MAY be present in the reply." - - Expiry times and explicit renewals are primarily useful in - environments like DHCP, where the server cannot reliably know when - the client has gone away. However, in IKEv2 this is known, and the - gateway can simply free the address when the IKE_SA is deleted. - - Also, Section 4 says that supporting renewals is not mandatory. - Given that this functionality is usually not needed, we recommend - that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. - (And since this attribute does not seem to make much sense for - CFG_REQUESTs, clients should not send it either.) - - Note that according to Section 4, clients are required to understand - INTERNAL_ADDRESS_EXPIRY if the receive it. A minimum implementation - would use the value to limit the lifetime of the IKE_SA. - - (References: Tero Kivinen's mail "Comments of - draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05. - "Questions about internal address" thread, April 2005.) - -6.9. Address assignment failures - - If the responder encounters an error while attempting to assign an IP - address to the initiator, it responds with an - INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. - However, there are some more complex error cases. - - First, if the responder does not support configuration payloads at - all, it can simply ignore all configuration payloads. This type of - implementation never sends INTERNAL_ADDRESS_FAILURE notifications. - If the initiator requires the assignment of an IP address, it will - - - -Eronen & Hoffman Expires August 6, 2006 [Page 42] - -Internet-Draft IKEv2 Clarifications February 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 clear - what 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 August 6, 2006 [Page 43] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 44] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 45] - -Internet-Draft IKEv2 Clarifications February 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 August 6, 2006 [Page 46] - -Internet-Draft IKEv2 Clarifications February 2006 - - - easier to draw. In particular, payloads in IKEv2 are not, in - general, aligned to 4-byte boundaries. (Note that payloads were not - aligned to 4-byte boundaries in IKEv1 either.) - - (References: "IKEv2: potential 4-byte alignment problem" thread, June - 2004.) - -7.11. Key length transform attribute - - Section 3.3.5 says that "The only algorithms defined in this document - that accept attributes are the AES based encryption, integrity, and - pseudo-random functions, which require a single attribute specifying - key width." - - This is incorrect. The AES-based integrity and pseudo-random - functions defined in [IKEv2] always use a 128-bit key. In fact, - there are currently no integrity or PRF algorithms that use the key - length attribute (and we recommend that they should not be defined in - the future either). - - For encryption algorithms, the situation is slightly more complex - since there are three different types of algorithms: - - o The key length attribute is never used with algorithms that use a - fixed length key, such as DES and IDEA. - - o The key length attribute is always included for the currently - defined AES-based algorithms (CBC, CTR, CCM and GCM). Omitting - the key length attribute is not allowed; if the proposal does not - contain it, the proposal has to be rejected. - - o For other algorithms, the key length attribute can be included but - is not mandatory. These algorithms include, e.g., RC5, CAST and - BLOWFISH. If the key length attribute is not included, the - 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 August 6, 2006 [Page 47] - -Internet-Draft IKEv2 Clarifications February 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. Status of the clarifications - - This document is work-in-progress, and it contains both relatively - stable and finished parts, and other parts that are incomplete or - even incorrect. To help the reader in deciding how much weight - should be given to each clarification, this section contains our - opinions about which parts we believe to are stable, and which are - likely to change in future versions. - - Those clarifications believed to be correct and without controversy - are marked with three asterisks (***); those where the clarification - is known to be incomplete and/or there is disagreement about what the - correct interpretation is are marked with one asterisk (*). The - clarifications marked with two asterisks (**) are somewhere between - - - -Eronen & Hoffman Expires August 6, 2006 [Page 48] - -Internet-Draft IKEv2 Clarifications February 2006 - - - the extremes. - - 2. Creating the IKE_SA - 2.1 SPI values in IKE_SA_INIT exchange *** - 2.2 Message IDs for IKE_SA_INIT messages *** - 2.3 Retransmissions of IKE_SA_INIT requests *** - 2.4 Interaction of COOKIE and INVALID_KE_PAYLOAD *** - 2.5 Invalid cookies *** - 3. Authentication - 3.1 Data included in AUTH payload calculation *** - 3.2 Hash function for RSA signatures *** - 3.3 Encoding method for RSA signatures *** - 3.4 Identification type for EAP *** - 3.5 Identity for policy lookups when using EAP *** - 3.6 (Section removed) - 3.7 Certificate encoding types *** - 3.8 Shared key authentication and fixed PRF key size *** - 3.9 EAP authentication and fixed PRF key size *** - 3.10 Matching ID payloads to certificate contents *** - 3.11 Message IDs for IKE_AUTH messages *** - 4. Creating CHILD_SAs - 4.1 Creating SAs with the CREATE_CHILD_SA exchange ** - 4.2 Creating an IKE_SA without a CHILD_SA *** - 4.3 Diffie-Hellman for first CHILD_SA *** - 4.4 Extended Sequence Numbers (ESN) transform *** - 4.5 Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED *** - 4.6 Negotiation of NON_FIRST_FRAGMENTS_ALSO *** - 4.7 Semantics of complex traffic selector payloads *** - 4.8 ICMP type/code in traffic selector payloads *** - 4.9 Mobility header in traffic selector payloads *** - 4.10 Narrowing the traffic selectors *** - 4.11 SINGLE_PAIR_REQUIRED *** - 4.12 Traffic selectors violating own policy *** - 5. Rekeying and deleting SAs - 5.1 Rekeying SAs with the CREATE_CHILD_SA exchange ** - 5.2 Rekeying the IKE_SA vs. reauthentication *** - 5.3 SPIs when rekeying the IKE_SA *** - 5.4 SPI when rekeying a CHILD_SA *** - 5.5 Changing PRFs when rekeying the IKE_SA *** - 5.6 Deleting vs. closing SAs *** - 5.7 Deleting an SA pair *** - 5.8 Deleting an IKE_SA *** - 5.9 Who is the original initiator of IKE_SA *** - 5.10 (Section removed) - 5.11 Comparing nonces *** - 5.12 Exchange collisions * - 5.13 Diffie-Hellman and rekeying the IKE_SA ** - 6. Configuration payloads - - - -Eronen & Hoffman Expires August 6, 2006 [Page 49] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 6.1 Assigning IP addresses *** - 6.2 (Section removed) - 6.3 Requesting any INTERNAL_IP4/IP6_ADDRESS *** - 6.4 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET *** - 6.5 INTERNAL_IP4_NETMASK ** - 6.6 Configuration payloads for IPv6 ** - 6.7 INTERNAL_IP6_NBNS *** - 6.8 INTERNAL_ADDRESS_EXPIRY *** - 6.9 Address assignment failures ** - 7. Miscellaneous issues - 7.1 Matching ID_IPV4_ADDR and ID_IPV6_ADDR *** - 7.2 Relationship of IKEv2 to RFC4301 *** - 7.3 Reducing the window size *** - 7.4 Minimum size of nonces *** - 7.5 Initial zero octets on port 4500 *** - 7.6 Destination port for NAT traversal *** - 7.7 SPI values for messages outside of an IKE_SA *** - 7.8 Protocol ID/SPI fields in Notify payloads *** - 7.9 Which message should contain INITIAL_CONTACT *** - 7.10 Alignment of payloads *** - 7.11 Key length transform attribute *** - 7.12 IPsec IANA considerations ** - 7.13 Combining ESP and AH * - - Future versions of this document will, of course, change these - estimates (and changes in both directions are possible, though - hopefully it's more towards higher confidence). - - -9. Implementation mistakes - - Some implementers at the 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. - - o Some implementations could only handle a single pair of traffic - selectors, or would only process the first pair in the proposal. - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 50] - -Internet-Draft IKEv2 Clarifications February 2006 - - - o Some implementations responded to a delete request by sending an - empty INFORMATIONAL response, and then initiated their own - INFORMATIONAL exchange with the pair of SAs to delete. - - o Although this did not happen at the bakeoff, from the discussion - there, it is clear that some people had not implemented message - window sizes correctly. Some implementations might have sent - messages that did not fit into the responder's message windows, - and some implementations may not have torn down an SA if they did - not ever receive a message that they know they should have. - - -10. 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. - - -11. IANA considerations - - This document does not change or create any IANA-registered values. - - -12. 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. - - -13. References - -13.1. Normative References - - [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) - Protocol", RFC 4306, December 2005. - - [IKEv2ALG] - Schiller, J., "Cryptographic Algorithms for Use in the - Internet Key Exchange Version 2 (IKEv2)", RFC 4307, - - - -Eronen & Hoffman Expires August 6, 2006 [Page 51] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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. - -13.2. Informative References - - [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 3513, April 2004. - - [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support - in IPv6", RFC 3775, June 2004. - - [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery - Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. - - [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The - Network Access Identifier", RFC 4282, December 2005. - - [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication - Dial In User Service) Support For Extensible - - - -Eronen & Hoffman Expires August 6, 2006 [Page 52] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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 IKEv2", - draft-nir-ikev2-auth-lt-03 (work in progress), - November 2005. - - [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 - - - -Eronen & Hoffman Expires August 6, 2006 [Page 53] - -Internet-Draft IKEv2 Clarifications February 2006 - - - 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+] - -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)], - - - -Eronen & Hoffman Expires August 6, 2006 [Page 54] - -Internet-Draft IKEv2 Clarifications February 2006 - - - [V+] - -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 August 6, 2006 [Page 55] - -Internet-Draft IKEv2 Clarifications February 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)] - - - - - - - - - - - - - - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 56] - -Internet-Draft IKEv2 Clarifications February 2006 - - -Authors' Addresses - - Pasi Eronen - Nokia Research Center - P.O. Box 407 - FIN-00045 Nokia Group - Finland - - Email: pasi.eronen@nokia.com - - - Paul Hoffman - VPN Consortium - 127 Segre Place - Santa Cruz, CA 95060 - USA - - Email: paul.hoffman@vpnc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 57] - -Internet-Draft IKEv2 Clarifications February 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. - - - - -Eronen & Hoffman Expires August 6, 2006 [Page 58] - diff --git a/doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt b/doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt deleted file mode 100644 index c1493c197..000000000 --- a/doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt +++ /dev/null @@ -1,6535 +0,0 @@ - - -INTERNET-DRAFT Charlie Kaufman, Editor -draft-ietf-ipsec-ikev2-17.txt -Obsoletes: 2407, 2408, 2409 September 23, 2004 -Expires: March 2005 - - - Internet Key Exchange (IKEv2) Protocol - - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. 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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This document is a submission by the IPSEC Working Group of the - Internet Engineering Task Force (IETF). Comments should be submitted - to the ipsec@lists.tislabs.com mailing list. - - Distribution of this memo is unlimited. - - This Internet-Draft expires in March 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes version 2 of the Internet Key Exchange (IKE) - protocol. IKE is a component of IPsec used for performing mutual - authentication and establishing and maintaining security associations - (SAs). - - This version of the IKE specification combines the contents of what - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 1] - - - - - -Internet-Draft September 23, 2004 - - - were previously separate documents, including ISAKMP (RFC 2408), IKE - (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy - authentication, and remote address acquisition. - - Version 2 of IKE does not interoperate with version 1, but it has - enough of the header format in common that both versions can - unambiguously run over the same UDP port. - -Table of Contents - - - 1 Introduction...............................................3 - 1.1 Usage Scenarios..........................................5 - 1.2 The Initial Exchanges....................................7 - 1.3 The CREATE_CHILD_SA Exchange.............................9 - 1.4 The INFORMATIONAL Exchange..............................10 - 1.5 Informational Messages outside of an IKE_SA.............12 - 2 IKE Protocol Details and Variations.......................12 - 2.1 Use of Retransmission Timers............................13 - 2.2 Use of Sequence Numbers for Message ID..................13 - 2.3 Window Size for overlapping requests....................14 - 2.4 State Synchronization and Connection Timeouts...........15 - 2.5 Version Numbers and Forward Compatibility...............16 - 2.6 Cookies.................................................18 - 2.7 Cryptographic Algorithm Negotiation.....................20 - 2.8 Rekeying................................................21 - 2.9 Traffic Selector Negotiation............................23 - 2.10 Nonces.................................................25 - 2.11 Address and Port Agility...............................26 - 2.12 Reuse of Diffie-Hellman Exponentials...................26 - 2.13 Generating Keying Material.............................27 - 2.14 Generating Keying Material for the IKE_SA..............28 - 2.15 Authentication of the IKE_SA...........................29 - 2.16 Extensible Authentication Protocol Methods.............30 - 2.17 Generating Keying Material for CHILD_SAs...............32 - 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......33 - 2.19 Requesting an internal address on a remote network.....33 - 2.20 Requesting a Peer's Version............................35 - 2.21 Error Handling.........................................35 - 2.22 IPComp.................................................36 - 2.23 NAT Traversal..........................................37 - 2.24 ECN (Explicit Congestion Notification).................40 - 3 Header and Payload Formats................................40 - 3.1 The IKE Header..........................................40 - 3.2 Generic Payload Header..................................43 - 3.3 Security Association Payload............................44 - 3.4 Key Exchange Payload....................................54 - 3.5 Identification Payloads.................................55 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 2] - - - - - -Internet-Draft September 23, 2004 - - - 3.6 Certificate Payload.....................................57 - 3.7 Certificate Request Payload.............................60 - 3.8 Authentication Payload..................................62 - 3.9 Nonce Payload...........................................62 - 3.10 Notify Payload.........................................63 - 3.11 Delete Payload.........................................71 - 3.12 Vendor ID Payload......................................72 - 3.13 Traffic Selector Payload...............................73 - 3.14 Encrypted Payload......................................76 - 3.15 Configuration Payload..................................77 - 3.16 Extensible Authentication Protocol (EAP) Payload.......82 - 4 Conformance Requirements..................................84 - 5 Security Considerations...................................86 - 6 IANA Considerations.......................................89 - 7 Acknowledgements..........................................89 - 8 References................................................90 - 8.1 Normative References....................................90 - 8.2 Informative References..................................91 - Appendix A: Summary of Changes from IKEv1...................94 - Appendix B: Diffie-Hellman Groups...........................96 - Change History (To be removed from RFC).....................97 - Editor's Address...........................................108 - Full Copyright Statement...................................108 - Intellectual Property Statement............................108 - -Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [Bra97]. - - The term "Expert Review" is to be interpreted as defined in - [RFC2434]. - -1 Introduction - - 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 of IKE. Version 1 of IKE was - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 3] - - - - - -Internet-Draft September 23, 2004 - - - defined in RFCs 2407, 2408, and 2409. 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 [RFC2401bis]. - - 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 - ESP [RFC2406] and/or AH [RFC2402] 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 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_SA"s. - - 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 - 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 4] - - - - - -Internet-Draft September 23, 2004 - - - 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 - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 5] - - - - - -Internet-Draft September 23, 2004 - - - IPsec, as required of hosts in [RFC2401bis]. 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 [RFC1958], [RFC2775], - and a method of limiting the inherent problems with complexity in - networks noted by [RFC3439]. While 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). - -1.1.3 Endpoint to Security Gateway Transport - - +-+-+-+-+-+ +-+-+-+-+-+ - ! ! 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. In support of the latter case, IKEv2 includes a mechanism - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 6] - - - - - -Internet-Draft September 23, 2004 - - - 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 - 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 is 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. - - 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 description, the payloads contained in the message - are indicated by names such as SA. The details of the contents of - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 7] - - - - - -Internet-Draft September 23, 2004 - - - each payload are described later. Payloads which may optionally - appear will be shown in brackets, such as [CERTREQ], would 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 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 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 8] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -1.3 The CREATE_CHILD_SA Exchange - - This exchange consists of a single request/response pair, and 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". - - Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this - section the term initiator refers to the endpoint initiating this - exchange. - - A CHILD_SA is created by sending a CREATE_CHILD_SA request. 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). - - In the CHILD_SA created as part of the initial exchange, a second KE - payload and nonce MUST NOT be sent. The nonces from the initial - exchange are used in computing the keys for the CHILD_SA. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 9] - - - - - -Internet-Draft September 23, 2004 - - - The CREATE_CHILD_SA request contains: - - 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 in the TSi and TSr payloads. If this - CREATE_CHILD_SA exchange is rekeying an existing SA other than the - IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA - being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an - existing SA, the N payload MUST be omitted. If the SA offers include - different Diffie-Hellman groups, KEi MUST be an element of the group - the initiator expects the responder to accept. If it guesses wrong, - the CREATE_CHILD_SA exchange will fail and it will have to retry with - a different KEi. - - 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 response contains: - - <-- 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. If the responder chooses a - cryptographic suite with a different group, it MUST reject the - request. The initiator SHOULD repeat the request, but now with a KEi - payload from the group the responder selected. - - The traffic selectors for traffic to be sent on that SA are specified - in the TS payloads, which may be a subset of what the initiator of - the CHILD_SA proposed. Traffic selectors are omitted if this - CREATE_CHILD_SA request is being used to change the key of the - IKE_SA. - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 10] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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. 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. 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. - - A node SHOULD regard half closed connections as anomalous and audit - their existence should 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 which 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 11] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -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). - - While 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. Further, use of IP fragmentation opens an - implementation to denial of service attacks [KPS03]. 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 12] - - - - - -Internet-Draft September 23, 2004 - - - to send, receive, and process messages that are up to 3000 bytes - long. IKEv2 implementations SHOULD 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 - then including certificates in exchanges where possible can avoid - most problems. Implementations and configuration should keep in mind, - however, that if the URL lookups are only possible after the IPsec SA - is established, recursion issues could prevent this technique from - working. - -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. The IKE_SA initial setup messages will - always be numbered 0 and 1. Each endpoint in the IKE Security - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 13] - - - - - -Internet-Draft September 23, 2004 - - - 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 assure - 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. An IKE endpoint SHOULD be prepared to 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 14] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -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 - 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. 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 acknowledgment (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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 15] - - - - - -Internet-Draft September 23, 2004 - - - 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 assures 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 acknowledgment 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. - 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. - -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 zero. It is likely that - some implementations will want to support both version 1.0 and - version 2.0, and in the future, other versions. - - The major version number should only be incremented if the packet - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 16] - - - - - -Internet-Draft September 23, 2004 - - - 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, - 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. 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 a version 2.0 implementation and their content MUST be - ignored by a version 2.0 implementation ("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 and implementations of version 2.0 MUST skip over those payloads - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 17] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - While 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 - SHOULD reject as invalid a message with those payloads in any other - order. - -2.6 Cookies - - The term "cookies" originates with Karn and Simpson [RFC2522] in - Photuris, an early proposal for key management with IPsec, and it has - persisted. The 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. Each endpoint chooses one - of the two SPIs and SHOULD 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 18] - - - - - -Internet-Draft September 23, 2004 - - - 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. 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 - 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. - - 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 does not affect interoperability and hence is 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 = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 19] - - - - - -Internet-Draft September 23, 2004 - - - where <secret> is a randomly generated secret known only to the - responder and periodically changed and | indicates concatenation. - <VersionIDofSecret> should be changed whenever <secret> 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 SPIr was generated - since the last change to <secret> and that IPi must be the same as - the source address it saw the first time. Incorporating SPIi into the - calculation assures 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 assures that - an attacker who sees only message 2 can't successfully forge a - message 3. - - If a new value for <secret> is chosen while there are connections in - the process of being initialized, an IKE_SA_INIT might be returned - with other than the current <VersionIDofSecret>. 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 <secret> around for a - short time and accept cookies computed from either one. The - responder SHOULD NOT accept cookies indefinitely after <secret> is - changed, since that would defeat part of the denial of service - protection. The responder SHOULD change the value of <secret> - frequently, especially if under attack. - -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 only - needed 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 20] - - - - - -Internet-Draft September 23, 2004 - - - 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 - 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 - - IKE, ESP, and AH security associations use secret keys which SHOULD - only be used 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 which 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. - 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, - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 21] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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 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. It SHOULD do so if there has been no traffic - since the last time the SA was rekeyed. - - 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. - - 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 QoS differences among the SAs (see section - 4.1 of [RFC2983]). 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. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 22] - - - - - -Internet-Draft September 23, 2004 - - - 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 SHOULD continue to - send requests on the old SA until it 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. If an - initiator receives a message on an SA for which it has not received a - response 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. - -2.9 Traffic Selector Negotiation - - When an IP packet is received by an RFC2401 compliant IPsec subsystem - and matches a "protect" selector in its SPD, the subsystem MUST - protect 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 23] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - IKEv2 allows the responder to choose a subset of the traffic proposed - by the initiator. This could happen when the configuration 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 from (or the source address of the traffic forwarded to) - 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.1.* has been reserved for use - in examples in RFCs and similar documents. This document needed two - such ranges, and so also used 192.0.2.*. 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 24] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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 only occur 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. Such - misconfigurations SHOULD be recorded in error logs. - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 25] - - - - - -Internet-Draft September 23, 2004 - - - obtain keys for CHILD_SA, and to ensure creation of strong - pseudorandom 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). 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 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 26] - - - - - -Internet-Draft September 23, 2004 - - - 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), they algorithm by which keys are derived from arbitrary - values MUST be specified by the cryptographic transform. For - integrity protection functions based on 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. - - 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 | ... - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 27] - - - - - -Internet-Draft September 23, 2004 - - - 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 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 - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 28] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 29] - - - - - -Internet-Draft September 23, 2004 - - - 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). The pre- - shared key SHOULD 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"), <msg octets>) - - 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. If the negotiated prf takes a fixed - size key, the shared secret MUST be of that fixed size. - -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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 30] - - - - - -Internet-Draft September 23, 2004 - - - 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 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 } - - For EAP methods that create a shared key as a side effect of - authentication, that shared key MUST be used by both the initiator - and responder to generate AUTH payloads in messages 5 and 6 using the - syntax for shared secrets specified in section 2.15. 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. - - The initiator of an IKE_SA using EAP SHOULD be capable of extending - the initial protocol exchange to at least ten IKE_AUTH exchanges in - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 31] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -2.17 Generating Keying Material for CHILD_SAs - - CHILD_SAs are created either by being piggybacked on the IKE_AUTH - exchange, or in a CREATE_CHILD_SA exchange. 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), - 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: - - All keys for SAs carrying data from the initiator to the responder - are taken before SAs going in the reverse direction. - - If multiple IPsec protocols are negotiated, keying material is - taken in the order in which the protocol headers will appear in - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 32] - - - - - -Internet-Draft September 23, 2004 - - - the encapsulated packet. - - 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). New initiator and responder SPIs are supplied in - the SPI fields. 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. - - The new IKE_SA MUST reset its message counters to 0. - - SK_d, SK_ai, SK_ar, and 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 IRAC (IPsec Remote - Access Client) trying to tunnel into a network protected by an IRAS - (IPsec Remote Access Server). 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. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 33] - - - - - -Internet-Draft September 23, 2004 - - - 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(0.0.0.0) - INTERNAL_NETMASK(0.0.0.0) - INTERNAL_DNS(0.0.0.0) - TSi = (0, 0-65536,0.0.0.0-255.255.255.255) - TSr = (0, 0-65536,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-65536,192.0.2.202-192.0.2.202) - TSr = (0, 0-65536,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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 34] - - - - - -Internet-Draft September 23, 2004 - - - 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.") - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 35] - - - - - -Internet-Draft September 23, 2004 - - - 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. 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. The recipient MUST NOT change - the state of any SA's as a result but SHOULD 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 CPI (compression parameter index), 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, and 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 though 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 messages that do not contain SA - payloads. - - While 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 36] - - - - - -Internet-Draft September 23, 2004 - - - 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 - - NAT (Network Address Translation) 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 which 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 require - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 37] - - - - - -Internet-Draft September 23, 2004 - - - 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, so an IPsec endpoint that discovers a NAT between it and - its correspondent MUST send all subsequent traffic to and from port - 4500, which NATs should not treat specially (as they might with port - 500). - - The specific requirements for supporting NAT traversal are listed - below. Support for NAT traversal is optional. In this section only, - requirements listed as MUST only apply to implementations supporting - NAT traversal. - - IKE MUST listen on port 4500 as well as port 500. IKE MUST respond - to the IP address and port from which packets arrived. - - 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). - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 38] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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 [Hutt04]. - - 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. 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. - - The original source and destination IP address required for the - transport mode TCP and UDP packet checksum fixup (see [Hutt04]) - 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. - - 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. - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 39] - - - - - -Internet-Draft September 23, 2004 - - -2.24 ECN (Explicit Congestion Notification) - - When IPsec tunnels behave as originally specified in [RFC2401], 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 RFC3168]). 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 Security Associations (SAs) created - by IKEv2 MUST support the ECN full-functionality option for tunnels - specified in [RFC3168] and MUST implement the tunnel encapsulation - and decapsulation processing specified in [RFC2401bis] to prevent - discarding of ECN congestion indications. - -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 - 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). - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 40] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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) and MUST NOT be zero in any other message. - - o Next Payload (1 octet) - Indicates the type of payload that - immediately follows the header. The format and value of each - payload is 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 41] - - - - - -Internet-Draft September 23, 2004 - - - 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 cleared in messages sent by the original - responder. It is used by the recipient to determine - which eight octets of the SPI was 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 42] - - - - - -Internet-Draft September 23, 2004 - - - 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 sections 2.1 and 2.2. - - o Length (4 octets) - Length of total message (header + payloads) - in octets. - -3.2 Generic Payload Header - - Each IKE payload defined in sections 3.3 through 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). - - Payload Type Values - - Next Payload Type Notation Value - - No Next Payload 0 - - RESERVED 1-32 - Security Association SA 33 - Key Exchange KE 34 - Identification - Initiator IDi 35 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 43] - - - - - -Internet-Draft September 23, 2004 - - - 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 used so that there is no - overlap with the code assignments for IKEv1. Payload type values - 49-127 are reserved to IANA for future assignment in IKEv2 (see - section 6). Payload type values 128-255 are for private use among - mutually consenting parties. - - 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. - -3.3 Security Association Payload - - The Security Association Payload, denoted SA in this memo, is used to - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 44] - - - - - -Internet-Draft September 23, 2004 - - - 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, - while 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 - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 45] - - - - - -Internet-Draft September 23, 2004 - - - proposed as an encryption algorithm and an integrity protection - algorithm MUST NOT be proposed. For each Protocol, the set of - permissible transforms are 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 - say (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 than 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Proposals> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: Security Association Payload - - o Proposals (variable) - one or more proposal substructures. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 46] - - - - - -Internet-Draft September 23, 2004 - - - 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) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Transforms> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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 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. - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 47] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 48] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - Transform Type Values - - Transform 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 (Optional in 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) - ENCR_3DES 3 (RFC2451) - ENCR_RC5 4 (RFC2451) - ENCR_IDEA 5 (RFC2451) - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 49] - - - - - -Internet-Draft September 23, 2004 - - - 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) - - values 14-1023 are reserved to IANA. Values 1024-65535 are for - private use among mutually consenting parties. - - For Transform Type 2 (Pseudo-random Function), defined Transform IDs - are: - - Name Number Defined In - RESERVED 0 - PRF_HMAC_MD5 1 (RFC2104) - PRF_HMAC_SHA1 2 (RFC2104) - PRF_HMAC_TIGER 3 (RFC2104) - PRF_AES128_CBC 4 (RFC3664) - - values 5-1023 are reserved to IANA. Values 1024-65535 are for - private use among mutually consenting parties. - - - 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 - AUTH_KPDK_MD5 4 (RFC1826) - AUTH_AES_XCBC_96 5 (RFC3566) - - values 6-1023 are reserved to IANA. Values 1024-65535 are for - private use among mutually consenting parties. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 50] - - - - - -Internet-Draft September 23, 2004 - - - 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 - - If Transform Type 5 is not included in a proposal, use of - Extended Sequence Numbers is assumed. - -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. - - Protocol Mandatory Types Optional Types - IKE ENCR, PRF, INTEG, D-H - ESP ENCR INTEG, D-H, ESN - AH INTEG D-H, ESN - -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 being written, many IKEv1 implementers are starting to migrate to - AES in CBC mode for 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 51] - - - - - -Internet-Draft September 23, 2004 - - - 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 parameters (the generator, modulus, and exponent lengths and - values) for new DH groups. Implementations SHOULD provide a - management interface via 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. - -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). - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 52] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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. 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. - - 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. Values 18-16383 are - reserved to IANA. Values 16384-32767 are for private use among - mutually consenting parties. - - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 53] - - - - - -Internet-Draft September 23, 2004 - - - Encryption Algorithm uses a fixed length key. - -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. - - 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 which they deem to supply - greater security. For instance if a peer is configured to accept a - variable lengthed 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 54] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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. - - NOTE: In IKEv1, two ID payloads were used in each direction to hold - Traffic Selector information for data passing over the SA. In IKEv2, - this information is carried in Traffic Selector (TS) payloads (see - section 3.13). - - The Identification Payload consists of the IKE generic payload header - followed by identification fields as follows: - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 55] - - - - - -Internet-Draft September 23, 2004 - - - 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, followed by a description of the Identification Data - which follows: - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 56] - - - - - -Internet-Draft September 23, 2004 - - - 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 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 - - Reserved for 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. - IPv6 capable implementations MUST additionally be configurable to - accept ID_IPV6_ADDR. IPv6 only implementations MAY be configurable - to send only ID_IPV6_ADDR. - - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 57] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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). - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 58] - - - - - -Internet-Draft September 23, 2004 - - - 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: - - X.509 Certificate - Signature (4) contains a DER encoded X.509 - certificate whose public key is used to validate the sender's AUTH - payload. - - Certificate Revocation List (7) contains a DER encoded X.509 - certificate revocation list. - - Raw RSA Key (11) contains a PKCS #1 encoded RSA key. - - Hash and URL encodings (12-13) allow IKE messages to remain short - by replacing long data structures with a 20 octet SHA-1 hash 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 - [KPS03]. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 59] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 60] - - - - - -Internet-Draft September 23, 2004 - - - of the public keys of trusted CAs. Each is encoded as the SHA-1 hash - of the Subject Public Key Info element (see section 4.1.2.7 of - [RFC3280]) from each Trust Anchor certificate. The twenty-octet - hashes are concatenated and included with no other formatting. - - 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 which - can be validated up to one of the specified certification - authorities. This can be a chain of certificates. - - If an end-entity certificate exists which 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 is configured to use certificate - authentication, - - - is allowed to send a CERT payload, - - - has matching CA trust policy governing the current negotiation, - and - - - 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 which 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). - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 61] - - - - - -Internet-Draft September 23, 2004 - - -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. - - 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 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 - attacks. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 62] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - - - - - - - - - - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 63] - - - - - -Internet-Draft September 23, 2004 - - - The Notify 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 ! Notify Message Type ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Notification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 16: Notification 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. For - notifications which do not relate to an existing SA, 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 Notification Payload is forty one (41). - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 64] - - - - - -Internet-Draft September 23, 2004 - - -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. - The table below lists the Notification messages and their - corresponding values. The number of different error statuses was - greatly reduced from IKE V1 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. Unrecognized error types - in a request and status types in a request or response MUST be - ignored except that 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 was received was invalid because - some type, length, or value was out of range or because the - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 65] - - - - - -Internet-Draft September 23, 2004 - - - 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. To aid debugging, more detailed - error 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 66] - - - - - -Internet-Draft September 23, 2004 - - - 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 - - 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 which 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 - Error types 40 - 8191 - - Private Use - Errors 8192 - 16383 - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 67] - - - - - -Internet-Draft September 23, 2004 - - - 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). - - 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 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 only be sent as an additional - payload in a message including accepted TSs. - - IPCOMP_SUPPORTED 16387 - - This notification may only be included 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 is - 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 68] - - - - - -Internet-Draft September 23, 2004 - - - 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 - - values 5-240 are reserved to IANA. Values 241-255 are - for private use among mutually consenting parties. - - 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, 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 [Hutt04]. 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 69] - - - - - -Internet-Draft September 23, 2004 - - - 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 - [RFC2401bis] 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 - - 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. 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. - - NON_FIRST_FRAGMENTS_ALSO 16395 - - Used for fragmentation control. See [RFC2401bis] for - explanation. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 70] - - - - - -Internet-Draft September 23, 2004 - - - RESERVED TO IANA - STATUS TYPES 16396 - 40959 - - Private Use - STATUS TYPES 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 a 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 71] - - - - - -Internet-Draft September 23, 2004 - - - 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 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 backwards - 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 - 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 - which 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 72] - - - - - -Internet-Draft September 23, 2004 - - - 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: - - 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Traffic Selectors> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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) - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 73] - - - - - -Internet-Draft September 23, 2004 - - - for addresses at the responder's end. - -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. - - o End Port (2 octets) - Value specifying the largest port - number allowed by this Traffic Selector. For protocols for - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 74] - - - - - -Internet-Draft September 23, 2004 - - - 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 [RFC2401bis] that wish to indicate - "ANY" ports MUST set the start port to 0 and the end port to 65535; - note that according to [RFC2401bis], "ANY" includes "OPAQUE". Systems - working with [RFC2401bis] that wish to indicate "OPAQUE" ports, but - not "ANY" ports, MUST set the start port to 65535 and the end port to - 0. - - 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 (4) 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 (16) - 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 - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 75] - - - - - -Internet-Draft September 23, 2004 - - -3.14 Encrypted Payload - - The Encrypted Payload, denoted SK{...} 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 - sections 2.14 and 2.18. - - The encryption and integrity protection algorithms are modeled after - the ESP algorithms described in RFCs 2104, 2406, 2451. This document - completely specifies the cryptographic processing of IKE data, but - those documents should be consulted for design rationale. We assume 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: - - 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. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 76] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - 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 - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 77] - - - - - -Internet-Draft September 23, 2004 - - - 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 which 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. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 78] - - - - - -Internet-Draft September 23, 2004 - - - 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). - - 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 - - values 5-127 are reserved to IANA. Values 128-255 are for private - use among mutually consenting parties. - - 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. - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 79] - - - - - -Internet-Draft September 23, 2004 - - -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 (7 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: - - 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 - - * These attributes may be multi-valued on return only if - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 80] - - - - - -Internet-Draft September 23, 2004 - - - multiple values were requested. - - Types 16-16383 are reserved to IANA. Values 16384-32767 are for - private use among mutually consenting parties. - - 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. - In a request message, the address specified is a requested - address (or zero 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 - being a 16 octet IPv6 address and the second being 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 - INTERNAL_IP4_ADDRESS attribute. - - 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. - - 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. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 81] - - - - - -Internet-Draft September 23, 2004 - - - 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 being a 16 octet IPv6 address the second being 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 how an - implementation actually figures out what information to send in a - reply. i.e., we do not recommend any specific method of an IRAS - determining which DNS server should be returned to a requesting - IRAC. - -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 are defined elsewhere, - but a short summary of RFC 3748 is included here to make this - document stand alone in the common cases. - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 82] - - - - - -Internet-Draft September 23, 2004 - - - 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 (one octet) indicates whether this message is a - Request (1), Response (2), Success (3), or Failure (4). - - o Identifier (one 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 (two octets) is the length of the EAP message and MUST - be four less than the Payload Length of the encapsulating - payload. - - o Type (one 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 83] - - - - - -Internet-Draft September 23, 2004 - - - 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]. - - 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 SHOULD, 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 only allow 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: - - Ability to negotiate SAs through a NAT and tunnel the resulting - ESP SA over UDP. - - Ability to request (and respond to a request for) a temporary IP - address on the remote end of a tunnel. - - Ability to support various types of legacy authentication. - - Ability to support window sizes greater than one. - - Ability to establish multiple ESP and/or AH SAs within a single - IKE_SA. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 84] - - - - - -Internet-Draft September 23, 2004 - - - 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 closing 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. The responder SHOULD include all of the other related - attributes if it has them. - - 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. The only attribute - it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 85] - - - - - -Internet-Draft September 23, 2004 - - - use to bound the lifetime of the SA unless it successfully renews the - lease before it expires. 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: - - 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. - - Shared key authentication where the ID passes is any of ID_KEY_ID, - ID_FQDN, or ID_RFC822_ADDR. - - 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. - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 86] - - - - - -Internet-Draft September 23, 2004 - - - 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 which prohibits using stronger - groups nor is there anything which 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 are 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 [RFC1750]). 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]. 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, - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 87] - - - - - -Internet-Draft September 23, 2004 - - - 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 which - 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 which 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. 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 - EAP data from active attackers. - - If the messages of IKEv2 are long enough that IP level fragmentation - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 88] - - - - - -Internet-Draft September 23, 2004 - - - 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 [KPS03]. - -6 IANA Considerations - - This document defines a number of new field types and values where - future assignments will be managed by the IANA. - - The following registries should be created: - - IKEv2 Exchange Types (section 3.1) - IKEv2 Payload Types (section 3.2) - IKEv2 Transform Types (section 3.3.2) - IKEv2 Transform Attribute Types (section 3.3.2) - IKEv2 Encryption Transform IDs (section 3.3.2) - IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) - IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) - IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) - IKEv2 Identification Payload ID Types (section 3.5) - IKEv2 Certificate Encodings (section 3.6) - IKEv2 Authentication Method (section 3.8) - IKEv2 Notify Message Types (section 3.10.1) - IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) - IKEv2 Security Protocol Identifiers (section 3.3.1) - IKEv2 Traffic Selector Types (section 3.13.1) - IKEv2 Configuration Payload CFG Types (section 3.15) - IKEv2 Configuration Payload Attribute Types (section 3.15.1) - - Note: when creating a new Transform Type, a new registry for it must - be created. - - Changes and additions to any of those registries are by expert - review. - -7 Acknowledgements - - 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, - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 89] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -8 References - -8.1 Normative References - - [ADDGROUP] Kivinen, T., and Kojo, M., "More Modular Exponential - (MODP) Diffie-Hellman groups for Internet Key - Exchange (IKE)", RFC 3526, May 2003. - - [ADDRIPV6] Hinden, R., and Deering, S., - "Internet Protocol Version 6 (IPv6) Addressing - Architecture", RFC 3513, April 2003. - - [Bra97] Bradner, S., "Key Words for use in RFCs to indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and - Levkowetz, H., "Extensible Authentication Protocol - (EAP)", RFC 3748, June 2004. - - [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec - Packets", draft-ietf-ipsec-udp-encaps-08.txt, February - 2004, work in progress. - - [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture - for the Internet Protocol", - draft-ietf-ipsec-rfc2401bis-02.txt, April 2004, work - in progress. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing - an IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., - "The Addition of Explicit Congestion Notification (ECN) - to IP", RFC 3168, September 2001. - - [RFC3280] Housley, R., Polk, W., Ford, W., Solo, D., "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 90] - - - - - -Internet-Draft September 23, 2004 - - - April 2002. - - [RFC3667] Bradner, S., "IETF Rights in Submissions", BCP 78, - RFC 3667, February 2004. - - [RFC3668] Bradner, S., "Intellectual Property Rights in IETF - Technology", BCP 79, RFC 3668, February 2004. - -8.2 Informative References - - [DES] ANSI X3.106, "American National Standard for Information - Systems-Data Link Encryption", American National Standards - Institute, 1983. - - [DH] Diffie, W., and Hellman M., "New Directions in - Cryptography", IEEE Transactions on Information Theory, V. - IT-22, n. 6, June 1977. - - [DHCP] R. Droms, "Dynamic Host Configuration Protocol", - RFC2131 - - [DSS] NIST, "Digital Signature Standard", FIPS 186, National - Institute of Standards and Technology, U.S. Department of - Commerce, May, 1994. - - [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle - in Tunneled Authentication Protocols", - http://eprint.iacr.org/2002/163, November 2002. - - [HC98] Harkins, D., Carrel, D., "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IDEA] Lai, X., "On the Design and Security of Block Ciphers," - ETH Series in Information Processing, v. 1, Konstanz: - Hartung-Gorre Verlag, 1992 - - [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP - Payload Compression Protocol (IPComp)", RFC 3173, - September 2001. - - [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS - protection for UDP-based protocols", ACM Conference on - Computer and Communications Security, October 2003. - - [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 91] - - - - - -Internet-Draft September 23, 2004 - - - [LDAP] M. Wahl, T. Howes, S. Kille., "Lightweight Directory - Access Protocol (v3)", RFC 2251 - - [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - - [MSST98] Maughhan, D., Schertler, M., Schneider, M., and Turner, J. - "Internet Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC - 2412, November 1998. - - [PFKEY] McDonald, D., Metz, C., and Phan, B., "PFKEY Key - Management API, Version 2", RFC 2367, July 1998. - - [PKCS1] Kaliski, B., and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2", September 1998. - - [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key - exchange Standard", WET-ICE Security Conference, MIT,2001, - http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. - - [Pip98] Piper, D., "The Internet IP Security Domain Of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote - Authentication Dial In User Service (RADIUS)", RFC 2138 - - [RFC1750] Eastlake, D., Crocker, S., and Schiller, J., "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [RFC1958] Carpenter, B., "Architectural Principles of the - Internet", RFC 1958, June 1996. - - [RFC2401] Kent, S., and Atkinson, R., "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. - - [RFC2402] Kent, S., and Atkinson, R., "IP Authentication Header", - RFC 2402, November 1998. - - [RFC2406] Kent, S., and Atkinson, R., "IP Encapsulating Security - Payload (ESP)", RFC 2406, November 1998. - - [RFC2474] Nichols, K., Blake, S., Baker, F. and Black, D., - "Definition of the Differentiated Services Field (DS - Field) in the IPv4 and IPv6 Headers", RFC 2474, - December 1998. - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 92] - - - - - -Internet-Draft September 23, 2004 - - - [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. - and Weiss, W., "An Architecture for Differentiated - Services", RFC 2475, December 1998. - - [RFC2522] Karn, P., and Simpson, W., "Photuris: Session-Key - Management Protocol", RFC 2522, March 1999. - - [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, - February 2000. - - [RFC2983] Black, D., "Differentiated Services and Tunnels", - RFC 2983, October 2000. - - [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3429, December 2002. - - [RFC3715] Aboba, B and Dixon, W., "IPsec-Network Address - Translation (NAT) Compatibility Requirements", - RFC 3715, March 2004. - - [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for - Obtaining Digital Signatures and Public-Key - Cryptosystems", Communications of the ACM, v. 21, n. 2, - February 1978. - - [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National - Institute of Standards and Technology, U.S. Department - of Commerce, May 1994. - - [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to - Authenticated Diffie-Hellman and its Use in the IKE - Protocols", in Advances in Cryptography - CRYPTO 2003 - Proceedings, LNCS 2729, Springer, 2003. Available at: - http://www.ee.technion.ac.il/~hugo/sigma.html - - [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange - Mechanism for Internet", from IEEE Proceedings of the - 1996 Symposium on Network and Distributed Systems - Security. - - [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, June 1997. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 93] - - - - - -Internet-Draft September 23, 2004 - - -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); - - 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 94] - - - - - -Internet-Draft September 23, 2004 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 95] - - - - - -Internet-Draft September 23, 2004 - - -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 [Orm96]. - - 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. - - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 96] - - - - - -Internet-Draft September 23, 2004 - - -Change History (To be removed from RFC) - -H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 - - 1) Changed Appendix B to specify the encryption and authentication - processing for IKE rather than referencing ESP. Simplified the format - by removing idiosyncrasies not needed for IKE. - - 2) Added option for authentication via a shared secret key. - - 3) Specified different keys in the two directions of IKE messages. - Removed requirement of different cookies in the two directions since - now no longer required. - - 4) Change the quantities signed by the two ends in AUTH fields to - assure the two parties sign different quantities. - - 5) Changed reference to AES to AES_128. - - 6) Removed requirement that Diffie-Hellman be repeated when rekeying - IKE_SA. - - 7) Fixed typos. - - 8) Clarified requirements around use of port 500 at the remote end in - support of NAT. - - 9) Clarified required ordering for payloads. - - 10) Suggested mechanisms for avoiding DoS attacks. - - 11) Removed claims in some places that the first phase 2 piggybacked - on phase 1 was optional. - -H.2 Changes from IKEv2-01 to IKEv2-02 April 2002 - - 1) Moved the Initiator CERTREQ payload from message 1 to message 3. - - 2) Added a second optional ID payload in message 3 for the Initiator - to name a desired Responder to support the case where multiple named - identities are served by a single IP address. - - 3) Deleted the optimization whereby the Diffie-Hellman group did not - need to be specified in phase 2 if it was the same as in phase 1 (it - complicated the design with no meaningful benefit). - - 4) Added a section on the implications of reusing Diffie-Hellman - exponentials - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 97] - - - - - -Internet-Draft September 23, 2004 - - - 5) Changed the specification of sequence numbers to being at 0 in - both directions. - - 6) Many editorial changes and corrections, the most significant being - a global replace of "byte" with "octet". - -H.3 Changes from IKEv2-02 to IKEv2-03 October 2002 - - 1) Reorganized the document moving introductory material to the - front. - - 2) Simplified the specification of Traffic Selectors to allow only - IPv4 and IPv6 address ranges, as was done in the JFK spec. - - 3) Fixed the problem brought up by David Faucher with the fix - suggested by Valery Smyslov. If Bob needs to narrow the selector - range, but has more than one matching narrower range, then if Alice's - first selector is a single address pair, Bob chooses the range that - encompasses that. - - 4) To harmonize with the JFK spec, changed the exchange so that the - initial exchange can be completed in four messages even if the - responder must invoke an anti-clogging defense and the initiator - incorrectly anticipates the responder's choice of Diffie-Hellman - group. - - 5) Replaced the hierarchical SA payload with a simplified version - that only negotiates suites of cryptographic algorithms. - -H.4 Changes from IKEv2-03 to IKEv2-04 January 2003 - - 1) Integrated NAT traversal changes (including Appendix A). - - 2) Moved the anti-clogging token (cookie) from the SPI to a NOTIFY - payload; changed negotiation back to 6 messages when a cookie is - needed. - - 3) Made capitalization of IKE_SA and CHILD_SA consistent. - - 4) Changed how IPComp was negotiated. - - 5) Added usage scenarios. - - 6) Added configuration payload for acquiring internal addresses on - remote networks. - - 7) Added negotiation of tunnel vs. transport mode. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 98] - - - - - -Internet-Draft September 23, 2004 - - -H.5 Changes from IKEv2-04 to IKEv2-05 February 2003 - - 1) Shortened Abstract - - 2) Moved NAT Traversal from Appendix to section 2. Moved changes from - IKEv2 to Appendix A. Renumbered sections. - - 3) Made language more consistent. Removed most references to Phase 1 - and Phase 2. - - 4) Made explicit the requirements for support of NAT Traversal. - - 5) Added support for Extended Authentication Protocol methods. - - 6) Added Response bit to message header. - - 7) Made more explicit the encoding of Diffie-Hellman numbers in key - expansion algorithms. - - 8) Added ID payloads to AUTH payload computation. - - 9) Expanded set of defined cryptographic suites. - - 10) Added text for MUST/SHOULD support for ID payloads. - - 11) Added new certificate formats and added MUST/SHOULD text. - - 12) Clarified use of CERTREQ. - - 13) Deleted "MUST SUPPORT" column in CP payload specification (it was - inconsistent with surrounding text). - - 14) Extended and clarified Conformance Requirements section, - including specification of a minimal implementation. - - 15) Added text to specify ECN handling. - -H.6 Changes from IKEv2-05 to IKEv2-06 March 2003 - - 1) Changed the suite based crypto negotiation back to ala carte. - - 2) Eliminated some awkward page breaks, typographical errors, and - other formatting issues. - - 3) Tightened language describing cryptographic strength. - - 4) Added references. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 99] - - - - - -Internet-Draft September 23, 2004 - - - 5) Added more specific error codes. - - 6) Added rationale for unintuitive key generation hash with shared - secret based authentication. - - 7) Changed the computation of the authenticating AUTH payload as - proposed by Hugo Krawczyk. - - 8) Changed the dashes (-) to underscores (_) in the names of fields - and constants. - -H.7 Changes from IKEv2-06 to IKEv2-07 April 2003 - - 1) Added a list of payload types to section 3.2. - - 2) Clarified use of SET_WINDOW_SIZE Notify payload. - - 3) Removed references to COOKIE_REQUIRED Notify payload. - - 4) Specified how to use a prf with a fixed key size. - - 5) Removed g^ir from data processed by prf+. - - 6) Strengthened cautions against using passwords as shared keys. - - 7) Renamed Protocol_id field SECURITY_PROTOCOL_ID when it is not the - Protocol ID from IP, and changed its values for consistency with - IKEv1. - - 8) Clarified use of ID payload in access control decisions. - - 9) Gave IDr and TSr their own payload type numbers. - - 10) Added Intellectual Property rights section. - - 11) Clarified some issues in NAT Traversal. - -H.8 Changes from IKEv2-07 to IKEv2-08 May 2003 - - 1) Numerous editorial corrections and clarifications. - - 2) Renamed Gateway to Security Gateway. - - 3) Made explicit that the ability to rekey SAs without restarting IKE - was optional. - - 4) Removed last references to MUST and SHOULD cipher suites. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 100] - - - - - -Internet-Draft September 23, 2004 - - - 5) Changed examples to "example.com". - - 6) Changed references to status codes to status types. - - 7) Simplified IANA Considerations section - - 8) Updated References - -H.9 Changes from IKEv2-08 to IKEv2-09 August 2003 - - 1) Numerous editorial corrections and clarifications. - - 2) Added REKEY_SA notify payload to the first message of a - CREATE_CHILD_SA exchange if the new exchange was rekeying an existing - SA. - - 3) Renamed AES_ENCR128 to AES_ENCR and made it take a single - parameter that is the key size (which may be 128, 192, or 256 bits). - - 4) Clarified when a newly created SA is useable. - - 5) Added additional text to section 2.23 specifying how to negotiate - NAT Traversal. - - 6) Replaced specification of ECN handling with a reference to - [RFC2401bis]. - - 7) Renumbered payloads so that numbers would not collide with IKEv1 - payload numbers in hopes of making code implementing both protocols - simpler. - - 8) Expanded the Transform ID field (also referred to as Diffie- - Hellman group number) from one byte to two bytes. - - 9) Removed ability to negotiate Diffie-Hellman groups by explicitly - passing parameters. They must now be negotiated using Transform IDs. - - 10) Renumbered status codes to be contiguous. - - 11) Specified the meaning of the "Port" fields in Traffic Selectors - when the ICMP protocol is being used. - - 12) Removed the specification of D-H Group #5 since it is already - specified in [ADDGROUP]. - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 101] - - - - - -Internet-Draft September 23, 2004 - - -H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 - - 1) Numerous boilerplate and formatting corrections to comply with RFC - Editorial Guidelines and procedures. - - 2) Fixed five typographical errors. - - 3) Added a sentence to the end of "Security considerations" - discouraging the use of non-key-generating EAP mechanisms. - -H.11 Changes from IKEv2-10 to IKEv2-11 October 2003 - - 1) Added SHOULD NOT language concerning use of non-key-generating EAP - authentication methods and added reference [EAPMITM]. - - 2) Clarified use of parallel SAs with identical traffic selectors for - purposes of QoS handling. - - 3) Fixed description of ECN handling to make normative references to - [RFC2401bis] and [RFC3168]. - - 4) Fixed two typos in the description of NAT traversal. - - 5) Added specific ASN.1 encoding of certificate bundles in section - 3.6. - -H.12 Changes from IKEv2-11 to IKEv2-12 January 2004 - - 1) Made the values of the one byte IPsec Protocol ID consistent - between payloads and made the naming more nearly consistent. - - 2) Changed the specification to require that AUTH payloads be - provided in EAP exchanges even when a non-key generating EAP method - is used. This protects against certain obscure cryptographic - threats. - - 3) Changed all example IP addresses to be within subnet 10. - - 4) Specified that issues surrounding weak keys and DES key parity - must be addressed in algorithm documents. - - 5) Removed the unsupported (and probably untrue) claim that Photuris - cookies were given that name because the IETF always supports - proposals involving cookies. - - 6) Fixed some text that specified that Transform ID was 1 octet while - everywhere else said it was 2 octets. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 102] - - - - - -Internet-Draft September 23, 2004 - - - 7) Corrected the ASN.1 specification of the encoding of X.509 - certificate bundles. - - 8) Added an INVALID_SELECTORS error type. - - 9) Replaced IANA considerations section with a reference to draft- - ietf-ipsec-ikev2-iana-00.txt. - - 10) Removed 2 obsolete informative references and added one to a - paper on UDP fragmentation problems. - - 11) 41 Editorial Corrections and Clarifications. - - 12) 6 Grammatical and Spelling errors fixed. - - 13) 4 Corrected capitalizations of MAY/MUST/etc. - - 14) 4 Attempts to make capitalization and use of underscores more - consistent. - -H.13 Changes from IKEv2-12 to IKEv2-13 March 2004 - - 1) Updated copyright and intellectual property right sections per RFC - 3667. Added normative references to RFC 3667 and RFC 3668. - - 2) Updated IANA Considerations section and adjusted some assignment - tables to be consistent with the IANA registries document. Added - Michael Richardson to the acknowledgements. - - 3) Changed the cryptographic formula for computing the AUTH payload - in the case where EAP authentication is used and the EAP algorithm - does not produce a shared key. Clarified the case where it does - produce a shared key. - - 4) Extended the EAP authentication protocol by two messages so that - the AUTH message is always sent after the success status is received. - - 5) Updated reference to ESP encapsulation in UDP and made it - normative. - - 6) Added notification type ESP_TFC_PADDING_NOT_SUPPORTED. - - 7) Clarified encoding of port number fields in transport selectors in - the cases of ICMP and OPAQUE. - - 8) Clarified that the length of the integrity checksum is fixed - length and determined by the negotiated integrity algorithm. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 103] - - - - - -Internet-Draft September 23, 2004 - - - 9) Added an informative reference to RFC 3715 (NAT Compatibility - Requirements). - - 10) Fixed 2 typos. - -H.14 Changes from IKEv2-13 to IKEv2-14 May 2004 - - 1) ISSUE #99: Clarified use of tunnel mode vs. transport mode. - - 2) Changed the cryptographic formula for computing the AUTH payload - in response to a suggestion from Hugo Krawczyk. - - 3) Fixed a wording error in the explanation of why NAT traversal - works as it does related to processing by legacy NAT gateways. - - 4) Corrected the label AUTH_AES_XCBC_96 to AUTH_AES_PRF_128. - - 5) Deleted suggestion that ID_KEY_ID field might be used to pass an - account name. - - 6) Listed the newly allocated OID for certificate bundle. - - 7) Added NON_FIRST_FRAGMENTS_ALSO notification for negotiating the - ability to send non-initial fragments of packets on the same SA as - the initial fragments. - - 8) ISSUE #97: Removed language concerning the relative strength of - Diffie-Hellman groups. - - 9) ISSUE #100: Reduced requirements concerning sending of - certificates to allow implementations to by more coy about their - identities and protect themselves from probing attacks. Listed in - Security Considerations some issues an implementer might consider in - deciding how to deal with such attacks. - - 10) Made the punctuation of references to RFCs more consistent. - - 11) Fixed fourteen typos. - -H.15 Changes from IKEv2-14 to IKEv2-15 August 2004 - - 1) ISSUE #111, 113: Made support for "Hash and URL" as a substitute - for certificates mandatory, and added explanatory text about the - dangers of depending on IP fragmentation for large messages. - - 2) ISSUE #110: Made support for configuring shared keys by means of a - HEX encoded byte string mandatory. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 104] - - - - - -Internet-Draft September 23, 2004 - - - 3) Clarified use of special traffic selectors with a port range from - 65535 - 0. - - 4) ISSUE #110: Added reference to RFC2401bis for definitions of - terms. - - 5) ISSUE #110, 114: Made required support of ID_IPV4_ADDR and - ID_IPV6_ADDR depend on support of IPv4 vs. IPv6 as a transport. - - 6) ISSUE #114: Removed INTERNAL_IP6_NETMASK and replaced it with text - describing how an endpoint should request an IP address with - specified low order bytes. - - 7) ISSUE #101, 102, 104, 105, 106, and 107: Fold in information from - draft-ietf-ipsec-ikev2-iana-00.txt to make that document unnecessary - for initial IANA settings. Deleted it from references. - - 8) ISSUE #110: Removed reference to ENCR_RC4. - - 9) ISSUE #112: Removed reference to draft-keromytis-ike-id-00.txt, - which will not be published as an RFC. - - 10) ISSUE #112: Removed text incorrectly implying that AH could be - tunneled over port 4500. - - 11) ISSUE #112: Removed reference to draft-ietf-ipsec-nat- - reqts-04.txt. - - 12) ISSUE #112: Removed reference to draft-ipsec-ike-hash- - revised-02.txt, and substituted a short explanation of the problem - addressed. - - 13) ISSUE #112: Changed the label of PRF_AES_CBC to PRF_AES128_CBC - - 14) ISSUE #110: Clarified distinction between Informational messages - and Informational exchanges. - - 15) ISSUE #110: Clarified distinction between SA payloads and SAs. - - 16) ISSUE #109: Clarified that cryptographic algorithms that MUST be - supported can still be configured as off. - - 17) ISSUE #110: Changed example IP addresses from 10.*.*.* to - 192.0.*.*. - - 18) ISSUE #108: Rephrased to avoid use of the undefined acronyms PFS - and NAT-T. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 105] - - - - - -Internet-Draft September 23, 2004 - - - 19) ISSUE #113: Added requirement that backoff timers on - retransmissions must increase exponentially to avoid network - congestion. - - 20) Replaced dubious explanation of NON_FIRST_FRAGMENTS_ALSO with a - reference to RFC2401bis. - - 21) Fixed 16 spelling/typographical/gramatical errors. - -H.16 Changes from IKEv2-15 to IKEv2-16 September 2004 - - 1) Added the text: "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." - - 2) Removed the two ECC groups from Appendix B. - - 3) Changed references to RFC 2284 to RFC 3748, references to Extended - Authentication Protocol to Extensible Authentication Protocol, and - made some editorial corrections related to EAP proposed by Jari - Arkko. - - 4) Added a note to security considerations saying that IKE MUST NOT - negotiate NONE as its integrity protection algorithm or ENCR_NULL as - its encryption algorithm. - - 5) Added I-D boilerplate concerning IPR claim disclosure. - - 6) Clarified that "empty" messages included a single empty Encrypted - payload. - - 7) Added (SA) after first reference to "Security Association". - - 8) Noted that incompatible configurations of traffic selectors SHOULD - be noted in error logs. - - 9) 3 minor editorial clarifications. - -H.17 Changes from IKEv2-16 to IKEv2-17 September 2004 - - 1) Removed all references to Alice and Bob, replacing them with "the - initiator" and "the responder". Also fixed the corresponding he/she, - his/her, and the capitalization of initiator and responder. - - 2) Changed specification of BER encoded fields to be DER encoded - fields. - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 106] - - - - - -Internet-Draft September 23, 2004 - - - 3) Removed obsolete reference to CA names appearing in CERTREQ - fields. - - 4) Fixed the specification of INTERNAL_IPx_SUBNET Configuration - Attributes to indicate that they could be multi-valued. - - 5) Added informative references to RFC 2402 and RFC 2406. - - 6) Fixed a formatting glitch in the computation of AUTH. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 107] - - - - - -Internet-Draft September 23, 2004 - - -Editor's Address - - Charlie Kaufman - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052 - 1-425-707-3335 - - charliek@microsoft.com - - By submitting this Internet-Draft, the editor represents that any - applicable patent or other IPR claims of which he is aware have been - or will be disclosed, and any of which he becomes aware will be - disclosed, in accordance with RFC 3668. - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). 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 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 - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 108] - - - - - -Internet-Draft September 23, 2004 - - - 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. - -Expiration - - This Internet-Draft (draft-ietf-ipsec-ikev2-17.txt) expires in March - 2005. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -IKEv2 draft-ietf-ipsec-ikev2-17.txt [Page 109] - diff --git a/doc/ikev2/[IKEv2bis] - draft-hoffman-ikev2bis-00.txt b/doc/ikev2/[IKEv2bis] - draft-hoffman-ikev2bis-00.txt deleted file mode 100644 index 9d1b9d74d..000000000 --- a/doc/ikev2/[IKEv2bis] - 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 = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) - - where <secret> is a randomly generated secret known only to the - responder and periodically changed and | indicates concatenation. - <VersionIDofSecret> should be changed whenever <secret> 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 <secret> 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 <secret> is chosen while there are connections in - the process of being initialized, an IKE_SA_INIT might be returned - with other than the current <VersionIDofSecret>. 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 <secret> around for a - short time and accept cookies computed from either one. {{ Demoted - the SHOULD NOT }} The responder should not accept cookies - indefinitely after <secret> is changed, since that would defeat part - of the denial of service protection. {{ Demoted the SHOULD }} The - responder should change the value of <secret> 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"), <msg octets>) - - 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Proposals> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Transforms> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Traffic Selectors> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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, - <http://eprint.iacr.org/2002/163>. - - [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, - <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>. - - [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, <http:// - www.informatik.uni-trier.de/~ley/db/conf/crypto/ - crypto2003.html>. - - [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/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt b/doc/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt deleted file mode 100644 index 863ffe3ff..000000000 --- a/doc/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt +++ /dev/null @@ -1,5657 +0,0 @@ -Network Working Group S. Kent -Internet Draft K. Seo -draft-ietf-ipsec-rfc2401bis-06.txt BBN Technologies -Obsoletes: RFC 2401 March 2005 -Expires September 2005 - - - - - - - - Security Architecture for the Internet Protocol - - - - Dedicated to the memory of Charlie Lynn, a long time senior - colleague at BBN, who made very significant contributions to - the IPsec documents. - - - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - This document is an Internet Draft and is subject to all provisions - of Section 10 of RFC2026. 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/1id-abstracts.html. The list of - Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - Copyright (C) The Internet Society (2005). All Rights Reserved. - -Abstract - - This document describes an updated version of the "Security - Architecture for IP", which is designed to provide security services - for traffic at the IP layer. This document obsoletes RFC 2401 - (November 1998). - - Comments should be sent to Stephen Kent (kent@bbn.com). [RFC Editor: - Please remove this line prior to publication as an RFC.] - - - -Kent & Seo [Page 1] - -Internet Draft Security Architecture for IP March 2005 - - -Table of Contents -1. Introduction........................................................4 - 1.1 Summary of Contents of Document................................4 - 1.2 Audience.......................................................4 - 1.3 Related Documents..............................................5 -2. Design Objectives...................................................5 - 2.1 Goals/Objectives/Requirements/Problem Description..............5 - 2.2 Caveats and Assumptions........................................6 -3. System Overview ....................................................7 - 3.1 What IPsec Does................................................7 - 3.2 How IPsec Works................................................9 - 3.3 Where IPsec Can Be Implemented................................10 -4. Security Associations..............................................11 - 4.1 Definition and Scope..........................................11 - 4.2 SA Functionality..............................................16 - 4.3 Combining SAs.................................................17 - 4.4 Major IPsec Databases.........................................17 - 4.4.1 The Security Policy Database (SPD).......................19 - 4.4.1.1 Selectors...........................................25 - 4.4.1.2 Structure of an SPD entry...........................29 - 4.4.1.3 More re: Fields Associated with Next Layer - Protocols...........................................31 - 4.4.2 Security Association Database (SAD)......................33 - 4.4.2.1 Data Items in the SAD...............................34 - 4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD.36 - 4.4.3 Peer Authorization Database (PAD)........................41 - 4.4.3.1 PAD Entry IDs and Matching Rules....................42 - 4.4.3.2 IKE Peer Authentication Data........................43 - 4.4.3.3 Child SA Authorization Data.........................44 - 4.4.3.4 How the PAD Is Used.................................44 - 4.5 SA and Key Management.........................................45 - 4.5.1 Manual Techniques........................................46 - 4.5.2 Automated SA and Key Management..........................46 - 4.5.3 Locating a Security Gateway..............................47 - 4.6 SAs and Multicast.............................................48 -5. IP Traffic Processing..............................................48 - 5.1 Outbound IP Traffic Processing (protected-to-unprotected).....49 - 5.1.1 Handling an Outbound Packet That Must Be Discarded.......52 - 5.1.2 Header Construction for Tunnel Mode......................53 - 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode.........55 - 5.1.2.2 IPv6 -- Header Construction for Tunnel Mode.........56 - 5.2 Processing Inbound IP Traffic (unprotected-to-protected)......57 -6. ICMP Processing ...................................................61 - 6.1 Processing ICMP Error Messages Directed to an IPsec - Implementation.....................................61 - 6.1.1 ICMP Error Messages Received on the Unprotected - Side of the Boundary...............................61 - 6.1.2 ICMP Error Messages Received on the Protected - Side of the Boundary...............................62 - - -Kent & Seo [Page 2] - -Internet Draft Security Architecture for IP March 2005 - - - 6.2 Processing Protected, Transit ICMP Error Messages.............62 -7. Handling Fragments (on the protected side of the IPsec boundary)...64 - 7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments..65 - 7.2 Separate Tunnel Mode SAs for Non-Initial Fragments............65 - 7.3 Stateful Fragment Checking....................................66 - 7.4 BYPASS/DISCARD traffic........................................66 -8. Path MTU/DF Processing.............................................67 - 8.1 DF Bit........................................................67 - 8.2 Path MTU (PMTU) Discovery.....................................67 - 8.2.1 Propagation of PMTU......................................68 - 8.2.2 PMTU Aging...............................................68 -9. Auditing...........................................................69 -10. Conformance Requirements..........................................69 -11. Security Considerations...........................................69 -12. IANA Considerations...............................................70 -13. Differences from RFC 2401.........................................70 -Acknowledgements......................................................73 -Appendix A -- Glossary................................................74 -Appendix B -- Decorrelation...........................................77 -Appendix C -- ASN.1 for an SPD Entry..................................80 -Appendix D -- Fragment Handling Rationale.............................86 - D.1 Transport Mode and Fragments..................................86 - D.2 Tunnel Mode and Fragments.....................................87 - D.3 The Problem of Non-Initial Fragments..........................88 - D.4 BYPASS/DISCARD traffic........................................91 - D.5 Just say no to ports?.........................................91 - D.6 Other Suggested Solutions.....................................92 - D.7 Consistency...................................................93 - D.8 Conclusions...................................................93 -Appendix E -- Example of Supporting Nested SAs via SPD and Forwarding - Table Entries.....................................94 -References............................................................96 -Author Information....................................................99 -Notices..............................................................100 - - - - - - - - - - - - - - - - - -Kent & Seo [Page 3] - -Internet Draft Security Architecture for IP March 2005 - - -1. Introduction - -1.1 Summary of Contents of Document - - This document specifies the base architecture for IPsec compliant - systems. It describes how to provide a set of security services for - traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] - environments. This document describes the requirements for systems - that implement IPsec, the fundamental elements of such systems, and - how the elements fit together and fit into the IP environment. It - also describes the security services offered by the IPsec protocols, - and how these services can be employed in the IP environment. This - document does not address all aspects of the IPsec architecture. - Other documents address additional architectural details in - specialized environments, e.g., use of IPsec in Network Address - Translation (NAT) environments and more comprehensive support for IP - multicast. The fundamental components of the IPsec security - architecture are discussed in terms of their underlying, required - functionality. Additional RFCs (see Section 1.3 for pointers to - other documents) define the protocols in (a), (c), and (d). - - a. Security Protocols -- Authentication Header (AH) and - Encapsulating Security Payload (ESP) - b. Security Associations -- what they are and how they work, - how they are managed, associated processing - c. Key Management -- manual and automated (The Internet Key - Exchange (IKE)) - d. Cryptographic algorithms for authentication and encryption - - This document is not a Security Architecture for the Internet; it - addresses security only at the IP layer, provided through the use of - a combination of cryptographic and protocol security mechanisms. - - The spelling "IPsec" is preferred and used throughout this and all - related IPsec standards. All other capitalizations of IPsec (e.g., - IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of - the sequence of letters "IPsec" should be understood to refer to the - IPsec protocols. - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in RFC 2119 [Bra97]. - -1.2 Audience - - The target audience for this document is primarily individuals who - implement this IP security technology or who architect systems that - will use this technology. Technically adept users of this technology - (end users or system administrators) also are part of the target - - -Kent & Seo [Page 4] - -Internet Draft Security Architecture for IP March 2005 - - - audience. A glossary is provided in Appendix A to help fill in gaps - in background/vocabulary. This document assumes that the reader is - familiar with the Internet Protocol (IP), related networking - technology, and general information system security terms and - concepts. - -1.3 Related Documents - - As mentioned above, other documents provide detailed definitions of - some of the components of IPsec and of their inter-relationship. - They include RFCs on the following topics: - - a. security protocols -- RFCs describing the Authentication - Header (AH) [Ken05b] and Encapsulating Security Payload - (ESP) [Ken05a] protocols. - b. cryptographic algorithms for integrity and encryption - one - RFC that defines the mandatory, default algorithms for use - with AH and ESP [Eas05], a similar RFC that defines the - mandatory algorithms for use with IKE v2 [Sch05] plus a - separate RFC for each cryptographic algorithm. - c. automatic key management -- RFCs on "The Internet Key - Exchange (IKE v2) Protocol" [Kau05] and "Cryptographic - Algorithms for use in the Internet Key Exchange Version 2" - [Sch05]. - - -2. Design Objectives - -2.1 Goals/Objectives/Requirements/Problem Description - - IPsec is designed to provide interoperable, high quality, - cryptographically-based security for IPv4 and IPv6. The set of - security services offered includes access control, connectionless - integrity, data origin authentication, detection and rejection of - replays (a form of partial sequence integrity), confidentiality (via - encryption), and limited traffic flow confidentiality. These - services are provided at the IP layer, offering protection in a - standard fashion for all protocols that may be carried over IP - (including IP itself). - - IPsec includes a specification for minimal firewall functionality, - since that is an essential aspect of access control at the IP layer. - Implementations are free to provide more sophisticated firewall - mechanisms, and to implement the IPsec-mandated functionality using - those more sophisticated mechanisms. (Note that interoperability may - suffer if additional firewall constraints on traffic flows are - imposed by an IPsec implementation but cannot be negotiated based on - the traffic selector features defined in this document and negotiated - via IKE v2.) The IPsec firewall function makes use of the - - -Kent & Seo [Page 5] - -Internet Draft Security Architecture for IP March 2005 - - - cryptographically-enforced authentication and integrity provided for - all IPsec traffic to offer better access control than could be - obtained through use of a firewall (one not privy to IPsec internal - parameters) plus separate cryptographic protection. - - Most of the security services are provided through use of two traffic - security protocols, the Authentication Header (AH) and the - Encapsulating Security Payload (ESP), and through the use of - cryptographic key management procedures and protocols. The set of - IPsec protocols employed in a context, and the ways in which they are - employed, will be determined by the users/administrators in that - context. It is the goal of the IPsec architecture to ensure that - compliant implementations include the services and management - interfaces needed to meet the security requirements of a broad user - population. - - When IPsec is correctly implemented and deployed, it ought not - adversely affect users, hosts, and other Internet components that do - not employ IPsec for traffic protection. IPsec security protocols - (AH & ESP, and to a lesser extent, IKE) are designed to be - cryptographic algorithm-independent. This modularity permits - selection of different sets of cryptographic algorithms as - appropriate, without affecting the other parts of the implementation. - For example, different user communities may select different sets of - cryptographic algorithms (creating cryptographically-enforced - cliques) if required. - - To facilitate interoperability in the global Internet, a set of - default cryptographic algorithms for use with AH and ESP is specified - in [Eas05] and a set of mandatory-to-implement algorithms for IKE v2 - is specified in [Sch05]. [Eas05] and [Sch05] will be periodically - updated to keep pace with computational and cryptologic advances. By - specifying these algorithms in documents that are separate from the - AH, ESP, and IKE v2 specifications, these algorithms can be updated - or replaced without affecting the standardization progress of the - rest of the IPsec document suite. The use of these cryptographic - algorithms, in conjunction with IPsec traffic protection and key - management protocols, is intended to permit system and application - developers to deploy high quality, Internet layer, cryptographic - security technology. - -2.2 Caveats and Assumptions - - The suite of IPsec protocols and associated default cryptographic - algorithms are designed to provide high quality security for Internet - traffic. However, the security offered by use of these protocols - ultimately depends on the quality of the their implementation, which - is outside the scope of this set of standards. Moreover, the - security of a computer system or network is a function of many - - -Kent & Seo [Page 6] - -Internet Draft Security Architecture for IP March 2005 - - - factors, including personnel, physical, procedural, compromising - emanations, and computer security practices. Thus IPsec is only one - part of an overall system security architecture. - - Finally, the security afforded by the use of IPsec is critically - dependent on many aspects of the operating environment in which the - IPsec implementation executes. For example, defects in OS security, - poor quality of random number sources, sloppy system management - protocols and practices, etc. can all degrade the security provided - by IPsec. As above, none of these environmental attributes are - within the scope of this or other IPsec standards. - -3. System Overview - - This section provides a high level description of how IPsec works, - the components of the system, and how they fit together to provide - the security services noted above. The goal of this description is - to enable the reader to "picture" the overall process/system, see how - it fits into the IP environment, and to provide context for later - sections of this document, which describe each of the components in - more detail. - - An IPsec implementation operates in a host, as a security gateway, or - as an independent device, affording protection to IP traffic. (A - security gateway is an intermediate system implementing IPsec, e.g., - a firewall or router that has been IPsec-enabled.) More detail on - these classes of implementations is provided later, in Section 3.3. - The protection offered by IPsec is based on requirements defined by a - Security Policy Database (SPD) established and maintained by a user - or system administrator, or by an application operating within - constraints established by either of the above. In general, packets - are selected for one of three processing actions based on IP and next - layer header information (Selectors, Section 4.4.1.1) matched against - entries in the Security Policy Database (SPD). Each packet is either - PROTECTed using IPsec security services, DISCARDed, or allowed to - BYPASS IPsec protection, based on the applicable SPD policies - identified by the Selectors. - - -3.1 What IPsec Does - - IPsec creates a boundary between unprotected and protected - interfaces, for a host or a network (see Figure 1 below). Traffic - traversing the boundary is subject to the access controls specified - by the user or administrator responsible for the IPsec configuration. - These controls indicate whether packets cross the boundary unimpeded, - are afforded security services via AH or ESP, or are discarded. IPsec - security services are offered at the IP layer through selection of - appropriate security protocols, cryptographic algorithms, and - - -Kent & Seo [Page 7] - -Internet Draft Security Architecture for IP March 2005 - - - cryptographic keys. IPsec can be used to protect one or more "paths" - (a) between a pair of hosts, (b) between a pair of security gateways, - or (c) between a security gateway and a host. A compliant host - implementation MUST support (a) and (c) and a compliant security - gateway must support all three of these forms of connectivity, since - under certain circumstances a security gateway acts as a host. - - Unprotected - ^ ^ - | | - +-------------|-------|-------+ - | +-------+ | | | - | |Discard|<--| V | - | +-------+ |B +--------+ | - ................|y..| AH/ESP |..... IPsec Boundary - | +---+ |p +--------+ | - | |IKE|<----|a ^ | - | +---+ |s | | - | +-------+ |s | | - | |Discard|<--| | | - | +-------+ | | | - +-------------|-------|-------+ - | | - V V - Protected - - Figure 1. Top Level IPsec Processing Model - - - In this diagram, "unprotected" refers to an interface that might also - be described as "black" or "ciphertext." Here, "protected" refers to - an interface that might also be described as "red" or "plaintext." - The protected interface noted above may be internal, e.g., in a host - implementation of IPsec, the protected interface may link to a socket - layer interface presented by the OS. In this document, the term - "inbound" refers to traffic entering an IPsec implementation via the - unprotected interface or emitted by the implementation on the - unprotected side of the boundary and directed towards the protected - interface. The term "outbound" refers to traffic entering the - implementation via the protected interface, or emitted by the - implementation on the protected side of the boundary and directed - toward the unprotected interface. An IPsec implementation may - support more than one interface on either or both sides of the - boundary. - - Note the facilities for discarding traffic on either side of the - IPsec boundary, the BYPASS facility that allows traffic to transit - the boundary without cryptographic protection, and the reference to - IKE as a protected-side key and security management function. - - -Kent & Seo [Page 8] - -Internet Draft Security Architecture for IP March 2005 - - - IPsec optionally supports negotiation of IP compression [SMPT01], - motivated in part by the observation that when encryption is employed - within IPsec, it prevents effective compression by lower protocol - layers. - -3.2 How IPsec Works - - IPsec uses two protocols to provide traffic security services -- - Authentication Header (AH) and Encapsulating Security Payload (ESP). - Both protocols are described in detail in their respective RFCs - [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY - support AH. (Support for AH has been downgraded to MAY because - experience has shown that there are very few contexts in which ESP - cannot provide the requisite security services. Note that ESP can be - used to provide only integrity, without confidentiality, making it - comparable to AH in most contexts.) - - o The IP Authentication Header (AH) [Ken05b] offers integrity and - data origin authentication, with optional (at the discretion of - the receiver) anti-replay features. - - o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers - the same set of services, and also offers confidentiality. Use of - ESP to provide confidentiality without integrity is NOT - RECOMMENDED. When ESP is used with confidentiality enabled, there - are provisions for limited traffic flow confidentiality, i.e., - provisions for concealing packet length, and for facilitating - efficient generation and discard of dummy packets. This capability - is likely to be effective primarily in VPN and overlay network - contexts. - - o Both AH and ESP offer access control, enforced through the - distribution of cryptographic keys and the management of traffic - flows as dictated by the Security Policy Database (SPD, Section - 4.4.1). - - These protocols may be applied individually or in combination with - each other to provide IPv4 and IPv6 security services. However, most - security requirements can be met through the use of ESP by itself. - Each protocol supports two modes of use: transport mode and tunnel - mode. In transport mode, AH and ESP provide protection primarily for - next layer protocols; in tunnel mode, AH and ESP are applied to - tunneled IP packets. The differences between the two modes are - discussed in Section 4.1. - - IPsec allows the user (or system administrator) to control the - granularity at which a security service is offered. For example, one - can create a single encrypted tunnel to carry all the traffic between - two security gateways or a separate encrypted tunnel can be created - - -Kent & Seo [Page 9] - -Internet Draft Security Architecture for IP March 2005 - - - for each TCP connection between each pair of hosts communicating - across these gateways. IPsec, through the SPD management paradigm, - incorporates facilities for specifying: - - o which security protocol (AH or ESP) to employ, the mode (transport - or tunnel), security service options, what cryptographic - algorithms to use, and in what combinations to use the specified - protocols and services, - - o the granularity at which protection should be applied. - - Because most of the security services provided by IPsec require the - use of cryptographic keys, IPsec relies on a separate set of - mechanisms for putting these keys in place. This document requires - support for both manual and automated distribution of keys. It - specifies a specific public-key based approach (IKE v2 [Kau05]) for - automated key management, but other automated key distribution - techniques MAY be used. - - Note: This document mandates support for several features for which - support is available in IKE v2 but not in IKE v1, e.g., negotiation - of an SA representing ranges of local and remote ports or negotiation - of multiple SAs with the same selectors. Therefore this document - assumes use of IKE v2 or a key and security association management - system with comparable features. - -3.3 Where IPsec Can Be Implemented - - There are many ways in which IPsec may be implemented in a host, or - in conjunction with a router or firewall to create a security - gateway, or as an independent security device. - - a. IPsec may be integrated into the native IP stack. This requires - access to the IP source code and is applicable to both hosts and - security gateways, although native host implementations benefit - the most from this strategy, as explained later (Section 4.4.1, - paragraph 6; Section 4.4.1.1, last paragraph). - - b. In a "bump-in-the-stack" (BITS) implementation, IPsec is - implemented "underneath" an existing implementation of an IP - protocol stack, between the native IP and the local network - drivers. Source code access for the IP stack is not required in - this context, making this implementation approach appropriate for - use with legacy systems. This approach, when it is adopted, is - usually employed in hosts. - - c. The use of a dedicated, inline security protocol processor is a - common design feature of systems used by the military, and of some - commercial systems as well. It is sometimes referred to as a - - -Kent & Seo [Page 10] - -Internet Draft Security Architecture for IP March 2005 - - - "bump-in-the-wire" (BITW) implementation. Such implementations - may be designed to serve either a host or a gateway. Usually the - BITW device is itself IP addressable. When supporting a single - host, it may be quite analogous to a BITS implementation, but in - supporting a router or firewall, it must operate like a security - gateway. - - This document often talks in terms of use of IPsec by a host or a - security gateway, without regard to whether the implementation is - native, BITS or BITW. When the distinctions among these - implementation options are significant, the document makes reference - to specific implementation approaches. - - A host implementation of IPsec may appear in devices that might not - be viewed as "hosts." For example, a router might employ IPsec to - protect routing protocols (e.g., BGP) and management functions (e.g., - Telnet), without affecting subscriber traffic traversing the router. - A security gateway might employ separate IPsec implementations to - protect its management traffic and subscriber traffic. The - architecture described in this document is very flexible. For - example, a computer with a full-featured, compliant, native OS IPsec - implementation should be capable of being configured to protect - resident (host) applications and to provide security gateway - protection for traffic traversing the computer. Such configuration - would make use of the forwarding tables and the SPD selection - function described in Sections 5.1 and 5.2. - -4. Security Associations - - This section defines Security Association management requirements for - all IPv6 implementations and for those IPv4 implementations that - implement AH, ESP, or both AH and ESP. The concept of a "Security - Association" (SA) is fundamental to IPsec. Both AH and ESP make use - of SAs and a major function of IKE is the establishment and - maintenance of SAs. All implementations of AH or ESP MUST support - the concept of an SA as described below. The remainder of this - section describes various aspects of SA management, defining required - characteristics for SA policy management and SA management - techniques. - -4.1 Definition and Scope - - An SA is a simplex "connection" that affords security services to the - traffic carried by it. Security services are afforded to an SA by - the use of AH, or ESP, but not both. If both AH and ESP protection - are applied to a traffic stream, then two SAs must be created and - coordinated to effect protection through iterated application of the - security protocols. To secure typical, bi-directional communication - between two IPsec-enabled systems, a pair of SAs (one in each - - -Kent & Seo [Page 11] - -Internet Draft Security Architecture for IP March 2005 - - - direction) is required. IKE explicitly creates SA pairs in - recognition of this common usage requirement. - - For an SA used to carry unicast traffic, the SPI (Security Parameters - Index - see Appendix A and AH [Ken05b] and ESP [Ken05a] - specifications) by itself suffices to specify an SA. However, as a - local matter, an implementation may choose to use the SPI in - conjunction with the IPsec protocol type (AH or ESP) for SA - identification. If an IPsec implementation supports multicast, then - it MUST support multicast SAs using the algorithm below for mapping - inbound IPsec datagrams to SAs. Implementations that support only - unicast traffic need not implement this demultiplexing algorithm. - - In many secure multicast architectures, e.g., [RFC3740], a central - Group Controller/Key Server unilaterally assigns the Group Security - Association's (GSA's) SPI. This SPI assignment is not negotiated or - coordinated with the key management (e.g., IKE) subsystems that - reside in the individual end systems that constitute the group. - Consequently, it is possible that a GSA and a unicast SA can - simultaneously use the same SPI. A multicast-capable IPsec - implementation MUST correctly de-multiplex inbound traffic even in - the context of SPI collisions. - - Each entry in the SA Database (SAD) (Section 4.4.2) must indicate - whether the SA lookup makes use of the destination IP address, or the - destination and source IP addresses, in addition to the SPI. For - multicast SAs, the protocol field is not employed for SA lookups. For - each inbound, IPsec-protected packet, an implementation must conduct - its search of the SAD such that it finds the entry that matches the - "longest" SA identifier. In this context, if two or more SAD entries - match based on the SPI value, then the entry that also matches based - on destination address, or destination and source address (as - indicated in the SAD entry) is the "longest" match. This implies a - logical ordering of the SAD search as follows: - - - 1. Search the SAD for a match on the combination of SPI, - destination address, and source address. If an SAD entry - matches, then process the inbound packet with that - matching SAD entry. Otherwise, proceed to step 2. - - 2. Search the SAD for a match on both SPI and destination address. - If the SAD entry matches then process the inbound packet - with that matching SAD entry. Otherwise, proceed to step 3. - - 3. Search the SAD for a match on only SPI if the receiver has - chosen to maintain a single SPI space for AH and ESP, and on - both SPI and protocol otherwise. If an SAD entry matches then - process the inbound packet with that matching SAD entry. - - -Kent & Seo [Page 12] - -Internet Draft Security Architecture for IP March 2005 - - - Otherwise, discard the packet and log an auditable event. - - - In practice, an implementation may choose any method (or none at all) - to accelerate this search, although its externally visible behavior - MUST be functionally equivalent to having searched the SAD in the - above order. For example, a software-based implementation could index - into a hash table by the SPI. The SAD entries in each hash table - bucket's linked list could be kept sorted to have those SAD entries - with the longest SA identifiers first in that linked list. Those SAD - entries having the shortest SA identifiers could be sorted so that - they are the last entries in the linked list. A hardware-based - implementation may be able to effect the longest match search - intrinsically, using commonly available Ternary Content-Addressable - Memory (TCAM) features. - - The indication of whether source and destination address matching is - required to map inbound IPsec traffic to SAs MUST be set either as a - side effect of manual SA configuration or via negotiation using an SA - management protocol, e.g., IKE or GDOI [RFC3547]. Typically, - Source-Specific Multicast (SSM) [HC03] groups use a 3-tuple SA - identifier composed of an SPI, a destination multicast address, and - source address. An Any-Source Multicast group SA requires only an SPI - and a destination multicast address as an identifier. - - If different classes of traffic (distinguished by Differentiated - Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the - same SA, and if the receiver is employing the optional anti-replay - feature available in both AH and ESP, this could result in - inappropriate discarding of lower priority packets due to the - windowing mechanism used by this feature. Therefore a sender SHOULD - put traffic of different classes, but with the same selector values, - on different SAs to support QoS appropriately. To permit this, the - IPsec implementation MUST permit establishment and maintenance of - multiple SAs between a given sender and receiver, with the same - selectors. Distribution of traffic among these parallel SAs to - support QoS is locally determined by the sender and is not negotiated - by IKE. The receiver MUST process the packets from the different SAs - without prejudice. These requirements apply to both transport and - tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in - question appear in the inner IP header. In transport mode, the DSCP - value might change en route, but this should not cause problems with - respect to IPsec processing since the value is not employed for SA - selection and MUST NOT be checked as part of SA/packet validation. - However, if significant re-ordering of packets occurs in an SA, e.g., - as a result of changes to DSCP values en route, this may trigger - packet discarding by a receiver due to application of the anti-replay - mechanism. - - - -Kent & Seo [Page 13] - -Internet Draft Security Architecture for IP March 2005 - - - DISCUSSION: While the DSCP [NiBlBaBL98, Gro02] and Explicit - Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", - as that term in used in this architecture, the sender will need a - mechanism to direct packets with a given (set of) DSCP values to the - appropriate SA. This mechanism might be termed a "classifier". - - As noted above, two types of SAs are defined: transport mode and - tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose - to require that both SAs in a pair be of the same mode, transport or - tunnel. - - A transport mode SA is an SA typically employed between a pair of - hosts to provide end-to-end security services. When security is - desired between two intermediate systems along a path (vs. end-to-end - use of IPsec), transport mode MAY be used between security gateways - or between a security gateway and a host. In the case where - transport mode is used between security gateways or between a - security gateway and a host, transport mode may be used to support - in-IP tunneling (e.g., IP-in-IP [Per96] or GRE tunneling - [FaLiHaMeTr00] or Dynamic routing [ToEgWa04]) over transport mode - SAs. To clarify, the use of transport mode by an intermediate system - (e.g., a security gateway) is permitted only when applied to packets - whose source address (for outbound packets) or destination address - (for inbound packets) is an address belonging to the intermediate - system itself. The access control functions that are an important - part of IPsec are significantly limited in this context, as they - cannot be applied to the end-to-end headers of the packets that - traverse a transport mode SA used in this fashion. Thus this way of - using transport mode should be evaluated carefully before being - employed in a specific context. - - In IPv4, a transport mode security protocol header appears - immediately after the IP header and any options, and before any next - layer protocols (e.g., TCP or UDP). In IPv6, the security protocol - header appears after the base IP header and selected extension - headers, but may appear before or after destination options; it MUST - appear before next layer protocols (e.g., TCP, UDP, SCTP). In the - case of ESP, a transport mode SA provides security services only for - these next layer protocols, not for the IP header or any extension - headers preceding the ESP header. In the case of AH, the protection - is also extended to selected portions of the IP header preceding it, - selected portions of extension headers, and selected options - (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or - IPv6 Destination extension headers). For more details on the - coverage afforded by AH, see the AH specification [Ken05b]. - - A tunnel mode SA is essentially an SA applied to an IP tunnel, with - the access controls applied to the headers of the traffic inside the - tunnel. Two hosts MAY establish a tunnel mode SA between themselves. - - -Kent & Seo [Page 14] - -Internet Draft Security Architecture for IP March 2005 - - - Aside from the two exceptions below, whenever either end of a - security association is a security gateway, the SA MUST be tunnel - mode. Thus an SA between two security gateways is typically a tunnel - mode SA, as is an SA between a host and a security gateway. The two - exceptions are as follows. - - o Where traffic is destined for a security gateway, e.g., SNMP - commands, the security gateway is acting as a host and transport - mode is allowed. In this case, the SA terminates at a host - (management) function within a security gateway and thus merits - different treatment. - - o As noted above, security gateways MAY support a transport mode SA - to provide security for IP traffic between two intermediate - systems along a path, e.g., between a host and a security gateway - or between two security gateways. - - Several concerns motivate the use of tunnel mode for an SA involving - a security gateway. For example, if there are multiple paths (e.g., - via different security gateways) to the same destination behind a - security gateway, it is important that an IPsec packet be sent to the - security gateway with which the SA was negotiated. Similarly, a - packet that might be fragmented en-route must have all the fragments - delivered to the same IPsec instance for reassembly prior to - cryptographic processing. Also, when a fragment is processed by IPsec - and transmitted, then fragmented en-route, it is critical that there - be inner and outer headers to retain the fragmentation state data for - the pre- and post-IPsec packet formats. Hence there are several - reasons for employing tunnel mode when either end of an SA is a - security gateway. (Use of an IP-in-IP tunnel in conjunction with - transport mode can also address these fragmentation issues. However, - this configuration limits the ability of IPsec to enforce access - control policies on traffic.) - - Note: AH and ESP cannot be applied using transport mode to IPv4 - packets that are fragments. Only tunnel mode can be employed in such - cases. For IPv6, it would be feasible to carry a plaintext fragment - on a transport mode SA; however, for simplicity, this restriction - also applies to IPv6 packets. See Section 7 for more details on - handling plaintext fragments on the protected side of the IPsec - barrier. - - For a tunnel mode SA, there is an "outer" IP header that specifies - the IPsec processing source and destination, plus an "inner" IP - header that specifies the (apparently) ultimate source and - destination for the packet. The security protocol header appears - after the outer IP header, and before the inner IP header. If AH is - employed in tunnel mode, portions of the outer IP header are afforded - protection (as above), as well as all of the tunneled IP packet - - -Kent & Seo [Page 15] - -Internet Draft Security Architecture for IP March 2005 - - - (i.e., all of the inner IP header is protected, as well as next layer - protocols). If ESP is employed, the protection is afforded only to - the tunneled packet, not to the outer header. - - In summary, - - a) A host implementation of IPsec MUST support both transport and - tunnel mode. This is true for native, BITS, and BITW - implementations for hosts. - - b) A security gateway MUST support tunnel mode and MAY support - transport mode. If it supports transport mode, that should be - used only when the security gateway is acting as a host, e.g., for - network management, or to provide security between two - intermediate systems along a path. - -4.2 SA Functionality - - The set of security services offered by an SA depends on the security - protocol selected, the SA mode, the endpoints of the SA, and on the - election of optional services within the protocol. - - For example, both AH and ESP offer integrity and authentication - services, but the coverage differs for each protocol and differs for - transport vs. tunnel mode. If the integrity of an IPv4 option or IPv6 - extension header must be protected en-route between sender and - receiver, AH can provide this service, except for IP or extension - headers that may change in a fashion not predictable by the sender. - However, the same security may be achieved in some contexts by - applying ESP to a tunnel carrying a packet. - - The granularity of access control provided is determined by the - choice of the selectors that define each SA. Moreover, the - authentication means employed by IPsec peers, e.g., during creation - of an IKE (vs. child) SA also effects the granularity of the access - control afforded. - - If confidentiality is selected, then an ESP (tunnel mode) SA between - two security gateways can offer partial traffic flow confidentiality. - The use of tunnel mode allows the inner IP headers to be encrypted, - concealing the identities of the (ultimate) traffic source and - destination. Moreover, ESP payload padding also can be invoked to - hide the size of the packets, further concealing the external - characteristics of the traffic. Similar traffic flow confidentiality - services may be offered when a mobile user is assigned a dynamic IP - address in a dialup context, and establishes a (tunnel mode) ESP SA - to a corporate firewall (acting as a security gateway). Note that - fine granularity SAs generally are more vulnerable to traffic - analysis than coarse granularity ones that are carrying traffic from - - -Kent & Seo [Page 16] - -Internet Draft Security Architecture for IP March 2005 - - - many subscribers. - - Note: A compliant implementation MUST NOT allow instantiation of an - ESP SA that employs both NULL encryption and no integrity algorithm. - An attempt to negotiate such an SA is an auditable event by both - initiator and responder. The audit log entry for this event SHOULD - include the current date/time, local IKE IP address, and remote IKE - IP address. The initiator SHOULD record the relevant SPD entry. - -4.3 Combining SAs - - This document does not require support for nested security - associations or for what RFC 2401 called "SA bundles." These features - still can be effected by appropriate configuration of both the SPD - and the local forwarding functions (for inbound and outbound - traffic), but this capability is outside of the IPsec module and thus - the scope of this specification. As a result, management of - nested/bundled SAs is potentially more complex and less assured than - under the model implied by RFC 2401. An implementation that provides - support for nested SAs SHOULD provide a management interface that - enables a user or administrator to express the nesting requirement, - and then create the appropriate SPD entries and forwarding table - entries to effect the requisite processing. (See Appendix E for an - example of how to configure nested SAs.) - -4.4 Major IPsec Databases - - Many of the details associated with processing IP traffic in an IPsec - implementation are largely a local matter, not subject to - standardization. However, some external aspects of the processing - must be standardized to ensure interoperability and to provide a - minimum management capability that is essential for productive use of - IPsec. This section describes a general model for processing IP - traffic relative to IPsec functionality, in support of these - interoperability and functionality goals. The model described below - is nominal; implementations need not match details of this model as - presented, but the external behavior of implementations MUST - correspond to the externally observable characteristics of this model - in order to be compliant. - - There are three nominal databases in this model: the Security Policy - Database (SPD), the Security Association Database (SAD), and the Peer - Authorization Database (PAD). The first specifies the policies that - determine the disposition of all IP traffic inbound or outbound from - a host or security gateway (Section 4.4.1). The second database - contains parameters that are associated with each established (keyed) - SA (Section 4.4.2). The third database, the Peer Authorization - Database (PAD) provides a link between an SA management protocol like - IKE and the SPD (Section 4.4.3). - - -Kent & Seo [Page 17] - -Internet Draft Security Architecture for IP March 2005 - - - Multiple Separate IPsec Contexts - - If an IPsec implementation acts as a security gateway for multiple - subscribers, it MAY implement multiple separate IPsec contexts. - Each context MAY have and MAY use completely independent - identities, policies, key management SAs, and/or IPsec SAs. This - is for the most part a local implementation matter. However, a - means for associating inbound (SA) proposals with local contexts - is required. To this end, if supported by the key management - protocol in use, context identifiers MAY be conveyed from - initiator to responder in the signaling messages, with the result - that IPsec SAs are created with a binding to a particular context. - For example, a security gateway that provides VPN service to - multiple customers will be able to associate each customer's - traffic with the correct VPN. - - Forwarding vs Security Decisions - - The IPsec model described here embodies a clear separation between - forwarding (routing) and security decisions, to accommodate a wide - range of contexts where IPsec may be employed. Forwarding may be - trivial, in the case where there are only two interfaces, or it - may be complex, e.g., if the context in which IPsec is implemented - employs a sophisticated forwarding function. IPsec assumes only - that outbound and inbound traffic that has passed through IPsec - processing is forwarded in a fashion consistent with the context - in which IPsec is implemented. Support for nested SAs is optional; - if required, it requires coordination between forwarding tables - and SPD entries to cause a packet to traverse the IPsec boundary - more than once. - - "Local" vs "Remote" - - In this document, with respect to IP addresses and ports, the - terms "Local" and "Remote" are used for policy rules. "Local" - refers to the entity being protected by an IPsec implementation, - i.e., the "source" address/port of outbound packets or the - "destination" address/port of inbound packets. "Remote" refers to - a peer entity or peer entities. The terms "source" and - "destination" are used for packet header fields. - - "Non-initial" vs "Initial" Fragments - - Throughout this document, the phrase "non-initial" fragments is - used to mean fragments that do not contain all of the selector - values that may be needed for access control (e.g., they might not - contain Next Layer Protocol, source and destination ports, ICMP - message type/code, Mobility Header type). And the phrase "initial" - fragment is used to mean a fragment that contains all the selector - - -Kent & Seo [Page 18] - -Internet Draft Security Architecture for IP March 2005 - - - values needed for access control. However, it should be noted that - for IPv6, which fragment contains the Next Layer Protocol and - ports (or ICMP message type/code or Mobility Header type) will - depend on the kind and number of extension headers present. The - "initial" fragment might not be the first fragment, in this - context. - -4.4.1 The Security Policy Database (SPD) - - An SA is a management construct used to enforce security policy for - traffic crossing the IPsec boundary. Thus an essential element of SA - processing is an underlying Security Policy Database (SPD) that - specifies what services are to be offered to IP datagrams and in what - fashion. The form of the database and its interface are outside the - scope of this specification. However, this section specifies minimum - management functionality that must be provided, to allow a user or - system administrator to control whether and how IPsec is applied to - traffic transmitted or received by a host or transiting a security - gateway. The SPD, or relevant caches, must be consulted during the - processing of all traffic (inbound and outbound), including traffic - not protected by IPsec, that traverses the IPsec boundary. This - includes IPsec management traffic such as IKE. An IPsec - implementation MUST have at least one SPD, and it MAY support - multiple SPDs, if appropriate for the context in which the IPsec - implementation operates. There is no requirement to maintain SPDs on - a per interface basis, as was specified in RFC 2401. However, if an - implementation supports multiple SPDs, then it MUST include an - explicit SPD selection function, that is invoked to select the - appropriate SPD for outbound traffic processing. The inputs to this - function are the outbound packet and any local metadata (e.g., the - interface via which the packet arrived) required to effect the SPD - selection function. The output of the function is an SPD identifier - (SPD-ID). - - The SPD is an ordered database, consistent with the use of ACLs or - packet filters in firewalls, routers, etc. The ordering requirement - arises because entries often will overlap due to the presence of - (non-trivial) ranges as values for selectors. Thus a user or - administrator MUST be able to order the entries to express a desired - access control policy. There is no way to impose a general, canonical - order on SPD entries, because of the allowed use of wildcards for - selector values and because the different types of selectors are not - hierarchically related. - - Processing Choices: DISCARD, BYPASS, PROTECT - - An SPD must discriminate among traffic that is afforded IPsec - protection and traffic that is allowed to bypass IPsec. This - applies to the IPsec protection to be applied by a sender and to - - -Kent & Seo [Page 19] - -Internet Draft Security Architecture for IP March 2005 - - - the IPsec protection that must be present at the receiver. For - any outbound or inbound datagram, three processing choices are - possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The - first choice refers to traffic that is not allowed to traverse the - IPsec boundary (in the specified direction). The second choice - refers to traffic that is allowed to cross the IPsec boundary - without IPsec protection. The third choice refers to traffic that - is afforded IPsec protection, and for such traffic the SPD must - specify the security protocols to be employed, their mode, - security service options, and the cryptographic algorithms to be - used. - - SPD-S, SPD-I, SPD-O - - An SPD is logically divided into three pieces. The SPD-S (secure - traffic) contains entries for all traffic subject to IPsec - protection. SPD-O (outbound) contains entries for all outbound - traffic that is to be bypassed or discarded. SPD-I (inbound) is - applied to inbound traffic that will be bypassed or discarded. All - three of these can be decorrelated (with the exception noted above - for native host implementations) to facilitate caching. If an - IPsec implementation supports only one SPD, then the SPD consists - of all three parts. If multiple SPDs are supported, some of them - may be partial, e.g., some SPDs might contain only SPD-I entries, - to control inbound bypassed traffic on a per-interface basis. The - split allows SPD-I to be consulted without having to consult - SPD-S, for such traffic. Since the SPD-I is just a part of the - SPD, if a packet that is looked up in the SPD-I cannot be matched - to an entry there, then the packet MUST be discarded. Note that - for outbound traffic, if a match is not found in SPD-S, then SPD-O - must be checked to see if the traffic should be bypassed. - Similarly, if SPD-O is checked first and no match is found, then - SPD-S must be checked. In an ordered, non-decorrelated SPD, the - entries for the SPD-S, SPD-I, and SPD-O are interleaved. So there - is one look up in the SPD. - - SPD entries - - Each SPD entry specifies packet disposition as BYPASS, DISCARD, or - PROTECT. The entry is keyed by a list of one or more selectors. - The SPD contains an ordered list of these entries. The required - selector types are defined in Section 4.4.1.1. These selectors are - used to define the granularity of the SAs that are created in - response to an outbound packet or in response to a proposal from a - peer. The detailed structure of an SPD entry is described in - Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that - matches anything that is otherwise unmatched, and discards it. - - The SPD MUST permit a user or administrator to specify policy - - -Kent & Seo [Page 20] - -Internet Draft Security Architecture for IP March 2005 - - - entries as follows: - - - SPD-I: For inbound traffic that is to be bypassed or discarded, - the entry consists of the values of the selectors that apply to - the traffic to be bypassed or discarded. - - - SPD-O: For outbound traffic that is to be bypassed or - discarded, the entry consists of the values of the selectors - that apply to the traffic to be bypassed or discarded. - - - SPD-S: For traffic that is to be protected using IPsec, the - entry consists of the values of the selectors that apply to the - traffic to be protected via AH or ESP, controls on how to - create SAs based on these selectors, and the parameters needed - to effect this protection (e.g., algorithms, modes, etc.). Note - that an SPD-S entry also contains information such as "populate - from packet" (PFP) flag (see paragraphs below on "How To Derive - the Values for an SAD entry") and bits indicating whether the - SA lookup makes use of the local and remote IP addresses in - addition to the SPI (see AH [Ken05b] or ESP [Ken05a] - specifications). - - Representing directionality in an SPD entry - - For traffic protected by IPsec, the Local and Remote address and - ports in an SPD entry are swapped to represent directionality, - consistent with IKE conventions. In general, the protocols that - IPsec deals with have the property of requiring symmetric SAs with - flipped Local/Remote IP addresses. However, for ICMP, there is - often no such bi-directional authorization requirement. - Nonetheless, for the sake of uniformity and simplicity, SPD - entries for ICMP are specified in the same way as for other - protocols. Note also that for ICMP, Mobility Header, and - non-initial fragments, there are no port fields in these packets. - ICMP has message type and code and Mobility Header has mobility - header type. Thus SPD entries have provisions for expressing - access controls appropriate for these protocols, in lieu of the - normal port field controls. For bypassed or discarded traffic, - separate inbound and outbound entries are supported, e.g., to - permit unidirectional flows if required. - - OPAQUE and ANY - - For each selector in an SPD entry, in addition to the literal - values that define a match, there are two special values: ANY and - OPAQUE. ANY is a wildcard that matches any value in the - corresponding field of the packet, or that matches packets where - that field is not present or is obscured. OPAQUE indicates that - the corresponding selector field is not available for examination - - -Kent & Seo [Page 21] - -Internet Draft Security Architecture for IP March 2005 - - - because it may not be present in a fragment, does not exist for - the given Next Layer Protocol, or because prior application of - IPsec may have encrypted the value. The ANY value encompasses the - OPAQUE value. Thus OPAQUE need be used only when it is necessary - to distinguish between the case of any allowed value for a field, - vs. the absence or unavailability (e.g., due to encryption) of the - field. - - How To Derive the Values for an SAD entry - - For each selector in an SPD entry, the entry specifies how to - derive the corresponding values for a new SA Database (SAD, see - Section 4.4.2) entry from those in the SPD and the packet. The - goal is to allow an SAD entry and an SPD cache entry to be created - based on specific selector values from the packet, or from the - matching SPD entry. For outbound traffic, there are SPD-S cache - entries and SPD-O cache entries. For inbound traffic not - protected by IPsec, there are SPD-I cache entries and there is the - SAD, which represents the cache for inbound IPsec-protected - traffic (See Section 4.4.2). If IPsec processing is specified for - an entry, a "populate from packet" (PFP) flag may be asserted for - one or more of the selectors in the SPD entry (Local IP address; - Remote IP address; Next Layer Protocol; and, depending on Next - Layer Protocol, Local port and Remote port, or ICMP type/code, or - Mobility Header type). If asserted for a given selector X, the - flag indicates that the SA to be created should take its value for - X from the value in the packet. Otherwise, the SA should take its - value(s) for X from the value(s) in the SPD entry. Note: In the - non-PFP case, the selector values negotiated by the SA management - protocol (e.g., IKE v2) may be a subset of those in the SPD entry, - depending on the SPD policy of the peer. Also, whether a single - flag is used for, e.g., source port, ICMP type/code, and MH type, - or a separate flag is used for each, is a local matter. - - The following example illustrates the use of the PFP flag in the - context of a security gateway or a BITS/BITW implementation. - Consider an SPD entry where the allowed value for Remote address - is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an - outbound packet arrives with a destination address of 192.0.2.3, - and there is no extant SA to carry this packet. The value used for - the SA created to transmit this packet could be either of the two - values shown below, depending on what the SPD entry for this - selector says is the source of the selector value: - - - - - - - - -Kent & Seo [Page 22] - -Internet Draft Security Architecture for IP March 2005 - - - PFP flag value example of new - for the Remote SAD dest. address - addr. selector selector value - --------------- ------------ - a. PFP TRUE 192.0.2.3 (one host) - b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts) - - Note that if the SPD entry above had a value of ANY for the Remote - address, then the SAD selector value would have to be ANY for case - (b), but would still be as illustrated for case (a). Thus the PFP - flag can be used to prohibit sharing of an SA, even among packets - that match the same SPD entry. - - Management Interface - - For every IPsec implementation, there MUST be a management - interface that allows a user or system administrator to manage the - SPD. The interface must allow the user (or administrator) to - specify the security processing to be applied to every packet that - traverses the IPsec boundary. (In a native host IPsec - implementation making use of a socket interface, the SPD may not - need to be consulted on a per packet basis, as noted above.) The - management interface for the SPD MUST allow creation of entries - consistent with the selectors defined in Section 4.4.1.1, and MUST - support (total) ordering of these entries, as seen via this - interface. The SPD entries' selectors are analogous to the ACL or - packet filters commonly found in a stateless firewall or packet - filtering router and which are currently managed this way. - - In host systems, applications MAY be allowed to create SPD - entries. (The means of signaling such requests to the IPsec - implementation are outside the scope of this standard.) However, - the system administrator MUST be able to specify whether or not a - user or application can override (default) system policies. The - form of the management interface is not specified by this document - and may differ for hosts vs. security gateways, and within hosts - the interface may differ for socket-based vs. BITS - implementations. However, this document does specify a standard - set of SPD elements that all IPsec implementations MUST support. - - Decorrelation - - The processing model described in this document assumes the - ability to decorrelate overlapping SPD entries to permit caching, - which enables more efficient processing of outbound traffic in - security gateways and BITS/BITW implementations. Decorrelation - [CoSa04] is only a means of improving performance and simplifying - the processing description. This RFC does not require a compliant - implementation to make use of decorrelation. For example, native - - -Kent & Seo [Page 23] - -Internet Draft Security Architecture for IP March 2005 - - - host implementations typically make use of caching implicitly - because they bind SAs to socket interfaces, and thus there is no - requirement to be able to decorrelate SPD entries in these - implementations. - - Note: Unless otherwise qualified, the use of "SPD" refers to the - body of policy information in both ordered or decorrelated - (unordered) state. Appendix B provides an algorithm that can be - used to decorrelate SPD entries, but any algorithm that produces - equivalent output may be used. Note that when an SPD entry is - decorrelated all the resulting entries MUST be linked together, so - that all members of the group derived from an individual, SPD - entry (prior to decorrelation) can all be placed into caches and - into the SAD at the same time. For example, suppose one starts - with an entry A (from an ordered SPD) that when decorrelated, - yields entries A1, A2 and A3. When a packet comes along that - matches, say A2, and triggers the creation of an SA, the SA - management protocol, e.g., IKE v2, negotiates A. And all 3 - decorrelated entries, A1, A2, and A3 are placed in the appropriate - SPD-S cache and linked to the SA. The intent is that use of a - decorrelated SPD ought not to create more SAs than would have - resulted from use of a not-decorrelated SPD. - - If a decorrelated SPD is employed, there are three options for - what an initiator sends to a peer via an SA management protocol - (e.g., IKE). By sending the complete set of linked, decorrelated - entries that were selected from the SPD, a peer is given the best - possible information to enable selection of the appropriate SPD - entry at its end, especially if the peer has also decorrelated its - SPD. However, if a large number of decorrelated entries are - linked, this may create large packets for SA negotiation, and - hence fragmentation problems for the SA management protocol. - - Alternatively, the original entry from the (correlated) SPD may be - retained and passed to the SA management protocol. Passing the - correlated SPD entry keeps the use of a decorrelated SPD a local - matter, not visible to peers, and avoids possible fragmentation - concerns, although it provides less precise info to a responder - for matching against the responder's SPD. - - An intermediate approach is to send a subset of the complete set - of linked, decorrelated SPD entries. This approach can avoid the - fragmentation problems cited above and yet provide better - information than the original, correlated entry. The major - shortcoming of this approach is that it may cause additional SAs - to be created later, since only a subset of the linked, - decorrelated entries are sent to a peer. Implementers are free to - employ any of the approaches cited above. - - - -Kent & Seo [Page 24] - -Internet Draft Security Architecture for IP March 2005 - - - A responder uses the traffic selector proposals it receives via an - SA management protocol to select an appropriate entry in its SPD. - The intent of the matching is to select an SPD entry and create an - SA that most closely matches the intent of the initiator, so that - traffic traversing the resulting SA will be accepted at both ends. - If the responder employs a decorrelated SPD, it SHOULD use the - decorrelated SPD entries for matching, as this will generally - result in creation of SAs that are more likely to match the intent - of both peers. If the responder has a correlated SPD, then it - SHOULD match the proposals against the correlated entries. For - IKE v2, use of a decorrelated SPD offers the best opportunity for - a responder to generate a "narrowed" response. - - In all cases, when a decorrelated SPD is available, the - decorrelated entries are used to populate the SPD-S cache. If the - SPD is not decorrelated, caching is not allowed and an ordered - search of SPD MUST be performed to verify that inbound traffic - arriving on an SA is consistent with the access control policy - expressed in the SPD. - - Handling Changes to the SPD while the System is Running - - If a change is made to the SPD while the system is running, a - check SHOULD be made of the effect of this change on extant SAs. - An implementation SHOULD check the impact of an SPD change on - extant SAs and SHOULD provide a user/administrator with a - mechanism for configuring what actions to take, e.g., delete an - affected SA, allow an affected SA to continue unchanged, etc. - -4.4.1.1 Selectors - - An SA may be fine-grained or coarse-grained, depending on the - selectors used to define the set of traffic for the SA. For example, - all traffic between two hosts may be carried via a single SA, and - afforded a uniform set of security services. Alternatively, traffic - between a pair of hosts might be spread over multiple SAs, depending - on the applications being used (as defined by the Next Layer Protocol - and related fields, e.g., ports), with different security services - offered by different SAs. Similarly, all traffic between a pair of - security gateways could be carried on a single SA, or one SA could be - assigned for each communicating host pair. The following selector - parameters MUST be supported by all IPsec implementations to - facilitate control of SA granularity. Note that both Local and Remote - addresses should either be IPv4 or IPv6, but not a mix of address - types. Also, note that the Local/Remote port selectors (and ICMP - message type and code, and Mobility Header type) may be labeled as - OPAQUE to accommodate situations where these fields are inaccessible - due to packet fragmentation. - - - -Kent & Seo [Page 25] - -Internet Draft Security Architecture for IP March 2005 - - - - Remote IP Address(es) (IPv4 or IPv6): this is a list of ranges - of IP addresses (unicast, broadcast (IPv4 only)). This structure - allows expression of a single IP address (via a trivial range), - or a list of addresses (each a trivial range), or a range of - addresses (low and high values, inclusive), as well as the most - generic form of a list of ranges. Address ranges are used to - support more than one remote system sharing the same SA, e.g., - behind a security gateway. - - - Local IP Address(es) (IPv4 or IPv6): this is a list of ranges of - IP addresses (unicast, broadcast (IPv4 only)). This structure - allows expression of a single IP address (via a trivial range), - or a list of addresses (each a trivial range), or a range of - addresses (low and high values, inclusive), as well as the most - generic form of a list of ranges. Address ranges are used to - support more than one source system sharing the same SA, e.g., - behind a security gateway. Local refers to the address(es) - being protected by this implementation (or policy entry). - - Note: The SPD does not include support for multicast address - entries. To support multicast SAs, an implementation should make - use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries - require a different structure, i.e., one cannot use of the - symmetric relationship associated with local and remote address - values for unicast SAs in a multicast context. Specifically, - outbound traffic directed to a multicast address on an SA would - not be received on a companion, inbound SA with the multicast - address as the source. - - - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the - IPv6 "Next Header" fields. This is an individual protocol - number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol - is whatever comes after any IP extension headers that are - present. To simplify locating the Next Layer Protocol, there - SHOULD be a mechanism for configuring which IPv6 extension - headers to skip. The default configuration for which protocols - to skip SHOULD include the following protocols: 0 (Hop-by-hop - options), 43 (Routing Header), 44 (Fragmentation Header), and 60 - (Destination Options). Note: The default list does NOT include - 51 (AH), or 50 (ESP). From a selector lookup point of view, - IPsec treats AH and ESP as Next Layer Protocols. - - Several additional selectors depend on the Next Layer Protocol - value: - - * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, - SCTP, ...), then there are selectors for Local and Remote - Ports. Each of these selectors has a list of ranges of - values. Note that the Local and Remote ports may not be - - -Kent & Seo [Page 26] - -Internet Draft Security Architecture for IP March 2005 - - - available in the case of receipt of a fragmented packet or if - the port fields have been protected by IPsec (encrypted), - thus a value of OPAQUE also MUST be supported. Note: In a - non-initial fragment, port values will not be available. If a - port selector specifies a value other than ANY or OPAQUE, it - cannot match packets that are non-initial fragments. If the - SA requires a port value other than ANY or OPAQUE, an - arriving fragment without ports MUST be discarded. (See - Section 7 Handling Fragments.) - - * If the Next Layer Protocol is a Mobility Header, then there - is a selector for IPv6 Mobility Header Message Type (MH type) - [Mobip]. This is an 8-bit value that identifies a particular - mobility message. Note that the MH type may not be available - in the case of receipt of a fragmented packet. (See Section 7 - Handling Fragments.) 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. - - * If the Next Layer Protocol value is ICMP then there is a - 16-bit selector for the ICMP message type and code. The - message type is a single 8-bit value, which defines the type - of an ICMP message, or ANY. The ICMP code is a single 8-bit - value that defines a specific subtype for an ICMP message. - For IKE, the message type is placed in the most significant 8 - bits of the 16-bit selector and the code is placed in the - least significant 8 bits. This 16-bit selector can contain a - single type and a range of codes, a single type and ANY code, - ANY type and ANY code. Given a policy entry with a range of - Types (T-start to T-end) and a range of Codes (C-start to - C-end), and an ICMP packet with Type t and Code c, an - implementation MUST test for a match using - - (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + - C-end - - Note that the ICMP message type and code may not be available - in the case of receipt of a fragmented packet. (See Section 7 - Handling Fragments.) - - - Name: This is not a selector like the others above. It is not - acquired from a packet. A name may be used as a symbolic - identifier for an IPsec Local or Remote address. Named SPD - entries are used in two ways: - - 1. A named SPD entry is used by a responder (not an initiator) - in support of access control when an IP address would not be - appropriate for the Remote IP address selector, e.g., for - "road warriors." The name used to match this field is - - -Kent & Seo [Page 27] - -Internet Draft Security Architecture for IP March 2005 - - - communicated during the IKE negotiation in the ID payload. - In this context, the initiator's Source IP address (inner IP - header in tunnel mode) is bound to the Remote IP address in - the SAD entry created by the IKE negotiation. This address - overrides the Remote IP address value in the SPD, when the - SPD entry is selected in this fashion. All IPsec - implementations MUST support this use of names. - - 2. A named SPD entry may be used by an initiator to identify a - user for whom an IPsec SA will be created (or for whom - traffic may be bypassed). The initiator's IP source address - (from inner IP header in tunnel mode) is used to replace the - following if and when they are created: - - - local address in the SPD cache entry - - local address in the outbound SAD entry - - remote address in the inbound SAD entry - - Support for this use is optional for multi-user, native host - implementations and not applicable to other implementations. - Note that this name is used only locally; it is not - communicated by the key management protocol. Also, name - forms other than those used for case 1 above (responder) are - applicable in the initiator context (see below). - - An SPD entry can contain both a name (or a list of names) and - also values for the Local or Remote IP address. - - For case 1, responder, the identifiers employed in named SPD - entries are one of the following four types: - - a. a fully qualified user name string (email), e.g., - mozart@foo.example.com - (this corresponds to ID_RFC822_ADDR in IKE v2) - - b. a fully qualified DNS name, e.g., - foo.example.com - (this corresponds to ID_FQDN in IKE v2) - - c. X.500 distinguished name, e.g., [WaKiHo97], - - - CN = Stephen T. Kent, O = BBN Technologies, - SP = MA, C = US - - (this corresponds to ID_DER_ASN1_DN in IKE v2, after - decoding) - - d. a byte string - - -Kent & Seo [Page 28] - -Internet Draft Security Architecture for IP March 2005 - - - (this corresponds to Key_ID in IKE v2) - - For case 2, initiator, the identifiers employed in named SPD - entries are of type byte string. They are likely to be Unix - UIDs, Windows security IDs or something similar, but could also - be a user name or account name. In all cases, this identifier - is only of local concern and is not transmitted. - - The IPsec implementation context determines how selectors are used. - For example, a native host implementation typically makes use of a - socket interface. When a new connection is established the SPD can - be consulted and an SA bound to the socket. Thus traffic sent via - that socket need not result in additional lookups to the SPD (SPD-O - and SPD-S) cache. In contrast, a BITS, BITW, or security gateway - implementation needs to look at each packet and perform an - SPD-O/SPD-S cache lookup based on the selectors. - -4.4.1.2 Structure of an SPD entry - - This section contains a prose description of an SPD entry. Also, - Appendix C provides an example of an ASN.1 definition of an SPD - entry. - - This text describes the SPD in a fashion that is intended to map - directly into IKE payloads to ensure that the policy required by SPD - entries can be negotiated through IKE. Unfortunately, the semantics - of the version of IKE v2 published concurrently with this document - [Kau05] do not align precisely with those defined for the SPD. - Specifically, IKE v2 does not enable negotiation of a single SA that - binds multiple pairs of local and remote addresses and ports to a - single SA. Instead, when multiple local and remote addresses and - ports are negotiated for an SA, IKE v2 treats these not as pairs, but - as (unordered) sets of local and remote values that can be - arbitrarily paired. Until IKE provides a facility that conveys the - semantics that are expressed in the SPD via selector sets (as - described below), users MUST NOT include multiple selector sets in a - single SPD entry unless the access control intent aligns with the IKE - "mix and match" semantics. An implementation MAY warn users, to alert - them to this problem if users create SPD entries with multiple - selector sets, the syntax of which indicates possible conflicts with - current IKE semantics. - - The management GUI can offer the user other forms of data entry and - display, e.g., the option of using address prefixes as well as - ranges, and symbolic names for protocols, ports, etc. (Do not confuse - the use of symbolic names in a management interface with the SPD - selector "Name".) Note that Remote/Local apply only to IP addresses - and ports, not to ICMP message type/code or Mobility Header type. - Also, if the reserved, symbolic selector value OPAQUE or ANY is - - -Kent & Seo [Page 29] - -Internet Draft Security Architecture for IP March 2005 - - - employed for a given selector type, only that value may appear in the - list for that selector, and it must appear only once in the list for - that selector. Note that ANY and OPAQUE are local syntax conventions - -- IKE v2 negotiates these values via the ranges indicated below: - - ANY: start = 0 end = <max> - OPAQUE: start = <max> end = 0 - - An SPD is an ordered list of entries each of which contains the - following fields. - - o Name -- a list of IDs. This quasi-selector is optional. - The forms that MUST be supported are described above in - Section 4.4.1.1 under "Name". - - o PFP flags -- one per traffic selector. A given flag, e.g., - for Next Layer Protocol, applies to the relevant selector - across all "selector sets" (see below) contained in an SPD - entry. When creating an SA, each flag specifies for the - corresponding traffic selector whether to instantiate the - selector from the corresponding field in the packet that - - triggered the creation of the SA or from the value(s) in - the corresponding SPD entry (see Section 4.4.1, "How To - Derive the Values for an SAD entry"). Whether a single - flag is used for, e.g., source port, ICMP type/code, and - MH type, or a separate flag is used for each, is a local - matter. There are PFP flags for: - - Local Address - - Remote Address - - Next Layer Protocol - - Local Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Remote Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - o One to N selector sets that correspond to the "condition" - for applying a particular IPsec action. Each selector set - contains: - - Local Address - - Remote Address - - Next Layer Protocol - - Local Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Remote Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Note: The "next protocol" selector is an individual value - (unlike the local and remote IP addresses) in a selector - - -Kent & Seo [Page 30] - -Internet Draft Security Architecture for IP March 2005 - - - set entry. This is consistent with how IKE v2 negotiates - the TS values for an SA. It also makes sense because one - may need to associate different port fields with different - protocols. It is possible to associate multiple protocols - (and ports) with a single SA by specifying multiple - selector sets for that SA. - - o processing info -- which action is required -- PROTECT, - BYPASS, or DISCARD. There is just one action that goes with - all the selector sets, not a separate action for each set. - If the required processing is PROTECT, the entry contains - the following information. - - IPsec mode -- tunnel or transport - - (if tunnel mode) local tunnel address -- For a - non-mobile host, if there is just one interface, this - is straightforward; and if there are multiple - interfaces, this must be statically configured. For a - mobile host, the specification of the local address - is handled externally to IPsec. - - (if tunnel mode) remote tunnel address -- There is no - standard way to determine this. See 4.5.3 "Locating a - Security Gateway". - - extended sequence number -- Is this SA using extended - sequence numbers? - - stateful fragment checking -- Is this SA using - stateful fragment checking (see Section 7 for more - details) - - Bypass DF bit (T/F) -- applicable to tunnel mode SAs - - Bypass DSCP (T/F) or map to unprotected DSCP values - (array) if needed to restrict bypass of DSCP values -- - applicable to tunnel mode SAs - - IPsec protocol -- AH or ESP - - algorithms -- which ones to use for AH, which ones to - use for ESP, which ones to use for combined mode, - ordered by decreasing priority - - It is a local matter as to what information is kept with regard to - handling extant SAs when the SPD is changed. - -4.4.1.3 More re: Fields Associated with Next Layer Protocols - - Additional selectors are often associated with fields in the Next - Layer Protocol header. A particular Next Layer Protocol can have - zero, one, or two selectors. There may be situations where there - aren't both local and remote selectors for the fields that are - dependent on the Next Layer Protocol. The IPv6 Mobility Header has - only a Mobility Header message type. AH and ESP have no further - selector fields. A system may be willing to send an ICMP message - type and code that it does not want to receive. In the descriptions - - -Kent & Seo [Page 31] - -Internet Draft Security Architecture for IP March 2005 - - - below, "port" is used to mean a field that is dependent on the Next - Layer Protocol. - - A. If a Next Layer Protocol has no "port" selectors, then - the Local and Remote "port" selectors are set to OPAQUE in - the relevant SPD entry, e.g., - - Local's - next layer protocol = AH - "port" selector = OPAQUE - - Remote's - next layer protocol = AH - "port" selector = OPAQUE - - B. If a Next Layer Protocol has only one selector, e.g., - Mobility Header type, then that field is placed in the - Local "port" selector in the relevant SPD entry, and the - Remote "port" selector is set to OPAQUE in the relevant - SPD entry, e.g., - - Local's - next layer protocol = Mobility Header - "port" selector = Mobility Header message type - - Remote's - next layer protocol = Mobility Header - "port" selector = OPAQUE - - C. If a system is willing to send traffic with a particular - "port" value but NOT receive traffic with that kind of - port value, the system's traffic selectors are set as - follows in the relevant SPD entry: - - Local's - next layer protocol = ICMP - "port" selector = <specific ICMP type & code> - - Remote's - next layer protocol = ICMP - "port" selector = OPAQUE - - D. To indicate that a system is willing to receive traffic - with a particular "port" value but NOT send that kind of - traffic, the system's traffic selectors are set as follows - in the relevant SPD entry: - - Local's - next layer protocol = ICMP - - -Kent & Seo [Page 32] - -Internet Draft Security Architecture for IP March 2005 - - - "port" selector = OPAQUE - - Remote's - next layer protocol = ICMP - "port" selector = <specific ICMP type & code> - - For example, if a security gateway is willing to allow - systems behind it to send ICMP traceroutes, but is not - willing to let outside systems run ICMP traceroutes to - systems behind it, then the security gateway's traffic - selectors are set as follows in the relevant SPD entry: - - Local's - next layer protocol = 1 (ICMPv4) - "port" selector = 30 (traceroute) - - Remote's - next layer protocol = 1 (ICMPv4) - "port" selector = OPAQUE - -4.4.2 Security Association Database (SAD) - - In each IPsec implementation there is a nominal Security Association - Database (SAD), in which each entry defines the parameters associated - with one SA. Each SA has an entry in the SAD. For outbound - processing, each SAD entry is pointed to by entries in the SPD-S part - of the SPD cache. For inbound processing, for unicast SAs, the SPI is - used either alone to look up an SA, or the SPI may be used in - conjunction with the IPsec protocol type. If an IPsec implementation - supports multicast, the SPI plus destination address, or SPI plus - destination and source addresses are used to look up the SA. (See - Section 4.1 for details on the algorithm that MUST be used for - mapping inbound IPsec datagrams to SAs.) The following parameters are - associated with each entry in the SAD. They should all be present - except where otherwise noted, e.g., AH Authentication algorithm. This - description does not purport to be a MIB, only a specification of the - minimal data items required to support an SA in an IPsec - implementation. - - For each of the selectors defined in Section 4.4.1.1, the entry for - an inbound SA in the SAD MUST be initially populated with the value - or values negotiated at the time the SA was created. (See Section - 4.4.1, paragraph on Handling Changes to the SPD while the System is - Running for guidance on the effect of SPD changes on extant SAs.) For - a receiver, these values are used to check that the header fields of - an inbound packet (after IPsec processing) match the selector values - negotiated for the SA. Thus, the SAD acts as a cache for checking the - selectors of inbound traffic arriving on SAs. For the receiver, this - is part of verifying that a packet arriving on an SA is consistent - - -Kent & Seo [Page 33] - -Internet Draft Security Architecture for IP March 2005 - - - with the policy for the SA. (See Section 6 for rules for ICMP - messages.) These fields can have the form of specific values, - ranges, ANY, or OPAQUE, as described in section 4.4.1.1, "Selectors." - Note also, that there are a couple of situations in which the SAD can - have entries for SAs that do not have corresponding entries in the - SPD. Since 2401bis does not mandate that the SAD be selectively - cleared when the SPD is changed, SAD entries can remain when the SPD - entries that created them are changed or deleted. Also, if a manually - keyed SA is created, there could be an SAD entry for this SA that - does not correspond to any SPD entry. - - Note: The SAD can support multicast SAs, if manually configured. An - outbound multicast SA has the same structure as a unicast SA. The - source address is that of the sender and the destination address is - the multicast group address. An inbound, multicast SA must be - configured with the source addresses of each peer authorized to - transmit to the multicast SA in question. The SPI value for a - multicast SA is provided by a multicast group controller, not by the - receiver, as for a unicast SA. Because an SAD entry may be required - to accommodate multiple, individual IP source addresses that were - part of an SPD entry (for unicast SAs), the required facility for - inbound, multicast SAs is a feature already present in an IPsec - implementation. However, because the SPD has no provisions for - accommodating multicast entries, this document does not specify an - automated way to create an SAD entry for a multicast, inbound SA. - Only manually configured SAD entries can be created to accommodate - inbound, multicast traffic. - -4.4.2.1 Data Items in the SAD - - The following data items MUST be in the SAD: - - o Security Parameter Index (SPI): a 32-bit value selected by the - receiving end of an SA to uniquely identify the SA. In an SAD - entry for an outbound SA, the SPI is used to construct the - packet's AH or ESP header. In an SAD entry for an inbound SA, the - SPI is used to map traffic to the appropriate SA (see text on - unicast/multicast in Section 4.1). - - o Sequence Number Counter: a 64-bit counter used to generate the - Sequence Number field in AH or ESP headers. 64-bit sequence - numbers are the default, but 32-bit sequence numbers are also - supported if negotiated. - - o Sequence Counter Overflow: a flag indicating whether overflow of - the Sequence Number Counter should generate an auditable event and - prevent transmission of additional packets on the SA, or whether - rollover is permitted. The audit log entry for this event SHOULD - include the SPI value, current date/time, Local Address, Remote - - -Kent & Seo [Page 34] - -Internet Draft Security Architecture for IP March 2005 - - - Address, and the selectors from the relevant SAD entry. - - o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) - used to determine whether an inbound AH or ESP packet is a replay. - - Note: If anti-replay has been disabled by the receiver for an SA, - e.g., in the case of a manually keyed SA, then the Anti-Replay - Window is ignored for the SA in question. 64-bit sequence numbers - are the default, but this counter size accommodates 32-bit - sequence numbers as well. - - o AH Authentication algorithm, key, etc. This is required only if AH - is supported. - - o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode - algorithm is used, these fields will not be applicable. - - - o ESP integrity algorithm, keys, etc. If the integrity service is - not selected, these fields will not be applicable. If a combined - mode algorithm is used, these fields will not be applicable. - - - o ESP combined mode algorithms, key(s), etc. This data is used when - a combined mode (encryption and integrity) algorithm is used with - ESP. If a combined mode algorithm is not used, these fields are - not applicable. - - o Lifetime of this SA: a time interval after which an SA must be - replaced with a new SA (and new SPI) or terminated, plus an - indication of which of these actions should occur. This may be - expressed as a time or byte count, or a simultaneous use of both - with the first lifetime to expire taking precedence. A compliant - implementation MUST support both types of lifetimes, and MUST - support a simultaneous use of both. If time is employed, and if - IKE employs X.509 certificates for SA establishment, the SA - lifetime must be constrained by the validity intervals of the - certificates, and the NextIssueDate of the CRLs used in the IKE - exchange for the SA. Both initiator and responder are responsible - for constraining the SA lifetime in this fashion. Note: The - details of how to handle the refreshing of keys when SAs expire is - a local matter. However, one reasonable approach is: - - (a) If byte count is used, then the implementation SHOULD count the - number of bytes to which the IPsec cryptographic algorithm is - applied. For ESP, this is the encryption algorithm (including - Null encryption) and for AH, this is the authentication - algorithm. This includes pad bytes, etc. Note that - implementations MUST be able to handle having the counters at - - -Kent & Seo [Page 35] - -Internet Draft Security Architecture for IP March 2005 - - - the ends of an SA get out of synch, e.g., because of packet - loss or because the implementations at each end of the SA - aren't doing things the same way. - - (b) There SHOULD be two kinds of lifetime -- a soft lifetime that - warns the implementation to initiate action such as setting up - a replacement SA; and a hard lifetime when the current SA ends - and is destroyed. - - (c) If the entire packet does not get delivered during the SAs - lifetime, the packet SHOULD be discarded. - - o IPsec protocol mode: tunnel or transport. Indicates which mode of - AH or ESP is applied to traffic on this SA. - - o Stateful fragment checking flag. Indicates whether or not stateful - fragment checking applies to this SA. - - o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both - inner and outer headers are IPv4. - - o DSCP values -- the set of DSCP values allowed for packets carried - over this SA. If no values are specified, no DSCP-specific - filtering is applied. If one or more values are specified, these - are used to select one SA among several that match the traffic - selectors for an outbound packet. Note that these values are NOT - checked against inbound traffic arriving on the SA. - - o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if - needed to restrict bypass of DSCP values - applicable to tunnel - mode SAs. This feature maps DSCP values from an inner header to - values in an outer header, e.g., to address covert channel - signaling concerns. - - o Path MTU: any observed path MTU and aging variables. - - o Tunnel header IP source and destination address - both addresses - must be either IPv4 or IPv6 addresses. The version implies the - type of IP header to be used. Only used when the IPsec protocol - mode is tunnel. - -4.4.2.2 Relationship between SPD, PFP flag, packet, and SAD - - For each selector, the following tables show the relationship - between the value in the SPD, the PFP flag, the value in the - triggering packet and the resulting value in the SAD. Note that - the administrative interface for IPsec can use various syntactic - options to make it easier for the administrator to enter rules. - For example, although a list of ranges is what IKE v2 sends, it - - -Kent & Seo [Page 36] - -Internet Draft Security Architecture for IP March 2005 - - - might be clearer and less error prone for the user to enter a - single IP address or IP address prefix. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - loc addr list of ranges 0 IP addr "S" list of ranges - ANY 0 IP addr "S" ANY - list of ranges 1 IP addr "S" "S" - ANY 1 IP addr "S" "S" - - rem addr list of ranges 0 IP addr "D" list of ranges - ANY 0 IP addr "D" ANY - list of ranges 1 IP addr "D" "D" - ANY 1 IP addr "D" "D" - - protocol list of prot's* 0 prot. "P" list of prot's* - ANY** 0 prot. "P" ANY - OPAQUE**** 0 prot. "P" OPAQUE - - list of prot's* 0 not avail. discard packet - ANY** 0 not avail. ANY - OPAQUE**** 0 not avail. OPAQUE - - list of prot's* 1 prot. "P" "P" - ANY** 1 prot. "P" "P" - OPAQUE**** 1 prot. "P" *** - - list of prot's* 1 not avail. discard packet - ANY** 1 not avail. discard packet - OPAQUE**** 1 not avail. *** - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 37] - -Internet Draft Security Architecture for IP March 2005 - - - If the protocol is one that has two ports then there will be - selectors for both Local and Remote ports. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - loc port list of ranges 0 src port "s" list of ranges - ANY 0 src port "s" ANY - OPAQUE 0 src port "s" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 src port "s" "s" - ANY 1 src port "s" "s" - OPAQUE 1 src port "s" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - rem port list of ranges 0 dst port "d" list of ranges - ANY 0 dst port "d" ANY - OPAQUE 0 dst port "d" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 dst port "d" "d" - ANY 1 dst port "d" "d" - OPAQUE 1 dst port "d" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - - - - - - - - - - -Kent & Seo [Page 38] - -Internet Draft Security Architecture for IP March 2005 - - - If the protocol is mobility header then there will be a selector - for mh type. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - mh type list of ranges 0 mh type "T" list of ranges - ANY 0 mh type "T" ANY - OPAQUE 0 mh type "T" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 mh type "T" "T" - ANY 1 mh type "T" "T" - OPAQUE 1 mh type "T" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 39] - -Internet Draft Security Architecture for IP March 2005 - - - If the protocol is ICMP, then there will be a 16-bit selector for - ICMP type and ICMP code. Note that the type and code are bound to - each other, i.e., the codes apply to the particular type. This - 16-bit selector can contain a single type and a range of codes, a - single type and ANY code, and ANY type and ANY code. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - --------- ---------------- --- ------------ -------------- - ICMP type a single type & 0 type "t" & single type & - and code range of codes code "c" range of codes - a single type & 0 type "t" & single type & - ANY code code "c" ANY code - ANY type & ANY 0 type "t" & ANY type & - code code "c" ANY code - OPAQUE 0 type "t" & OPAQUE - code "c" - - a single type & 0 not avail. discard packet - range of codes - a single type & 0 not avail. discard packet - ANY code - ANY type & 0 not avail. ANY type & - ANY code ANY code - OPAQUE 0 not avail. OPAQUE - - a single type & 1 type "t" & "t" and "c" - range of codes code "c" - a single type & 1 type "t" & "t" and "c" - ANY code code "c" - ANY type & 1 type "t" & "t" and "c" - ANY code code "c" - OPAQUE 1 type "t" & *** - code "c" - - a single type & 1 not avail. discard packet - range of codes - a single type & 1 not avail. discard packet - ANY code - ANY type & 1 not avail. discard packet - ANY code - OPAQUE 1 not avail. *** - - - - - - - - -Kent & Seo [Page 40] - -Internet Draft Security Architecture for IP March 2005 - - - If the name selector is used... - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - --------- ---------------- --- ------------ -------------- - name list of user or N/A N/A N/A - system names - - - * "List of protocols" is the information, not the way - that the SPD or SAD or IKv2 have to represent this - information. - ** 0 (zero) is used by IKE to indicate ANY for - protocol. - *** Use of PFP=1 with an OPAQUE value is an error and - SHOULD be prohibited by an IPsec implementation. - **** The protocol field cannot be OPAQUE in IPv4. This - table entry applies only to IPv6. - -4.4.3 Peer Authorization Database (PAD) - - The Peer Authorization Database (PAD) provides the link between the - SPD and a security association management protocol such as IKE. It - embodies several critical functions: - - o identifies the peers or groups of peers that are authorized - to communicate with this IPsec entity - o specifies the protocol and method used to authenticate each - peer - o provides the authentication data for each peer - o constrains the types and values of IDs that can be asserted - by a peer with regard to child SA creation, to ensure that the - peer does not assert identities for lookup in the SPD that it - is not authorized to represent, when child SAs are created - o peer gateway location info, e.g., IP address(es) or DNS names, - MAY be included for peers that are known to be "behind" a - security gateway - The PAD provides these functions for an IKE peer when the peer acts - as either the initiator or the responder. - - To perform these functions, the PAD contains an entry for each peer - or group of peers with which the IPsec entity will communicate. An - entry names an individual peer (a user, end system or security - gateway) or specifies a group of peers (using ID matching rules - defined below). The entry specifies the authentication protocol - (e.g., IKE v1, IKE v2, KINK) method used (e.g., certificates or pre- - shared secrets) and the authentication data (e.g., the pre-shared - secret or the trust anchor relative to which the peer's certificate - - -Kent & Seo [Page 41] - -Internet Draft Security Architecture for IP March 2005 - - - will be validated). For certificate-based authentication, the entry - also may provide information to assist in verifying the revocation - status of the peer, e.g., a pointer to a CRL repository or the name - of an OSCP server associated with the peer or with the trust anchor - associated with the peer. - - Each entry also specifies whether the IKE ID payload will be used as - a symbolic name for SPD lookup, or whether the remote IP address - provided in traffic selector payloads will be used for SPD lookups - when child SAs are created. - - Note that the PAD information MAY be used to support creation of more - than one tunnel mode SA at a time between two peers, e.g., two - tunnels to protect the same addresses/hosts, but with different - tunnel endpoints. - -4.4.3.1 PAD Entry IDs and Matching Rules - - The PAD is an ordered database, where the order is defined by an - administrator (or a user in the case of a single-user end system). - Usually, the same administrator will be responsible for both the PAD - and SPD, since the two databases must be coordinated. The ordering - requirement for the PAD arises for the same reason as for the SPD, - i.e., because use of "star name" entries allows for overlaps in the - set of IKE IDs that could match a specific entry. - - Six types of IDs are supported for entries in the PAD, consistent - with the symbolic name types and IP addresses used to identify SPD - entries. The ID for each entry acts as the index for the PAD, i.e., - it is the value used to select an entry. All of these ID types can be - used to match IKE ID payload types. The six types are: - o DNS name (specific or partial) - o Distinguished Name (complete or sub-tree constrained) - o RFC822 email address (complete or partially qualified) - o IPv4 address (range) - o IPv6 address (range) - o Key ID (exact match only) - - The first three name types can accommodate sub-tree matching as well - as exact matches. A DNS name may be fully qualified and thus match - exactly one name, e.g., foo.example.com. Alternatively, the name may - encompass a group of peers by being partially specified, e.g., the - string ".example.com" could be used to match any DNS name ending in - these two domain name components. - - Similarly, a Distinguished Name may specify a complete DN to match - exactly one entry, e.g., CN = Stephen, O = BBN Technologies, SP = MA, - C = US. Alternatively, an entry may encompass a group of peers by - specifying a sub-tree, e.g., an entry of the form "C = US, SP = MA" - - -Kent & Seo [Page 42] - -Internet Draft Security Architecture for IP March 2005 - - - might be used to match all DNs that contain these two attributes as - the top two RDNs. - - For an RFC822 e-mail addresses, the same options exist. A complete - address such as foo@example.com matches one entity, but a sub-tree - name such as "@example.com" could be used to match all the entities - with names ending in those two domain names to the right of the @. - - The specific syntax used by an implementation to accommodate sub-tree - matching for distinguished names, domain names or RFC822 e-mail - addresses is a local matter. But, at a minimum, sub-tree matching of - the sort described above MUST be supported. (Substring matching - within a DN, DNS name or RFC822 address MAY be supported, but is not - required.) - - For IPv4 and IPv6 addresses, the same address range syntax used for - SPD entries MUST be supported. This allows specification of an - individual address (via a trivial range), an address prefix (by - choosing a range that adheres to CIDR-style prefixes), or an - arbitrary address range. - - The Key ID field is defined as an OCTET string in IKE. For this name - type, only exact match syntax MUST be supported (since there is no - explicit structure for this ID type. Additional matching functions - MAY be supported for this ID type. - -4.4.3.2 IKE Peer Authentication Data - - Once an entry is located based on an ordered search of the PAD based - on ID field matching, it is necessary to verify the asserted - identity, i.e., to authenticate the asserted ID. For each PAD entry - there is an indication of the type of authentication to be performed. - This document requires support for two required authentication data - types: - - - X.509 certificate - - pre-shared secret - - For authentication based on an X.509 certificate, the PAD entry - contains a trust anchor via which the end entity (EE) certificate for - the peer must be verifiable, either directly or via a certificate - path. See RFC 3280 for the definition of a trust anchor. An entry - used with certificate-based authentication MAY include additional - data to facilitate certificate revocation status, e.g., a list of - appropriate OCSP responders or CRL repositories, and associated - authentication data. For authentication based on a pre-shared secret, - the PAD contains the pre-shared secret to be used by IKE. - - This document does not require that the IKE ID asserted by a peer be - - -Kent & Seo [Page 43] - -Internet Draft Security Architecture for IP March 2005 - - - syntactically related to a specific field in an end entity - certificate that is employed to authenticate the identity of that - peer. However, it often will be appropriate to impose such a - requirement, e.g., when a single entry represents a set of peers each - of whom may have a distinct SPD entry. Thus implementations MUST - provide a means for an administrator to require a match between an - asserted IKE ID and the subject name or subject alt name in a - certificate. The former is applicable to IKE IDs expressed as - distinguished names; the latter is appropriate for DNS names, RFC822 - e-mail addresses, and IP addresses. Since KEY ID is intended for - identifying a peer authenticated via a pre-shred secret, there is no - requirement to match this ID type to a certificate field. - - See IKE v1 [HarCar98] and IKE v2 [Kau05] for details of how IKE - performs peer authentication using certificates or pre-shared - secrets. - - This document does not mandate support for any other authentication - methods, although such methods MAY be employed. - -4.4.3.3 Child SA Authorization Data - - Once an IKE peer is authenticated, child SAs may be created. Each PAD - entry contains data to constrain the set of IDs that can be asserted - by an IKE peer, for matching against the SPD. Each PAD entry - indicates whether the IKE ID is to be used as a symbolic name for SPD - matching, or whether an IP address asserted in a traffic selector - payload is to be used. - - If the entry indicates that the IKE ID is to be used, then the PAD - entry ID field defines the authorized set of IDs. If the entry - indicates that child SAs traffic selectors are to be used, then an - additional data element is required, in the form of IPv4 and/or IPv6 - address ranges. (A peer may be authorized for both address types, so - there MUST be provision for both a v4 and a v6 address range.) - -4.4.3.4 How the PAD Is Used - - During the initial IKE exchange, the initiator and responder each - assert their identity via the IKE ID payload, and send an AUTH - payload to verify the asserted identity. One or more CERT payloads - may be transmitted to facilitate the verification of each asserted - identity. - - When an IKE entity receives an IKE ID payload, it uses the asserted - ID to locate an entry in the PAD, using the matching rules described - above. The PAD entry specifies the authentication method to be - employed for the identified peer. This ensures that the right method - is used for each peer and that different methods can be used for - - -Kent & Seo [Page 44] - -Internet Draft Security Architecture for IP March 2005 - - - different peers. The entry also specifies the authentication data - that will be used to verify the asserted identity. This data is - employed in conjunction with the specified method to authenticate the - peer, before any CHILD SAs are created. - - - Child SAs are created based on the exchange of traffic selector - payloads, either at the end of the initial IKE exchange, or in - subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now - authenticated) IKE peer is used to constrain creation of child SAs, - specifically the PAD entry specifies how the SPD is searched using a - traffic selector proposal from a peer. There are two choices: either - the IKE ID asserted by the peer is used to find an SPD entry via its - symbolic name, or peer IP addresses asserted in traffic selector - payloads are used for SPD lookups based on the remote IP address - field portion of an SPD entry. 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. - - Note that because the PAD is checked before searching for an SPD - entry, this safeguard protects an initiator against spoofing attacks. - For example, assume that IKE A receives an outbound packet destined - for IP address X, a host served by a security gateway. RFC 2401 and - 2401bis do not specify how A determines the address of the IKE peer - serving X. However, any peer contacted by A as the presumed - representative for X must be registered in the PAD in order to allow - the IKE exchange to be authenticated. Moreover, when the - authenticated peer asserts that it represents X in its traffic - selector exchange, the PAD will be consulted to determine if the peer - in question is authorized to represent X. Thus the PAD provides a - binding of address ranges (or name sub-spaces) to peers, to counter - such attacks. - - -4.5 SA and Key Management - - All IPsec implementations MUST support both manual and automated SA - and cryptographic key management. The IPsec protocols, AH and ESP, - are largely independent of the associated SA management techniques, - although the techniques involved do affect some of the security - services offered by the protocols. For example, the optional - anti-replay service available for AH and ESP requires automated SA - management. Moreover, the granularity of key distribution employed - with IPsec determines the granularity of authentication provided. In - general, data origin authentication in AH and ESP is limited by the - extent to which secrets used with the integrity algorithm (or with a - key management protocol that creates such secrets) are shared among - multiple possible sources. - - - -Kent & Seo [Page 45] - -Internet Draft Security Architecture for IP March 2005 - - - The following text describes the minimum requirements for both types - of SA management. - -4.5.1 Manual Techniques - - The simplest form of management is manual management, in which a - person manually configures each system with keying material and SA - management data relevant to secure communication with other systems. - Manual techniques are practical in small, static environments but - they do not scale well. For example, a company could create a - Virtual Private Network (VPN) using IPsec in security gateways at - several sites. If the number of sites is small, and since all the - sites come under the purview of a single administrative domain, this - might be a feasible context for manual management techniques. In - this case, the security gateway might selectively protect traffic to - and from other sites within the organization using a manually - configured key, while not protecting traffic for other destinations. - It also might be appropriate when only selected communications need - to be secured. A similar argument might apply to use of IPsec - entirely within an organization for a small number of hosts and/or - gateways. Manual management techniques often employ statically - configured, symmetric keys, though other options also exist. - -4.5.2 Automated SA and Key Management - - Widespread deployment and use of IPsec requires an Internet-standard, - scalable, automated, SA management protocol. Such support is required - to facilitate use of the anti-replay features of AH and ESP, and to - accommodate on-demand creation of SAs, e.g., for user- and - session-oriented keying. (Note that the notion of "rekeying" an SA - actually implies creation of a new SA with a new SPI, a process that - generally implies use of an automated SA/key management protocol.) - - The default automated key management protocol selected for use with - IPsec is IKE v2 [Kau05]. This document assumes the availability of - certain functions from the key management protocol which are not - supported by IKE v1. Other automated SA management protocols MAY be - employed. - - When an automated SA/key management protocol is employed, the output - from this protocol is used to generate multiple keys for a single SA. - This also occurs because distinct keys are used for each of the two - SAs created by IKE. If both integrity and confidentiality are - employed, then a minimum of four keys are required. Additionally, - some cryptographic algorithms may require multiple keys, e.g., 3DES. - - The Key Management System may provide a separate string of bits for - each key or it may generate one string of bits from which all keys - are extracted. If a single string of bits is provided, care needs to - - -Kent & Seo [Page 46] - -Internet Draft Security Architecture for IP March 2005 - - - be taken to ensure that the parts of the system that map the string - of bits to the required keys do so in the same fashion at both ends - of the SA. To ensure that the IPsec implementations at each end of - the SA use the same bits for the same keys, and irrespective of which - part of the system divides the string of bits into individual keys, - the encryption keys MUST be taken from the first (left-most, - high-order) bits and the integrity keys MUST be taken from the - remaining bits. The number of bits for each key is defined in the - relevant cryptographic algorithm specification RFC. In the case of - multiple encryption keys or multiple integrity keys, the - specification for the cryptographic algorithm must specify the order - in which they are to be selected from a single string of bits - provided to the cryptographic algorithm. - -4.5.3 Locating a Security Gateway - - This section discusses issues relating to how a host learns about the - existence of relevant security gateways and once a host has contacted - these security gateways, how it knows that these are the correct - security gateways. The details of where the required information is - stored is a local matter, but the Peer Authorization Database - described in Section 4.4 is the most likely candidate. (Note: S* - indicates a system that is running IPsec, e.g., SH1 and SG2 below.) - - Consider a situation in which a remote host (SH1) is using the - Internet to gain access to a server or other machine (H2) and there - is a security gateway (SG2), e.g., a firewall, through which H1's - traffic must pass. An example of this situation would be a mobile - host crossing the Internet to his home organization's firewall (SG2). - This situation raises several issues: - - 1. How does SH1 know/learn about the existence of the security - gateway SG2? - - 2. How does it authenticate SG2, and once it has authenticated SG2, - how does it confirm that SG2 has been authorized to represent H2? - - 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to - contact H2? - - 4. How does SH1 know/learn about any additional gateways that provide - alternate paths to H2? - - To address these problems, an IPsec-supporting host or security - gateway MUST have an administrative interface that allows the - user/administrator to configure the address of one or more security - gateways for ranges of destination addresses that require its use. - This includes the ability to configure information for locating and - authenticating one or more security gateways and verifying the - - -Kent & Seo [Page 47] - -Internet Draft Security Architecture for IP March 2005 - - - authorization of these gateways to represent the destination host. - (The authorization function is implied in the PAD.) This document - does not address the issue of how to automate the - discovery/verification of security gateways. - -4.6 SAs and Multicast - - The receiver-orientation of the SA implies that, in the case of - unicast traffic, the destination system will select the SPI value. - By having the destination select the SPI value, there is no potential - for manually configured SAs to conflict with automatically configured - (e.g., via a key management protocol) SAs or for SAs from multiple - sources to conflict with each other. For multicast traffic, there - are multiple destination systems associated with a single SA. So - some system or person will need to coordinate among all multicast - groups to select an SPI or SPIs on behalf of each multicast group and - then communicate the group's IPsec information to all of the - legitimate members of that multicast group via mechanisms not defined - here. - - Multiple senders to a multicast group SHOULD use a single Security - Association (and hence SPI) for all traffic to that group when a - symmetric key encryption or integrity algorithm is employed. In such - circumstances, the receiver knows only that the message came from a - system possessing the key for that multicast group. In such - circumstances, a receiver generally will not be able to authenticate - which system sent the multicast traffic. Specifications for other, - more general multicast approaches are deferred to the IETF Multicast - Security Working Group. - -5. IP Traffic Processing - - As mentioned in Section 4.4.1 "The Security Policy Database (SPD)", - the SPD (or associated caches) MUST be consulted during the - processing of all traffic that crosses the IPsec protection boundary, - including IPsec management traffic. If no policy is found in the SPD - that matches a packet (for either inbound or outbound traffic), the - packet MUST be discarded. To simplify processing, and to allow for - very fast SA lookups (for SG/BITS/BITW), this document introduces the - notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), - and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As - mentioned earlier, the SAD acts as a cache for checking the selectors - of inbound IPsec-protected traffic arriving on SAs.) There is - nominally one cache per SPD. For the purposes of this specification, - it is assumed that each cached entry will map to exactly one SA. - Note, however, exceptions arise when one uses multiple SAs to carry - traffic of different priorities (e.g., as indicated by distinct DSCP - values) but the same selectors. Note also, that there are a couple - of situations in which the SAD can have entries for SAs that do not - - -Kent & Seo [Page 48] - -Internet Draft Security Architecture for IP March 2005 - - - have corresponding entries in the SPD. Since 2401bis does not mandate - that the SAD be selectively cleared when the SPD is changed, SAD - entries can remain when the SPD entries that created them are changed - or deleted. Also, if a manually keyed SA is created, there could be - an SAD entry for this SA that does not correspond to any SPD entry. - - Since SPD entries may overlap, one cannot safely cache these entries - in general. Simple caching might result in a match against a cache - entry whereas an ordered search of the SPD would have resulted in a - match against a different entry. But, if the SPD entries are first - decorrelated, then the resulting entries can safely be cached. Each - cached entry will indicate that matching traffic should be bypassed - or discarded, appropriately. (Note: The original SPD entry might - result in multiple SAs, e.g., because of PFP.) Unless otherwise - noted, all references below to the "SPD" or "SPD cache" or "cache" - are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache - containing entries from the decorrelated SPD. - - Note: In a host IPsec implementation based on sockets, the SPD will - be consulted whenever a new socket is created, to determine what, if - any, IPsec processing will be applied to the traffic that will flow - on that socket. This provides an implicit caching mechanism and the - portions of the preceding discussion that address caching can be - ignored in such implementations. - - Note: It is assumed that one starts with a correlated SPD because - that is how users and administrators are accustomed to managing these - sorts of access control lists or firewall filter rules. Then the - decorrelation algorithm is applied to build a list of cache-able SPD - entries. The decorrelation is invisible at the management interface. - - For inbound IPsec traffic, the SAD entry selected by the SPI serves - as the cache for the selectors to be matched against arriving IPsec - packets, after AH or ESP processing has been performed. - -5.1 Outbound IP Traffic Processing (protected-to-unprotected) - - First consider the path for traffic entering the implementation via a - protected interface and exiting via an unprotected interface. - - - - - - - - - - - - -Kent & Seo [Page 49] - -Internet Draft Security Architecture for IP March 2005 - - - Unprotected Interface - ^ - | - (nested SAs) +----------+ - -------------------|Forwarding|<-----+ - | +----------+ | - | ^ | - | | BYPASS | - V +-----+ | - +-------+ | SPD | +--------+ - ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec - | (*) | | (*) |---->|(AH/ESP)| boundary - +-------+ +-----+ +--------+ - | +-------+ / ^ - | |DISCARD| <--/ | - | +-------+ | - | | - | +-------------+ - |---------------->|SPD Selection| - +-------------+ - ^ - | +------+ - | -->| ICMP | - | / +------+ - |/ - | - | - Protected Interface - - - Figure 2. Processing Model for Outbound Traffic - (*) = The SPD caches are shown here. If there - is a cache miss, then the SPD is checked. - There is no requirement that an - implementation buffer the packet if - there is a cache miss. - - - IPsec MUST perform the following steps when processing outbound - packets: - - 1. When a packet arrives from the subscriber (protected) interface, - invoke the SPD selection function to obtain the SPD-ID needed to - choose the appropriate SPD. (If the implementation uses only one - SPD, this step is a no-op.) - - 2. Match the packet headers against the cache for the SPD specified - by the SPD-ID from step 1. Note that this cache contains entries - from SPD-O and SPD-S. - - -Kent & Seo [Page 50] - -Internet Draft Security Architecture for IP March 2005 - - - 3a. If there is a match, then process the packet as specified by the - matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH - or ESP. If IPsec processing is applied, there is a link from the - SPD cache entry to the relevant SAD entry (specifying the mode, - cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec - processing is as previously defined, for tunnel or transport modes - and for AH or ESP, as specified in their respective RFCs [Ken05b - and Ken05a]. Note that the SA PMTU value, plus the value of the - stateful fragment checking flag (and the DF bit in the IP header - of the outbound packet) determine whether the packet can (must) be - fragmented prior to or after IPsec processing, or if it must be - discarded and an ICMP PMTU message is sent. - - 3b. If no match is found in the cache, search the SPD (SPD-S and - SPD-O parts) specified by SPD-ID. If the SPD entry calls for - BYPASS or DISCARD, create one or more new outbound SPD cache - entries and if BYPASS, create one or more new inbound SPD cache - entries. (More than one cache entry may be created since a - decorrelated SPD entry may be linked to other such entries that - were created as a side effect of the decorrelation process.) If - the SPD entry calls for PROTECT, i.e., creation of an SA, the key - management mechanism (e.g., IKE v2) is invoked to create the SA. - If SA creation succeeds, a new outbound (SPD-S) cache entry is - created, along with outbound and inbound SAD entries, otherwise - the packet is discarded. (A packet that triggers an SPD lookup MAY - be discarded by the implementation, or it MAY be processed against - the newly created cache entry, if one is created.) Since SAs are - created in pairs, an SAD entry for the corresponding inbound SA - also is created, and it contains the selector values derived from - the SPD entry (and packet, if any PFP flags were "true") used to - create the inbound SA, for use in checking inbound traffic - delivered via the SA. - - 4. The packet is passed to the outbound forwarding function - (operating outside of the IPsec implementation), to select the - interface to which the packet will be directed. This function may - cause the packet to be passed back across the IPsec boundary, for - additional IPsec processing, e.g., in support of nested SAs. If - so, there MUST be an entry in SPD-I database that permits inbound - bypassing of the packet, otherwise the packet will be discarded. - If necessary, i.e., if there is more than one SPD-I, the traffic - being looped back MAY be tagged as coming from this internal - interface. This would allow the use of a different SPD-I for - "real" external traffic vs looped traffic, if needed. - - Note: With the exception of IPv4 and IPv6 transport mode, an SG, - BITS, or BITW implementation MAY fragment packets before applying - IPsec. (This applies only to IPv4. For IPv6 packets, only the - originator is allowed to fragment them.) The device SHOULD have a - - -Kent & Seo [Page 51] - -Internet Draft Security Architecture for IP March 2005 - - - configuration setting to disable this. The resulting fragments are - evaluated against the SPD in the normal manner. Thus, fragments not - containing port numbers (or ICMP message type and code, or Mobility - Header type) will only match rules having port (or ICMP message type - and code, or MH type) selectors of OPAQUE or ANY. (See section 7 for - more details.) - - - - Note: With regard to determining and enforcing the PMTU of an SA, the - IPsec system MUST follow the steps described in Section 8.2. - -5.1.1 Handling an Outbound Packet That Must Be Discarded - - If an IPsec system receives an outbound packet that it finds it must - discard, it SHOULD be capable of generating and sending an ICMP - message to indicate to the sender of the outbound packet that the - packet was discarded. The type and code of the ICMP message will - depend on the reason for discarding the packet, as specified below. - The reason SHOULD be recorded in the audit log. The audit log entry - for this event SHOULD include the reason, current date/time, and the - selector values from the packet. - - a. The selectors of the packet matched an SPD entry requiring the - packet to be discarded. - - IPv4 Type = 3 (destination unreachable) Code = 13 - (Communication Administratively Prohibited) - - IPv6 Type = 1 (destination unreachable) Code = 1 - (Communication with destination administratively - prohibited) - - b1. The IPsec system successfully reached the remote peer but was - unable to negotiate the SA required by the SPD entry matching the - packet, e.g., because the remote peer is administratively - prohibited from communicating with the initiator, or the - initiating peer was unable to authenticate itself to the remote - peer, or the remote peer was unable to authenticate itself to the - initiating peer, or SPD at remote peer did not have a suitable - entry, etc. - - IPv4 Type = 3 (destination unreachable) Code = 13 - (Communication Administratively Prohibited) - - IPv6 Type = 1 (destination unreachable) Code = 1 - (Communication with destination administratively - prohibited) - - - -Kent & Seo [Page 52] - -Internet Draft Security Architecture for IP March 2005 - - - b2. The IPsec system was unable to set up the SA required by the SPD - entry matching the packet because the IPsec peer at the other end - of the exchange could not be contacted. - - IPv4 Type = 3 (destination unreachable) Code = 1 (host - unreachable) - - IPv6 Type = 1 (destination unreachable) Code = 3 (address - unreachable) - - Note that an attacker behind a security gateway could send packets - with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it - to send ICMP messages to W.X.Y.Z. This creates an opportunity for a - DoS attack among hosts behind a security gateway. To address this, a - security gateway SHOULD include a management control to allow an - administrator to configure an IPsec implementation to send or not - send the ICMP messages under these circumstances, and if this - facility is selected, to rate limit the transmission of such ICMP - responses. - -5.1.2 Header Construction for Tunnel Mode - - This section describes the handling of the inner and outer IP - headers, extension headers, and options for AH and ESP tunnels, with - regard to outbound traffic processing. This includes how to - construct the encapsulating (outer) IP header, how to process fields - in the inner IP header, and what other actions should be taken for - outbound, tunnel mode traffic. The general processing described here - is modeled after RFC 2003, "IP Encapsulation with IP" [Per96]: - - o The outer IP header Source Address and Destination Address - identify the "endpoints" of the tunnel (the encapsulator and - decapsulator). The inner IP header Source Address and Destination - Addresses identify the original sender and recipient of the - datagram, (from the perspective of this tunnel), respectively. - (See footnote 3 after the table in 5.1.2.1 for more details on the - encapsulating source IP address.) - - o The inner IP header is not changed except as noted below for TTL - (or Hop Limit) and the DS/ECN Fields. The inner IP header - otherwise remains unchanged during its delivery to the tunnel exit - point. - - o No change to IP options or extension headers in the inner header - occurs during delivery of the encapsulated datagram through the - tunnel. - - Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC - 2003) in several ways: - - -Kent & Seo [Page 53] - -Internet Draft Security Architecture for IP March 2005 - - - o IPsec offers certain controls to a security administrator to - manage covert channels (which would not normally be a concern for - tunneling) and to ensure that the receiver examines the right - portions of the received packet re: application of access - controls. An IPsec implementation MAY be configurable with regard - to how it processes the outer DS field for tunnel mode for - transmitted packets. For outbound traffic, one configuration - setting for the outer DS field will operate as described in the - following sections on IPv4 and IPv6 header processing for IPsec - tunnels. Another will allow the outer DS field to be mapped to a - fixed value, which MAY be configured on a per SA basis. (The value - might really be fixed for all traffic outbound from a device, but - per SA granularity allows that as well.) This configuration option - allows a local administrator to decide whether the covert channel - provided by copying these bits outweighs the benefits of copying. - - o IPsec describes how to handle ECN or DS and provides the ability - to control propagation of changes in these fields between - unprotected and protected domains. In general, propagation from a - protected to an unprotected domain is a covert channel and thus - controls are provided to manage the bandwidth of this channel. - Propagation of ECN values in the other direction are controlled so - that only legitimate ECN changes (indicating occurrence of - congestion between the tunnel endpoints) are propagated. By - default, DS propagation from an unprotected domain to a protected - domain is not permitted. However, if the sender and receiver do - not share the same DS code space, and the receiver has no way of - learning how to map between the two spaces, then it may be - appropriate to deviate from the default. Specifically, an IPsec - implementation MAY be configurable in terms of how it processes - the outer DS field for tunnel mode for received packets. It may be - configured to either discard the outer DS value (the default) OR - to overwrite the inner DS field with the outer DS field. If - offered, the discard vs. overwrite behavior MAY be configured on a - per SA basis. This configuration option allows a local - administrator to decide whether the vulnerabilities created by - copying these bits outweigh the benefits of copying. See [RFC - 2983] for further information on when each of these behaviors may - be useful, and also for the possible need for diffserv traffic - conditioning prior or subsequent to IPsec processing (including - tunnel decapsulation). - - o IPsec allows the IP version of the encapsulating header to be - different from that of the inner header. - - The tables in the following sub-sections show the handling for the - different header/option fields ("constructed" means that the value in - the outer field is constructed independently of the value in the - inner). - - -Kent & Seo [Page 54] - -Internet Draft Security Architecture for IP March 2005 - - -5.1.2.1 IPv4 -- Header Construction for Tunnel Mode - - <-- How Outer Hdr Relates to Inner Hdr --> - Outer Hdr at Inner Hdr at - IPv4 Encapsulator Decapsulator - Header fields: -------------------- ------------ - version 4 (1) no change - header length constructed no change - DS Field copied from inner hdr (5) no change - ECN Field copied from inner hdr constructed (6) - total length constructed no change - ID constructed no change - flags (DF,MF) constructed, DF (4) no change - fragment offset constructed no change - TTL constructed (2) decrement (2) - protocol AH, ESP no change - checksum constructed constructed (2)(6) - src address constructed (3) no change - dest address constructed (3) no change - Options never copied no change - 1. The IP version in the encapsulating header can be - different from the value in the inner header. - - 2. The TTL in the inner header is decremented by the - encapsulator prior to forwarding and by the decapsulator - if it forwards the packet. (The IPv4 checksum changes - when the TTL changes.) - - Note: Decrementing the TTL value is a normal part of - forwarding a packet. Thus, a packet originating from - the same node as the encapsulator does not have its TTL - decremented, since the sending node is originating the - packet rather than forwarding it. - - 3. Local and Remote addresses depend on the SA, which is - used to determine the Remote address which in turn - determines which Local address (net interface) is used - to forward the packet. - - Note: For multicast traffic, the destination address, or - source and destination addresses, may be required for - demuxing. In that case, it is important to ensure - consistency over the lifetime of the SA by ensuring that - the source address that appears in the encapsulating - tunnel header is the same as the one that was negotiated - during the SA establishment process. There is an - exception to this general rule, i.e., a mobile IPsec - implementation will update its source address as it - moves. - - -Kent & Seo [Page 55] - -Internet Draft Security Architecture for IP March 2005 - - - 4. Configuration determines whether to copy from the inner - header (IPv4 only), clear, or set the DF. - - 5. If the packet will immediately enter a domain for which - the DSCP value in the outer header is not appropriate, - that value MUST be mapped to an appropriate value for - the domain [RFC 2474]. See RFC 2475[BBCDWW98] for - further information. - - 6. If the ECN field in the inner header is set to ECT(0) or - ECT(1) and the ECN field in the outer header is set to - CE, then set the ECN field in the inner header to CE, - otherwise make no change to the ECN field in the inner - header. (The IPv4 checksum changes when the ECN - changes.) - - Note: IPsec does not copy the options from the inner header into the - outer header, nor does IPsec construct the options in the outer - header. However, post-IPsec code MAY insert/construct options for the - outer header. - -5.1.2.2 IPv6 -- Header Construction for Tunnel Mode - - See previous section 5.1.2.1 for notes 1-6 indicated by (footnote - number). - - <-- How Outer Hdr Relates Inner Hdr ---> - Outer Hdr at Inner Hdr at - IPv6 Encapsulator Decapsulator - Header fields: -------------------- ------------ - version 6 (1) no change - DS Field copied from inner hdr (5) no change (9) - ECN Field copied from inner hdr constructed (6) - flow label copied or configured (8) no change - payload length constructed no change - next header AH,ESP,routing hdr no change - hop limit constructed (2) decrement (2) - src address constructed (3) no change - dest address constructed (3) no change - Extension headers never copied (7) no change - - 7. IPsec does not copy the extension headers from the inner - packet into outer headers, nor does IPsec construct - extension headers in the outer header. However, - post-IPsec code MAY insert/construct extension headers - for the outer header. - - 8. See [RaCoCaDe04]. Copying is acceptable only for end - systems, not SGs. If an SG copied flow labels from the - - -Kent & Seo [Page 56] - -Internet Draft Security Architecture for IP March 2005 - - - inner header to the outer header, collisions might - result. - - 9. An implementation MAY choose to provide a facility to - pass the DS value from the outer header to the inner - header, on a per SA basis, for received tunnel mode - packets. The motivation for providing this feature is to - accommodate situations in which the DS code space at the - receiver is different from that of the sender and the - receiver has no way of knowing how to translate from the - sender's space. There is a danger in copying this value - from the outer header to the inner header, since it - enables an attacker to modify the outer DSCP value in a - fashion that may adversely affect other traffic at the - receiver. Hence the default behavior for IPsec - implementations is NOT to permit such copying. - -5.2 Processing Inbound IP Traffic (unprotected-to-protected) - - Inbound processing is somewhat different from outbound processing, - because of the use of SPIs to map IPsec protected traffic to SAs. The - inbound SPD cache (SPD-I) is applied only to bypassed or discarded - traffic. If an arriving packet appears to be an IPsec fragment from - an unprotected interface, reassembly is performed prior to IPsec - processing. The intent for any SPD cache is that a packet that fails - to match any entry is then referred to the corresponding SPD. Every - SPD SHOULD have a nominal, final entry that catches anything that is - otherwise unmatched, and discards it. This ensures that non-IPsec - protected traffic that arrives and does not match any SPD-I entry - will be discarded. - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 57] - -Internet Draft Security Architecture for IP March 2005 - - - - Unprotected Interface - | - V - +-----+ IPsec protected - ------------------->|Demux|-------------------+ - | +-----+ | - | | | - | Not IPsec | | - | | | - | V | - | +-------+ +---------+ | - | |DISCARD|<---|SPD-I (*)| | - | +-------+ +---------+ | - | | | - | |-----+ | - | | | | - | | V | - | | +------+ | - | | | ICMP | | - | | +------+ | - | | V - +---------+ | +---------+ - ....|SPD-O (*)|............|...................|PROCESS**|...IPsec - +---------+ | |(AH/ESP) | Boundary - ^ | +---------+ - | | +---+ | - | BYPASS | +-->|IKE| | - | | | +---+ | - | V | V - | +----------+ +---------+ +----+ - |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| - nested SAs +----------+ | (***) | +----+ - | +---------+ - V - Protected Interface - - Figure 3. Inbound Traffic Processing Model - (*) = The caches are shown here. If there is - a cache miss, then the SPD is checked. - There is no requirement that an - implementation buffer the packet if - there is a cache miss. - (**) = This processing includes using the - packet's SPI, etc to look up the SA - in the SAD, which forms a cache of the - SPD for inbound packets (except for - cases noted in Sections 4.4.2 and 5) - - see step 3a below. - - -Kent & Seo [Page 58] - -Internet Draft Security Architecture for IP March 2005 - - - (***) = This SAD check refers to step 4 below. - - - Prior to performing AH or ESP processing, any IP fragments that - arrive via the unprotected interface are reassembled (by IP). Each - inbound IP datagram to which IPsec processing will be applied is - identified by the appearance of the AH or ESP values in the IP Next - Protocol field (or of AH or ESP as a next layer protocol in the IPv6 - context). - - IPsec MUST perform the following steps: - - 1. When a packet arrives, it may be tagged with the ID of the - interface (physical or virtual) via which it arrived, if necessary - to support multiple SPDs and associated SPD-I caches. (The - interface ID is mapped to a corresponding SPD-ID.) - - 2. The packet is examined and demuxed into one of two categories: - - If the packet appears to be IPsec protected and it is addressed - to this device, an attempt is made to map it to an active SA - via the SAD. Note that the device may have multiple IP - addresses that may be used in the SAD lookup, e.g., in the case - of protocols such as SCTP. - - Traffic not addressed to this device, or addressed to this - device and not AH or ESP, is directed to SPD-I lookup. (This - implies that IKE traffic MUST have an explicit BYPASS entry in - the SPD.) If multiple SPDs are employed, the tag assigned to - the packet in step 1 is used to select the appropriate SPD-I - (and cache) to search. SPD-I lookup determines whether the - action is DISCARD or BYPASS. - - 3a. If the packet is addressed to the IPsec device and AH or ESP is - specified as the protocol, the packet is looked up in the SAD. For - unicast traffic, use only the SPI (or SPI plus protocol). For - multicast traffic, use the SPI plus the destination or SPI plus - destination and source addresses, as specified in section 4.1. In - either case (unicast or multicast), if there is no match, discard - the traffic. This is an auditable event. The audit log entry for - this event SHOULD include the current date/time, SPI, source and - destination of the packet, IPsec protocol, and any other selector - values of the packet that are available. If the packet is found - in the SAD, process it accordingly (see step 4). - - 3b. If the packet is not addressed to the device or is addressed to - this device and is not AH or ESP, look up the packet header in the - (appropriate) SPD-I cache. If there is a match and the packet is - to be discarded or bypassed, do so. If there is no cache match, - look up the packet in the corresponding SPD-I and create a cache - entry as appropriate. (No SAs are created in response to receipt - - -Kent & Seo [Page 59] - -Internet Draft Security Architecture for IP March 2005 - - - of a packet that requires IPsec protection; only BYPASS or DISCARD - cache entries can be created this way.) If there is no match, - discard the traffic. This is an auditable event. The audit log - entry for this event SHOULD include the current date/time, SPI if - available, IPsec protocol if available, source and destination of - the packet, and any other selector values of the packet that are - available. - - 3c. Processing of ICMP messages is assumed to take place on the - unprotected side of the IPsec boundary. Unprotected ICMP messages - are examined and local policy is applied to determine whether to - accept or reject these messages and, if accepted, what action to - take as a result. For example, if an ICMP unreachable message is - received, the implementation must decide whether to act on it, - reject it, or act on it with constraints. (See Section 6.) - - 4. Apply AH or ESP processing as specified, using the SAD entry - selected in step 3a above. Then match the packet against the - inbound selectors identified by the SAD entry to verify that the - received packet is appropriate for the SA via which it was - received. - - 5. If an IPsec system receives an inbound packet on an SA and the - packet's header fields are not consistent with the selectors for - the SA, it MUST discard the packet. This is an auditable event. - The audit log entry for this event SHOULD include the current - date/time, SPI, IPsec protocol(s), source and destination of the - packet, and any other selector values of the packet that are - available, and the selector values from the relevant SAD entry. - The system SHOULD also be capable of generating and sending an IKE - notification of INVALID_SELECTORS to the sender (IPsec peer), - indicating that the received packet was discarded because of - failure to pass selector checks. - - To minimize the impact of a DoS attack, or a mis-configured peer, the - IPsec system SHOULD include a management control to allow an - administrator to configure the IPsec implementation to send or not - send this IKE notification, and if this facility is selected, to rate - limit the transmission of such notifications. - - After traffic is bypassed or processed through IPsec, it is handed to - the inbound forwarding function for disposition. This function may - cause the packet to be sent (outbound) across the IPsec boundary for - additional inbound IPsec processing, e.g., in support of nested SAs. - If so, then as with ALL outbound traffic that is to be bypassed, the - packet MUST be matched against an SPD-O entry. Ultimately, the packet - should be forwarded to the destination host or process for - disposition. - - - -Kent & Seo [Page 60] - -Internet Draft Security Architecture for IP March 2005 - - -6. ICMP Processing - - This section describes IPsec handling of ICMP traffic. There are two - categories of ICMP traffic: error messages (e.g., type = destination - unreachable) and non-error messages (e.g., type = echo). This section - applies exclusively to error messages. Disposition of non-error, - ICMP messages (that are not addressed to the IPsec implementation - itself) MUST be explicitly accounted for using SPD entries. - - The discussion in this section applies to ICMPv6 as well as to - ICMPv4. Also, a mechanism SHOULD be provided to allow an - administrator to cause ICMP error messages (selected, all, or none) - to be logged as an aid to problem diagnosis. - -6.1 Processing ICMP Error Messages Directed to an IPsec Implementation - -6.1.1 ICMP Error Messages Received on the Unprotected Side of the -Boundary - - Figure 3 in Section 5.2 shows a distinct ICMP processing module on - the unprotected side of the IPsec boundary, for processing ICMP - messages (error or otherwise) that are addressed to the IPsec device - and that are not protected via AH or ESP. An ICMP message of this - sort is unauthenticated and its processing may result in denial or - degradation of service. This suggests that, in general, it would be - desirable to ignore such messages. However, many ICMP messages will - be received by hosts or security gateways from unauthenticated - sources, e.g., routers in the public Internet. Ignoring these ICMP - messages can degrade service, e.g., because of a failure to process - PMTU message and redirection messages. Thus there is also a - motivation for accepting and acting upon unauthenticated ICMP - messages. - - To accommodate both ends of this spectrum, a compliant IPsec - implementation MUST permit a local administrator to configure an - IPsec implementation to accept or reject unauthenticated ICMP - traffic. This control MUST be at the granularity of ICMP type and - MAY be at the granularity of ICMP type and code. Additionally, an - implementation SHOULD incorporate mechanisms and parameters for - dealing with such traffic. For example, there could be the ability to - establish a minimum PMTU for traffic (on a per destination basis), to - prevent receipt of an unauthenticated ICMP from setting the PMTU to a - trivial size. - - If an ICMP PMTU message passes the checks above and the system is - configured to accept it, then there are two possibilities. If the - implementation applies fragmentation on the ciphertext side of the - boundary, then the accepted PMTU information is passed to the - forwarding module (outside of the IPsec implementation) which uses it - - -Kent & Seo [Page 61] - -Internet Draft Security Architecture for IP March 2005 - - - to manage outbound packet fragmentation. If the implementation is - configured to effect plaintext side fragmentation, then the PMTU - information is passed to the plaintext side and processed as - described in Section 8.2. - -6.1.2 ICMP Error Messages Received on the Protected Side of the Boundary - - These ICMP messages are not authenticated, but they do come from - sources on the protected side of the IPsec boundary. Thus these - messages generally are viewed as more "trustworthy" than their - counterparts arriving from sources on the unprotected side of the - boundary. The major security concern here is that a compromised host - or router might emit erroneous ICMP error messages that could degrade - service for other devices "behind" the security gateway, or that - could even result in violations of confidentiality. For example, if a - bogus ICMP redirect were consumed by a security gateway, it could - cause the forwarding table on the protected side of the boundary to - be modified so as to deliver traffic to an inappropriate destination - "behind" the gateway. Thus implementers MUST provide controls to - allow local administrators to constrain the processing of ICMP error - messages received on the protected side of the boundary, and directed - to the IPsec implementation. These controls are of the same type as - those employed on the unprotected side, described above in Section - 6.1.1. - -6.2 Processing Protected, Transit ICMP Error Messages - - When an ICMP error message is transmitted via an SA to a device - "behind" an IPsec implementation, both the payload and the header of - the ICMP message require checking from an access control perspective. - If one of these messages is forwarded to a host behind a security - gateway, the receiving host IP implementation will make decisions - based on the payload, i.e., the header of the packet that purportedly - triggered the error response. Thus an IPsec implementation MUST be - configurable to check that this payload header information is - consistent with the SA via which it arrives. (This means that the - payload header, with source and destination address and port fields - reversed, matches the traffic selectors for the SA.) If this sort of - check is not performed, then for example, anyone with whom the - receiving IPsec system (A) has an active SA could send an ICMP - destination dead message that refers to any host/net with which A is - currently communicating, and thus effect a highly efficient DoS - attack re: communication with other peers of A. Normal IPsec - receiver processing of traffic is not sufficient to protect against - such attacks. However, not all contexts may require such checks, so - it is also necessary to allow a local administrator to configure an - implementation to NOT perform such checks. - - To accommodate both policies, the following convention is adopted. If - - -Kent & Seo [Page 62] - -Internet Draft Security Architecture for IP March 2005 - - - an administrator wants to allow ICMP error messages to be carried by - an SA without inspection of the payload, then configure an SPD entry - that explicitly allows for carriage of such traffic. If an - administrator wants IPsec to check the payload of ICMP error messages - for consistency, then do not create any SPD entries that accommodate - carriage of such traffic based on the ICMP packet header. This - convention motivates the following processing description. - - IPsec senders and receivers MUST support the following processing for - ICMP error messages that are sent and received via SAs. - - If an SA exists that accommodates an outbound ICMP error message, - then the message is mapped to the SA and only the IP and ICMP headers - are checked upon receipt, just as would be the case for other - traffic. If no SA exists that matches the traffic selectors - associated with an ICMP error message, then the SPD is searched to - determine if such an SA can be created. If so, the SA is created and - the ICMP error message is transmitted via that SA. Upon receipt, this - message is subject to the usual traffic selector checks at the - receiver. This processing is exactly what would happen for traffic in - general, and thus does not represent any special processing for ICMP - error messages. - - If no SA exists that would carry the outbound ICMP message in - question, and if no SPD entry would allow carriage of this outbound - ICMP error message, then an IPsec implementation MUST map the message - to the SA that would carry the return traffic associated with the - packet that triggered the ICMP error message. This requires an IPsec - implementation to detect outbound ICMP error messages that map to no - extant SA or SPD entry, and treat them specially with regard to SA - creation and lookup. The implementation extracts the header for the - packet that triggered the error (from the ICMP message payload), - reverses the source and destination IP address fields, extracts the - protocol field, and reverses the port fields (if accessible). It then - uses this extracted information to locate an appropriate, active - outbound SA, and transmits the error message via this SA. If no such - SA exists, no SA will be created, and this is an auditable event. - - If an IPsec implementation receives an inbound ICMP error message on - an SA, and the IP and ICMP headers of the message do not match the - traffic selectors for the SA, the receiver MUST process the received - message in a special fashion. Specifically, the receiver must extract - the header of the triggering packet from the ICMP payload, and - reverse fields as described above to determine if the packet is - consistent with the selectors for the SA via which the ICMP error - message was received. If the packet fails this check, the IPsec - implementation MUST NOT forwarded the ICMP message to the - destination. This is an auditable event. - - - -Kent & Seo [Page 63] - -Internet Draft Security Architecture for IP March 2005 - - -7. Handling Fragments (on the protected side of the IPsec boundary) - - Earlier sections of this document describe mechanisms for (a) - fragmenting an outbound packet after IPsec processing has been - applied and reassembling it at the receiver before IPsec processing - and (b) handling inbound fragments received from the unprotected side - of the IPsec boundary. This section describes how an implementation - should handle the processing of outbound plaintext fragments on the - protected side of the IPsec boundary. (See Appendix D for discussion - of Fragment Handling Rationale.) In particular, it addresses: - - o mapping an outbound non-initial fragment to the right SA - (or finding the right SPD entry) - o verifying that a received non-initial fragment is - authorized for the SA via which it was received - o mapping outbound and inbound non-initial fragments to the - right SPD-O/SPD-I entry or the relevant cache entry, for - BYPASS/DISCARD traffic - - Note: In Section 4.1, transport mode SAs have been defined to not - carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two - special values, ANY and OPAQUE, were defined for selectors and that - ANY includes OPAQUE. The term "non-trivial" is used to mean that the - selector has a value other than OPAQUE or ANY. - - Note: The term "non-initial fragment" is used here to indicate a - fragment that does not contain all the selector values that may be - needed for access control. As observed in Section 4.4.1, depending - on the Next Layer Protocol, in addition to Ports, the ICMP message - type/code or Mobility Header type could be missing from non-initial - fragments. Also, for IPv6, even the first fragment might NOT contain - the Next Layer Protocol or Ports (or ICMP message type/code, or - Mobility Header type) depending on the kind and number of extension - headers present. If a non-initial fragment contains the Port (or - ICMP type and code or Mobility header type) but not the Next Layer - Protocol, then unless there is an SPD entry for the relevant - Local/Remote addresses with ANY for Next Layer Protocol and Port (or - ICMP type and code or Mobility header type), the fragment would not - contain all the selector information needed for access control. - - To address the above issues, three approaches have been defined: - - o Tunnel mode SAs that carry initial and non-initial fragments - (See Section 7.1) - o Separate tunnel mode SAs for non-initial fragments (See - Section 7.2) - o Stateful fragment checking (See Section 7.3) - - - - -Kent & Seo [Page 64] - -Internet Draft Security Architecture for IP March 2005 - - -7.1 Tunnel Mode SAs that Carry Initial and Non-Initial Fragments - - All implementations MUST support tunnel mode SAs that are configured - to pass traffic without regard to port field (or ICMP type/code or - Mobility Header type) values. If the SA will carry traffic for - specified protocols, the selector set for the SA MUST specify the - port fields (or ICMP type/code or Mobility Header type) as ANY. An SA - defined in this fashion will carry all traffic including initial and - non-initial fragments for the indicated Local/Remote addresses and - specified Next Layer protocol(s). If the SA will carry traffic - without regard to a specific protocol value (i.e., ANY is specified - as the (Next Layer) protocol selector value), then the port field - values are undefined and MUST be set to ANY as well. (As noted in - 4.4.1, ANY includes OPAQUE as well as all specific values.) - -7.2 Separate Tunnel Mode SAs for Non-Initial Fragments - - An implementation MAY support tunnel mode SAs that will carry only - non-initial fragments, separate from non-fragmented packets and - initial fragments. The OPAQUE value will be used to specify port (or - ICMP type/code or Mobility Header type) field selectors for an SA to - carry such fragments. Receivers MUST perform a minimum offset check - on IPv4 (non-initial) fragments to protect against overlapping - fragment attacks when SAs of this type are employed. Because such - checks cannot be performed on IPv6 non-initial fragments, users and - administrators are advised that carriage of such fragments may be - dangerous, and implementers may choose to NOT support such SAs for - IPv6 traffic. Also, an SA of this sort will carry all non-initial - fragments that match a specified Local/Remote address pair and - protocol value, i.e., the fragments carried on this SA belong to - packets that if not fragmented, might have gone on separate SAs of - differing security. Therefore users and administrators are advised - to protect such traffic using ESP (with integrity) and the - "strongest" integrity and encryption algorithms in use between both - peers. (Determination of the "strongest" algorithms requires - imposing an ordering of the available algorithms, a local - determination at the discretion of the initiator of the SA.) - - Specific port (or ICMP type/code or Mobility header type) selector - values will be used to define SAs to carry initial fragments and - non-fragmented packets. This approach can be used if a user or - administrator wants to create one or more tunnel mode SAs between the - same Local/Remote addresses that discriminate based on port (or ICMP - type/code or Mobility header type) fields. These SAs MUST have - non-trivial protocol selector values, otherwise approach #1 above - MUST be used. - - Note: In general, for the approach described in this section, one - needs only a single SA between two implementations to carry all - - -Kent & Seo [Page 65] - -Internet Draft Security Architecture for IP March 2005 - - - non-initial fragments. However, if one chooses to have multiple SAs - between the two implementations for QoS differentiation, then one - might also want multiple SAs to carry fragments-without-ports, one - for each supported QoS class. Since support for QoS via distinct SAs - is a local matter, not mandated by this document, the choice to have - multiple SAs to carry non-initial fragments should also be local. - -7.3 Stateful Fragment Checking - - An implementation MAY support some form of stateful fragment checking - for a tunnel mode SA with non-trivial port (or ICMP type/code or MH - type) field values (not ANY or OPAQUE). 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. This standard does not - specify how peers will deal with such fragments, e.g., via reassembly - or other means, at either sender or receiver. However, a receiver - MUST discard non-initial fragments that arrive on an SA with - non-trivial port (or ICMP type/code or MH type) selector values - unless this feature has been negotiated. Also, the receiver MUST - discard non-initial fragments that do not comply with the security - policy applied to the overall packet. Discarding such packets is an - auditable event. Note that in network configurations where fragments - of a packet might be sent or received via different security gateways - or BITW implementations, stateful strategies for tracking fragments - may fail. - -7.4 BYPASS/DISCARD traffic - - All implementations MUST support DISCARDing of fragments using the - normal SPD packet classification mechanisms. All implementations MUST - support stateful fragment checking to accommodate BYPASS traffic for - which a non-trivial port range is specified. The concern is that - BYPASS of a cleartext, non-initial fragment arriving at an IPsec - implementation could undermine the security afforded IPsec-protected - traffic directed to the same destination. For example, consider an - IPsec implementation configured with an SPD entry that calls for - IPsec-protection of traffic between a specific source/destination - address pair, and for a specific protocol and destination port, e.g., - TCP traffic on port 23 (Telnet). Assume that the implementation also - allows BYPASS of traffic from the same source/destination address - pair and protocol, but for a different destination port, e.g., port - 119 (NNTP). An attacker could send a non-initial fragment (with a - forged source address) that, if bypassed, could overlap with - - -Kent & Seo [Page 66] - -Internet Draft Security Architecture for IP March 2005 - - - IPsec-protected traffic from the same source and thus violate the - integrity of the IPsec-protected traffic. Requiring stateful fragment - checking for BYPASS entries with non-trivial port ranges prevents - attacks of this sort. As noted above, in network configurations where - fragments of a packet might be sent or received via different - security gateways or BITW implementations, stateful strategies for - tracking fragments may fail. - -8. Path MTU/DF Processing - - The application of AH or ESP to an outbound packet increases the size - of a packet and thus may cause a packet to exceed the PMTU for the SA - via which the packet will travel. An IPsec implementation also may - receive an unprotected ICMP PMTU message and, if it choose to act - upon it, the result will affect outbound traffic processing. This - section describes the processing required of an IPsec implementation - to deal with these two PMTU issues. - -8.1 DF Bit - - All IPsec implementations MUST support the option of copying the DF - bit from an outbound packet to the tunnel mode header that it emits, - when traffic is carried via a tunnel mode SA. This means that it MUST - be possible to configure the implementation's treatment of the DF bit - (set, clear, copy from inner header) for each SA. This applies to SAs - where both inner and outer headers are IPv4. - -8.2 Path MTU Discovery (PMTU) - - This section discusses IPsec handling for unprotected Path MTU - Discovery messages. ICMP PMTU is used here to refer to an ICMP - message for: - - IPv4 (RFC 792 [Pos81b]): - - Type = 3 (Destination Unreachable) - - Code = 4 (Fragmentation needed and DF set) - - Next--Hop MTU in the low-order 16 bits of the - second word of the ICMP header (labeled "unused" - in RFC 792), with high-order 16 bits set to zero) - - IPv6 (RFC 2463 [CD98]): - - Type = 2 (Packet Too Big) - - Code = 0 (Fragmentation needed) - - Next-Hop MTU in the 32 bit MTU field of the ICMP6 - message - - - - - - -Kent & Seo [Page 67] - -Internet Draft Security Architecture for IP March 2005 - - -8.2.1 Propagation of PMTU - - When an IPsec implementation receives an unauthenticated PMTU - message, and it is configured to process (vs. ignore) such messages, - it maps the message to the SA to which it corresponds. This mapping - is effected by extracting the header information from the payload of - the PMTU message and applying the procedure described in Section 5.2. - The PMTU determined by this message is used to update the SAD PMTU - field, taking into account the size of the AH or ESP header that will - be applied, any crypto synchronization data, and the overhead imposed - by an additional IP header, in the case of a tunnel mode SA. - - In a native host implementation, it is possible to maintain PMTU data - at the same granularity as for unprotected communication, so there is - no loss of functionality. Signaling of the PMTU information is - internal to the host. For all other IPsec implementation options, the - PMTU data must be propagated via a synthesized ICMP PMTU. In these - cases, the IPsec implementation SHOULD wait for outbound traffic to - be mapped to the SAD entry. When such traffic arrives, if the traffic - would exceed the updated PMTU value the traffic MUST be handled as - follows: - - Case 1: Original (cleartext) packet is IPv4 and has the DF - bit set. The implementation SHOULD discard the packet - and send a PMTU ICMP message. - - Case 2: Original (cleartext) packet is IPv4 and has the DF - bit clear. The implementation SHOULD fragment (before or - after encryption per its configuration) and then forward - the fragments. It SHOULD NOT send a PMTU ICMP message. - - Case 3: Original (cleartext) packet is IPv6. The implementation - SHOULD discard the packet and send a PMTU ICMP message. - -8.2.2 PMTU Aging - - In all IPsec implementations the PMTU associated with an SA MUST be - "aged" and some mechanism is required to update the PMTU in a timely - manner, especially for discovering if the PMTU is smaller than - required by current network conditions. A given PMTU has to remain - in place long enough for a packet to get from the source of the SA to - the peer, and to propagate an ICMP error message if the current PMTU - is too big. - - Implementations SHOULD use the approach described in the Path MTU - Discovery document (RFC 1191 [MD90], Section 6.3), which suggests - periodically resetting the PMTU to the first-hop data-link MTU and - then letting the normal PMTU Discovery processes update the PMTU as - necessary. The period SHOULD be configurable. - - -Kent & Seo [Page 68] - -Internet Draft Security Architecture for IP March 2005 - - -9. Auditing - - IPsec implementations are not required to support auditing. For the - most part, the granularity of auditing is a local matter. However, - several auditable events are identified in this document and for each - of these events a minimum set of information that SHOULD be included - in an audit log is defined. Additional information also MAY be - included in the audit log for each of these events, and additional - events, not explicitly called out in this specification, also MAY - result in audit log entries. There is no requirement for the - receiver to transmit any message to the purported transmitter in - response to the detection of an auditable event, because of the - potential to induce denial of service via such action. - -10. Conformance Requirements - - All IPv4 IPsec implementations MUST comply with all requirements of - this document. All IPv6 implementations MUST comply with all - requirements of this document. - -11. Security Considerations - - The focus of this document is security; hence security considerations - permeate this specification. - - IPsec imposes stringent constraints on bypass of IP header data in - both directions, across the IPsec barrier, especially when tunnel - mode SAs are employed. Some constraints are absolute, while others - are subject to local administrative controls, often on a per-SA - basis. For outbound traffic, these constraints are designed to limit - covert channel bandwidth. For inbound traffic, the constraints are - designed to prevent an adversary who has the ability to tamper with - one data stream (on the unprotected side of the IPsec barrier) from - adversely affecting other data streams (on the protected side of the - barrier). The discussion in Section 5 dealing with processing DSCP - values for tunnel mode SAs illustrates this concern. - - If an IPsec implementation is configured to pass ICMP error messages - over SAs based on the ICMP header values, without checking the header - information from the ICMP message payload, serious vulnerabilities - may arise. Consider a scenario in which several sites (A, B, and C) - are connected to one another via ESP-protected tunnels: A-B, A-C, and - B-C. Also assume that the traffic selectors for each tunnel specify - ANY for protocol and port fields and IP source/destination address - ranges that encompass the address range for the systems behind the - security gateways serving each site. This would allow a host at site - B to send an ICMP destination dead message to any host at site A, - that declares all hosts on the net at site C to be unreachable. This - is a very efficient DoS attack that could have been prevented if the - - -Kent & Seo [Page 69] - -Internet Draft Security Architecture for IP March 2005 - - - ICMP error messages were subjected to the checks that IPsec provides, - if the SPD is suitably configured, as described in Section 6.2. - -12. IANA Considerations - - Upon approval of this draft for publication as an RFC, this document - requests that IANA fill in the number (xx) for the asn1-modules - registry and assign the object identifier (yy) for the spd-module in - Appendix C "ASN.1 for an SPD Entry". - -13. Differences from RFC 2401 - - This architecture document differs substantially from RFC 2401 in - detail and in organization, but the fundamental notions are - unchanged. - - o The processing model has been revised to address new IPsec - scenarios, improve performance and simplify implementation. This - includes a separation between forwarding (routing) and SPD - selection, several SPD changes, and the addition of an outbound - SPD cache and an inbound SPD cache for bypassed or discarded - traffic. There is also a new database, the Peer Authorization - Database (PAD). This provides a link between an SA management - protocol like IKE and the SPD. - - o There is no longer a requirement to support nested SAs or "SA - bundles." Instead this functionality can be achieved through SPD - and forwarding table configuration. An example of a configuration - has been added in Appendix E. - - o SPD entries were redefined to provide more flexibility. Each SPD - entry now consists of 1 to N sets of selectors, where each - selector set contains one protocol and a "list of ranges" can now - be specified for the Local IP address, Remote IP address, and - whatever fields (if any) are associated with the Next Layer - Protocol (Local Port, Remote Port, ICMP message type and code, and - Mobility Header Type). An individual value for a selector is - represented via a trivial range and ANY is represented via a range - than spans all values for the selector. An example of an ASN.1 - description is included in Appendix C. - - o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and - ECN. The tunnel section has been updated to explain how to handle - DSCP and ECN bits. - - o For tunnel mode SAs, an SG, BITS, or BITW implementation is now - allowed to fragment packets before applying IPsec. This applies - only to IPv4. For IPv6 packets, only the originator is allowed to - fragment them. - - -Kent & Seo [Page 70] - -Internet Draft Security Architecture for IP March 2005 - - - o When security is desired between two intermediate systems along a - path or between an intermediate system and an end system, - transport mode may now be used between security gateways and - between a security gateway and a host. - - o This document clarifies that for all traffic that crosses the IPsec - boundary, including IPsec management traffic, the SPD or - associated caches must be consulted. - - o This document defines how to handle the situation of a security - gateway with multiple subscribers requiring separate IPsec - contexts. - - o A definition of reserved SPIs has been added. - - o Text has been added explaining why ALL IP packets must be checked - -- IPsec includes minimal firewall functionality to support access - control at the IP layer. - - o The tunnel section has been updated to clarify how to handle the IP - options field and IPv6 extension headers when constructing the - outer header. - - o SA mapping for inbound traffic has been updated to be consistent - with the changes made in AH and ESP for support of unicast and - multicast SAs. - - o Guidance has been added re: how to handle the covert channel - created in tunnel mode by copying the DSCP value to outer header. - - o Support for AH in both IPv4 and IPv6 is no longer required. - - o PMTU handling has been updated. The appendix on - PMTU/DF/Fragmentation has been deleted. - - - o Three approaches have been added for handling plaintext fragments - on the protected side of the IPsec boundary. Appendix D documents - the rationale behind them. - - o Added revised text describing how to derive selector values for SAs - (from the SPD entry or from the packet, etc.) - - o Added a new table describing the relationship between selector - values in an SPD entry, the PFP flag, and resulting selector - values in the corresponding SAD entry. - - o Added Appendix B to describe decorrelation. - - - -Kent & Seo [Page 71] - -Internet Draft Security Architecture for IP March 2005 - - - o Added text describing how to handle an outbound packet which must - be discarded. - - o Added text describing how to handle a DISCARDED inbound packet, - i.e., one that does not match the SA upon which it arrived. - - o IPv6 mobility header has been added as a possible Next Layer - Protocol. IPv6 mobility header message type has been added as a - selector. - - o ICMP message type and code have been added as selectors. - - o The selector "data sensitivity level" has been removed to simplify - things. - - o Updated text describing handling ICMP error messages. The appendix - on "Categorization of ICMP messages" has been deleted. - - o The text for the selector name has been updated and clarified. - - o The "Next Layer Protocol" has been further explained and a default - list of protocols to skip when looking for the Next Layer Protocol - has been added. - - o The text has been amended to say that this document assumes use of - IKE v2 or an SA management protocol with comparable features. - - o Text has been added clarifying the algorithm for mapping inbound - IPsec datagrams to SAs in the presence of multicast SAs. - - o The appendix "Sequence Space Window Code Example" has been removed. - - o With respect to IP addresses and ports, the terms "Local" and - "Remote" are used for policy rules (replacing source and - destination). "Local" refers to the entity being protected by an - IPsec implementation, i.e., the "source" address/port of outbound - packets or the "destination" address/port of inbound packets. - "Remote" refers to a peer entity or peer entities. The terms - "source" and "destination" are still used for packet header - fields. - - - - - - - - - - - -Kent & Seo [Page 72] - -Internet Draft Security Architecture for IP March 2005 - - -Acknowledgements - - The authors would like to acknowledge the contributions of Ran - Atkinson, who played a critical role in initial IPsec activities, and - who authored the first series of IPsec standards: RFCs 1825-1827; and - Charlie Lynn, who made significant contributions to the second series - of IPsec standards (RFCs 2401,2402,and 2406) and to the current - versions, especially with regard to IPv6 issues. The authors also - would like to thank the members of the IPsec and MSEC working groups - who have contributed to the development of this protocol - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 73] - -Internet Draft Security Architecture for IP March 2005 - - -Appendix A -- Glossary - -This section provides definitions for several key terms that are -employed in this document. Other documents provide additional -definitions and background information relevant to this technology, -e.g., [Shi00, VK83, HA94]. Included in this glossary are generic -security service and security mechanism terms, plus IPsec-specific -terms. - - Access Control - Access control is a security service that prevents unauthorized - use of a resource, including the prevention of use of a resource - in an unauthorized manner. In the IPsec context, the resource to - which access is being controlled is often: - o for a host, computing cycles or data - o for a security gateway, a network behind the gateway - or bandwidth on that network. - - Anti-replay - [See "Integrity" below] - - Authentication - This term is used informally to refer to the combination of two - nominally distinct security services, data origin authentication - and connectionless integrity. See the definitions below for each - of these services. - - Availability - Availability, when viewed as a security service, addresses the - security concerns engendered by attacks against networks that deny - or degrade service. For example, in the IPsec context, the use of - anti-replay mechanisms in AH and ESP support availability. - - Confidentiality - Confidentiality is the security service that protects data from - unauthorized disclosure. The primary confidentiality concern in - most instances is unauthorized disclosure of application level - data, but disclosure of the external characteristics of - communication also can be a concern in some circumstances. - Traffic flow confidentiality is the service that addresses this - latter concern by concealing source and destination addresses, - message length, or frequency of communication. In the IPsec - context, using ESP in tunnel mode, especially at a security - gateway, can provide some level of traffic flow confidentiality. - (See also traffic analysis, below.) - - Data Origin Authentication - Data origin authentication is a security service that verifies the - identity of the claimed source of data. This service is usually - - -Kent & Seo [Page 74] - -Internet Draft Security Architecture for IP March 2005 - - - bundled with connectionless integrity service. - - Encryption - Encryption is a security mechanism used to transform data from an - intelligible form (plaintext) into an unintelligible form - (ciphertext), to provide confidentiality. The inverse - transformation process is designated "decryption". Oftimes the - term "encryption" is used to generically refer to both processes. - - Integrity - Integrity is a security service that ensures that modifications to - data are detectable. Integrity comes in various flavors to match - application requirements. IPsec supports two forms of integrity: - connectionless and a form of partial sequence integrity. - Connectionless integrity is a service that detects modification of - an individual IP datagram, without regard to the ordering of the - datagram in a stream of traffic. The form of partial sequence - integrity offered in IPsec is referred to as anti-replay - integrity, and it detects arrival of duplicate IP datagrams - (within a constrained window). This is in contrast to - connection-oriented integrity, which imposes more stringent - sequencing requirements on traffic, e.g., to be able to detect - lost or re-ordered messages. Although authentication and - integrity services often are cited separately, in practice they - are intimately connected and almost always offered in tandem. - - Protected vs Unprotected - "Protected" refers to the systems or interfaces that are inside - the IPsec protection boundary and "unprotected" refers to the - systems or interfaces that are outside the IPsec protection - boundary. IPsec provides a boundary through which traffic passes. - There is an asymmetry to this barrier, which is reflected in the - processing model. Outbound data, if not discarded or bypassed, is - protected via the application of AH or ESP and the addition of the - corresponding headers. Inbound data, if not discarded or - bypassed, is processed via the removal of AH or ESP headers. In - this document, inbound traffic enters an IPsec implementation from - the "unprotected" interface. Outbound traffic enters the - implementation via the "protected" interface, or is internally - generated by the implementation on the "protected" side of the - boundary and directed toward the "unprotected" interface. An IPsec - implementation may support more than one interface on either or - both sides of the boundary. The protected interface may be - internal, e.g., in a host implementation of IPsec. The protected - interface may link to a socket layer interface presented by the - OS. - - Security Association (SA) - A simplex (uni-directional) logical connection, created for - - -Kent & Seo [Page 75] - -Internet Draft Security Architecture for IP March 2005 - - - security purposes. All traffic traversing an SA is provided the - same security processing. In IPsec, an SA is an internet layer - abstraction implemented through the use of AH or ESP. State data - associated with an SA is represented in the SA Database (SAD). - - Security Gateway - A security gateway is an intermediate system that acts as the - communications interface between two networks. The set of hosts - (and networks) on the external side of the security gateway is - termed unprotected (they are generally at least less protected - than those "behind" the SG), while the networks and hosts on the - internal side are viewed as protected. The internal subnets and - hosts served by a security gateway are presumed to be trusted by - virtue of sharing a common, local, security administration. (See - "Trusted Subnetwork" below.) In the IPsec context, a security - gateway is a point at which AH and/or ESP is implemented in order - to serve a set of internal hosts, providing security services for - these hosts when they communicate with external hosts also - employing IPsec (either directly or via another security gateway). - - SPI - Acronym for "Security Parameters Index" (SPI). The SPI is an - arbitrary 32-bit value that is used by a receiver to identify the - SA to which an incoming packet should be bound. For a unicast SA, - the SPI can be used by itself to specify an SA, or it may be used - in conjunction with the IPsec protocol type. Additional IP - address information is used to identify multicast SAs. The SPI is - carried in AH and ESP protocols to enable the receiving system to - select the SA under which a received packet will be processed. An - SPI has only local significance, as defined by the creator of the - SA (usually the receiver of the packet carrying the SPI); thus an - SPI is generally viewed as an opaque bit string. However, the - creator of an SA may choose to interpret the bits in an SPI to - facilitate local processing. - - Traffic Analysis - The analysis of network traffic flow for the purpose of deducing - information that is useful to an adversary. Examples of such - information are frequency of transmission, the identities of the - conversing parties, sizes of packets, flow identifiers, etc. - [Sch94] - - - - - - - - - - -Kent & Seo [Page 76] - -Internet Draft Security Architecture for IP March 2005 - - -Appendix B - Decorrelation - - This appendix is based on work done for caching of policies in the IP - Security Policy Working Group by Luis Sanchez, Matt Condell, and John - Zao. - - Two SPD entries are correlated if there is a non-null intersection - between the values of corresponding selectors in each entry. Caching - correlated SPD entries can lead to incorrect policy enforcement. A - solution to this problem, that still allows for caching, is to remove - the ambiguities by decorrelating the entries. That is, the SPD - entries must be rewritten so that for every pair of entries there - exists a selector for which there is a null intersection between the - values in both of the entries. Once the entries are decorrelated, - there is no longer any ordering requirement on them, since only one - entry will match any lookup. The next section describes - decorrelation in more detail and presents an algorithm that may be - used to implement decorrelation. - - B.1 Decorrelation Algorithm - - The basic decorrelation algorithm takes each entry in a correlated - SPD and divides it up into a set of entries using a tree structure. - The nodes of the tree are the selectors that may overlap between the - policies. At each node, the algorithm creates a branch for each of - the values of the selector. It also creates one branch for the - complement of the union of all selector values. Policies are then - formed by traversing the tree from the root to each leaf. The - policies at the leaves are compared to the set of already - decorrelated policy rules. Each policy at a leaf is either completely - overridden by a policy in the already decorrelated set and is - discarded or is decorrelated with all the policies in the - decorrelated set and is added to it. - - The basic algorithm does not guarantee an optimal set of decorrelated - entries. That is, the entries may be broken up into smaller sets - than is necessary, though they will still provide all the necessary - policy information. Some extensions to the basic algorithm are - described later to improve this and improve the performance of the - algorithm. - - C A set of ordered, correlated entries (a correlated SPD) - Ci The ith entry in C. - U The set of decorrelated entries being built from C - Ui The ith entry in U. - Sik The kth selection for policy Ci - Ai The action for policy Ci - - A policy (SPD entry) P may be expressed as a sequence of selector - - -Kent & Seo [Page 77] - -Internet Draft Security Architecture for IP March 2005 - - - values and an action (BYPASS, DISCARD, or PROTECT): - - Ci = Si1 x Si2 x ... x Sik -> Ai - - 1) Put C1 in set U as U1 - - For each policy Cj (j > 1) in C - - 2) If Cj is decorrelated with every entry in U, then add it to U. - - 3) If Cj is correlated with one or more entries in U, create a tree - rooted at the policy Cj that partitions Cj into a set of decorrelated - entries. The algorithm starts with a root node where no selectors - have yet been chosen. - - A) Choose a selector in Cj, Sjn, that has not yet been chosen when - traversing the tree from the root to this node. If there are no - selectors not yet used, continue to the next unfinished branch - until all branches have been completed. When the tree is - completed, go to step D. - - T is the set of entries in U that are correlated with the entry - at this node. - - The entry at this node is the entry formed by the selector - values of each of the branches between the root and this node. - Any selector values that are not yet represented by branches - assume the corresponding selector value in Cj, since the values - in Cj represent the maximum value for each selector. - - B) Add a branch to the tree for each value of the selector Sjn that - appears in any of the entries in T. (If the value is a superset - of the value of Sjn in Cj, then use the value in Cj, since that - value represents the universal set.) Also add a branch for the - complement of the union of all the values of the selector Sjn - in T. When taking the complement, remember that the universal - set is the value of Sjn in Cj. A branch need not be created - for the null set. - - C) Repeat A and B until the tree is completed. - - D) The entry to each leaf now represents an entry that is a subset - of Cj. The entries at the leaves completely partition Cj in - such a way that each entry is either completely overridden by - an entry in U, or is decorrelated with the entries in U. - - Add all the decorrelated entries at the leaves of the tree to U. - - 4) Get next Cj and go to 2. - - -Kent & Seo [Page 78] - -Internet Draft Security Architecture for IP March 2005 - - - - 5) When all entries in C have been processed, then U will contain an - decorrelated version of C. - - There are several optimizations that can be made to this algorithm. - A few of them are presented here. - - It is possible to optimize, or at least improve, the amount of - branching that occurs by carefully choosing the order of the - selectors used for the next branch. For example, if a selector Sjn - can be chosen so that all the values for that selector in T are equal - to or a superset of the value of Sjn in Cj, then only a single branch - needs to be created (since the complement will be null). - - Branches of the tree do not have to proceed with the entire - decorrelation algorithm. For example, if a node represents an entry - that is decorrelated with all the entries in U, then there is no - reason to continue decorrelating that branch. Also, if a branch is - completely overridden by an entry in U, then there is no reason to - continue decorrelating the branch. - - An additional optimization is to check to see if a branch is - overridden by one of the CORRELATED entries in set C that has already - been decorrelated. That is, if the branch is part of decorrelating - Cj, then check to see if it was overridden by an entry Cm, m < j. - This is a valid check, since all the entries Cm are already expressed - in U. - - Along with checking if an entry is already decorrelated in step 2, - check if Cj is overridden by any entry in U. If it is, skip it since - it is not relevant. An entry x is overridden by another entry y if - every selector in x is equal to or a subset of the corresponding - selector in entry y. - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 79] - -Internet Draft Security Architecture for IP March 2005 - - -Appendix C -- ASN.1 for an SPD Entry - - This appendix is included as an additional way to describe SPD - entries, as defined in Section 4.4.1. It uses ASN.1 syntax which has - been successfully compiled. This syntax is merely illustrative and - need not be employed in an implementation to achieve compliance. The - SPD description in Section 4.4.1 is normative. - - - SPDModule - - {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) - asn1-modules (xx) spd-module (yy) } - - DEFINITIONS IMPLICIT TAGS ::= - - BEGIN - - IMPORTS - RDNSequence FROM PKIX1Explicit88 - { iso(1) identified-organization(3) - dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) } ; - - -- An SPD is a list of policies in decreasing order of preference - SPD ::= SEQUENCE OF SPDEntry - - SPDEntry ::= CHOICE { - iPsecEntry IPsecEntry, -- PROTECT traffic - bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS - - IPsecEntry ::= SEQUENCE { -- Each entry consists of - name NameSets OPTIONAL, - pFPs PacketFlags, -- Populate from packet flags - -- Applies to ALL of the corresponding - -- traffic selectors in the SelectorLists - condition SelectorLists, -- Policy "condition" - processing Processing -- Policy "action" - } - - BypassOrDiscardEntry ::= SEQUENCE { - bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD - condition InOutBound } - - InOutBound ::= CHOICE { - outbound [0] SelectorLists, - inbound [1] SelectorLists, - bothways [2] BothWays } - - - -Kent & Seo [Page 80] - -Internet Draft Security Architecture for IP March 2005 - - - BothWays ::= SEQUENCE { - inbound SelectorLists, - outbound SelectorLists } - - NameSets ::= SEQUENCE { - passed SET OF Names-R, -- Matched to IKE ID by - -- responder - local SET OF Names-I } -- Used internally by IKE - -- initiator - - Names-R ::= CHOICE { -- IKE v2 IDs - dName RDNSequence, -- ID_DER_ASN1_DN - fqdn FQDN, -- ID_FQDN - rfc822 [0] RFC822Name, -- ID_RFC822_ADDR - keyID OCTET STRING } -- KEY_ID - - Names-I ::= OCTET STRING -- Used internally by IKE - -- initiator - - FQDN ::= IA5String - - RFC822Name ::= IA5String - - PacketFlags ::= BIT STRING { - -- if set, take selector value from packet - -- establishing SA - -- else use value in SPD entry - localAddr (0), - remoteAddr (1), - protocol (2), - localPort (3), - remotePort (4) } - - SelectorLists ::= SET OF SelectorList - - SelectorList ::= SEQUENCE { - localAddr AddrList, - remoteAddr AddrList, - protocol ProtocolChoice } - - Processing ::= SEQUENCE { - extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit - seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit - fragCheck BOOLEAN, -- TRUE stateful fragment checking, - -- FALSE no stateful fragment checking - lifetime SALifetime, - spi ManualSPI, - algorithms ProcessingAlgs, - tunnel TunnelOptions OPTIONAL } -- if absent, use - - -Kent & Seo [Page 81] - -Internet Draft Security Architecture for IP March 2005 - - - -- transport mode - - SALifetime ::= SEQUENCE { - seconds [0] INTEGER OPTIONAL, - bytes [1] INTEGER OPTIONAL } - - ManualSPI ::= SEQUENCE { - spi INTEGER, - keys KeyIDs } - - KeyIDs ::= SEQUENCE OF OCTET STRING - - ProcessingAlgs ::= CHOICE { - ah [0] IntegrityAlgs, -- AH - esp [1] ESPAlgs} -- ESP - - ESPAlgs ::= CHOICE { - integrity [0] IntegrityAlgs, -- integrity only - confidentiality [1] ConfidentialityAlgs, -- confidentiality - -- only - both [2] IntegrityConfidentialityAlgs, - combined [3] CombinedModeAlgs } - - IntegrityConfidentialityAlgs ::= SEQUENCE { - integrity IntegrityAlgs, - confidentiality ConfidentialityAlgs } - - -- Integrity Algorithms, ordered by decreasing preference - IntegrityAlgs ::= SEQUENCE OF IntegrityAlg - - -- Confidentiality Algorithms, ordered by decreasing preference - ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg - - -- Integrity Algorithms - IntegrityAlg ::= SEQUENCE { - algorithm IntegrityAlgType, - parameters ANY -- DEFINED BY algorithm -- OPTIONAL } - - IntegrityAlgType ::= INTEGER { - none (0), - auth-HMAC-MD5-96 (1), - auth-HMAC-SHA1-96 (2), - auth-DES-MAC (3), - auth-KPDK-MD5 (4), - auth-AES-XCBC-96 (5) - -- tbd (6..65535) - } - - -- Confidentiality Algorithms - - -Kent & Seo [Page 82] - -Internet Draft Security Architecture for IP March 2005 - - - ConfidentialityAlg ::= SEQUENCE { - algorithm ConfidentialityAlgType, - parameters ANY -- DEFINED BY algorithm -- OPTIONAL } - - ConfidentialityAlgType ::= INTEGER { - encr-DES-IV64 (1), - encr-DES (2), - encr-3DES (3), - encr-RC5 (4), - encr-IDEA (5), - encr-CAST (6), - encr-BLOWFISH (7), - encr-3IDEA (8), - encr-DES-IV32 (9), - encr-RC4 (10), - encr-NULL (11), - encr-AES-CBC (12), - encr-AES-CTR (13) - -- tbd (14..65535) - } - - CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg - - CombinedModeAlg ::= SEQUENCE { - algorithm CombinedModeType, - parameters ANY -- DEFINED BY algorithm} -- defined outside - -- of this document for AES modes. - - CombinedModeType ::= INTEGER { - comb-AES-CCM (1), - comb-AES-GCM (2) - -- tbd (3..65535) - } - - TunnelOptions ::= SEQUENCE { - dscp DSCP, - ecn BOOLEAN, -- TRUE Copy CE to inner header - df DF, - addresses TunnelAddresses } - - TunnelAddresses ::= CHOICE { - ipv4 IPv4Pair, - ipv6 [0] IPv6Pair } - - IPv4Pair ::= SEQUENCE { - local OCTET STRING (SIZE(4)), - remote OCTET STRING (SIZE(4)) } - - IPv6Pair ::= SEQUENCE { - - -Kent & Seo [Page 83] - -Internet Draft Security Architecture for IP March 2005 - - - local OCTET STRING (SIZE(16)), - remote OCTET STRING (SIZE(16)) } - - DSCP ::= SEQUENCE { - copy BOOLEAN, -- TRUE copy from inner header - -- FALSE do not copy - mapping OCTET STRING OPTIONAL} -- points to table - -- if no copy - - DF ::= INTEGER { - clear (0), - set (1), - copy (2) } - - ProtocolChoice::= CHOICE { - anyProt AnyProtocol, -- for ANY protocol - noNext [0] NoNextLayerProtocol, -- has no next layer - -- items - oneNext [1] OneNextLayerProtocol, -- has one next layer - -- item - twoNext [2] TwoNextLayerProtocol, -- has two next layer - -- items - fragment FragmentNoNext } -- has no next layer - -- info - - AnyProtocol ::= SEQUENCE { - id INTEGER (0), -- ANY protocol - nextLayer AnyNextLayers } - - AnyNextLayers ::= SEQUENCE { -- with either - first AnyNextLayer, -- ANY next layer selector - second AnyNextLayer } -- ANY next layer selector - - NoNextLayerProtocol ::= INTEGER (2..254) - - FragmentNoNext ::= INTEGER (44) -- Fragment identifier - - OneNextLayerProtocol ::= SEQUENCE { - id INTEGER (1..254), -- ICMP, MH, ICMPv6 - nextLayer NextLayerChoice } -- ICMP Type*256+Code - -- MH Type*256 - - TwoNextLayerProtocol ::= SEQUENCE { - id INTEGER (2..254), -- Protocol - local NextLayerChoice, -- Local and - remote NextLayerChoice } -- Remote ports - - NextLayerChoice ::= CHOICE { - any AnyNextLayer, - - -Kent & Seo [Page 84] - -Internet Draft Security Architecture for IP March 2005 - - - opaque [0] OpaqueNextLayer, - range [1] NextLayerRange } - - -- Representation of ANY in next layer field - AnyNextLayer ::= SEQUENCE { - start INTEGER (0), - end INTEGER (65535) } - - -- Representation of OPAQUE in next layer field. - -- Matches IKE convention - OpaqueNextLayer ::= SEQUENCE { - start INTEGER (65535), - end INTEGER (0) } - - -- Range for a next layer field - NextLayerRange ::= SEQUENCE { - start INTEGER (0..65535), - end INTEGER (0..65535) } - - -- List of IP addresses - AddrList ::= SEQUENCE { - v4List IPv4List OPTIONAL, - v6List [0] IPv6List OPTIONAL } - - -- IPv4 address representations - IPv4List ::= SEQUENCE OF IPv4Range - - IPv4Range ::= SEQUENCE { -- close, but not quite right ... - ipv4Start OCTET STRING (SIZE (4)), - ipv4End OCTET STRING (SIZE (4)) } - - -- IPv6 address representations - IPv6List ::= SEQUENCE OF IPv6Range - - IPv6Range ::= SEQUENCE { -- close, but not quite right ... - ipv6Start OCTET STRING (SIZE (16)), - ipv6End OCTET STRING (SIZE (16)) } - - - END - - - - - - - - - - - -Kent & Seo [Page 85] - -Internet Draft Security Architecture for IP March 2005 - - -Appendix D -- Fragment Handling Rationale - - There are three issues that must be resolved re processing of - (plaintext) fragments in IPsec: - - - mapping a non-initial, outbound fragment to the right SA - (or finding the right SPD entry) - - verifying that a received, non-initial fragment is authorized - for the SA via which it is received - - mapping outbound and inbound non-initial fragments to the - right SPD/cache entry, for BYPASS/DISCARD traffic. - - The first and third issues arise because we need a deterministic - algorithm for mapping traffic to SAs (and SPD/cache entries). All - three issues are important because we want to make sure that - non-initial fragments that cross the IPsec boundary do not cause the - access control policies in place at the receiver (or transmitter) to - be violated. - -D.1 Transport Mode and Fragments - - First, we note that transport mode SAs have been defined to not carry - fragments. This is a carryover from RFC 2401, where transport mode - SAs always terminated at end points. This is a fundamental - requirement because, in the worst case, an IPv4 fragment to which - IPsec was applied, might then be fragmented (as a ciphertext packet), - en route to the destination. IP fragment reassembly procedures at the - IPsec receiver would not be able to distinguish between pre-IPsec - fragments and fragments created after IPsec processing. - - For IPv6, only the sender is allowed to fragment a packet. As for - IPv4, an IPsec implementation is allowed to fragment tunnel mode - packets after IPsec processing, because it is the sender relative to - the (outer) tunnel header. However, unlike IPv4, it would be feasible - to carry a plaintext fragment on a transport mode SA, because the - fragment header in IPv6 would appear after the AH or ESP header, and - thus would not cause confusion at the receiver re reassembly. - Specifically, the receiver would not attempt reassembly for the - fragment until after IPsec processing. To keep things simple, this - specification prohibits carriage of fragments on transport mode SAs - for IPv6 traffic. - - When only end systems used transport mode SAs, the prohibition on - carriage of fragments was not a problem, since we assumed that the - end system could be configured to not offer a fragment to IPsec. For - a native host implementation this seems reasonable, and, as someone - already noted, RFC 2401 warned that a BITS implementation might have - to reassemble fragments before performing an SA lookup. (It would - then apply AH or ESP and could re-fragment the packet after IPsec - - -Kent & Seo [Page 86] - -Internet Draft Security Architecture for IP March 2005 - - - processing.) Because a BITS implementation is assumed to be able to - have access to all traffic emanating from its host, even if the host - has multiple interfaces, this was deemed a reasonable mandate. - - In this specification, it is acceptable to use transport mode in - cases where the IPsec implementation is not the ultimate destination, - e.g., between two SGs. In principle, this creates a new opportunity - for outbound, plaintext fragments to be mapped to a transport mode SA - for IPsec processing. However, in these new contexts in which a - transport mode SA is now approved for use, it seems likely that we - can continue to prohibit transmission of fragments, as seen by IPsec, - i.e., packets that have an "outer header" with a non-zero fragment - offset field. For example, in an IP overlay network, packets being - sent over transport mode SAs are IP-in-IP tunneled and thus have the - necessary inner header to accommodate fragmentation prior to IPsec - processing. When carried via a transport mode SA, IPsec would not - examine the inner IP header for such traffic, and thus would not - consider the packet to be a fragment. - -D.2 Tunnel Mode and Fragments - - For tunnel mode SAs, it has always been the case that outbound - fragments might arrive for processing at an IPsec implementation. The - need to accommodate fragmented outbound packets can pose a problem - because a non-initial fragment generally will not contain the port - fields associated with a next layer protocol such as TCP, UDP, or - SCTP. Thus, depending on the SPD configuration for a given IPsec - implementation, plaintext fragments might or might not pose a - problem. - - For example, if the SPD requires that all traffic between two address - ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries - apply to this address range), then it should be easy to carry - non-initial fragments on the SA defined for this address range, since - the SPD entry implies an intent to carry ALL traffic between the - address ranges. But, if there are multiple SPD entries that could - match a fragment, and if these entries reference different subsets of - port fields (vs. ANY), then it is not possible to map an outbound - non-initial fragment to the right entry, unambiguously. (If we choose - to allow carriage of fragments on transport mode SAs for IPv6, the - problems arises in that context as well.) - - This problem largely, though not exclusively, motivated the - definition of OPAQUE as a selector value for port fields in RFC 2401. - The other motivation for OPAQUE is the observation that port fields - might not be accessible due to the prior application of IPsec. For - example, if a host applied IPsec to its traffic and that traffic - arrived at an SG, these fields would be encrypted. The algorithm - specified for locating the "next layer protocol" described in RFC - - -Kent & Seo [Page 87] - -Internet Draft Security Architecture for IP March 2005 - - - 2401 also motivated use of OPAQUE to accommodate an encrypted next - layer protocol field in such circumstances. Nonetheless, the primary - use of the OPAQUE value was to match traffic selector fields in - packets that did not contain port fields (non-initial fragments), or - packets in which the port fields were already encrypted (as a result - of nested application of IPsec). RFC 2401 was ambiguous in discussing - the use of OPAQUE vs. ANY, suggesting in some places that ANY might - be an alternative to OPAQUE. - - We gain additional access control capability by defining both ANY and - OPAQUE values. OPAQUE can be defined to match only fields that are - not accessible. We could define ANY as the complement of OPAQUE, - i.e., it would match all values but only for accessible port fields. - We have therefore simplified the procedure employed to locate the - next layer protocol in this document, so that we treat ESP and AH as - next layer protocols. As a result, the notion of an encrypted next - layer protocol field has vanished, and there is also no need to worry - about encrypted port fields either. And accordingly, OPAQUE will be - applicable only to non-initial fragments. - - Since we have adopted the definitions above for ANY and OPAQUE, we - need to clarify how these values work when the specified protocol - does not have port fields, and when ANY is used for the protocol - selector. Accordingly, if a specific protocol value is used as a - selector, and if that protocol has no port fields, then the port - field selectors are to be ignored and ANY MUST be specified as the - value for the port fields. (In this context, ICMP TYPE and CODE - values are lumped together as a single port field (for IKE v2 - negotiation), as is the IPv6 Mobility Header TYPE value.) If the - protocol selector is ANY, then this should be treated as equivalent - to specifying a protocol for which no port fields are defined, and - thus the port selectors should be ignored, and MUST be set to ANY. - -D.3. The Problem of Non-Initial Fragments - - For an SG implementation, it is obvious that fragments might arrive - from end systems behind the SG. A BITW implementation also may - encounter fragments from a host or gateway behind it. (As noted - earlier, native host implementations and BITS implementations - probably can avoid the problems described below.) In the worst case, - fragments from a packet might arrive at distinct BITW or SG - instantiations and thus preclude reassembly as a solution option. - Hence, in RFC 2401 we adopted a general requirement that fragments - must be accommodated in tunnel mode for all implementations. However, - RFC 2401 did not provide a perfect solution. The use of OPAQUE as a - selector value for port fields (a SHOULD in RFC 2401) allowed an SA - to carry non-initial fragments. - - Using the features defined in RFC 2401, if one defined an SA between - - -Kent & Seo [Page 88] - -Internet Draft Security Architecture for IP March 2005 - - - two IPsec (SG or BITW) implementations using the OPAQUE value for - both port fields, then all non-initial fragments matching the S/D - address and protocol values for the SA would be mapped to that SA. - Initial fragments would NOT map to this SA, if we adopt a strict - definition of OPAQUE. However, RFC 2401 did not provide detailed - guidance on this and thus it may not have been apparent that use of - this feature would essentially create a "non-initial fragment only" - SA. - - In the course of discussing the "fragment-only" SA approach, it was - noted that some subtle problems, problems not considered in RFC 2401, - would have to be avoided. For example, an SA of this sort must be - configured to offer the "highest quality" security services for any - traffic between the indicated S/D addresses (for the specified - protocol). This is necessary to ensure that any traffic captured by - the fragment-only SA is not offered degraded security relative to - what it would have been offered if the packet were not fragmented. A - possible problem here is that we may not be able to identify the - "highest quality" security services defined for use between two IPsec - implementation, since the choice of security protocols, options, and - algorithms is a lattice, not a totally ordered set. (We might safely - say that BYPASS < AH < ESP w/integrity, but it gets complicated if we - have multiple ESP encryption or integrity algorithm options.) So, one - has to impose a total ordering on these security parameters to make - this work, but this can be done locally. - - However, this conservative strategy has a possible performance down - side; if most traffic traversing an IPsec implementation for a given - S/D address pair (and specified protocol) is bypassed, then a - fragment-only SA for that address pair might cause a dramatic - increase in the volume of traffic afforded crypto processing. If the - crypto implementation cannot support high traffic rates, this could - cause problems. (An IPsec implementation that is capable of line rate - or near line rate crypto performance would not be adversely affected - by this SA configuration approach. Nonetheless, the performance - impact is a potential concern, specific to implementation - capabilities.) - - Another concern is that non-initial fragments sent over a dedicated - SA might be used to effect overlapping reassembly attacks, when - combined with an apparently acceptable initial fragment. (This sort - of attack assumes creation of bogus fragments, and is not a side - effect of normal fragmentation.) This concern is easily addressed in - IPv4, by checking the fragment offset value to ensure that no - non-initial fragments have a small enough offset to overlap port - fields that should be contained in the initial fragment. Recall that - the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 - bytes, so any ports should be present in the initial fragment. If we - require all non-initial fragments to have an offset of say 128 or - - -Kent & Seo [Page 89] - -Internet Draft Security Architecture for IP March 2005 - - - greater, just to be on the safe side, this should prevent successful - attacks of this sort. If the intent is only to protect against this - sort of reassembly attack, this check need be implemented only by a - receiver. - - IPv6 also has a fragment offset, carried in the fragmentation - extension header. However, IPv6 extension headers are variable in - length and there is no analogous max header length value that we can - use to check non-initial fragments, to reject ones that might be used - for an attack of the sort noted above. A receiver would need to - maintain state analogous to reassembly state, to provide equivalent - protection. So, only for IPv4 it is feasible to impose a fragment - offset check that would reject attacks designed to circumvent port - field checks by IPsec (or firewalls) when passing non-initial - fragments. - - Another possible concern is that in some topologies and SPD - configurations this approach might result in an access control - surprise. The notion is that if we create an SA to carry ALL - (non-initial) fragments then that SA would carry some traffic that - might otherwise arrive as plaintext via a separate path, e.g., a path - monitored by a proxy firewall. But, this concern arises only if the - other path allows initial fragments to traverse it without requiring - reassembly, presumably a bad idea for a proxy firewall. Nonetheless, - this does represent a potential problem in some topologies and under - certain assumptions re: SPD and (other) firewall rule sets, and - administrators need to be warned of this possibility. - - A less serious concern is that non-initial fragments sent over a - non-initial fragment-only SA might represent a DoS opportunity, in - that they could be sent when no valid, initial fragment will ever - arrive. This might be used to attack hosts behind an SG or BITW - device. However, the incremental risk posed by this sort of attack, - which can be mounted only by hosts behind an SG or BITW device, seems - small. - - If we interpret the ANY selector value as encompassing OPAQUE, then a - single SA with ANY values for both port fields would be able to - accommodate all traffic matching the S/D address and protocol traffic - selectors, an alternative to using the OPAQUE value. But, using ANY - here precludes multiple, distinct SAs between the same IPsec - implementations for the same address pairs and protocol. So, it is - not an exactly equivalent alternative. - - Fundamentally, fragment handling problems arise only when more than - one SA is defined with the same S/D address and protocol selector - values, but with different port field selector values. - - - - -Kent & Seo [Page 90] - -Internet Draft Security Architecture for IP March 2005 - - -D.4 BYPASS/DISCARD Traffic - - We also have to address the non-initial fragment processing issue for - BYPASS/DISCARD entries, independent of SA processing. This is largely - a local matter for two reasons: - 1) We have no means for coordinating SPD entries for such - traffic between IPsec implementations since IKE is not - invoked. - 2) Many of these entries refer to traffic that is NOT - directed to or received from a location that is using - IPsec. So there is no peer IPsec implementation with - which to coordinate via any means. - - However, this document should provide guidance here, consistent with - our goal of offering a well-defined, access control function for all - traffic, relative to the IPsec boundary. To that end, this document - says that implementations MUST support fragment reassembly for - BYPASS/DISCARD traffic when port fields are specified. An - implementation also MUST permit a user or administrator to accept - such traffic or reject such traffic using the SPD conventions - described in Secion 4.4.1. The concern is that BYPASS of a - cleartext, non-initial fragment arriving at an IPsec implementation - could undermine the security afforded IPsec-protected traffic - directed to the same destination. For example, consider an IPsec - implementation configured with an SPD entry that calls for - IPsec-protection of traffic between a specific source/destination - address pair, and for a specific protocol and destination port, e.g., - TCP traffic on port 23 (Telnet). Assume that the implementation also - allows BYPASS of traffic from the same source/destination address - pair and protocol, but for a different destination port, e.g., port - 119 (NNTP). An attacker could send a non-initial fragment (with a - forged source address) that, if bypassed, could overlap with - IPsec-protected traffic from the same source and thus violate the - integrity of the IPsec-protected traffic. Requiring stateful fragment - checking for BYPASS entries with non-trivial port ranges prevents - attacks of this sort. - -D.5 Just say no to ports? - - It has been suggested that we could avoid the problems described - above by not allowing port field selectors to be used in tunnel mode. - But the discussion above shows this to be an unnecessarily stringent - approach, i.e., since no problems arise for the native OS and BITS - implementations. Moreover, some WG members have described scenarios - where use of tunnel mode SAs with (non-trivial) port field selectors - is appropriate. So the challenge is defining a strategy that can deal - with this problem in BITW and SG contexts. Also note that - BYPASS/DISCARD entries in the SPD that make use of ports pose the - same problems, irrespective of tunnel vs. transport mode notions. - - -Kent & Seo [Page 91] - -Internet Draft Security Architecture for IP March 2005 - - - Some folks have suggested that a firewall behind an SG or BITW should - be left to enforce port level access controls, and the effects of - fragmentation. However, this seems to be an incongruous suggestion in - that elsewhere in IPsec (e.g., in IKE payloads) we are concerned - about firewalls that always discard fragments. If many firewalls - don't pass fragments in general, why should we expect them to deal - with fragments in this case? So, this analysis rejects the suggestion - of disallowing use of port field selectors with tunnel mode SAs. - -D.6 Other Suggested Solutions - - One suggestion is to reassemble fragments at the sending IPsec - implementation, and thus avoid the problem entirely. This approach is - invisible to a receiver and thus could be adopted as a purely local - implementation option. - - A more sophisticated version of this suggestion calls for - establishing and maintaining minimal state from each initial fragment - encountered, to allow non-initial fragments to be matched to the - right SAs or SPD/cache entries. This implies an extension to the - current processing model (and the old one). The IPsec implementation - would intercept all fragments, capture Source/Destination IP - addresses, protocol, packet ID, and port fields from initial - fragments and then use this data to map non-initial fragments to SAs - that require port fields. If this approach is employed, the receiver - needs to employ an equivalent scheme, as it too must verify that - received fragments are consistent with SA selector values. A - non-initial fragment that arrives prior to an initial fragment could - be cached or discarded, awaiting arrival of the corresponding initial - fragment. - - A downside of both approaches noted above is that they will not - always work. When a BITW device or SG is configured in a topology - that might allow some fragments for a packet to be processed at - different SGs or BITW devices, then there is no guarantee that all - fragments will ever arrive at the same IPsec device. This approach - also raises possible processing problems. If the sender caches - non-initial fragments until the corresponding initial fragment - arrives, buffering problems might arise, especially at high speeds. - If the non-initial fragments are discarded rather than cached, there - is no guarantee that traffic will ever pass, e.g., retransmission - will result in different packet IDs that cannot be matched with prior - transmissions. In any case, housekeeping procedures will be needed to - decide when to delete the fragment state data, adding some complexity - to the system. Nonetheless, this is a viable solution in some - topologies, and these are likely to be common topologies. - - The Working Group rejected an earlier version of the convention of - creating an SA to carry only non-initial fragments, something that - - -Kent & Seo [Page 92] - -Internet Draft Security Architecture for IP March 2005 - - - was supported implicitly under the RFC 2401 model via use of OPAQUE - port fields, but never clearly articulated in RFC 2401. The - (rejected) text called for each non-initial fragment to be treated as - protocol 44 (the IPv6 fragment header protocol ID) by the sender and - receiver. This approach has the potential to make IPv4 and IPv6 - fragment handling more uniform, but it does not fundamentally change - the problem, nor does it address the issue of fragment handling for - BYPASS/DISCARD traffic. Given the fragment overlap attack problem - that IPv6 poses, it does not seem that it is worth the effort to - adopt this strategy. - -D.7 Consistency - - Earlier the WG agreed to allow an IPsec BITS, BITW or SG to perform - fragmentation prior to IPsec processing. If this fragmentation is - performed after SA lookup at the sender, there is no "mapping to the - right SA" problem. But, the receiver still needs to be able to verify - that the non-initial fragments are consistent with the SA via which - they are received. Since the initial fragment might be lost en route, - the receiver encounters all of the potential problems noted above. - Thus, if we are to be consistent in our decisions, we need to say how - a receiver will deal with the non-initial fragments that arrive. - -D.8 Conclusions - - There is no simple, uniform way to handle fragments in all contexts. - Different approaches work better in different contexts. Thus this - document offers 3 choices -- one MUST and two MAYs. At some point in - the future, if the community gains experience with the two MAYs, they - may become SHOULDs or MUSTs or other approaches may be proposed. - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 93] - -Internet Draft Security Architecture for IP March 2005 - - -Appendix E - Example of Supporting Nested SAs via SPD and Forwarding -Table Entries - - This appendix provides an example of how to configure the SPD and - forwarding tables to support a nested pair of SAs, consistent with - the new processing model. For simplicity, this example assumes just - one SPD-I. - - The goal in this example is to support a transport mode SA from A to - C, carried over a tunnel mode SA from A to B. For example, A might be - a laptop connected to the public internet, B a firewall that protects - a corporate network, and C a server on the corporate network that - demands end-to-end authentication of A's traffic. - - +---+ +---+ +---+ - | A |=====| B | | C | - | |------------| | - | |=====| | | | - +---+ +---+ +---+ - - A's SPD contains entries of the form: - - Next Layer - Rule Local Remote Protocol Action - ---- ----- ------ ---------- ----------------------- - 1 C A ESP BYPASS - 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) - 3 A C ANY PROTECT(ESP,transport,integr-only) - 4 A B ICMP,IKE BYPASS - - A's unprotected-side forwarding table is set so that outbound packets - destined for C are looped back to the protected side. A's protected - side forwarding table is set so that inbound ESP packets are looped - back to the unprotected side. A's forwarding tables contain entries - of the form: - - Unprotected-side forwarding table - - Rule Local Remote Protocol Action - ---- ----- ------ -------- --------------------------- - 1 A C ANY loop back to protected side - 2 A B ANY forward to B - - Protected-side forwarding table - - Rule Local Remote Protocol Action - ---- ----- ------ -------- ----------------------------- - 1 A C ESP loop back to unprotected side - - - -Kent & Seo [Page 94] - -Internet Draft Security Architecture for IP March 2005 - - - An outbound TCP packet from A to C would match SPD rule 3 and have - transport mode ESP applied to it. The unprotected-side forwarding - table would then loop back the packet. The packet is compared against - SPD-I (see Figure 2), matches SPD rule 1, and so it is BYPASSed. The - packet is treated as an outbound packet and compared against the SPD - for a third time. This time it matches SPD rule 2, so ESP is applied - in tunnel mode. This time the forwarding table doesn't loop back the - packet, because the outer destination address is B, so the packet - goes out onto the wire. - - An inbound TCP packet from C to A, is wrapped in two ESP headers; the - outer header (ESP in tunnel mode) shows B as the source whereas the - inner header (ESP transport mode) shows C as the source. Upon arrival - at A, the packet would be mapped to an SA based on the SPI, have the - outer header removed, and be decrypted and integrity-checked. Then it - would be matched against the SAD selectors for this SA, which would - specify C as the source and A as the destination, derived from SPD - rule 2. The protected-side forwarding function would then send it - back to the unprotected side based on the addresses and the next - layer protocol (ESP), indicative of nesting. It is compared against - SPD-O (see figure 3) and found to match SPD rule 1, so it is - BYPASSed. The packet is mapped to an SA based on the SPI, - integrity-checked, and compared against the SAD selectors derived - from SPD rule 3. The forwarding function then passes it up to the - next layer, because it isn't an ESP packet. - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 95] - -Internet Draft Security Architecture for IP March 2005 - - -References - - -Normative - - [BBCDWW98]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., - and W. Weiss, "An Architecture for Differentiated Service", - RFC 2475, December 1998. - - [Bra97] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Level", BCP 14, RFC 2119, March 1997. - - [CD98] Conta, A. and S. Deering, "Internet Control Message - Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. - - [DH98] Deering, S., and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - - [Eas05] Eastlake, D., "Cryptographic Algorithm Implementation - Requirements For ESP And AH", ???, ???? 200?. - - [RFC Editor: Please update reference [Eas05] "Cryptographic - Algorithm Implementation Requirements For ESP And AH" - (draft-ietf-ipsec-esp-ah-algorithms-02.txt) with the RFC - number and month and year when it is issued.] - - [HarCar98]Harkins, D., and Carrel, D., "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [Kau05] Kaufman, C., "The Internet Key Exchange (IKEv2) Protocol", - RFC ???, ???? 200?. - - [RFC Editor: Please update the reference [Kau05] "The - Internet Key Exchange (IKEv2) Protocol" - (draft-ietf-ipsec-ikev2-17.txt) with the RFC number and - month and year when it is issued.] - - [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - ???, ???? 200?. - - [RFC Editor: Please update the reference [Ken05a] "IP - Encapsulating Security Payload (ESP)" - (draft-ietf-ipsec-esp-v3-09.txt) with the RFC number and - month and year when it is issued.] - - [Ken05b] Kent, S., "IP Authentication Header", RFC ???, ??? 200?. - - [RFC Editor: Please update the reference [Ken05b] "IP - - -Kent & Seo [Page 96] - -Internet Draft Security Architecture for IP March 2005 - - - Authentication Header" (draft-ietf-ipsec-rfc2402bis-09.txt) - with the RFC number and month and year when it is issued.] - - [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, - November 1990. - - [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, September - 1981 - - [Pos81b] Postel, J., "Internet Control Message Protocol", RFC 792, - September 1981 - - [Sch05] Schiller, J., "Cryptographic Algorithms for use in the - Internet Key Exchange Version 2", RFC ???, ???? 200? - - [RFC Editor: Please update the reference [Sch05] - "Cryptographic Algorithms for use in the Internet Key - Exchange Version 2" - (draft-ietf-ipsec-ikev2-algorithms-05.txt) with the RFC - number and month and year when it is issued.] - - [WaKiHo97]Wahl, M., Kille, S., Howes, T., "Lightweight Directory - Access Protocol (v3): UTF-8 String Representation of - Distinguished Names", RFC 2253, December 1997 - -Informative - - [CoSa04] Condell, M., and Sanchez, L. On the Deterministic - Enforcement of Un-ordered Security Policies", BBN Technical - Memo 1346, March 2004 - - [FaLiHaMeTr00]Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, - P., "Generic Routing Encapsulation (GRE), RFC 2784, March - 2000. - - [Gro02] Grossman, D., "New Terminology and Clarifications for - Diffserv", RFC 3260, April 2002. - [HC03] Holbrook, H., and Cain, B., "Source Specific Multicast for - IP", WWork in Progress, November 3, 2002. - - [HA94] Haller, N., and Atkinson, R., "On Internet Authentication", - RFC 1704, October 1994 - - [Mobip] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in - IPv6", RFC 3775, June 2004 - - [NiBlBaBL98]Nichols, K., Blake, S., Baker, F., Black, D., "Definition - of the Differentiated Services Field (DS Field) in the IPv4 - and IPv6 Headers", RFC2474, December 1998. - - -Kent & Seo [Page 97] - -Internet Draft Security Architecture for IP March 2005 - - - [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - - [RaFlBl01]Ramakrishnan, K., Floyd, S., Black, D., "The Addition of - Explicit Congestion Notification (ECN) to IP", RFC 3168, - September 2001. - - [RFC3547] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The Group - Domain of Interpretation", RFC 3547, July 2003. - - [RFC3740] Hardjono, T., Weis, B., "The Multicast Group Security - Architecture", RFC 3740, March 2004. - - [RaCoCaDe04]Rajahalme, J., Conta, A., Carpenter, B., Deering, S., - "IPv6 Flow Label Specification, RFC 3697, March 2004. - - [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John - Wiley & Sons, New York, NY, 1994. - - [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, May - 2000. - - [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP - Payload Compression Protocol (IPComp)", RFC 3173, September - 2001. - - [ToEgWa04]Touch, J., Eggert, L., Wang, Y., Use of IPsec Transport - Mode for Dynamic Routing, RFC 3884, September 2004. - - [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in - High-level Networks", ACM Computing Surveys, Vol. 15, No. - 2, June 1983. - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 98] - -Internet Draft Security Architecture for IP March 2005 - - -Author Information - - Stephen Kent - BBN Technologies - 10 Moulton Street - Cambridge, MA 02138 - USA - Phone: +1 (617) 873-3988 - EMail: kent@bbn.com - - Karen Seo - BBN Technologies - 10 Moulton Street - Cambridge, MA 02138 - USA - Phone: +1 (617) 873-3152 - EMail: kseo@bbn.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 99] - -Internet Draft Security Architecture for IP March 2005 - - -Notices - - - 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. - - Full Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation may be prepared, copied, published and - distributed, in whole or in part, without restriction of any kind, - provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. The limited permissions granted above are perpetual and - will not be revoked by the Internet Society or its successors or - assigns. - - - -Kent & Seo [Page 100] - -Internet Draft Security Architecture for IP March 2005 - - - 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. - - - - -Expires September 2005 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo [Page 101] diff --git a/doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf b/doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf Binary files differdeleted file mode 100644 index a467aea78..000000000 --- a/doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf +++ /dev/null diff --git a/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt b/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt deleted file mode 100644 index 1fb8fe11a..000000000 --- a/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group H. Krawczyk -Request for Comments: 2104 IBM -Category: Informational M. Bellare - UCSD - R. Canetti - IBM - February 1997 - - - HMAC: Keyed-Hashing for Message Authentication - -Status of This Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -Abstract - - This document describes HMAC, a mechanism for message authentication - using cryptographic hash functions. HMAC can be used with any - iterative cryptographic hash function, e.g., MD5, SHA-1, in - combination with a secret shared key. The cryptographic strength of - HMAC depends on the properties of the underlying hash function. - -1. Introduction - - Providing a way to check the integrity of information transmitted - over or stored in an unreliable medium is a prime necessity in the - world of open computing and communications. Mechanisms that provide - such integrity check based on a secret key are usually called - "message authentication codes" (MAC). Typically, message - authentication codes are used between two parties that share a secret - key in order to validate information transmitted between these - parties. In this document we present such a MAC mechanism based on - cryptographic hash functions. This mechanism, called HMAC, is based - on work by the authors [BCK1] where the construction is presented and - cryptographically analyzed. We refer to that work for the details on - the rationale and security analysis of HMAC, and its comparison to - other keyed-hash methods. - - - - - - - - - - - -Krawczyk, et. al. Informational [Page 1] - -RFC 2104 HMAC February 1997 - - - HMAC can be used in combination with any iterated cryptographic hash - function. MD5 and SHA-1 are examples of such hash functions. HMAC - also uses a secret key for calculation and verification of the - message authentication values. The main goals behind this - construction are - - * To use, without modifications, available hash functions. - In particular, hash functions that perform well in software, - and for which code is freely and widely available. - - * To preserve the original performance of the hash function without - incurring a significant degradation. - - * To use and handle keys in a simple way. - - * To have a well understood cryptographic analysis of the strength of - the authentication mechanism based on reasonable assumptions on the - underlying hash function. - - * To allow for easy replaceability of the underlying hash function in - case that faster or more secure hash functions are found or - required. - - This document specifies HMAC using a generic cryptographic hash - function (denoted by H). Specific instantiations of HMAC need to - define a particular hash function. Current candidates for such hash - functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD]. - These different realizations of HMAC will be denoted by HMAC-SHA1, - HMAC-MD5, HMAC-RIPEMD, etc. - - Note: To the date of writing of this document MD5 and SHA-1 are the - most widely used cryptographic hash functions. MD5 has been recently - shown to be vulnerable to collision search attacks [Dobb]. This - attack and other currently known weaknesses of MD5 do not compromise - the use of MD5 within HMAC as specified in this document (see - [Dobb]); however, SHA-1 appears to be a cryptographically stronger - function. To this date, MD5 can be considered for use in HMAC for - applications where the superior performance of MD5 is critical. In - any case, implementers and users need to be aware of possible - cryptanalytic developments regarding any of these cryptographic hash - functions, and the eventual need to replace the underlying hash - function. (See section 6 for more information on the security of - HMAC.) - - - - - - - - -Krawczyk, et. al. Informational [Page 2] - -RFC 2104 HMAC February 1997 - - -2. Definition of HMAC - - The definition of HMAC requires a cryptographic hash function, which - we denote by H, and a secret key K. We assume H to be a cryptographic - hash function where data is hashed by iterating a basic compression - function on blocks of data. We denote by B the byte-length of such - blocks (B=64 for all the above mentioned examples of hash functions), - and by L the byte-length of hash outputs (L=16 for MD5, L=20 for - SHA-1). The authentication key K can be of any length up to B, the - block length of the hash function. Applications that use keys longer - than B bytes will first hash the key using H and then use the - resultant L byte string as the actual key to HMAC. In any case the - minimal recommended length for K is L bytes (as the hash output - length). See section 3 for more information on keys. - - We define two fixed and different strings ipad and opad as follows - (the 'i' and 'o' are mnemonics for inner and outer): - - ipad = the byte 0x36 repeated B times - opad = the byte 0x5C repeated B times. - - To compute HMAC over the data `text' we perform - - H(K XOR opad, H(K XOR ipad, text)) - - Namely, - - (1) append zeros to the end of K to create a B byte string - (e.g., if K is of length 20 bytes and B=64, then K will be - appended with 44 zero bytes 0x00) - (2) XOR (bitwise exclusive-OR) the B byte string computed in step - (1) with ipad - (3) append the stream of data 'text' to the B byte string resulting - from step (2) - (4) apply H to the stream generated in step (3) - (5) XOR (bitwise exclusive-OR) the B byte string computed in - step (1) with opad - (6) append the H result from step (4) to the B byte string - resulting from step (5) - (7) apply H to the stream generated in step (6) and output - the result - - For illustration purposes, sample code based on MD5 is provided as an - appendix. - - - - - - - -Krawczyk, et. al. Informational [Page 3] - -RFC 2104 HMAC February 1997 - - -3. Keys - - The key for HMAC can be of any length (keys longer than B bytes are - first hashed using H). However, less than L bytes is strongly - discouraged as it would decrease the security strength of the - function. Keys longer than L bytes are acceptable but the extra - length would not significantly increase the function strength. (A - longer key may be advisable if the randomness of the key is - considered weak.) - - Keys need to be chosen at random (or using a cryptographically strong - pseudo-random generator seeded with a random seed), and periodically - refreshed. (Current attacks do not indicate a specific recommended - frequency for key changes as these attacks are practically - infeasible. However, periodic key refreshment is a fundamental - security practice that helps against potential weaknesses of the - function and keys, and limits the damage of an exposed key.) - -4. Implementation Note - - HMAC is defined in such a way that the underlying hash function H can - be used with no modification to its code. In particular, it uses the - function H with the pre-defined initial value IV (a fixed value - specified by each iterative hash function to initialize its - compression function). However, if desired, a performance - improvement can be achieved at the cost of (possibly) modifying the - code of H to support variable IVs. - - The idea is that the intermediate results of the compression function - on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed - only once at the time of generation of the key K, or before its first - use. These intermediate results are stored and then used to - initialize the IV of H each time that a message needs to be - authenticated. This method saves, for each authenticated message, - the application of the compression function of H on two B-byte blocks - (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be - significant when authenticating short streams of data. We stress - that the stored intermediate values need to be treated and protected - the same as secret keys. - - Choosing to implement HMAC in the above way is a decision of the - local implementation and has no effect on inter-operability. - - - - - - - - - -Krawczyk, et. al. Informational [Page 4] - -RFC 2104 HMAC February 1997 - - -5. Truncated output - - A well-known practice with message authentication codes is to - truncate the output of the MAC and output only part of the bits - (e.g., [MM, ANSI]). Preneel and van Oorschot [PV] show some - analytical advantages of truncating the output of hash-based MAC - functions. The results in this area are not absolute as for the - overall security advantages of truncation. It has advantages (less - information on the hash result available to an attacker) and - disadvantages (less bits to predict for the attacker). Applications - of HMAC can choose to truncate the output of HMAC by outputting the t - leftmost bits of the HMAC computation for some parameter t (namely, - the computation is carried in the normal way as defined in section 2 - above but the end result is truncated to t bits). We recommend that - the output length t be not less than half the length of the hash - output (to match the birthday attack bound) and not less than 80 bits - (a suitable lower bound on the number of bits that need to be - predicted by an attacker). We propose denoting a realization of HMAC - that uses a hash function H with t bits of output as HMAC-H-t. For - example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function - and with the output truncated to 80 bits. (If the parameter t is not - specified, e.g. HMAC-MD5, then it is assumed that all the bits of the - hash are output.) - -6. Security - - The security of the message authentication mechanism presented here - depends on cryptographic properties of the hash function H: the - resistance to collision finding (limited to the case where the - initial value is secret and random, and where the output of the - function is not explicitly available to the attacker), and the - message authentication property of the compression function of H when - applied to single blocks (in HMAC these blocks are partially unknown - to an attacker as they contain the result of the inner H computation - and, in particular, cannot be fully chosen by the attacker). - - These properties, and actually stronger ones, are commonly assumed - for hash functions of the kind used with HMAC. In particular, a hash - function for which the above properties do not hold would become - unsuitable for most (probably, all) cryptographic applications, - including alternative message authentication schemes based on such - functions. (For a complete analysis and rationale of the HMAC - function the reader is referred to [BCK1].) - - - - - - - - -Krawczyk, et. al. Informational [Page 5] - -RFC 2104 HMAC February 1997 - - - Given the limited confidence gained so far as for the cryptographic - strength of candidate hash functions, it is important to observe the - following two properties of the HMAC construction and its secure use - for message authentication: - - 1. The construction is independent of the details of the particular - hash function H in use and then the latter can be replaced by any - other secure (iterative) cryptographic hash function. - - 2. Message authentication, as opposed to encryption, has a - "transient" effect. A published breaking of a message authentication - scheme would lead to the replacement of that scheme, but would have - no adversarial effect on information authenticated in the past. This - is in sharp contrast with encryption, where information encrypted - today may suffer from exposure in the future if, and when, the - encryption algorithm is broken. - - The strongest attack known against HMAC is based on the frequency of - collisions for the hash function H ("birthday attack") [PV,BCK2], and - is totally impractical for minimally reasonable hash functions. - - As an example, if we consider a hash function like MD5 where the - output length equals L=16 bytes (128 bits) the attacker needs to - acquire the correct message authentication tags computed (with the - _same_ secret key K!) on about 2**64 known plaintexts. This would - require the processing of at least 2**64 blocks under H, an - impossible task in any realistic scenario (for a block length of 64 - bytes this would take 250,000 years in a continuous 1Gbps link, and - without changing the secret key K during all this time). This attack - could become realistic only if serious flaws in the collision - behavior of the function H are discovered (e.g. collisions found - after 2**30 messages). Such a discovery would determine the immediate - replacement of the function H (the effects of such failure would be - far more severe for the traditional uses of H in the context of - digital signatures, public key certificates, etc.). - - Note: this attack needs to be strongly contrasted with regular - collision attacks on cryptographic hash functions where no secret key - is involved and where 2**64 off-line parallelizable (!) operations - suffice to find collisions. The latter attack is approaching - feasibility [VW] while the birthday attack on HMAC is totally - impractical. (In the above examples, if one uses a hash function - with, say, 160 bit of output then 2**64 should be replaced by 2**80.) - - - - - - - - -Krawczyk, et. al. Informational [Page 6] - -RFC 2104 HMAC February 1997 - - - A correct implementation of the above construction, the choice of - random (or cryptographically pseudorandom) keys, a secure key - exchange mechanism, frequent key refreshments, and good secrecy - protection of keys are all essential ingredients for the security of - the integrity verification mechanism provided by HMAC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Krawczyk, et. al. Informational [Page 7] - -RFC 2104 HMAC February 1997 - - -Appendix -- Sample Code - - For the sake of illustration we provide the following sample code for - the implementation of HMAC-MD5 as well as some corresponding test - vectors (the code is based on MD5 code as described in [MD5]). - -/* -** Function: hmac_md5 -*/ - -void -hmac_md5(text, text_len, key, key_len, digest) -unsigned char* text; /* pointer to data stream */ -int text_len; /* length of data stream */ -unsigned char* key; /* pointer to authentication key */ -int key_len; /* length of authentication key */ -caddr_t digest; /* caller digest to be filled in */ - -{ - MD5_CTX context; - unsigned char k_ipad[65]; /* inner padding - - * key XORd with ipad - */ - unsigned char k_opad[65]; /* outer padding - - * key XORd with opad - */ - unsigned char tk[16]; - int i; - /* if key is longer than 64 bytes reset it to key=MD5(key) */ - if (key_len > 64) { - - MD5_CTX tctx; - - MD5Init(&tctx); - MD5Update(&tctx, key, key_len); - MD5Final(tk, &tctx); - - key = tk; - key_len = 16; - } - - /* - * the HMAC_MD5 transform looks like: - * - * MD5(K XOR opad, MD5(K XOR ipad, text)) - * - * where K is an n byte key - * ipad is the byte 0x36 repeated 64 times - - - -Krawczyk, et. al. Informational [Page 8] - -RFC 2104 HMAC February 1997 - - - * opad is the byte 0x5c repeated 64 times - * and text is the data being protected - */ - - /* start out by storing key in pads */ - bzero( k_ipad, sizeof k_ipad); - bzero( k_opad, sizeof k_opad); - bcopy( key, k_ipad, key_len); - bcopy( key, k_opad, key_len); - - /* XOR key with ipad and opad values */ - for (i=0; i<64; i++) { - k_ipad[i] ^= 0x36; - k_opad[i] ^= 0x5c; - } - /* - * perform inner MD5 - */ - MD5Init(&context); /* init context for 1st - * pass */ - MD5Update(&context, k_ipad, 64) /* start with inner pad */ - MD5Update(&context, text, text_len); /* then text of datagram */ - MD5Final(digest, &context); /* finish up 1st pass */ - /* - * perform outer MD5 - */ - MD5Init(&context); /* init context for 2nd - * pass */ - MD5Update(&context, k_opad, 64); /* start with outer pad */ - MD5Update(&context, digest, 16); /* then results of 1st - * hash */ - MD5Final(digest, &context); /* finish up 2nd pass */ -} - -Test Vectors (Trailing '\0' of a character string not included in test): - - key = 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b - key_len = 16 bytes - data = "Hi There" - data_len = 8 bytes - digest = 0x9294727a3638bb1c13f48ef8158bfc9d - - key = "Jefe" - data = "what do ya want for nothing?" - data_len = 28 bytes - digest = 0x750c783e6ab0b503eaa86e310a5db738 - - key = 0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - - - -Krawczyk, et. al. Informational [Page 9] - -RFC 2104 HMAC February 1997 - - - key_len 16 bytes - data = 0xDDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD... - ..DDDDDDDDDDDDDDDDDDDD - data_len = 50 bytes - digest = 0x56be34521d144c88dbb8c733f0e8b3f6 - -Acknowledgments - - Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided - useful comments on early drafts, and ran the first interoperability - tests of this specification. Jeff and Pau-Chen kindly provided the - sample code and test vectors that appear in the appendix. Burt - Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van - Oorschot have provided useful comments and suggestions during the - investigation of the HMAC construction. - -References - - [ANSI] ANSI X9.9, "American National Standard for Financial - Institution Message Authentication (Wholesale)," American - Bankers Association, 1981. Revised 1986. - - [Atk] Atkinson, R., "IP Authentication Header", RFC 1826, August - 1995. - - [BCK1] M. Bellare, R. Canetti, and H. Krawczyk, - "Keyed Hash Functions and Message Authentication", - Proceedings of Crypto'96, LNCS 1109, pp. 1-15. - (http://www.research.ibm.com/security/keyed-md5.html) - - [BCK2] M. Bellare, R. Canetti, and H. Krawczyk, - "Pseudorandom Functions Revisited: The Cascade Construction", - Proceedings of FOCS'96. - - [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", - RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. - http://www.rsa.com/rsalabs/pubs/cryptobytes.html - - [PV] B. Preneel and P. van Oorschot, "Building fast MACs from hash - functions", Advances in Cryptology -- CRYPTO'95 Proceedings, - Lecture Notes in Computer Science, Springer-Verlag Vol.963, - 1995, pp. 1-14. - - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", - RFC 1321, April 1992. - - - -Krawczyk, et. al. Informational [Page 10] - -RFC 2104 HMAC February 1997 - - - [MM] Meyer, S. and Matyas, S.M., Cryptography, New York Wiley, - 1982. - - [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A - strengthened version of RIPEMD", Fast Software Encryption, - LNCS Vol 1039, pp. 71-82. - ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/. - - [SHA] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. - - [Tsu] G. Tsudik, "Message authentication with one-way hash - functions", In Proceedings of Infocom'92, May 1992. - (Also in "Access Control and Policy Enforcement in - Internetworks", Ph.D. Dissertation, Computer Science - Department, University of Southern California, April 1991.) - - [VW] P. van Oorschot and M. Wiener, "Parallel Collision - Search with Applications to Hash Functions and Discrete - Logarithms", Proceedings of the 2nd ACM Conf. Computer and - Communications Security, Fairfax, VA, November 1994. - -Authors' Addresses - - Hugo Krawczyk - IBM T.J. Watson Research Center - P.O.Box 704 - Yorktown Heights, NY 10598 - - EMail: hugo@watson.ibm.com - - Mihir Bellare - Dept of Computer Science and Engineering - Mail Code 0114 - University of California at San Diego - 9500 Gilman Drive - La Jolla, CA 92093 - - EMail: mihir@cs.ucsd.edu - - Ran Canetti - IBM T.J. Watson Research Center - P.O.Box 704 - Yorktown Heights, NY 10598 - - EMail: canetti@watson.ibm.com - - - - - - -Krawczyk, et. al. Informational [Page 11] - diff --git a/doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt b/doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt deleted file mode 100644 index 7b2f87c85..000000000 --- a/doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt +++ /dev/null @@ -1,1795 +0,0 @@ - - - - - - -Network Working Group D. Piper -Request for Comments: 2407 Network Alchemy -Category: Standards Track November 1998 - - - The Internet IP Security Domain of Interpretation for ISAKMP - -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 Internet Society (1998). All Rights Reserved. - -IESG Note - - Section 4.4.4.2 states, "All implememtations within the IPSEC DOI - MUST support ESP_DES...". Recent work in the area of cryptanalysis - suggests that DES may not be sufficiently strong for many - applications. Therefore, it is very likely that the IETF will - deprecate the use of ESP_DES as a mandatory cipher suite in the near - future. It will remain as an optional use protocol. Although the - IPsec working group and the IETF in general have not settled on an - alternative algorithm (taking into account concerns of security and - performance), implementers may want to heed the recommendations of - section 4.4.4.3 on the use of ESP_3DES. - -1. Abstract - - The Internet Security Association and Key Management Protocol - (ISAKMP) defines a framework for security association management and - cryptographic key establishment for the Internet. This framework - consists of defined exchanges, payloads, and processing guidelines - that occur within a given Domain of Interpretation (DOI). This - document defines the Internet IP Security DOI (IPSEC DOI), which - instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate - security associations. - - For a list of changes since the previous version of the IPSEC DOI, - please see Section 7. - - - - - - -Piper Standards Track [Page 1] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -2. Introduction - - Within ISAKMP, a Domain of Interpretation is used to group related - protocols using ISAKMP to negotiate security associations. Security - protocols sharing a DOI choose security protocol and cryptographic - transforms from a common namespace and share key exchange protocol - identifiers. They also share a common interpretation of DOI-specific - payload data content, including the Security Association and - Identification payloads. - - Overall, ISAKMP places the following requirements on a DOI - definition: - - o define the naming scheme for DOI-specific protocol identifiers - o define the interpretation for the Situation field - o define the set of applicable security policies - o define the syntax for DOI-specific SA Attributes (Phase II) - o define the syntax for DOI-specific payload contents - o define additional Key Exchange types, if needed - o define additional Notification Message types, if needed - - The remainder of this document details the instantiation of these - requirements for using the IP Security (IPSEC) protocols to provide - authentication, integrity, and/or confidentiality for IP packets sent - between cooperating host systems and/or firewalls. - - For a description of the overall IPSEC architecture, see [ARCH], - [AH], and [ESP]. - -3. Terms and Definitions - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in [RFC 2119]. - -4.1 IPSEC Naming Scheme - - Within ISAKMP, all DOI's must be registered with the IANA in the - "Assigned Numbers" RFC [STD-2]. The IANA Assigned Number for the - Internet IP Security DOI (IPSEC DOI) is one (1). Within the IPSEC - DOI, all well-known identifiers MUST be registered with the IANA - under the IPSEC DOI. Unless otherwise noted, all tables within this - document refer to IANA Assigned Numbers for the IPSEC DOI. See - Section 6 for further information relating to the IANA registry for - the IPSEC DOI. - - All multi-octet binary values are stored in network byte order. - - - - -Piper Standards Track [Page 2] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.2 IPSEC Situation Definition - - Within ISAKMP, the Situation provides information that can be used by - the responder to make a policy determination about how to process the - incoming Security Association request. For the IPSEC DOI, the - Situation field is a four (4) octet bitmask with the following - values. - - Situation Value - --------- ----- - SIT_IDENTITY_ONLY 0x01 - SIT_SECRECY 0x02 - SIT_INTEGRITY 0x04 - -4.2.1 SIT_IDENTITY_ONLY - - The SIT_IDENTITY_ONLY type specifies that the security association - will be identified by source identity information present in an - associated Identification Payload. See Section 4.6.2 for a complete - description of the various Identification types. All IPSEC DOI - implementations MUST support SIT_IDENTITY_ONLY by including an - Identification Payload in at least one of the Phase I Oakley - exchanges ([IKE], Section 5) and MUST abort any association setup - that does not include an Identification Payload. - - If an initiator supports neither SIT_SECRECY nor SIT_INTEGRITY, the - situation consists only of the 4 octet situation bitmap and does not - include the Labeled Domain Identifier field (Figure 1, Section 4.6.1) - or any subsequent label information. Conversely, if the initiator - supports either SIT_SECRECY or SIT_INTEGRITY, the Labeled Domain - Identifier MUST be included in the situation payload. - -4.2.2 SIT_SECRECY - - The SIT_SECRECY type specifies that the security association is being - negotiated in an environment that requires labeled secrecy. If - SIT_SECRECY is present in the Situation bitmap, the Situation field - will be followed by variable-length data that includes a sensitivity - level and compartment bitmask. See Section 4.6.1 for a complete - description of the Security Association Payload format. - - If an initiator does not support SIT_SECRECY, SIT_SECRECY MUST NOT be - set in the Situation bitmap and no secrecy level or category bitmaps - shall be included. - - If a responder does not support SIT_SECRECY, a SITUATION-NOT- - SUPPORTED Notification Payload SHOULD be returned and the security - association setup MUST be aborted. - - - -Piper Standards Track [Page 3] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.2.3 SIT_INTEGRITY - - The SIT_INTEGRITY type specifies that the security association is - being negotiated in an environment that requires labeled integrity. - If SIT_INTEGRITY is present in the Situation bitmap, the Situation - field will be followed by variable-length data that includes an - integrity level and compartment bitmask. If SIT_SECRECY is also in - use for the association, the integrity information immediately - follows the variable-length secrecy level and categories. See - section 4.6.1 for a complete description of the Security Association - Payload format. - - If an initiator does not support SIT_INTEGRITY, SIT_INTEGRITY MUST - NOT be set in the Situation bitmap and no integrity level or category - bitmaps shall be included. - - If a responder does not support SIT_INTEGRITY, a SITUATION-NOT- - SUPPORTED Notification Payload SHOULD be returned and the security - association setup MUST be aborted. - -4.3 IPSEC Security Policy Requirements - - The IPSEC DOI does not impose specific security policy requirements - on any implementation. Host system policy issues are outside of the - scope of this document. - - However, the following sections touch on some of the issues that must - be considered when designing an IPSEC DOI host implementation. This - section should be considered only informational in nature. - -4.3.1 Key Management Issues - - It is expected that many systems choosing to implement ISAKMP will - strive to provide a protected domain of execution for a combined IKE - key management daemon. On protected-mode multiuser operating - systems, this key management daemon will likely exist as a separate - privileged process. - - In such an environment, a formalized API to introduce keying material - into the TCP/IP kernel may be desirable. The IP Security - architecture does not place any requirements for structure or flow - between a host TCP/IP kernel and its key management provider. - - - - - - - - - -Piper Standards Track [Page 4] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.3.2 Static Keying Issues - - Host systems that implement static keys, either for use directly by - IPSEC, or for authentication purposes (see [IKE] Section 5.4), should - take steps to protect the static keying material when it is not - residing in a protected memory domain or actively in use by the - TCP/IP kernel. - - For example, on a laptop, one might choose to store the static keys - in a configuration store that is, itself, encrypted under a private - password. - - Depending on the operating system and utility software installed, it - may not be possible to protect the static keys once they've been - loaded into the TCP/IP kernel, however they should not be trivially - recoverable on initial system startup without having to satisfy some - additional form of authentication. - -4.3.3 Host Policy Issues - - It is not realistic to assume that the transition to IPSEC will occur - overnight. Host systems must be prepared to implement flexible - policy lists that describe which systems they desire to speak - securely with and which systems they require speak securely to them. - Some notion of proxy firewall addresses may also be required. - - A minimal approach is probably a static list of IP addresses, network - masks, and a security required flag or flags. - - A more flexible implementation might consist of a list of wildcard - DNS names (e.g. '*.foo.bar'), an in/out bitmask, and an optional - firewall address. The wildcard DNS name would be used to match - incoming or outgoing IP addresses, the in/out bitmask would be used - to determine whether or not security was to be applied and in which - direction, and the optional firewall address would be used to - indicate whether or not tunnel mode would be needed to talk to the - target system though an intermediate firewall. - -4.3.4 Certificate Management - - Host systems implementing a certificate-based authentication scheme - will need a mechanism for obtaining and managing a database of - certificates. - - Secure DNS is to be one certificate distribution mechanism, however - the pervasive availability of secure DNS zones, in the short term, is - doubtful for many reasons. What's far more likely is that hosts will - - - - -Piper Standards Track [Page 5] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - need an ability to import certificates that they acquire through - secure, out-of-band mechanisms, as well as an ability to export their - own certificates for use by other systems. - - However, manual certificate management should not be done so as to - preclude the ability to introduce dynamic certificate discovery - mechanisms and/or protocols as they become available. - -4.4 IPSEC Assigned Numbers - - The following sections list the Assigned Numbers for the IPSEC DOI: - Situation Identifiers, Protocol Identifiers, Transform Identifiers, - AH, ESP, and IPCOMP Transform Identifiers, Security Association - Attribute Type Values, Labeled Domain Identifiers, ID Payload Type - Values, and Notify Message Type Values. - -4.4.1 IPSEC Security Protocol Identifier - - The ISAKMP proposal syntax was specifically designed to allow for the - simultaneous negotiation of multiple Phase II security protocol - suites within a single negotiation. As a result, the protocol suites - listed below form the set of protocols that can be negotiated at the - same time. It is a host policy decision as to what protocol suites - might be negotiated together. - - The following table lists the values for the Security Protocol - Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC - DOI. - - Protocol ID Value - ----------- ----- - RESERVED 0 - PROTO_ISAKMP 1 - PROTO_IPSEC_AH 2 - PROTO_IPSEC_ESP 3 - PROTO_IPCOMP 4 - -4.4.1.1 PROTO_ISAKMP - - The PROTO_ISAKMP type specifies message protection required during - Phase I of the ISAKMP protocol. The specific protection mechanism - used for the IPSEC DOI is described in [IKE]. All implementations - within the IPSEC DOI MUST support PROTO_ISAKMP. - - NB: ISAKMP reserves the value one (1) across all DOI definitions. - - - - - - -Piper Standards Track [Page 6] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.4.1.2 PROTO_IPSEC_AH - - The PROTO_IPSEC_AH type specifies IP packet authentication. The - default AH transform provides data origin authentication, integrity - protection, and replay detection. For export control considerations, - confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform. - -4.4.1.3 PROTO_IPSEC_ESP - - The PROTO_IPSEC_ESP type specifies IP packet confidentiality. - Authentication, if required, must be provided as part of the ESP - transform. The default ESP transform includes data origin - authentication, integrity protection, replay detection, and - confidentiality. - -4.4.1.4 PROTO_IPCOMP - - The PROTO_IPCOMP type specifies IP payload compression as defined in - [IPCOMP]. - -4.4.2 IPSEC ISAKMP Transform Identifiers - - As part of an ISAKMP Phase I negotiation, the initiator's choice of - Key Exchange offerings is made using some host system policy - description. The actual selection of Key Exchange mechanism is made - using the standard ISAKMP Proposal Payload. The following table - lists the defined ISAKMP Phase I Transform Identifiers for the - Proposal Payload for the IPSEC DOI. - - Transform Value - --------- ----- - RESERVED 0 - KEY_IKE 1 - - Within the ISAKMP and IPSEC DOI framework it is possible to define - key establishment protocols other than IKE (Oakley). Previous - versions of this document defined types both for manual keying and - for schemes based on use of a generic Key Distribution Center (KDC). - These identifiers have been removed from the current document. - - The IPSEC DOI can still be extended later to include values for - additional non-Oakley key establishment protocols for ISAKMP and - IPSEC, such as Kerberos [RFC-1510] or the Group Key Management - Protocol (GKMP) [RFC-2093]. - - - - - - - -Piper Standards Track [Page 7] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.4.2.1 KEY_IKE - - The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman - key exchange (IKE) as defined in the [IKE] document. All - implementations within the IPSEC DOI MUST support KEY_IKE. - -4.4.3 IPSEC AH Transform Identifiers - - The Authentication Header Protocol (AH) defines one mandatory and - several optional transforms used to provide authentication, - integrity, and replay detection. The following table lists the - defined AH Transform Identifiers for the ISAKMP Proposal Payload for - the IPSEC DOI. - - Note: the Authentication Algorithm attribute MUST be specified to - identify the appropriate AH protection suite. For example, AH_MD5 - can best be thought of as a generic AH transform using MD5. To - request the HMAC construction with AH, one specifies the AH_MD5 - transform ID along with the Authentication Algorithm attribute set to - HMAC-MD5. This is shown using the "Auth(HMAC-MD5)" notation in the - following sections. - - Transform ID Value - ------------ ----- - RESERVED 0-1 - AH_MD5 2 - AH_SHA 3 - AH_DES 4 - - Note: all mandatory-to-implement algorithms are listed as "MUST" - implement (e.g. AH_MD5) in the following sections. All other - algorithms are optional and MAY be implemented in any particular - implementation. - -4.4.3.1 AH_MD5 - - The AH_MD5 type specifies a generic AH transform using MD5. The - actual protection suite is determined in concert with an associated - SA attribute list. A generic MD5 transform is currently undefined. - - All implementations within the IPSEC DOI MUST support AH_MD5 along - with the Auth(HMAC-MD5) attribute. This suite is defined as the - HMAC-MD5-96 transform described in [HMACMD5]. - - The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH - transform (Key/Pad/Data/Key) described in RFC-1826. - - - - - -Piper Standards Track [Page 8] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Use of AH_MD5 with any other Authentication Algorithm attribute value - is currently undefined. - -4.4.3.2 AH_SHA - - The AH_SHA type specifies a generic AH transform using SHA-1. The - actual protection suite is determined in concert with an associated - SA attribute list. A generic SHA transform is currently undefined. - - All implementations within the IPSEC DOI MUST support AH_SHA along - with the Auth(HMAC-SHA) attribute. This suite is defined as the - HMAC-SHA-1-96 transform described in [HMACSHA]. - - Use of AH_SHA with any other Authentication Algorithm attribute value - is currently undefined. - -4.4.3.3 AH_DES - - The AH_DES type specifies a generic AH transform using DES. The - actual protection suite is determined in concert with an associated - SA attribute list. A generic DES transform is currently undefined. - - The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute - to be a DES-MAC transform. Implementations are not required to - support this mode. - - Use of AH_DES with any other Authentication Algorithm attribute value - is currently undefined. - -4.4.4 IPSEC ESP Transform Identifiers - - The Encapsulating Security Payload (ESP) defines one mandatory and - many optional transforms used to provide data confidentiality. The - following table lists the defined ESP Transform Identifiers for the - ISAKMP Proposal Payload for the IPSEC DOI. - - Note: when authentication, integrity protection, and replay detection - are required, the Authentication Algorithm attribute MUST be - specified to identify the appropriate ESP protection suite. For - example, to request HMAC-MD5 authentication with 3DES, one specifies - the ESP_3DES transform ID with the Authentication Algorithm attribute - set to HMAC-MD5. For additional processing requirements, see Section - 4.5 (Authentication Algorithm). - - - - - - - - -Piper Standards Track [Page 9] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Transform ID Value - ------------ ----- - RESERVED 0 - ESP_DES_IV64 1 - ESP_DES 2 - ESP_3DES 3 - ESP_RC5 4 - ESP_IDEA 5 - ESP_CAST 6 - ESP_BLOWFISH 7 - ESP_3IDEA 8 - ESP_DES_IV32 9 - ESP_RC4 10 - ESP_NULL 11 - - Note: all mandatory-to-implement algorithms are listed as "MUST" - implement (e.g. ESP_DES) in the following sections. All other - algorithms are optional and MAY be implemented in any particular - implementation. - -4.4.4.1 ESP_DES_IV64 - - The ESP_DES_IV64 type specifies the DES-CBC transform defined in - RFC-1827 and RFC-1829 using a 64-bit IV. - -4.4.4.2 ESP_DES - - The ESP_DES type specifies a generic DES transform using DES-CBC. - The actual protection suite is determined in concert with an - associated SA attribute list. A generic transform is currently - undefined. - - All implementations within the IPSEC DOI MUST support ESP_DES along - with the Auth(HMAC-MD5) attribute. This suite is defined as the - [DES] transform, with authentication and integrity provided by HMAC - MD5 [HMACMD5]. - -4.4.4.3 ESP_3DES - - The ESP_3DES type specifies a generic triple-DES transform. The - actual protection suite is determined in concert with an associated - SA attribute list. The generic transform is currently undefined. - - All implementations within the IPSEC DOI are strongly encouraged to - support ESP_3DES along with the Auth(HMAC-MD5) attribute. This suite - is defined as the [ESPCBC] transform, with authentication and - integrity provided by HMAC MD5 [HMACMD5]. - - - - -Piper Standards Track [Page 10] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.4.4.4 ESP_RC5 - - The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC]. - -4.4.4.5 ESP_IDEA - - The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC]. - -4.4.4.6 ESP_CAST - - The ESP_CAST type specifies the CAST transform defined in [ESPCBC]. - -4.4.4.7 ESP_BLOWFISH - - The ESP_BLOWFISH type specifies the BLOWFISH transform defined in - [ESPCBC]. - -4.4.4.8 ESP_3IDEA - - The ESP_3IDEA type is reserved for triple-IDEA. - -4.4.4.9 ESP_DES_IV32 - - The ESP_DES_IV32 type specifies the DES-CBC transform defined in - RFC-1827 and RFC-1829 using a 32-bit IV. - -4.4.4.10 ESP_RC4 - - The ESP_RC4 type is reserved for RC4. - -4.4.4.11 ESP_NULL - - The ESP_NULL type specifies no confidentiality is to be provided by - ESP. ESP_NULL is used when ESP is being used to tunnel packets which - require only authentication, integrity protection, and replay - detection. - - All implementations within the IPSEC DOI MUST support ESP_NULL. The - ESP NULL transform is defined in [ESPNULL]. See the Authentication - Algorithm attribute description in Section 4.5 for additional - requirements relating to the use of ESP_NULL. - -4.4.5 IPSEC IPCOMP Transform Identifiers - - The IP Compression (IPCOMP) transforms define optional compression - algorithms that can be negotiated to provide for IP payload - compression ([IPCOMP]). The following table lists the defined IPCOMP - Transform Identifiers for the ISAKMP Proposal Payload within the - - - -Piper Standards Track [Page 11] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - IPSEC DOI. - - Transform ID Value - ------------ ----- - RESERVED 0 - IPCOMP_OUI 1 - IPCOMP_DEFLATE 2 - IPCOMP_LZS 3 - -4.4.5.1 IPCOMP_OUI - - The IPCOMP_OUI type specifies a proprietary compression transform. - The IPCOMP_OUI type must be accompanied by an attribute which further - identifies the specific vendor algorithm. - -4.4.5.2 IPCOMP_DEFLATE - - The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate - algorithm as specified in [DEFLATE]. - -4.4.5.3 IPCOMP_LZS - - The IPCOMP_LZS type specifies the use of the Stac Electronics LZS - algorithm as specified in [LZS]. - -4.5 IPSEC Security Association Attributes - - The following SA attribute definitions are used in Phase II of an IKE - negotiation. Attribute types can be either Basic (B) or Variable- - Length (V). Encoding of these attributes is defined in the base - ISAKMP specification. - - Attributes described as basic MUST NOT be encoded as variable. - Variable length attributes MAY be encoded as basic attributes if - their value can fit into two octets. See [IKE] for further - information on attribute encoding in the IPSEC DOI. All restrictions - listed in [IKE] also apply to the IPSEC DOI. - - - - - - - - - - - - - - -Piper Standards Track [Page 12] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Attribute Types - - class value type - ------------------------------------------------- - SA Life Type 1 B - SA Life Duration 2 V - Group Description 3 B - Encapsulation Mode 4 B - Authentication Algorithm 5 B - Key Length 6 B - Key Rounds 7 B - Compress Dictionary Size 8 B - Compress Private Algorithm 9 V - - Class Values - - SA Life Type - SA Duration - - Specifies the time-to-live for the overall security - association. When the SA expires, all keys negotiated under - the association (AH or ESP) must be renegotiated. The life - type values are: - - RESERVED 0 - seconds 1 - kilobytes 2 - - Values 3-61439 are reserved to IANA. Values 61440-65535 are - for private use. For a given Life Type, the value of the - Life Duration attribute defines the actual length of the - component lifetime -- either a number of seconds, or a number - of Kbytes that can be protected. - - If unspecified, the default value shall be assumed to be - 28800 seconds (8 hours). - - An SA Life Duration attribute MUST always follow an SA Life - Type which describes the units of duration. - - See Section 4.5.4 for additional information relating to - lifetime notification. - - Group Description - - Specifies the Oakley Group to be used in a PFS QM - negotiation. For a list of supported values, see Appendix A - of [IKE]. - - - -Piper Standards Track [Page 13] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Encapsulation Mode - RESERVED 0 - Tunnel 1 - Transport 2 - - Values 3-61439 are reserved to IANA. Values 61440-65535 are - for private use. - - If unspecified, the default value shall be assumed to be - unspecified (host-dependent). - - Authentication Algorithm - RESERVED 0 - HMAC-MD5 1 - HMAC-SHA 2 - DES-MAC 3 - KPDK 4 - - Values 5-61439 are reserved to IANA. Values 61440-65535 are - for private use. - - There is no default value for Auth Algorithm, as it must be - specified to correctly identify the applicable AH or ESP - transform, except in the following case. - - When negotiating ESP without authentication, the Auth - Algorithm attribute MUST NOT be included in the proposal. - - When negotiating ESP without confidentiality, the Auth - Algorithm attribute MUST be included in the proposal and the - ESP transform ID must be ESP_NULL. - - Key Length - RESERVED 0 - - There is no default value for Key Length, as it must be - specified for transforms using ciphers with variable key - lengths. For fixed length ciphers, the Key Length attribute - MUST NOT be sent. - - Key Rounds - RESERVED 0 - - There is no default value for Key Rounds, as it must be - specified for transforms using ciphers with varying numbers - of rounds. - - - - - -Piper Standards Track [Page 14] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Compression Dictionary Size - RESERVED 0 - - Specifies the log2 maximum size of the dictionary. - - There is no default value for dictionary size. - - Compression Private Algorithm - - Specifies a private vendor compression algorithm. The first - three (3) octets must be an IEEE assigned company_id (OUI). - The next octet may be a vendor specific compression subtype, - followed by zero or more octets of vendor data. - -4.5.1 Required Attribute Support - - To ensure basic interoperability, all implementations MUST be - prepared to negotiate all of the following attributes. - - SA Life Type - SA Duration - Auth Algorithm - -4.5.2 Attribute Parsing Requirement (Lifetime) - - To allow for flexible semantics, the IPSEC DOI requires that a - conforming ISAKMP implementation MUST correctly parse an attribute - list that contains multiple instances of the same attribute class, so - long as the different attribute entries do not conflict with one - another. Currently, the only attributes which requires this - treatment are Life Type and Duration. - - To see why this is important, the following example shows the binary - encoding of a four entry attribute list that specifies an SA Lifetime - of either 100MB or 24 hours. (See Section 3.3 of [ISAKMP] for a - complete description of the attribute encoding format.) - - Attribute #1: - 0x80010001 (AF = 1, type = SA Life Type, value = seconds) - - Attribute #2: - 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) - 0x00015180 (value = 0x15180 = 86400 seconds = 24 hours) - - Attribute #3: - 0x80010002 (AF = 1, type = SA Life Type, value = KB) - - - - - -Piper Standards Track [Page 15] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Attribute #4: - 0x00020004 (AF = 0, type = SA Duration, length = 4 bytes) - 0x000186A0 (value = 0x186A0 = 100000KB = 100MB) - - If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED - Notification Payload SHOULD be returned and the security association - setup MUST be aborted. - -4.5.3 Attribute Negotiation - - If an implementation receives a defined IPSEC DOI attribute (or - attribute value) which it does not support, an ATTRIBUTES-NOT-SUPPORT - SHOULD be sent and the security association setup MUST be aborted, - unless the attribute value is in the reserved range. - - If an implementation receives an attribute value in the reserved - range, an implementation MAY chose to continue based on local policy. - -4.5.4 Lifetime Notification - - When an initiator offers an SA lifetime greater than what the - responder desires based on their local policy, the responder has - three choices: 1) fail the negotiation entirely; 2) complete the - negotiation but use a shorter lifetime than what was offered; 3) - complete the negotiation and send an advisory notification to the - initiator indicating the responder's true lifetime. The choice of - what the responder actually does is implementation specific and/or - based on local policy. - - To ensure interoperability in the latter case, the IPSEC DOI requires - the following only when the responder wishes to notify the initiator: - if the initiator offers an SA lifetime longer than the responder is - willing to accept, the responder SHOULD include an ISAKMP - Notification Payload in the exchange that includes the responder's - IPSEC SA payload. Section 4.6.3.1 defines the payload layout for the - RESPONDER-LIFETIME Notification Message type which MUST be used for - this purpose. - -4.6 IPSEC Payload Content - - The following sections describe those ISAKMP payloads whose data - representations are dependent on the applicable DOI. - -4.6.1 Security Association Payload - - The following diagram illustrates the content of the Security - Association Payload for the IPSEC DOI. See Section 4.2 for a - description of the Situation bitmap. - - - -Piper Standards Track [Page 16] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation (IPSEC) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Situation (bitmap) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Labeled Domain Identifier ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Secrecy Length (in octets) ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Secrecy Level ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Secrecy Cat. Length (in bits) ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Secrecy Category Bitmap ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Integrity Length (in octets) ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Integrity Level ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Integ. Cat. Length (in bits) ! RESERVED ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Integrity Category Bitmap ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 1: Security Association Payload Format - - The Security Association Payload is 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, this field will be zero (0). - - o RESERVED (1 octet) - Unused, must be zero (0). - - o Payload Length (2 octets) - Length, in octets, of the current - payload, including the generic header. - - o Domain of Interpretation (4 octets) - Specifies the IPSEC DOI, - which has been assigned the value one (1). - - o Situation (4 octets) - Bitmask used to interpret the remainder - of the Security Association Payload. See Section 4.2 for a - complete list of values. - - - - - -Piper Standards Track [Page 17] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - o Labeled Domain Identifier (4 octets) - IANA Assigned Number used - to interpret the Secrecy and Integrity information. - - o Secrecy Length (2 octets) - Specifies the length, in octets, of - the secrecy level identifier, excluding pad bits. - - o RESERVED (2 octets) - Unused, must be zero (0). - - o Secrecy Level (variable length) - Specifies the mandatory - secrecy level required. The secrecy level MUST be padded with - zero (0) to align on the next 32-bit boundary. - - o Secrecy Category Length (2 octets) - Specifies the length, in - bits, of the secrecy category (compartment) bitmap, excluding - pad bits. - - o RESERVED (2 octets) - Unused, must be zero (0). - - o Secrecy Category Bitmap (variable length) - A bitmap used to - designate secrecy categories (compartments) that are required. - The bitmap MUST be padded with zero (0) to align on the next - 32-bit boundary. - - o Integrity Length (2 octets) - Specifies the length, in octets, - of the integrity level identifier, excluding pad bits. - - o RESERVED (2 octets) - Unused, must be zero (0). - - o Integrity Level (variable length) - Specifies the mandatory - integrity level required. The integrity level MUST be padded - with zero (0) to align on the next 32-bit boundary. - - o Integrity Category Length (2 octets) - Specifies the length, in - bits, of the integrity category (compartment) bitmap, excluding - pad bits. - - o RESERVED (2 octets) - Unused, must be zero (0). - - o Integrity Category Bitmap (variable length) - A bitmap used to - designate integrity categories (compartments) that are required. - The bitmap MUST be padded with zero (0) to align on the next - 32-bit boundary. - -4.6.1.1 IPSEC Labeled Domain Identifiers - - The following table lists the assigned values for the Labeled Domain - Identifier field contained in the Situation field of the Security - Association Payload. - - - -Piper Standards Track [Page 18] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Domain Value - ------- ----- - RESERVED 0 - -4.6.2 Identification Payload Content - - The Identification Payload is used to identify the initiator of the - Security Association. The identity of the initiator SHOULD be used - by the responder to determine the correct host system security policy - requirement for the association. For example, a host might choose to - require authentication and integrity without confidentiality (AH) - from a certain set of IP addresses and full authentication with - confidentiality (ESP) from another range of IP addresses. The - Identification Payload provides information that can be used by the - responder to make this decision. - - During Phase I negotiations, the ID port and protocol fields MUST be - set to zero or to UDP port 500. If an implementation receives any - other values, this MUST be treated as an error and the security - association setup MUST be aborted. This event SHOULD be auditable. - - The following diagram illustrates the content of the Identification - Payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ID Type ! Protocol ID ! Port ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Identification Data ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 2: Identification Payload Format - - The Identification Payload 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, this field will be zero (0). - - o RESERVED (1 octet) - Unused, must be zero (0). - - o Payload Length (2 octets) - Length, in octets, of the - identification data, including the generic header. - - o Identification Type (1 octet) - Value describing the identity - information found in the Identification Data field. - - - -Piper Standards Track [Page 19] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - o Protocol ID (1 octet) - Value specifying an associated IP - protocol ID (e.g. UDP/TCP). A value of zero means that the - Protocol ID field should be ignored. - - o Port (2 octets) - Value specifying an associated port. A value - of zero means that the Port field should be ignored. - - o Identification Data (variable length) - Value, as indicated by - the Identification Type. - -4.6.2.1 Identification Type Values - - The following table lists the assigned values for the Identification - Type field found in the Identification Payload. - - ID Type Value - ------- ----- - RESERVED 0 - ID_IPV4_ADDR 1 - ID_FQDN 2 - ID_USER_FQDN 3 - ID_IPV4_ADDR_SUBNET 4 - ID_IPV6_ADDR 5 - ID_IPV6_ADDR_SUBNET 6 - ID_IPV4_ADDR_RANGE 7 - ID_IPV6_ADDR_RANGE 8 - ID_DER_ASN1_DN 9 - ID_DER_ASN1_GN 10 - ID_KEY_ID 11 - - For types where the ID entity is variable length, the size of the ID - entity is computed from size in the ID payload header. - - When an IKE exchange is authenticated using certificates (of any - format), any ID's used for input to local policy decisions SHOULD be - contained in the certificate used in the authentication of the - exchange. - -4.6.2.2 ID_IPV4_ADDR - - The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. - -4.6.2.3 ID_FQDN - - The ID_FQDN type specifies a fully-qualified domain name string. An - example of a ID_FQDN is, "foo.bar.com". The string should not - contain any terminators. - - - - -Piper Standards Track [Page 20] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.6.2.4 ID_USER_FQDN - - The ID_USER_FQDN type specifies a fully-qualified username string, An - example of a ID_USER_FQDN is, "piper@foo.bar.com". The string should - not contain any terminators. - -4.6.2.5 ID_IPV4_ADDR_SUBNET - - The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, - represented by two four (4) octet values. The first value is an IPv4 - address. The second is an IPv4 network mask. Note that ones (1s) in - the network mask indicate that the corresponding bit in the address - is fixed, while zeros (0s) indicate a "wildcard" bit. - -4.6.2.6 ID_IPV6_ADDR - - The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 - address. - -4.6.2.7 ID_IPV6_ADDR_SUBNET - - The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, - represented by two sixteen (16) octet values. The first value is an - IPv6 address. The second is an IPv6 network mask. Note that ones - (1s) in the network mask indicate that the corresponding bit in the - address is fixed, while zeros (0s) indicate a "wildcard" bit. - -4.6.2.8 ID_IPV4_ADDR_RANGE - - The ID_IPV4_ADDR_RANGE type specifies a range of IPv4 addresses, - represented by two four (4) 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. - -4.6.2.9 ID_IPV6_ADDR_RANGE - - The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses, - represented by two sixteen (16) 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. - -4.6.2.10 ID_DER_ASN1_DN - - The ID_DER_ASN1_DN type specifies the binary DER encoding of an ASN.1 - X.500 Distinguished Name [X.501] of the principal whose certificates - are being exchanged to establish the SA. - - - -Piper Standards Track [Page 21] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -4.6.2.11 ID_DER_ASN1_GN - - The ID_DER_ASN1_GN type specifies the binary DER encoding of an ASN.1 - X.500 GeneralName [X.509] of the principal whose certificates are - being exchanged to establish the SA. - -4.6.2.12 ID_KEY_ID - - The ID_KEY_ID type specifies an opaque byte stream which may be used - to pass vendor-specific information necessary to identify which pre- - shared key should be used to authenticate Aggressive mode - negotiations. - -4.6.3 IPSEC Notify Message Types - - ISAKMP defines two blocks of Notify Message codes, one for errors and - one for status messages. ISAKMP also allocates a portion of each - block for private use within a DOI. The IPSEC DOI defines the - following private message types for its own use. - - Notify Messages - Error Types Value - ----------------------------- ----- - RESERVED 8192 - - Notify Messages - Status Types Value - ------------------------------ ----- - RESPONDER-LIFETIME 24576 - REPLAY-STATUS 24577 - INITIAL-CONTACT 24578 - - Notification Status Messages MUST be sent under the protection of an - ISAKMP SA: either as a payload in the last Main Mode exchange; in a - separate Informational Exchange after Main Mode or Aggressive Mode - processing is complete; or as a payload in any Quick Mode exchange. - These messages MUST NOT be sent in Aggressive Mode exchange, since - Aggressive Mode does not provide the necessary protection to bind the - Notify Status Message to the exchange. - - Nota Bene: a Notify payload is fully protected only in Quick Mode, - where the entire payload is included in the HASH(n) digest. In Main - Mode, while the notify payload is encrypted, it is not currently - included in the HASH(n) digests. As a result, an active substitution - attack on the Main Mode ciphertext could cause the notify status - message type to be corrupted. (This is true, in general, for the - last message of any Main Mode exchange.) While the risk is small, a - corrupt notify message might cause the receiver to abort the entire - negotiation thinking that the sender encountered a fatal error. - - - - -Piper Standards Track [Page 22] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - Implementation Note: the ISAKMP protocol does not guarantee delivery - of Notification Status messages when sent in an ISAKMP Informational - Exchange. To ensure receipt of any particular message, the sender - SHOULD include a Notification Payload in a defined Main Mode or Quick - Mode exchange which is protected by a retransmission timer. - -4.6.3.1 RESPONDER-LIFETIME - - The RESPONDER-LIFETIME status message may be used to communicate the - IPSEC SA lifetime chosen by the responder. - - When present, the Notification Payload MUST have the following - format: - - o Payload Length - set to length of payload + size of data (var) - o DOI - set to IPSEC DOI (1) - o Protocol ID - set to selected Protocol ID from chosen SA - o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP - cookies) or four (4) (one IPSEC SPI) - o Notify Message Type - set to RESPONDER-LIFETIME (Section 4.6.3) - o SPI - set to the two ISAKMP cookies or to the sender's inbound - IPSEC SPI - o Notification Data - contains an ISAKMP attribute list with the - responder's actual SA lifetime(s) - - Implementation Note: saying that the Notification Data field contains - an attribute list is equivalent to saying that the Notification Data - field has zero length and the Notification Payload has an associated - attribute list. - -4.6.3.2 REPLAY-STATUS - - The REPLAY-STATUS status message may be used for positive - confirmation of the responder's election on whether or not he is to - perform anti-replay detection. - - When present, the Notification Payload MUST have the following - format: - - o Payload Length - set to length of payload + size of data (4) - o DOI - set to IPSEC DOI (1) - o Protocol ID - set to selected Protocol ID from chosen SA - o SPI Size - set to either sixteen (16) (two eight-octet ISAKMP - cookies) or four (4) (one IPSEC SPI) - o Notify Message Type - set to REPLAY-STATUS - o SPI - set to the two ISAKMP cookies or to the sender's inbound - IPSEC SPI - o Notification Data - a 4 octet value: - - - -Piper Standards Track [Page 23] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - 0 = replay detection disabled - 1 = replay detection enabled - -4.6.3.3 INITIAL-CONTACT - - The INITIAL-CONTACT status message may be used when one side wishes - to inform the other that this is the first SA being established with - the remote system. The receiver of this Notification Message might - then elect to delete any existing SA's it has for the sending system - under the assumption that the sending system has rebooted and no - longer has access to the original SA's and their associated keying - material. When used, the content of the Notification Data field - SHOULD be null (i.e. the Payload Length should be set to the fixed - length of Notification Payload). - - When present, the Notification Payload MUST have the following - format: - - o Payload Length - set to length of payload + size of data (0) - o DOI - set to IPSEC DOI (1) - o Protocol ID - set to selected Protocol ID from chosen SA - o SPI Size - set to sixteen (16) (two eight-octet ISAKMP cookies) - o Notify Message Type - set to INITIAL-CONTACT - o SPI - set to the two ISAKMP cookies - o Notification Data - <not included> - -4.7 IPSEC Key Exchange Requirements - - The IPSEC DOI introduces no additional Key Exchange types. - -5. Security Considerations - - This entire memo pertains to the Internet Key Exchange protocol - ([IKE]), which combines ISAKMP ([ISAKMP]) and Oakley ([OAKLEY]) to - provide for the derivation of cryptographic keying material in a - secure and authenticated manner. Specific discussion of the various - security protocols and transforms identified in this document can be - found in the associated base documents and in the cipher references. - -6. IANA Considerations - - This document contains many "magic" numbers to be maintained by the - IANA. This section explains the criteria to be used by the IANA to - assign additional numbers in each of these lists. All values not - explicitly defined in previous sections are reserved to IANA. - - - - - - -Piper Standards Track [Page 24] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -6.1 IPSEC Situation Definition - - The Situation Definition is a 32-bit bitmask which represents the - environment under which the IPSEC SA proposal and negotiation is - carried out. Requests for assignments of new situations must be - accompanied by an RFC which describes the interpretation for the - associated bit. - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The upper two bits are reserved for private use amongst cooperating - systems. - -6.2 IPSEC Security Protocol Identifiers - - The Security Protocol Identifier is an 8-bit value which identifies a - security protocol suite being negotiated. Requests for assignments - of new security protocol identifiers must be accompanied by an RFC - which describes the requested security protocol. [AH] and [ESP] are - examples of security protocol documents. - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The values 249-255 are reserved for private use amongst cooperating - systems. - -6.3 IPSEC ISAKMP Transform Identifiers - - The IPSEC ISAKMP Transform Identifier is an 8-bit value which - identifies a key exchange protocol to be used for the negotiation. - Requests for assignments of new ISAKMP transform identifiers must be - accompanied by an RFC which describes the requested key exchange - protocol. [IKE] is an example of one such document. - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The values 249-255 are reserved for private use amongst cooperating - systems. - - - - -Piper Standards Track [Page 25] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -6.4 IPSEC AH Transform Identifiers - - The IPSEC AH Transform Identifier is an 8-bit value which identifies - a particular algorithm to be used to provide integrity protection for - AH. Requests for assignments of new AH transform identifiers must be - accompanied by an RFC which describes how to use the algorithm within - the AH framework ([AH]). - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The values 249-255 are reserved for private use amongst cooperating - systems. - -6.5 IPSEC ESP Transform Identifiers - - The IPSEC ESP Transform Identifier is an 8-bit value which identifies - a particular algorithm to be used to provide secrecy protection for - ESP. Requests for assignments of new ESP transform identifiers must - be accompanied by an RFC which describes how to use the algorithm - within the ESP framework ([ESP]). - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The values 249-255 are reserved for private use amongst cooperating - systems. - -6.6 IPSEC IPCOMP Transform Identifiers - - The IPSEC IPCOMP Transform Identifier is an 8-bit value which - identifier a particular algorithm to be used to provide IP-level - compression before ESP. Requests for assignments of new IPCOMP - transform identifiers must be accompanied by an RFC which describes - how to use the algorithm within the IPCOMP framework ([IPCOMP]). In - addition, the requested algorithm must be published and in the public - domain. - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - - - - -Piper Standards Track [Page 26] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - The values 1-47 are reserved for algorithms for which an RFC has been - approved for publication. The values 48-63 are reserved for private - use amongst cooperating systems. The values 64-255 are reserved for - future expansion. - -6.7 IPSEC Security Association Attributes - - The IPSEC Security Association Attribute consists of a 16-bit type - and its associated value. IPSEC SA attributes are used to pass - miscellaneous values between ISAKMP peers. Requests for assignments - of new IPSEC SA attributes must be accompanied by an Internet Draft - which describes the attribute encoding (Basic/Variable-Length) and - its legal values. Section 4.5 of this document provides an example - of such a description. - - The values 32001-32767 are reserved for private use amongst - cooperating systems. - -6.8 IPSEC Labeled Domain Identifiers - - The IPSEC Labeled Domain Identifier is a 32-bit value which - identifies a namespace in which the Secrecy and Integrity levels and - categories values are said to exist. Requests for assignments of new - IPSEC Labeled Domain Identifiers should be granted on demand. No - accompanying documentation is required, though Internet Drafts are - encouraged when appropriate. - - The values 0x80000000-0xffffffff are reserved for private use amongst - cooperating systems. - -6.9 IPSEC Identification Type - - The IPSEC Identification Type is an 8-bit value which is used as a - discriminant for interpretation of the variable-length Identification - Payload. Requests for assignments of new IPSEC Identification Types - must be accompanied by an RFC which describes how to use the - identification type within IPSEC. - - If the RFC is not on the standards-track (i.e., it is an - informational or experimental RFC), it must be explicitly reviewed - and approved by the IESG before the RFC is published and the - transform identifier is assigned. - - The values 249-255 are reserved for private use amongst cooperating - systems. - - - - - - -Piper Standards Track [Page 27] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -6.10 IPSEC Notify Message Types - - The IPSEC Notify Message Type is a 16-bit value taken from the range - of values reserved by ISAKMP for each DOI. There is one range for - error messages (8192-16383) and a different range for status messages - (24576-32767). Requests for assignments of new Notify Message Types - must be accompanied by an Internet Draft which describes how to use - the identification type within IPSEC. - - The values 16001-16383 and the values 32001-32767 are reserved for - private use amongst cooperating systems. - -7. Change Log - -7.1 Changes from V9 - - o add explicit reference to [IPCOMP], [DEFLATE], and [LZS] - o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed - at an IPSEC SPI in addition to the ISAKMP "SPI" - o added padding exclusion to Secrecy and Integrity Length text - o added forward reference to Section 4.5 in Section 4.4.4 - o update document references - -7.2 Changes from V8 - - o update IPCOMP identifier range to better reflect IPCOMP draft - o update IANA considerations per Jeff/Ted's suggested text - o eliminate references to DES-MAC ID ([DESMAC]) - o correct bug in Notify section; ISAKMP Notify values are 16-bits - -7.3 Changes from V7 - - o corrected name of IPCOMP (IP Payload Compression) - o corrected references to [ESPCBC] - o added missing Secrecy Level and Integrity Level to Figure 1 - o removed ID references to PF_KEY and ARCFOUR - o updated Basic/Variable text to align with [IKE] - o updated document references and add intro pointer to [ARCH] - o updated Notification requirements; remove aggressive reference - o added clarification about protection for Notify payloads - o restored RESERVED to ESP transform ID namespace; moved ESP_NULL - o added requirement for ESP_NULL support and [ESPNULL] reference - o added clarification on Auth Alg use with AH/ESP - o added restriction against using conflicting AH/Auth combinations - -7.4 Changes from V6 - - The following changes were made relative to the IPSEC DOI V6: - - - -Piper Standards Track [Page 28] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - o added IANA Considerations section - o moved most IANA numbers to IANA Considerations section - o added prohibition on sending (V) encoding for (B) attributes - o added prohibition on sending Key Length attribute for fixed - length ciphers (e.g. DES) - o replaced references to ISAKMP/Oakley with IKE - o renamed ESP_ARCFOUR to ESP_RC4 - o updated Security Considerations section - o updated document references - -7.5 Changes from V5 - - The following changes were made relative to the IPSEC DOI V5: - - o changed SPI size in Lifetime Notification text - o changed REPLAY-ENABLED to REPLAY-STATUS - o moved RESPONDER-LIFETIME payload definition from Section 4.5.4 - to Section 4.6.3.1 - o added explicit payload layout for 4.6.3.3 - o added Implementation Note to Section 4.6.3 introduction - o changed AH_SHA text to require SHA-1 in addition to MD5 - o updated document references - -7.6 Changes from V4 - - The following changes were made relative to the IPSEC DOI V4: - - o moved compatibility AH KPDK authentication method from AH - transform ID to Authentication Algorithm identifier - o added REPLAY-ENABLED notification message type per Architecture - o added INITIAL-CONTACT notification message type per list - o added text to ensure protection for Notify Status messages - o added Lifetime qualification to attribute parsing section - o added clarification that Lifetime notification is optional - o removed private Group Description list (now points at [IKE]) - o replaced Terminology with pointer to RFC-2119 - o updated HMAC MD5 and SHA-1 ID references - o updated Section 1 (Abstract) - o updated Section 4.4 (IPSEC Assigned Numbers) - o added restriction for ID port/protocol values for Phase I - -7.7 Changes from V3 to V4 - - The following changes were made relative to the IPSEC DOI V3, that - was posted to the IPSEC mailing list prior to the Munich IETF: - - o added ESP transform identifiers for NULL and ARCFOUR - - - - -Piper Standards Track [Page 29] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - o renamed HMAC Algorithm to Auth Algorithm to accommodate - DES-MAC and optional authentication/integrity for ESP - o added AH and ESP DES-MAC algorithm identifiers - o removed KEY_MANUAL and KEY_KDC identifier definitions - o added lifetime duration MUST follow lifetype attribute to - SA Life Type and SA Life Duration attribute definition - o added lifetime notification and IPSEC DOI message type table - o added optional authentication and confidentiality - restrictions to MAC Algorithm attribute definition - o corrected attribute parsing example (used obsolete attribute) - o corrected several Internet Draft document references - o added ID_KEY_ID per ipsec list discussion (18-Mar-97) - o removed Group Description default for PFS QM ([IKE] MUST) - -Acknowledgments - - This document is derived, in part, from previous works by Douglas - Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins, - and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran - Atkinson also contributed suggestions and, in many cases, text. - -References - - [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC - 2402, November 1998. - - [ARCH] Kent, S., and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC - 2394, August 1998. - - [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security - Payload (ESP)", RFC 2406, November 1998. - - [ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and - Its Use With IPsec", RFC 2410, November 1998. - - [DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher - Algorithm With Explicit IV", RFC 2405, November 1998. - - [HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP - and AH", RFC 2403, November 1998. - - - - - -Piper Standards Track [Page 30] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - - [HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within - ESP and AH", RFC 2404, November 1998. - - [IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP - Payload Compression Protocol (IPComp)", RFC 2393, August - 1998. - - [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, - "Internet Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [LZS] Friend, R., and R. Monsour, "IP Payload Compression Using - LZS", RFC 2395, August 1998. - - [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC - 2412, November 1998. - - [X.501] ISO/IEC 9594-2, "Information Technology - Open Systems - Interconnection - The Directory: Models", CCITT/ITU - Recommendation X.501, 1993. - - [X.509] ISO/IEC 9594-8, "Information Technology - Open Systems - Interconnection - The Directory: Authentication - Framework", CCITT/ITU Recommendation X.509, 1993. - -Author's Address - - Derrell Piper - Network Alchemy - 1521.5 Pacific Ave - Santa Cruz, California, 95060 - United States of America - - Phone: +1 408 460-3822 - EMail: ddp@network-alchemy.com - - - - - - - - - - - - - -Piper Standards Track [Page 31] - -RFC 2407 IP Security Domain of Interpretation November 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Piper Standards Track [Page 32] - diff --git a/doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt b/doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt deleted file mode 100644 index c3af56268..000000000 --- a/doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt +++ /dev/null @@ -1,4819 +0,0 @@ - - - - - - -Network Working Group D. Maughan -Request for Comments: 2408 National Security Agency -Category: Standards Track M. Schertler - Securify, Inc. - M. Schneider - National Security Agency - J. Turner - RABA Technologies, Inc. - November 1998 - - - Internet Security Association and Key Management Protocol (ISAKMP) - -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 Internet Society (1998). All Rights Reserved. - -Abstract - - This memo describes a protocol utilizing security concepts necessary - for establishing Security Associations (SA) and cryptographic keys in - an Internet environment. A Security Association protocol that - negotiates, establishes, modifies and deletes Security Associations - and their attributes is required for an evolving Internet, where - there will be numerous security mechanisms and several options for - each security mechanism. The key management protocol must be robust - in order to handle public key generation for the Internet community - at large and private key requirements for those private networks with - that requirement. The Internet Security Association and Key - Management Protocol (ISAKMP) defines the procedures for - authenticating a communicating peer, creation and management of - Security Associations, key generation techniques, and threat - mitigation (e.g. denial of service and replay attacks). All of - these are necessary to establish and maintain secure communications - (via IP Security Service or any other security protocol) in an - Internet environment. - - - - - - - -Maughan, et. al. Standards Track [Page 1] - -RFC 2408 ISAKMP November 1998 - - -Table of Contents - - 1 Introduction 4 - 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . 5 - 1.2 The Need for Negotiation . . . . . . . . . . . . . . . . . 5 - 1.3 What can be Negotiated? . . . . . . . . . . . . . . . . . 6 - 1.4 Security Associations and Management . . . . . . . . . . . 7 - 1.4.1 Security Associations and Registration . . . . . . . . 7 - 1.4.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 8 - 1.5 Authentication . . . . . . . . . . . . . . . . . . . . . . 8 - 1.5.1 Certificate Authorities . . . . . . . . . . . . . . . 9 - 1.5.2 Entity Naming . . . . . . . . . . . . . . . . . . . . 9 - 1.5.3 ISAKMP Requirements . . . . . . . . . . . . . . . . . 10 - 1.6 Public Key Cryptography . . . . . . . . . . . . . . . . . . 10 - 1.6.1 Key Exchange Properties . . . . . . . . . . . . . . . 11 - 1.6.2 ISAKMP Requirements . . . . . . . . . . . . . . . . . 12 - 1.7 ISAKMP Protection . . . . . . . . . . . . . . . . . . . . . 12 - 1.7.1 Anti-Clogging (Denial of Service) . . . . . . . . . . 12 - 1.7.2 Connection Hijacking . . . . . . . . . . . . . . . . . 13 - 1.7.3 Man-in-the-Middle Attacks . . . . . . . . . . . . . . 13 - 1.8 Multicast Communications . . . . . . . . . . . . . . . . . 13 - 2 Terminology and Concepts 14 - 2.1 ISAKMP Terminology . . . . . . . . . . . . . . . . . . . . 14 - 2.2 ISAKMP Placement . . . . . . . . . . . . . . . . . . . . . 16 - 2.3 Negotiation Phases . . . . . . . . . . . . . . . . . . . . 16 - 2.4 Identifying Security Associations . . . . . . . . . . . . . 17 - 2.5 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 20 - 2.5.1 Transport Protocol . . . . . . . . . . . . . . . . . . 20 - 2.5.2 RESERVED Fields . . . . . . . . . . . . . . . . . . . 20 - 2.5.3 Anti-Clogging Token ("Cookie") Creation . . . . . . . 20 - 3 ISAKMP Payloads 21 - 3.1 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 21 - 3.2 Generic Payload Header . . . . . . . . . . . . . . . . . . 25 - 3.3 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 25 - 3.4 Security Association Payload . . . . . . . . . . . . . . . 27 - 3.5 Proposal Payload . . . . . . . . . . . . . . . . . . . . . 28 - 3.6 Transform Payload . . . . . . . . . . . . . . . . . . . . . 29 - 3.7 Key Exchange Payload . . . . . . . . . . . . . . . . . . . 31 - 3.8 Identification Payload . . . . . . . . . . . . . . . . . . 32 - 3.9 Certificate Payload . . . . . . . . . . . . . . . . . . . . 33 - 3.10 Certificate Request Payload . . . . . . . . . . . . . . . 34 - 3.11 Hash Payload . . . . . . . . . . . . . . . . . . . . . . 36 - 3.12 Signature Payload . . . . . . . . . . . . . . . . . . . . 37 - 3.13 Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 37 - 3.14 Notification Payload . . . . . . . . . . . . . . . . . . 38 - 3.14.1 Notify Message Types . . . . . . . . . . . . . . . . 40 - 3.15 Delete Payload . . . . . . . . . . . . . . . . . . . . . 41 - 3.16 Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 43 - - - -Maughan, et. al. Standards Track [Page 2] - -RFC 2408 ISAKMP November 1998 - - - 4 ISAKMP Exchanges 44 - 4.1 ISAKMP Exchange Types . . . . . . . . . . . . . . . . . . . 45 - 4.1.1 Notation . . . . . . . . . . . . . . . . . . . . . . . 46 - 4.2 Security Association Establishment . . . . . . . . . . . . 46 - 4.2.1 Security Association Establishment Examples . . . . . 48 - 4.3 Security Association Modification . . . . . . . . . . . . . 50 - 4.4 Base Exchange . . . . . . . . . . . . . . . . . . . . . . . 51 - 4.5 Identity Protection Exchange . . . . . . . . . . . . . . . 52 - 4.6 Authentication Only Exchange . . . . . . . . . . . . . . . 54 - 4.7 Aggressive Exchange . . . . . . . . . . . . . . . . . . . . 55 - 4.8 Informational Exchange . . . . . . . . . . . . . . . . . . 57 - 5 ISAKMP Payload Processing 58 - 5.1 General Message Processing . . . . . . . . . . . . . . . . 58 - 5.2 ISAKMP Header Processing . . . . . . . . . . . . . . . . . 59 - 5.3 Generic Payload Header Processing . . . . . . . . . . . . . 61 - 5.4 Security Association Payload Processing . . . . . . . . . . 62 - 5.5 Proposal Payload Processing . . . . . . . . . . . . . . . . 63 - 5.6 Transform Payload Processing . . . . . . . . . . . . . . . 64 - 5.7 Key Exchange Payload Processing . . . . . . . . . . . . . . 65 - 5.8 Identification Payload Processing . . . . . . . . . . . . . 66 - 5.9 Certificate Payload Processing . . . . . . . . . . . . . . 66 - 5.10 Certificate Request Payload Processing . . . . . . . . . 67 - 5.11 Hash Payload Processing . . . . . . . . . . . . . . . . . 69 - 5.12 Signature Payload Processing . . . . . . . . . . . . . . 69 - 5.13 Nonce Payload Processing . . . . . . . . . . . . . . . . 70 - 5.14 Notification Payload Processing . . . . . . . . . . . . . 71 - 5.15 Delete Payload Processing . . . . . . . . . . . . . . . . 73 - 6 Conclusions 75 - A ISAKMP Security Association Attributes 77 - A.1 Background/Rationale . . . . . . . . . . . . . . . . . . . 77 - A.2 Internet IP Security DOI Assigned Value . . . . . . . . . . 77 - A.3 Supported Security Protocols . . . . . . . . . . . . . . . 77 - A.4 ISAKMP Identification Type Values . . . . . . . . . . . . . 78 - A.4.1 ID_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . 78 - A.4.2 ID_IPV4_ADDR_SUBNET . . . . . . . . . . . . . . . . . . 78 - A.4.3 ID_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . 78 - A.4.4 ID_IPV6_ADDR_SUBNET . . . . . . . . . . . . . . . . . 78 - B Defining a new Domain of Interpretation 79 - B.1 Situation . . . . . . . . . . . . . . . . . . . . . . . . . 79 - B.2 Security Policies . . . . . . . . . . . . . . . . . . . . . 80 - B.3 Naming Schemes . . . . . . . . . . . . . . . . . . . . . . 80 - B.4 Syntax for Specifying Security Services . . . . . . . . . . 80 - B.5 Payload Specification . . . . . . . . . . . . . . . . . . . 80 - B.6 Defining new Exchange Types . . . . . . . . . . . . . . . . 80 - Security Considerations 81 - IANA Considerations 81 - Domain of Interpretation 81 - Supported Security Protocols 82 - - - -Maughan, et. al. Standards Track [Page 3] - -RFC 2408 ISAKMP November 1998 - - - Acknowledgements 82 - References 82 - Authors' Addresses 85 - Full Copyright Statement 86 - -List of Figures - - 1 ISAKMP Relationships . . . . . . . . . . . . . . . . . . . 16 - 2 ISAKMP Header Format . . . . . . . . . . . . . . . . . . . 22 - 3 Generic Payload Header . . . . . . . . . . . . . . . . . . 25 - 4 Data Attributes . . . . . . . . . . . . . . . . . . . . . . 26 - 5 Security Association Payload . . . . . . . . . . . . . . . 27 - 6 Proposal Payload Format . . . . . . . . . . . . . . . . . . 28 - 7 Transform Payload Format . . . . . . . . . . . . . . . . . 30 - 8 Key Exchange Payload Format . . . . . . . . . . . . . . . . 31 - 9 Identification Payload Format . . . . . . . . . . . . . . . 32 - 10 Certificate Payload Format . . . . . . . . . . . . . . . . 33 - 11 Certificate Request Payload Format . . . . . . . . . . . . 34 - 12 Hash Payload Format . . . . . . . . . . . . . . . . . . . . 36 - 13 Signature Payload Format . . . . . . . . . . . . . . . . . 37 - 14 Nonce Payload Format . . . . . . . . . . . . . . . . . . . 38 - 15 Notification Payload Format . . . . . . . . . . . . . . . . 39 - 16 Delete Payload Format . . . . . . . . . . . . . . . . . . . 42 - 17 Vendor ID Payload Format . . . . . . . . . . . . . . . . . 44 - -1 Introduction - - This document describes an Internet Security Association and Key - Management Protocol (ISAKMP). ISAKMP combines the security concepts - of authentication, key management, and security associations to - establish the required security for government, commercial, and - private communications on the Internet. - - The Internet Security Association and Key Management Protocol - (ISAKMP) defines procedures and packet formats to establish, - negotiate, modify and delete Security Associations (SA). SAs contain - all the information required for execution of various network - security services, such as the IP layer services (such as header - authentication and payload encapsulation), transport or application - layer services, or self-protection of negotiation traffic. ISAKMP - defines payloads for exchanging key generation and authentication - data. These formats provide a consistent framework for transferring - key and authentication data which is independent of the key - generation technique, encryption algorithm and authentication - mechanism. - - - - - - -Maughan, et. al. Standards Track [Page 4] - -RFC 2408 ISAKMP November 1998 - - - ISAKMP is distinct from key exchange protocols in order to cleanly - separate the details of security association management (and key - management) from the details of key exchange. There may be many - different key exchange protocols, each with different security - properties. However, a common framework is required for agreeing to - the format of SA attributes, and for negotiating, modifying, and - deleting SAs. ISAKMP serves as this common framework. - - Separating the functionality into three parts adds complexity to the - security analysis of a complete ISAKMP implementation. However, the - separation is critical for interoperability between systems with - differing security requirements, and should also simplify the - analysis of further evolution of a ISAKMP server. - - ISAKMP is intended to support the negotiation of SAs for security - protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, - OSPF, etc.). By centralizing the management of the security - associations, ISAKMP reduces the amount of duplicated functionality - within each security protocol. ISAKMP can also reduce connection - setup time, by negotiating a whole stack of services at once. - - The remainder of section 1 establishes the motivation for security - negotiation and outlines the major components of ISAKMP, i.e. - Security Associations and Management, Authentication, Public Key - Cryptography, and Miscellaneous items. Section 2 presents the - terminology and concepts associated with ISAKMP. Section 3 describes - the different ISAKMP payload formats. Section 4 describes how the - payloads of ISAKMP are composed together as exchange types to - establish security associations and perform key exchanges in an - authenticated manner. Additionally, security association - modification, deletion, and error notification are discussed. - Section 5 describes the processing of each payload within the context - of ISAKMP exchanges, including error handling and associated actions. - The appendices provide the attribute values necessary for ISAKMP and - requirement for defining a new Domain of Interpretation (DOI) within - ISAKMP. - -1.1 Requirements Terminology - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in [RFC-2119]. - -1.2 The Need for Negotiation - - ISAKMP extends the assertion in [DOW92] that authentication and key - exchanges must be combined for better security to include security - association exchanges. The security services required for - - - -Maughan, et. al. Standards Track [Page 5] - -RFC 2408 ISAKMP November 1998 - - - communications depends on the individual network configurations and - environments. Organizations are setting up Virtual Private Networks - (VPN), also known as Intranets, that will require one set of security - functions for communications within the VPN and possibly many - different security functions for communications outside the VPN to - support geographically separate organizational components, customers, - suppliers, sub-contractors (with their own VPNs), government, and - others. Departments within large organizations may require a number - of security associations to separate and protect data (e.g. - personnel data, company proprietary data, medical) on internal - networks and other security associations to communicate within the - same department. Nomadic users wanting to "phone home" represent - another set of security requirements. These requirements must be - tempered with bandwidth challenges. Smaller groups of people may - meet their security requirements by setting up "Webs of Trust". - ISAKMP exchanges provide these assorted networking communities the - ability to present peers with the security functionality that the - user supports in an authenticated and protected manner for agreement - upon a common set of security attributes, i.e. an interoperable - security association. - -1.3 What can be Negotiated? - - Security associations must support different encryption algorithms, - authentication mechanisms, and key establishment algorithms for other - security protocols, as well as IP Security. Security associations - must also support host-oriented certificates for lower layer - protocols and user- oriented certificates for higher level protocols. - Algorithm and mechanism independence is required in applications such - as e-mail, remote login, and file transfer, as well as in session - oriented protocols, routing protocols, and link layer protocols. - ISAKMP provides a common security association and key establishment - protocol for this wide range of security protocols, applications, - security requirements, and network environments. - - ISAKMP is not bound to any specific cryptographic algorithm, key - generation technique, or security mechanism. This flexibility is - beneficial for a number of reasons. First, it supports the dynamic - communications environment described above. Second, the independence - from specific security mechanisms and algorithms provides a forward - migration path to better mechanisms and algorithms. When improved - security mechanisms are developed or new attacks against current - encryption algorithms, authentication mechanisms and key exchanges - are discovered, ISAKMP will allow the updating of the algorithms and - mechanisms without having to develop a completely new KMP or patch - the current one. - - - - - -Maughan, et. al. Standards Track [Page 6] - -RFC 2408 ISAKMP November 1998 - - - ISAKMP has basic requirements for its authentication and key exchange - components. These requirements guard against denial of service, - replay / reflection, man-in-the-middle, and connection hijacking - attacks. This is important because these are the types of attacks - that are targeted against protocols. Complete Security Association - (SA) support, which provides mechanism and algorithm independence, - and protection from protocol threats are the strengths of ISAKMP. - -1.4 Security Associations and Management - - A Security Association (SA) is a relationship between two or more - entities that describes how the entities will utilize security - services to communicate securely. This relationship is represented - by a set of information that can be considered a contract between the - entities. The information must be agreed upon and shared between all - the entities. Sometimes the information alone is referred to as an - SA, but this is just a physical instantiation of the existing - relationship. The existence of this relationship, represented by the - information, is what provides the agreed upon security information - needed by entities to securely interoperate. All entities must - adhere to the SA for secure communications to be possible. When - accessing SA attributes, entities use a pointer or identifier refered - to as the Security Parameter Index (SPI). [SEC-ARCH] provides details - on IP Security Associations (SA) and Security Parameter Index (SPI) - definitions. - -1.4.1 Security Associations and Registration - - The SA attributes required and recommended for the IP Security (AH, - ESP) are defined in [SEC-ARCH]. The attributes specified for an IP - Security SA include, but are not limited to, authentication - mechanism, cryptographic algorithm, algorithm mode, key length, and - Initialization Vector (IV). Other protocols that provide algorithm - and mechanism independent security MUST define their requirements for - SA attributes. The separation of ISAKMP from a specific SA - definition is important to ensure ISAKMP can es tablish SAs for all - possible security protocols and applications. - - NOTE: See [IPDOI] for a discussion of SA attributes that should be - considered when defining a security protocol or application. - - In order to facilitate easy identification of specific attributes - (e.g. a specific encryption algorithm) among different network - entites the attributes must be assigned identifiers and these - identifiers must be registered by a central authority. The Internet - Assigned Numbers Authority (IANA) provides this function for the - Internet. - - - - -Maughan, et. al. Standards Track [Page 7] - -RFC 2408 ISAKMP November 1998 - - -1.4.2 ISAKMP Requirements - - Security Association (SA) establishment MUST be part of the key - management protocol defined for IP based networks. The SA concept is - required to support security protocols in a diverse and dynamic - networking environment. Just as authentication and key exchange must - be linked to provide assurance that the key is established with the - authenticated party [DOW92], SA establishment must be linked with the - authentication and the key exchange protocol. - - ISAKMP provides the protocol exchanges to establish a security - association between negotiating entities followed by the - establishment of a security association by these negotiating entities - in behalf of some protocol (e.g. ESP/AH). First, an initial protocol - exchange allows a basic set of security attributes to be agreed upon. - This basic set provides protection for subsequent ISAKMP exchanges. - It also indicates the authentication method and key exchange that - will be performed as part of the ISAKMP protocol. If a basic set of - security attributes is already in place between the negotiating - server entities, the initial ISAKMP exchange may be skipped and the - establishment of a security association can be done directly. After - the basic set of security attributes has been agreed upon, initial - identity authenticated, and required keys generated, the established - SA can be used for subsequent communications by the entity that - invoked ISAKMP. The basic set of SA attributes that MUST be - implemented to provide ISAKMP interoperability are defined in - Appendix A. - -1.5 Authentication - - A very important step in establishing secure network communications - is authentication of the entity at the other end of the - communication. Many authentication mechanisms are available. - Authentication mechanisms fall into two catagories of strength - weak - and strong. Sending cleartext keys or other unprotected - authenticating information over a network is weak, due to the threat - of reading them with a network sniffer. Additionally, sending one- - way hashed poorly-chosen keys with low entropy is also weak, due to - the threat of brute-force guessing attacks on the sniffed messages. - While passwords can be used for establishing identity, they are not - considered in this context because of recent statements from the - Internet Architecture Board [IAB]. Digital signatures, such as the - Digital Signature Standard (DSS) and the Rivest-Shamir-Adleman (RSA) - signature, are public key based strong authentication mechanisms. - When using public key digital signatures each entity requires a - public key and a private key. Certificates are an essential part of - a digital signature authentication mechanism. Certificates bind a - specific entity's identity (be it host, network, user, or - - - -Maughan, et. al. Standards Track [Page 8] - -RFC 2408 ISAKMP November 1998 - - - application) to its public keys and possibly other security-related - information such as privileges, clearances, and compartments. - Authentication based on digital signatures requires a trusted third - party or certificate authority to create, sign and properly - distribute certificates. For more detailed information on digital - signatures, such as DSS and RSA, and certificates see [Schneier]. - -1.5.1 Certificate Authorities - - Certificates require an infrastructure for generation, verification, - revocation, management and distribution. The Internet Policy - Registration Authority (IPRA) [RFC-1422] has been established to - direct this infrastructure for the IETF. The IPRA certifies Policy - Certification Authorities (PCA). PCAs control Certificate Authorities - (CA) which certify users and subordinate entities. Current - certificate related work includes the Domain Name System (DNS) - Security Extensions [DNSSEC] which will provide signed entity keys in - the DNS. The Public Key Infrastucture (PKIX) working group is - specifying an Internet profile for X.509 certificates. There is also - work going on in industry to develop X.500 Directory Services which - would provide X.509 certificates to users. The U.S. Post Office is - developing a (CA) hierarchy. The NIST Public Key Infrastructure - Working Group has also been doing work in this area. The DOD Multi - Level Information System Security Initiative (MISSI) program has - begun deploying a certificate infrastructure for the U.S. Government. - Alternatively, if no infrastructure exists, the PGP Web of Trust - certificates can be used to provide user authentication and privacy - in a community of users who know and trust each other. - -1.5.2 Entity Naming - - An entity's name is its identity and is bound to its public keys in - certificates. The CA MUST define the naming semantics for the - certificates it issues. See the UNINETT PCA Policy Statements - [Berge] for an example of how a CA defines its naming policy. When - the certificate is verified, the name is verified and that name will - have meaning within the realm of that CA. An example is the DNS - security extensions which make DNS servers CAs for the zones and - nodes they serve. Resource records are provided for public keys and - signatures on those keys. The names associated with the keys are IP - addresses and domain names which have meaning to entities accessing - the DNS for this information. A Web of Trust is another example. - When webs of trust are set up, names are bound with the public keys. - In PGP the name is usually the entity's e-mail address which has - meaning to those, and only those, who understand e-mail. Another web - of trust could use an entirely different naming scheme. - - - - - -Maughan, et. al. Standards Track [Page 9] - -RFC 2408 ISAKMP November 1998 - - -1.5.3 ISAKMP Requirements - - Strong authentication MUST be provided on ISAKMP exchanges. Without - being able to authenticate the entity at the other end, the Security - Association (SA) and session key established are suspect. Without - authentication you are unable to trust an entity's identification, - which makes access control questionable. While encryption (e.g. - ESP) and integrity (e.g. AH) will protect subsequent communications - from passive eavesdroppers, without authentication it is possible - that the SA and key may have been established with an adversary who - performed an active man-in-the-middle attack and is now stealing all - your personal data. - - A digital signature algorithm MUST be used within ISAKMP's - authentication component. However, ISAKMP does not mandate a - specific signature algorithm or certificate authority (CA). ISAKMP - allows an entity initiating communications to indicate which CAs it - supports. After selection of a CA, the protocol provides the - messages required to support the actual authentication exchange. The - protocol provides a facility for identification of different - certificate authorities, certificate types (e.g. X.509, PKCS #7, - PGP, DNS SIG and KEY records), and the exchange of the certificates - identified. - - ISAKMP utilizes digital signatures, based on public key cryptography, - for authentication. There are other strong authentication systems - available, which could be specified as additional optional - authentication mechanisms for ISAKMP. Some of these authentication - systems rely on a trusted third party called a key distribution - center (KDC) to distribute secret session keys. An example is - Kerberos, where the trusted third party is the Kerberos server, which - holds secret keys for all clients and servers within its network - domain. A client's proof that it holds its secret key provides - authenticaton to a server. - - The ISAKMP specification does not specify the protocol for - communicating with the trusted third parties (TTP) or certificate - directory services. These protocols are defined by the TTP and - directory service themselves and are outside the scope of this - specification. The use of these additional services and protocols - will be described in a Key Exchange specific document. - -1.6 Public Key Cryptography - - Public key cryptography is the most flexible, scalable, and efficient - way for users to obtain the shared secrets and session keys needed to - support the large number of ways Internet users will interoperate. - Many key generation algorithms, that have different properties, are - - - -Maughan, et. al. Standards Track [Page 10] - -RFC 2408 ISAKMP November 1998 - - - available to users (see [DOW92], [ANSI], and [Oakley]). Properties - of key exchange protocols include the key establishment method, - authentication, symmetry, perfect forward secrecy, and back traffic - protection. - - NOTE: Cryptographic keys can protect information for a considerable - length of time. However, this is based on the assumption that keys - used for protection of communications are destroyed after use and not - kept for any reason. - -1.6.1 Key Exchange Properties - - Key Establishment (Key Generation / Key Transport): The two common - methods of using public key cryptography for key establishment are - key transport and key generation. An example of key transport is the - use of the RSA algorithm to encrypt a randomly generated session key - (for encrypting subsequent communications) with the recipient's - public key. The encrypted random key is then sent to the recipient, - who decrypts it using his private key. At this point both sides have - the same session key, however it was created based on input from only - one side of the communications. The benefit of the key transport - method is that it has less computational overhead than the following - method. The Diffie-Hellman (D-H) algorithm illustrates key - generation using public key cryptography. The D-H algorithm is begun - by two users exchanging public information. Each user then - mathematically combines the other's public information along with - their own secret information to compute a shared secret value. This - secret value can be used as a session key or as a key encryption key - for encrypting a randomly generated session key. This method - generates a session key based on public and secret information held - by both users. The benefit of the D-H algorithm is that the key used - for encrypting messages is based on information held by both users - and the independence of keys from one key exchange to another - provides perfect forward secrecy. Detailed descriptions of these - algorithms can be found in [Schneier]. There are a number of - variations on these two key generation schemes and these variations - do not necessarily interoperate. - - Key Exchange Authentication: Key exchanges may be authenticated - during the protocol or after protocol completion. Authentication of - the key exchange during the protocol is provided when each party - provides proof it has the secret session key before the end of the - protocol. Proof can be provided by encrypting known data in the - secret session key during the protocol echange. Authentication after - the protocol must occur in subsequent commu nications. - Authentication during the protocol is preferred so subsequent - communications are not initiated if the secret session key is not - established with the desired party. - - - -Maughan, et. al. Standards Track [Page 11] - -RFC 2408 ISAKMP November 1998 - - - Key Exchange Symmetry: A key exchange provides symmetry if either - party can initiate the exchange and exchanged messages can cross in - transit without affecting the key that is generated. This is - desirable so that computation of the keys does not require either - party to know who initated the exchange. While key exchange symmetry - is desirable, symmetry in the entire key management protocol may - provide a vulnerablity to reflection attacks. - - Perfect Forward Secrecy: As described in [DOW92], an authenticated - key exchange protocol provides perfect forward secrecy if disclosure - of longterm secret keying material does not compromise the secrecy of - the exchanged keys from previous communications. The property of - perfect forward secrecy does not apply to key exchange without - authentication. - -1.6.2 ISAKMP Requirements - - An authenticated key exchange MUST be supported by ISAKMP. Users - SHOULD choose additional key establishment algorithms based on their - requirements. ISAKMP does not specify a specific key exchange. - However, [IKE] describes a proposal for using the Oakley key exchange - [Oakley] in conjunction with ISAKMP. Requirements that should be - evaluated when choosing a key establishment algorithm include - establishment method (generation vs. transport), perfect forward - secrecy, computational overhead, key escrow, and key strength. Based - on user requirements, ISAKMP allows an entity initiating - communications to indicate which key exchanges it supports. After - selection of a key exchange, the protocol provides the messages - required to support the actual key establishment. - -1.7 ISAKMP Protection - -1.7.1 Anti-Clogging (Denial of Service) - - Of the numerous security services available, protection against - denial of service always seems to be one of the most difficult to - address. A "cookie" or anti-clogging token (ACT) is aimed at - protecting the computing resources from attack without spending - excessive CPU resources to determine its authenticity. An exchange - prior to CPU-intensive public key operations can thwart some denial - of service attempts (e.g. simple flooding with bogus IP source - addresses). Absolute protection against denial of service is - impossible, but this anti-clogging token provides a technique for - making it easier to handle. The use of an anti-clogging token was - introduced by Karn and Simpson in [Karn]. - - - - - - -Maughan, et. al. Standards Track [Page 12] - -RFC 2408 ISAKMP November 1998 - - - It should be noted that in the exchanges shown in section 4, the - anticlogging mechanism should be used in conjuction with a garbage- - state collection mechanism; an attacker can still flood a server - using packets with bogus IP addresses and cause state to be created. - Such aggressive memory management techniques SHOULD be employed by - protocols using ISAKMP that do not go through an initial, anti- - clogging only phase, as was done in [Karn]. - -1.7.2 Connection Hijacking - - ISAKMP prevents connection hijacking by linking the authentication, - key exchange and security association exchanges. This linking - prevents an attacker from allowing the authentication to complete and - then jumping in and impersonating one entity to the other during the - key and security association exchanges. - -1.7.3 Man-in-the-Middle Attacks - - Man-in-the-Middle attacks include interception, insertion, deletion, - and modification of messages, reflecting messages back at the sender, - replaying old messages and redirecting messages. ISAKMP features - prevent these types of attacks from being successful. The linking of - the ISAKMP exchanges prevents the insertion of messages in the - protocol exchange. The ISAKMP protocol state machine is defined so - deleted messages will not cause a partial SA to be created, the state - machine will clear all state and return to idle. The state machine - also prevents reflection of a message from causing harm. The - requirement for a new cookie with time variant material for each new - SA establishment prevents attacks that involve replaying old - messages. The ISAKMP strong authentication requirement prevents an - SA from being established with anyone other than the intended party. - Messages may be redirected to a different destination or modified but - this will be detected and an SA will not be established. The ISAKMP - specification defines where abnormal processing has occurred and - recommends notifying the appropriate party of this abnormality. - -1.8 Multicast Communications - - It is expected that multicast communications will require the same - security services as unicast communications and may introduce the - need for additional security services. The issues of distributing - SPIs for multicast traffic are presented in [SEC-ARCH]. Multicast - security issues are also discussed in [RFC-1949] and [BC]. A future - extension to ISAKMP will support multicast key distribution. For an - introduction to the issues related to multicast security, consult the - Internet Drafts, [RFC-2094] and [RFC-2093], describing Sparta's - research in this area. - - - - -Maughan, et. al. Standards Track [Page 13] - -RFC 2408 ISAKMP November 1998 - - -2 Terminology and Concepts - -2.1 ISAKMP Terminology - - Security Protocol: A Security Protocol consists of an entity at a - single point in the network stack, performing a security service for - network communication. For example, IPSEC ESP and IPSEC AH are two - different security protocols. TLS is another example. Security - Protocols may perform more than one service, for example providing - integrity and confidentiality in one module. - - Protection Suite: A protection suite is a list of the security - services that must be applied by various security protocols. For - example, a protection suite may consist of DES encryption in IP ESP, - and keyed MD5 in IP AH. All of the protections in a suite must be - treated as a single unit. This is necessary because security - services in different security protocols can have subtle - interactions, and the effects of a suite must be analyzed and - verified as a whole. - - Security Association (SA): A Security Association is a security- - protocol- specific set of parameters that completely defines the - services and mechanisms necessary to protect traffic at that security - protocol location. These parameters can include algorithm - identifiers, modes, cryptographic keys, etc. The SA is referred to - by its associated security protocol (for example, "ISAKMP SA", "ESP - SA", "TLS SA"). - - ISAKMP SA: An SA used by the ISAKMP servers to protect their own - traffic. Sections 2.3 and 2.4 provide more details about ISAKMP SAs. - - Security Parameter Index (SPI): An identifier for a Security - Assocation, relative to some security protocol. Each security - protocol has its own "SPI-space". A (security protocol, SPI) pair - may uniquely identify an SA. The uniqueness of the SPI is - implementation dependent, but could be based per system, per - protocol, or other options. Depending on the DOI, additional - information (e.g. host address) may be necessary to identify an SA. - The DOI will also determine which SPIs (i.e. initiator's or - responder's) are sent during communication. - - Domain of Interpretation: A Domain of Interpretation (DOI) defines - payload formats, exchange types, and conventions for naming - security-relevant information such as security policies or - cryptographic algorithms and modes. A Domain of Interpretation (DOI) - identifier is used to interpret the payloads of ISAKMP payloads. A - system SHOULD support multiple Domains of Interpretation - simultaneously. The concept of a DOI is based on previous work by - - - -Maughan, et. al. Standards Track [Page 14] - -RFC 2408 ISAKMP November 1998 - - - the TSIG CIPSO Working Group, but extends beyond security label - interpretation to include naming and interpretation of security - services. A DOI defines: - - o A "situation": the set of information that will be used to - determine the required security services. - - o The set of security policies that must, and may, be supported. - - o A syntax for the specification of proposed security services. - - o A scheme for naming security-relevant information, including - encryption algorithms, key exchange algorithms, security policy - attributes, and certificate authorities. - - o The specific formats of the various payload contents. - - o Additional exchange types, if required. - - The rules for the IETF IP Security DOI are presented in [IPDOI]. - Specifications of the rules for customized DOIs will be presented in - separate documents. - - Situation: A situation contains all of the security-relevant - information that a system considers necessary to decide the security - services required to protect the session being negotiated. The - situation may include addresses, security classifications, modes of - operation (normal vs. emergency), etc. - - Proposal: A proposal is a list, in decreasing order of preference, of - the protection suites that a system considers acceptable to protect - traffic under a given situation. - - Payload: ISAKMP defines several types of payloads, which are used to - transfer information such as security association data, or key - exchange data, in DOI-defined formats. A payload consists of a - generic payload header and a string of octects that is opaque to - ISAKMP. ISAKMP uses DOI- specific functionality to synthesize and - interpret these payloads. Multiple payloads can be sent in a single - ISAKMP message. See section 3 for more details on the payload types, - and [IPDOI] for the formats of the IETF IP Security DOI payloads. - - Exchange Type: An exchange type is a specification of the number of - messages in an ISAKMP exchange, and the payload types that are - contained in each of those messages. Each exchange type is designed - to provide a particular set of security services, such as anonymity - of the participants, perfect forward secrecy of the keying material, - authentication of the participants, etc. Section 4.1 defines the - - - -Maughan, et. al. Standards Track [Page 15] - -RFC 2408 ISAKMP November 1998 - - - default set of ISAKMP exchange types. Other exchange types can be - added to support additional key exchanges, if required. - -2.2 ISAKMP Placement - - Figure 1 is a high level view of the placement of ISAKMP within a - system context in a network architecture. An important part of - negotiating security services is to consider the entire "stack" of - individual SAs as a unit. This is referred to as a "protection - suite". - - +------------+ +--------+ +--------------+ - ! DOI ! ! ! ! Application ! - ! Definition ! <----> ! ISAKMP ! ! Process ! - +------------+ --> ! ! !--------------! - +--------------+ ! +--------+ ! Appl Protocol! - ! Key Exchange ! ! ^ ^ +--------------+ - ! Definition !<-- ! ! ^ - +--------------+ ! ! ! - ! ! ! - !----------------! ! ! - v ! ! - +-------+ v v - ! API ! +---------------------------------------------+ - +-------+ ! Socket Layer ! - ! !---------------------------------------------! - v ! Transport Protocol (TCP / UDP) ! - +----------+ !---------------------------------------------! - ! Security ! <----> ! IP ! - ! Protocol ! !---------------------------------------------! - +----------+ ! Link Layer Protocol ! - +---------------------------------------------+ - - - Figure 1: ISAKMP Relationships - -2.3 Negotiation Phases - - ISAKMP offers two "phases" of negotiation. In the first phase, two - entities (e.g. ISAKMP servers) agree on how to protect further - negotiation traffic between themselves, establishing an ISAKMP SA. - This ISAKMP SA is then used to protect the negotiations for the - Protocol SA being requested. Two entities (e.g. ISAKMP servers) can - negotiate (and have active) multiple ISAKMP SAs. - - - - - - - -Maughan, et. al. Standards Track [Page 16] - -RFC 2408 ISAKMP November 1998 - - - The second phase of negotiation is used to establish security - associations for other security protocols. This second phase can be - used to establish many security associations. The security - associations established by ISAKMP during this phase can be used by a - security protocol to protect many message/data exchanges. - - While the two-phased approach has a higher start-up cost for most - simple scenarios, there are several reasons that it is beneficial for - most cases. - - First, entities (e.g. ISAKMP servers) can amortize the cost of the - first phase across several second phase negotiations. This allows - multiple SAs to be established between peers over time without having - to start over for each communication. - - Second, security services negotiated during the first phase provide - security properties for the second phase. For example, after the - first phase of negotiation, the encryption provided by the ISAKMP SA - can provide identity protection, potentially allowing the use of - simpler second-phase exchanges. On the other hand, if the channel - established during the first phase is not adequate to protect - identities, then the second phase must negotiate adequate security - mechanisms. - - Third, having an ISAKMP SA in place considerably reduces the cost of - ISAKMP management activity - without the "trusted path" that an - ISAKMP SA gives you, the entities (e.g. ISAKMP servers) would have - to go through a complete re-authentication for each error - notification or deletion of an SA. - - Negotiation during each phase is accomplished using ISAKMP-defined - exchanges (see section 4) or exchanges defined for a key exchange - within a DOI. - - Note that security services may be applied differently in each - negotiation phase. For example, different parties are being - authenticated during each of the phases of negotiation. During the - first phase, the parties being authenticated may be the ISAKMP - servers/hosts, while during the second phase, users or application - level programs are being authenticated. - -2.4 Identifying Security Associations - - While bootstrapping secure channels between systems, ISAKMP cannot - assume the existence of security services, and must provide some - protections for itself. Therefore, ISAKMP considers an ISAKMP - Security Association to be different than other types, and manages - ISAKMP SAs itself, in their own name space. ISAKMP uses the two - - - -Maughan, et. al. Standards Track [Page 17] - -RFC 2408 ISAKMP November 1998 - - - cookie fields in the ISAKMP header to identify ISAKMP SAs. The - Message ID in the ISAKMP Header and the SPI field in the Proposal - payload are used during SA establishment to identify the SA for other - security protocols. The interpretation of these four fields is - dependent on the operation taking place. - - The following table shows the presence or absence of several fields - during SA establishment. The following fields are necessary for - various operations associated with SA establishment: cookies in the - ISAKMP header, the ISAKMP Header Message ID field, and the SPI field - in the Proposal payload. An 'X' in the column means the value MUST - be present. An 'NA' in the column means a value in the column is Not - Applicable to the operation. - - # Operation I-Cookie R-Cookie Message ID SPI - (1) Start ISAKMP SA negotiation X 0 0 0 - (2) Respond ISAKMP SA negotiation X X 0 0 - (3) Init other SA negotiation X X X X - (4) Respond other SA negotiation X X X X - (5) Other (KE, ID, etc.) X X X/0 NA - (6) Security Protocol (ESP, AH) NA NA NA X - - In the first line (1) of the table, the initiator includes the - Initiator Cookie field in the ISAKMP Header, using the procedures - outlined in sections 2.5.3 and 3.1. - - In the second line (2) of the table, the responder includes the - Initiator and Responder Cookie fields in the ISAKMP Header, using the - procedures outlined in sections 2.5.3 and 3.1. Additional messages - may be exchanged between ISAKMP peers, depending on the ISAKMP - exchange type used during the phase 1 negotiation. Once the phase 1 - exchange is completed, the Initiator and Responder cookies are - included in the ISAKMP Header of all subsequent communications - between the ISAKMP peers. - - During phase 1 negotiations, the initiator and responder cookies - determine the ISAKMP SA. Therefore, the SPI field in the Proposal - payload is redundant and MAY be set to 0 or it MAY contain the - transmitting entity's cookie. - - In the third line (3) of the table, the initiator associates a - Message ID with the Protocols contained in the SA Proposal. This - Message ID and the initiator's SPI(s) to be associated with each - protocol in the Proposal are sent to the responder. The SPI(s) will - be used by the security protocols once the phase 2 negotiation is - completed. - - - - - -Maughan, et. al. Standards Track [Page 18] - -RFC 2408 ISAKMP November 1998 - - - In the fourth line (4) of the table, the responder includes the same - Message ID and the responder's SPI(s) to be associated with each - protocol in the accepted Proposal. This information is returned to - the initiator. - - In the fifth line (5) of the table, the initiator and responder use - the Message ID field in the ISAKMP Header to keep track of the in- - progress protocol negotiation. This is only applicable for a phase 2 - exchange and the value MUST be 0 for a phase 1 exchange because the - combined cookies identify the ISAKMP SA. The SPI field in the - Proposal payload is not applicable because the Proposal payload is - only used during the SA negotiation message exchange (steps 3 and 4). - - In the sixth line (6) of the table, the phase 2 negotiation is - complete. The security protocols use the SPI(s) to determine which - security services and mechanisms to apply to the communication - between them. The SPI value shown in the sixth line (6) is not the - SPI field in the Proposal payload, but the SPI field contained within - the security protocol header. - - During the SA establishment, a SPI MUST be generated. ISAKMP is - designed to handle variable sized SPIs. This is accomplished by - using the SPI Size field within the Proposal payload during SA - establishment. Handling of SPIs will be outlined by the DOI - specification (e.g. [IPDOI]). - - When a security association (SA) is initially established, one side - assumes the role of initiator and the other the role of responder. - Once the SA is established, both the original initiator and responder - can initiate a phase 2 negotiation with the peer entity. Thus, - ISAKMP SAs are bidirectional in nature. - - Additionally, ISAKMP allows both initiator and responder to have some - control during the negotiation process. While ISAKMP is designed to - allow an SA negotiation that includes multiple proposals, the - initiator can maintain some control by only making one proposal in - accordance with the initiator's local security policy. Once the - initiator sends a proposal containing more than one proposal (which - are sent in decreasing preference order), the initiator relinquishes - control to the responder. Once the responder is controlling the SA - establishment, the responder can make its policy take precedence over - the initiator within the context of the multiple options offered by - the initiator. This is accomplished by selecting the proposal best - suited for the responder's local security policy and returning this - selection to the initiator. - - - - - - -Maughan, et. al. Standards Track [Page 19] - -RFC 2408 ISAKMP November 1998 - - -2.5 Miscellaneous - -2.5.1 Transport Protocol - - ISAKMP can be implemented over any transport protocol or over IP - itself. Implementations MUST include send and receive capability for - ISAKMP using the User Datagram Protocol (UDP) on port 500. UDP Port - 500 has been assigned to ISAKMP by the Internet Assigned Numbers - Authority (IANA). Implementations MAY additionally support ISAKMP - over other transport protocols or over IP itself. - -2.5.2 RESERVED Fields - - The existence of RESERVED fields within ISAKMP payloads are used - strictly to preserve byte alignment. All RESERVED fields in the - ISAKMP protocol MUST be set to zero (0) when a packet is issued. The - receiver SHOULD check the RESERVED fields for a zero (0) value and - discard the packet if other values are found. - -2.5.3 Anti-Clogging Token ("Cookie") Creation - - The details of cookie generation are implementation dependent, but - MUST satisfy these basic requirements (originally stated by Phil Karn - in [Karn]): - - 1. The cookie must depend on the specific parties. This - prevents an attacker from obtaining a cookie using a real IP - address and UDP port, and then using it to swamp the victim - with Diffie-Hellman requests from randomly chosen IP - addresses or ports. - - 2. It must not be possible for anyone other than the issuing - entity to generate cookies that will be accepted by that - entity. This implies that the issuing entity must use local - secret information in the generation and subsequent - verification of a cookie. It must not be possible to deduce - this secret information from any particular cookie. - - 3. The cookie generation function must be fast to thwart - attacks intended to sabotage CPU resources. - - Karn's suggested method for creating the cookie is to perform a fast - hash (e.g. MD5) over the IP Source and Destination Address, the UDP - Source and Destination Ports and a locally generated secret random - value. ISAKMP requires that the cookie be unique for each SA - establishment to help prevent replay attacks, therefore, the date and - time MUST be added to the information hashed. The generated cookies - are placed in the ISAKMP Header (described in section 3.1) Initiator - - - -Maughan, et. al. Standards Track [Page 20] - -RFC 2408 ISAKMP November 1998 - - - and Responder cookie fields. These fields are 8 octets in length, - thus, requiring a generated cookie to be 8 octets. Notify and Delete - messages (see sections 3.14, 3.15, and 4.8) are uni-directional - transmissions and are done under the protection of an existing ISAKMP - SA, thus, not requiring the generation of a new cookie. One - exception to this is the transmission of a Notify message during a - Phase 1 exchange, prior to completing the establishment of an SA. - Sections 3.14 and 4.8 provide additional details. - -3 ISAKMP Payloads - - ISAKMP payloads provide modular building blocks for constructing - ISAKMP messages. The presence and ordering of payloads in ISAKMP is - defined by and dependent upon the Exchange Type Field located in the - ISAKMP Header (see Figure 2). The ISAKMP payload types are discussed - in sections 3.4 through 3.15. The descriptions of the ISAKMP - payloads, messages, and exchanges (see Section 4) are shown using - network octet ordering. - -3.1 ISAKMP Header Format - - An ISAKMP message has a fixed header format, shown in Figure 2, - followed by a variable number of payloads. A fixed header simplifies - parsing, providing the benefit of protocol parsing software that is - less complex and easier to implement. The fixed header contains the - information required by the protocol to maintain state, process - payloads and possibly prevent denial of service or replay attacks. - - The ISAKMP Header fields are defined as follows: - - o Initiator Cookie (8 octets) - Cookie of entity that initiated SA - establishment, SA notification, or SA deletion. - - o Responder Cookie (8 octets) - Cookie of entity that is responding - to an SA establishment request, SA notification, or SA deletion. - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 21] - -RFC 2408 ISAKMP November 1998 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Initiator ! - ! Cookie ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Responder ! - ! Cookie ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Message ID ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 2: ISAKMP Header Format - - o Next Payload (1 octet) - Indicates the type of the first payload - in the message. The format for each payload is defined in - sections 3.4 through 3.16. The processing for the payloads is - defined in section 5. - - - Next Payload Type Value - NONE 0 - Security Association (SA) 1 - Proposal (P) 2 - Transform (T) 3 - Key Exchange (KE) 4 - Identification (ID) 5 - Certificate (CERT) 6 - Certificate Request (CR) 7 - Hash (HASH) 8 - Signature (SIG) 9 - Nonce (NONCE) 10 - Notification (N) 11 - Delete (D) 12 - Vendor ID (VID) 13 - RESERVED 14 - 127 - Private USE 128 - 255 - - o Major Version (4 bits) - indicates the major version of the ISAKMP - protocol in use. Implementations based on this version of the - ISAKMP Internet-Draft MUST set the Major Version to 1. - Implementations based on previous versions of ISAKMP Internet- - Drafts MUST set the Major Version to 0. Implementations SHOULD - - - -Maughan, et. al. Standards Track [Page 22] - -RFC 2408 ISAKMP November 1998 - - - never accept packets with a major version number larger than its - own. - - o Minor Version (4 bits) - indicates the minor version of the - ISAKMP protocol in use. Implementations based on this version of - the ISAKMP Internet-Draft MUST set the Minor Version to 0. - Implementations based on previous versions of ISAKMP Internet- - Drafts MUST set the Minor Version to 1. Implementations SHOULD - never accept packets with a minor version number larger than its - own, given the major version numbers are identical. - - o Exchange Type (1 octet) - indicates the type of exchange being - used. This dictates the message and payload orderings in the - ISAKMP exchanges. - - - Exchange Type Value - NONE 0 - Base 1 - Identity Protection 2 - Authentication Only 3 - Aggressive 4 - Informational 5 - ISAKMP Future Use 6 - 31 - DOI Specific Use 32 - 239 - Private Use 240 - 255 - - o Flags (1 octet) - indicates specific options that are set for the - ISAKMP exchange. The flags listed below are specified in the - Flags field beginning with the least significant bit, i.e the - Encryption bit is bit 0 of the Flags field, the Commit bit is bit - 1 of the Flags field, and the Authentication Only bit is bit 2 of - the Flags field. The remaining bits of the Flags field MUST be - set to 0 prior to transmission. - - -- E(ncryption Bit) (1 bit) - If set (1), all payloads following - the header are encrypted using the encryption algorithm - identified in the ISAKMP SA. The ISAKMP SA Identifier is the - combination of the initiator and responder cookie. It is - RECOMMENDED that encryption of communications be done as soon - as possible between the peers. For all ISAKMP exchanges - described in section 4.1, the encryption SHOULD begin after - both parties have exchanged Key Exchange payloads. If the - E(ncryption Bit) is not set (0), the payloads are not - encrypted. - - - - - - -Maughan, et. al. Standards Track [Page 23] - -RFC 2408 ISAKMP November 1998 - - - -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange - synchronization. It is used to ensure that encrypted material - is not received prior to completion of the SA establishment. - The Commit Bit can be set (at anytime) by either party - participating in the SA establishment, and can be used during - both phases of an ISAKMP SA establishment. However, the value - MUST be reset after the Phase 1 negotiation. If set(1), the - entity which did not set the Commit Bit MUST wait for an - Informational Exchange containing a Notify payload (with the - CONNECTED Notify Message) from the entity which set the Commit - Bit. In this instance, the Message ID field of the - Informational Exchange MUST contain the Message ID of the - original ISAKMP Phase 2 SA negotiation. This is done to - ensure that the Informational Exchange with the CONNECTED - Notify Message can be associated with the correct Phase 2 SA. - The receipt and processing of the Informational Exchange - indicates that the SA establishment was successful and either - entity can now proceed with encrypted traffic communication. - In addition to synchronizing key exchange, the Commit Bit can - be used to protect against loss of transmissions over - unreliable networks and guard against the need for multiple - re-transmissions. - - NOTE: It is always possible that the final message of an - exchange can be lost. In this case, the entity expecting to - receive the final message of an exchange would receive the - Phase 2 SA negotiation message following a Phase 1 exchange or - encrypted traffic following a Phase 2 exchange. Handling of - this situation is not standardized, but we propose the - following possibilities. If the entity awaiting the - Informational Exchange can verify the received message (i.e. - Phase 2 SA negotiation message or encrypted traffic), then - they MAY consider the SA was established and continue - processing. The other option is to retransmit the last ISAKMP - message to force the other entity to retransmit the final - message. This suggests that implementations may consider - retaining the last message (locally) until they are sure the - SA is established. - - -- A(uthentication Only Bit) (1 bit) - This bit is intended for - use with the Informational Exchange with a Notify payload and - will allow the transmission of information with integrity - checking, but no encryption (e.g. "emergency mode"). Section - 4.8 states that a Phase 2 Informational Exchange MUST be sent - under the protection of an ISAKMP SA. This is the only - exception to that policy. If the Authentication Only bit is - set (1), only authentication security services will be applied - to the entire Notify payload of the Informational Exchange and - - - -Maughan, et. al. Standards Track [Page 24] - -RFC 2408 ISAKMP November 1998 - - - the payload will not be encrypted. - - o Message ID (4 octets) - Unique Message Identifier used to - identify protocol state during Phase 2 negotiations. This value - is randomly generated by the initiator of the Phase 2 - negotiation. In the event of simultaneous SA establishments - (i.e. collisions), the value of this field will likely be - different because they are independently generated and, thus, two - security associations will progress toward establishment. - However, it is unlikely there will be absolute simultaneous - establishments. During Phase 1 negotiations, the value MUST be - set to 0. - - o Length (4 octets) - Length of total message (header + payloads) - in octets. Encryption can expand the size of an ISAKMP message. - -3.2 Generic Payload Header - - Each ISAKMP payload defined in sections 3.4 through 3.16 begins with - a generic header, shown in Figure 3, which provides a payload - "chaining" capability and clearly defines the boundaries of a - payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 3: 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 - the "chaining" capability. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - -3.3 Data Attributes - - There are several instances within ISAKMP where it is necessary to - represent Data Attributes. An example of this is the Security - Association (SA) Attributes contained in the Transform payload - - - -Maughan, et. al. Standards Track [Page 25] - -RFC 2408 ISAKMP November 1998 - - - (described in section 3.6). These Data Attributes are not an ISAKMP - payload, but are contained within ISAKMP payloads. The format of the - Data Attributes provides the flexibility for representation of many - different types of information. There can be multiple Data - Attributes within a payload. The length of the Data Attributes will - either be 4 octets or defined by the Attribute Length field. This is - done using the Attribute Format bit described below. Specific - information about the attributes for each domain will be described in - a DOI document, e.g. IPSEC DOI [IPDOI]. - - 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 4: Data Attributes - - The Data Attributes fields are defined as follows: - - o Attribute Type (2 octets) - Unique identifier for each type of - attribute. These attributes are defined as part of the DOI- - specific information. - - The most significant bit, or Attribute Format (AF), indicates - whether the data attributes follow the Type/Length/Value (TLV) - format or a shortened Type/Value (TV) format. If the AF bit is a - 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 DOI-specific 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. - - - - - - -Maughan, et. al. Standards Track [Page 26] - -RFC 2408 ISAKMP November 1998 - - -3.4 Security Association Payload - - The Security Association Payload is used to negotiate security - attributes and to indicate the Domain of Interpretation (DOI) and - Situation under which the negotiation is taking place. Figure 5 - shows the format of the Security Association payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation (DOI) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Situation ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 5: Security Association Payload - - 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 MUST NOT - contain the values for the Proposal or Transform payloads as they - are considered part of the security association negotiation. For - example, this field would contain the value "10" (Nonce payload) - in the first message of a Base Exchange (see Section 4.4) and the - value "0" in the first message of an Identity Protect Exchange - (see Section 4.5). - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the entire - Security Association payload, including the SA payload, all - Proposal payloads, and all Transform payloads associated with the - proposed Security Association. - - o Domain of Interpretation (4 octets) - Identifies the DOI (as - described in Section 2.1) under which this negotiation is taking - place. The DOI is a 32-bit unsigned integer. A DOI value of 0 - during a Phase 1 exchange specifies a Generic ISAKMP SA which can - be used for any protocol during the Phase 2 exchange. The - necessary SA Attributes are defined in A.4. A DOI value of 1 is - assigned to the IPsec DOI [IPDOI]. All other DOI values are - reserved to IANA for future use. IANA will not normally assign a - DOI value without referencing some public specification, such as - - - -Maughan, et. al. Standards Track [Page 27] - -RFC 2408 ISAKMP November 1998 - - - an Internet RFC. Other DOI's can be defined using the description - in appendix B. This field MUST be present within the Security - Association payload. - - o Situation (variable length) - A DOI-specific field that - identifies the situation under which this negotiation is taking - place. The Situation is used to make policy decisions regarding - the security attributes being negotiated. Specifics for the IETF - IP Security DOI Situation are detailed in [IPDOI]. This field - MUST be present within the Security Association payload. - -3.5 Proposal Payload - - The Proposal Payload contains information used during Security - Association negotiation. The proposal consists of security - mechanisms, or transforms, to be used to secure the communications - channel. Figure 6 shows the format of the Proposal Payload. A - description of its use can be found in section 4.2. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! SPI (variable) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 6: Proposal Payload Format - - The Proposal Payload fields are defined as follows: - - o Next Payload (1 octet) - Identifier for the payload type of the - next payload in the message. This field MUST only contain the - value "2" or "0". If there are additional Proposal payloads in - the message, then this field will be 2. If the current Proposal - payload is the last within the security association proposal, - then this field will be 0. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the entire - Proposal payload, including generic payload header, the Proposal - payload, and all Transform payloads associated with this - proposal. In the event there are multiple proposals with the - same proposal number (see section 4.2), the Payload Length field - - - -Maughan, et. al. Standards Track [Page 28] - -RFC 2408 ISAKMP November 1998 - - - only applies to the current Proposal payload and not to all - Proposal payloads. - - o Proposal # (1 octet) - Identifies the Proposal number for the - current payload. A description of the use of this field is found - in section 4.2. - - o Protocol-Id (1 octet) - Specifies the protocol identifier for the - current negotiation. Examples might include IPSEC ESP, IPSEC AH, - OSPF, TLS, etc. - - o SPI Size (1 octet) - Length in octets of the SPI as defined by - the Protocol-Id. In the case of ISAKMP, the Initiator and - Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, - therefore, the SPI Size is irrelevant and MAY be from zero (0) to - sixteen (16). If the SPI Size is non-zero, the content of the - SPI field MUST be ignored. If the SPI Size is not a multiple of - 4 octets it will have some impact on the SPI field and the - alignment of all payloads in the message. The Domain of - Interpretation (DOI) will dictate the SPI Size for other - protocols. - - o # of Transforms (1 octet) - Specifies the number of transforms - for the Proposal. Each of these is contained in a Transform - payload. - - o SPI (variable) - The sending entity's SPI. In the event the SPI - Size is not a multiple of 4 octets, there is no padding applied - to the payload, however, it can be applied at the end of the - message. - - The payload type for the Proposal Payload is two (2). - -3.6 Transform Payload - - The Transform Payload contains information used during Security - Association negotiation. The Transform payload consists of a - specific security mechanism, or transforms, to be used to secure the - communications channel. The Transform payload also contains the - security association attributes associated with the specific - transform. These SA attributes are DOI-specific. Figure 7 shows the - format of the Transform Payload. A description of its use can be - found in section 4.2. - - - - - - - - -Maughan, et. al. Standards Track [Page 29] - -RFC 2408 ISAKMP November 1998 - - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Transform # ! Transform-Id ! RESERVED2 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ SA Attributes ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 7: Transform Payload Format - - The Transform Payload fields are defined as follows: - - o Next Payload (1 octet) - Identifier for the payload type of the - next payload in the message. This field MUST only contain the - value "3" or "0". If there are additional Transform payloads in - the proposal, then this field will be 3. If the current - Transform payload is the last within the proposal, then this - field will be 0. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header, Transform values, - and all SA Attributes. - - o Transform # (1 octet) - Identifies the Transform number for the - current payload. If there is more than one transform proposed - for a specific protocol within the Proposal payload, then each - Transform payload has a unique Transform number. A description - of the use of this field is found in section 4.2. - - o Transform-Id (1 octet) - Specifies the Transform identifier for - the protocol within the current proposal. These transforms are - defined by the DOI and are dependent on the protocol being - negotiated. - - o RESERVED2 (2 octets) - Unused, set to 0. - - o SA Attributes (variable length) - This field contains the - security association attributes as defined for the transform - given in the Transform-Id field. The SA Attributes SHOULD be - represented using the Data Attributes format described in section - 3.3. If the SA Attributes are not aligned on 4-byte boundaries, - - - -Maughan, et. al. Standards Track [Page 30] - -RFC 2408 ISAKMP November 1998 - - - then subsequent payloads will not be aligned and any padding will - be added at the end of the message to make the message 4-octet - aligned. - - The payload type for the Transform Payload is three (3). - -3.7 Key Exchange Payload - - The Key Exchange Payload supports a variety of key exchange - techniques. Example key exchanges are Oakley [Oakley], Diffie- - Hellman, the enhanced Diffie-Hellman key exchange described in X9.42 - [ANSI], and the RSA-based key exchange used by PGP. Figure 8 shows - the format of the Key Exchange payload. - - The Key Exchange Payload fields are defined as follows: - - o Next Payload (1 octet) - Identifier for the payload type of the - nextpayload in the message. If the current payload is the last - in the message, then this field will be 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Key Exchange Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 8: Key Exchange Payload Format - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Key Exchange Data (variable length) - Data required to generate a - session key. The interpretation of this data is specified by the - DOI and the associated Key Exchange algorithm. This field may - also contain pre-placed key indicators. - - The payload type for the Key Exchange Payload is four (4). - - - - - - - -Maughan, et. al. Standards Track [Page 31] - -RFC 2408 ISAKMP November 1998 - - -3.8 Identification Payload - - The Identification Payload contains DOI-specific data used to - exchange identification information. This information is used for - determining the identities of communicating peers and may be used for - determining authenticity of information. Figure 9 shows the format - of the Identification Payload. - - The Identification Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o ID Type (1 octet) - Specifies the type of Identification being - used. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ID Type ! DOI Specific ID Data ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Identification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 9: Identification Payload Format - - This field is DOI-dependent. - - o DOI Specific ID Data (3 octets) - Contains DOI specific - Identification data. If unused, then this field MUST be set to - 0. - - o Identification Data (variable length) - Contains identity - information. The values for this field are DOI-specific and the - format is specified by the ID Type field. Specific details for - the IETF IP Security DOI Identification Data are detailed in - [IPDOI]. - - - -Maughan, et. al. Standards Track [Page 32] - -RFC 2408 ISAKMP November 1998 - - - The payload type for the Identification Payload is five (5). - -3.9 Certificate Payload - - The Certificate Payload provides a means to transport certificates or - other certificate-related information via ISAKMP and can appear in - any ISAKMP message. Certificate payloads SHOULD be included in an - exchange whenever an appropriate directory service (e.g. Secure DNS - [DNSSEC]) is not available to distribute certificates. The - Certificate payload MUST be accepted at any point during an exchange. - Figure 10 shows the format of the Certificate Payload. - - NOTE: Certificate types and formats are not generally bound to a DOI - - it is expected that there will only be a few certificate types, and - that most DOIs will accept all of these types. - - The Certificate Payload 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. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert Encoding ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certificate Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 10: Certificate Payload Format - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Certificate Encoding (1 octet) - This field indicates the type of - certificate or certificate-related information contained in the - Certificate Data field. - - - - - - - -Maughan, et. al. Standards Track [Page 33] - -RFC 2408 ISAKMP November 1998 - - - Certificate Type Value - NONE 0 - PKCS #7 wrapped X.509 certificate 1 - PGP Certificate 2 - DNS Signed Key 3 - X.509 Certificate - Signature 4 - X.509 Certificate - Key Exchange 5 - Kerberos Tokens 6 - Certificate Revocation List (CRL) 7 - Authority Revocation List (ARL) 8 - SPKI Certificate 9 - X.509 Certificate - Attribute 10 - RESERVED 11 - 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 six (6). - -3.10 Certificate Request Payload - - The Certificate Request Payload provides a means to request - certificates via ISAKMP and can appear in any message. Certificate - Request payloads SHOULD be included in an exchange whenever an - appropriate directory service (e.g. Secure DNS [DNSSEC]) is not - available to distribute certificates. The Certificate Request - payload MUST be accepted at any point during the exchange. The - responder to the Certificate Request payload MUST send its - certificate, if certificates are supported, based on the values - contained in the payload. If multiple certificates are required, - then multiple Certificate Request payloads SHOULD be transmitted. - Figure 11 shows the format of the Certificate Request Payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Cert. Type ! ! - +-+-+-+-+-+-+-+-+ ! - ~ Certificate Authority ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 11: Certificate Request Payload Format - - - - -Maughan, et. al. Standards Track [Page 34] - -RFC 2408 ISAKMP November 1998 - - - The Certificate Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Certificate Type (1 octet) - Contains an encoding of the type of - certificate requested. Acceptable values are listed in section - 3.9. - - o Certificate Authority (variable length) - Contains an encoding of - an acceptable certificate authority for the type of certificate - requested. As an example, for an X.509 certificate this field - would contain the Distinguished Name encoding of the Issuer Name - of an X.509 certificate authority acceptable to the sender of - this payload. This would be included to assist the responder in - determining how much of the certificate chain would need to be - sent in response to this request. If there is no specific - certificate authority requested, this field SHOULD not be - included. - - The payload type for the Certificate Request Payload is seven (7). - - - - - - - - - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 35] - -RFC 2408 ISAKMP November 1998 - - -3.11 Hash Payload - - The Hash Payload contains data generated by the hash function - (selected during the SA establishment exchange), over some part of - the message and/or ISAKMP state. This payload may be used to verify - the integrity of the data in an ISAKMP message or for authentication - of the negotiating entities. Figure 12 shows the format of the Hash - Payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Hash Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 12: Hash Payload Format - - The Hash Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Hash Data (variable length) - Data that results from applying the - hash routine to the ISAKMP message and/or state. - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 36] - -RFC 2408 ISAKMP November 1998 - - -3.12 Signature Payload - - The Signature Payload contains data generated by the digital - signature function (selected during the SA establishment exchange), - over some part of the message and/or ISAKMP state. This payload is - used to verify the integrity of the data in the ISAKMP message, and - may be of use for non-repudiation services. Figure 13 shows the - format of the Signature Payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Signature Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 13: Signature Payload Format - - The Signature Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Signature Data (variable length) - Data that results from - applying the digital signature function to the ISAKMP message - and/or state. - - The payload type for the Signature Payload is nine (9). - -3.13 Nonce Payload - - The Nonce Payload contains random data used to guarantee liveness - during an exchange and protect against replay attacks. Figure 14 - shows the format of the Nonce Payload. If nonces are used by a - particular key exchange, the use of the Nonce payload will be - dictated by the key exchange. The nonces may be transmitted as part - of the key exchange data, or as a separate payload. However, this is - defined by the key exchange, not by ISAKMP. - - - -Maughan, et. al. Standards Track [Page 37] - -RFC 2408 ISAKMP November 1998 - - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Nonce Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 14: Nonce Payload Format - - The Nonce Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Nonce Data (variable length) - Contains the random data generated - by the transmitting entity. - - The payload type for the Nonce Payload is ten (10). - -3.14 Notification Payload - - The Notification Payload can contain both ISAKMP and DOI-specific - data and is used to transmit informational data, such as error - conditions, to an ISAKMP peer. It is possible to send multiple - Notification payloads in a single ISAKMP message. Figure 15 shows - the format of the Notification Payload. - - Notification which occurs during, or is concerned with, a Phase 1 - negotiation is identified by the Initiator and Responder cookie pair - in the ISAKMP Header. The Protocol Identifier, in this case, is - ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP - Header identifies the ISAKMP SA. If the notification takes place - prior to the completed exchange of keying information, then the - notification will be unprotected. - - - - - - - -Maughan, et. al. Standards Track [Page 38] - -RFC 2408 ISAKMP November 1998 - - - Notification which occurs during, or is concerned with, a Phase 2 - negotiation is identified by the Initiator and Responder cookie pair - in the ISAKMP Header and the Message ID and SPI associated with the - current negotiation. One example for this type of notification is to - indicate why a proposal was rejected. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation (DOI) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol-ID ! SPI Size ! Notify Message Type ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Notification Data ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 15: Notification Payload Format - - The Notification Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Domain of Interpretation (4 octets) - Identifies the DOI (as - described in Section 2.1) under which this notification is taking - place. For ISAKMP this value is zero (0) and for the IPSEC DOI - it is one (1). Other DOI's can be defined using the description - in appendix B. - - o Protocol-Id (1 octet) - Specifies the protocol identifier for the - current notification. Examples might include ISAKMP, IPSEC ESP, - IPSEC AH, OSPF, TLS, etc. - - - - -Maughan, et. al. Standards Track [Page 39] - -RFC 2408 ISAKMP November 1998 - - - o SPI Size (1 octet) - Length in octets of the SPI as defined by - the Protocol-Id. In the case of ISAKMP, the Initiator and - Responder cookie pair from the ISAKMP Header is the ISAKMP SPI, - therefore, the SPI Size is irrelevant and MAY be from zero (0) to - sixteen (16). If the SPI Size is non-zero, the content of the - SPI field MUST be ignored. The Domain of Interpretation (DOI) - will dictate the SPI Size for other protocols. - - o Notify Message Type (2 octets) - Specifies the type of - notification message (see section 3.14.1). Additional text, if - specified by the DOI, is placed in the Notification Data field. - - o SPI (variable length) - Security Parameter Index. The receiving - entity's SPI. The use of the SPI field is described in section - 2.4. The length of this field is determined by the SPI Size - field and is not necessarily aligned to a 4 octet boundary. - - o Notification Data (variable length) - Informational or error data - transmitted in addition to the Notify Message Type. Values for - this field are DOI-specific. - - The payload type for the Notification Payload is eleven (11). - -3.14.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. - For example, a secure front end or security gateway may use the - Notify message to synchronize SA communication. The table below - lists the Nofitication messages and their corresponding values. - Values in the Private Use range are expected to be DOI-specific - values. - - NOTIFY MESSAGES - ERROR TYPES - - Errors Value - INVALID-PAYLOAD-TYPE 1 - DOI-NOT-SUPPORTED 2 - SITUATION-NOT-SUPPORTED 3 - INVALID-COOKIE 4 - INVALID-MAJOR-VERSION 5 - INVALID-MINOR-VERSION 6 - INVALID-EXCHANGE-TYPE 7 - INVALID-FLAGS 8 - INVALID-MESSAGE-ID 9 - INVALID-PROTOCOL-ID 10 - INVALID-SPI 11 - - - -Maughan, et. al. Standards Track [Page 40] - -RFC 2408 ISAKMP November 1998 - - - INVALID-TRANSFORM-ID 12 - ATTRIBUTES-NOT-SUPPORTED 13 - NO-PROPOSAL-CHOSEN 14 - BAD-PROPOSAL-SYNTAX 15 - PAYLOAD-MALFORMED 16 - INVALID-KEY-INFORMATION 17 - INVALID-ID-INFORMATION 18 - INVALID-CERT-ENCODING 19 - INVALID-CERTIFICATE 20 - CERT-TYPE-UNSUPPORTED 21 - INVALID-CERT-AUTHORITY 22 - INVALID-HASH-INFORMATION 23 - AUTHENTICATION-FAILED 24 - INVALID-SIGNATURE 25 - ADDRESS-NOTIFICATION 26 - NOTIFY-SA-LIFETIME 27 - CERTIFICATE-UNAVAILABLE 28 - UNSUPPORTED-EXCHANGE-TYPE 29 - UNEQUAL-PAYLOAD-LENGTHS 30 - RESERVED (Future Use) 31 - 8191 - Private Use 8192 - 16383 - - - - NOTIFY MESSAGES - STATUS TYPES - Status Value - CONNECTED 16384 - RESERVED (Future Use) 16385 - 24575 - DOI-specific codes 24576 - 32767 - Private Use 32768 - 40959 - RESERVED (Future Use) 40960 - 65535 - -3.15 Delete Payload - - The Delete Payload contains a protocol-specific security association - identifier that the sender has removed from its security association - database and is, therefore, no longer valid. Figure 16 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 with the Delete - payload. - - Deletion which is concerned with an ISAKMP SA will contain a - Protocol-Id of ISAKMP and the SPIs are the initiator and responder - cookies from the ISAKMP Header. Deletion which is concerned with a - Protocol SA, such as ESP or AH, will contain the Protocol-Id of that - protocol (e.g. ESP, AH) and the SPI is the sending entity's SPI(s). - - - - -Maughan, et. al. Standards Track [Page 41] - -RFC 2408 ISAKMP November 1998 - - - NOTE: The Delete Payload is not a request for the responder to delete - an SA, but an advisory from the initiator to the responder. If the - responder chooses to ignore the message, the next communication from - the responder to the initiator, using that security association, will - fail. A responder is not expected to acknowledge receipt of a Delete - payload. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation (DOI) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Protocol-Id ! SPI Size ! # of SPIs ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Security Parameter Index(es) (SPI) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 16: Delete Payload Format - - The Delete Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Domain of Interpretation (4 octets) - Identifies the DOI (as - described in Section 2.1) under which this deletion is taking - place. For ISAKMP this value is zero (0) and for the IPSEC DOI - it is one (1). Other DOI's can be defined using the description - in appendix B. - - o Protocol-Id (1 octet) - ISAKMP can establish security - associations for various protocols, including ISAKMP and IPSEC. - This field identifies which security association database to - apply the delete request. - - - - - - -Maughan, et. al. Standards Track [Page 42] - -RFC 2408 ISAKMP November 1998 - - - o SPI Size (1 octet) - Length in octets of the SPI as defined by - the Protocol-Id. In the case of ISAKMP, the Initiator and - Responder cookie pair is the ISAKMP SPI. In this case, the SPI - Size would be 16 octets for each SPI being deleted. - - 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. Values for this - field are DOI and protocol specific. The length of this field is - determined by the SPI Size and # of SPIs fields. - - The payload type for the Delete Payload is twelve (12). - -3.16 Vendor ID Payload - - The Vendor ID Payload 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 backwards - compatibility. This is not a general extension facility of ISAKMP. - Figure 17 shows the format of the Vendor ID Payload. - - The Vendor ID payload is not an announcement from the sender that it - will send private payload types. A vendor sending the Vendor ID MUST - not make any assumptions about private payloads that it may send - unless a Vendor ID is received as well. Multiple Vendor ID payloads - MAY be sent. An implementation is NOT REQUIRED to understand any - Vendor ID payloads. An implementation is NOT REQUIRED to send any - Vendor ID payload at all. If a private payload was sent without - prior agreement to send it, a compliant implementation may reject a - proposal with a notify message of type INVALID-PAYLOAD-TYPE. - - If a Vendor ID payload is sent, it MUST be sent during the Phase 1 - negotiation. Reception of a familiar Vendor ID payload in the Phase - 1 negotiation allows an implementation to make use of Private USE - payload numbers (128-255), described in section 3.1 for vendor - specific extensions during Phase 2 negotiations. The definition of - "familiar" is left to implementations to determine. Some vendors may - wish to implement another vendor's extension prior to - standardization. However, this practice SHOULD not be widespread and - vendors should work towards standardization instead. - - The vendor defined constant MUST be unique. The choice of hash and - text to hash is left to the vendor to decide. As an example, vendors - could generate their vendor id by taking a plain (non-keyed) hash of - a string containing the product name, and the version of the product. - - - -Maughan, et. al. Standards Track [Page 43] - -RFC 2408 ISAKMP November 1998 - - - A hash is used instead of a vendor registry to avoid local - cryptographic policy problems with having a list of "approved" - products, to keep away from maintaining a list of vendors, and to - allow classified products to avoid having to appear on any list. For - instance: - - "Example Company IPsec. Version 97.1" - - (not including the quotes) has MD5 hash: - 48544f9b1fe662af98b9b39e50c01a5a, when using MD5file. Vendors may - include all of the hash, or just a portion of it, as the payload - length will bound the data. There are no security implications of - this hash, so its choice is arbitrary. - - 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 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Vendor ID (VID) ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 17: Vendor ID Payload Format - - The Vendor ID Payload 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. - - o RESERVED (1 octet) - Unused, set to 0. - - o Payload Length (2 octets) - Length in octets of the current - payload, including the generic payload header. - - o Vendor ID (variable length) - Hash of the vendor string plus - version (as described above). - - The payload type for the Vendor ID Payload is thirteen (13). - -4 ISAKMP Exchanges - - ISAKMP supplies the basic syntax of a message exchange. The basic - building blocks for ISAKMP messages are the payload types described - in section 3. This section describes the procedures for SA - - - -Maughan, et. al. Standards Track [Page 44] - -RFC 2408 ISAKMP November 1998 - - - establishment and SA modification, followed by a default set of - exchanges that MAY be used for initial interoperability. Other - exchanges will be defined depending on the DOI and key exchange. - [IPDOI] and [IKE] are examples of how this is achieved. Appendix B - explains the procedures for accomplishing these additions. - -4.1 ISAKMP Exchange Types - - ISAKMP allows the creation of exchanges for the establishment of - Security Associations and keying material. There are currently five - default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 - describe these exchanges. Exchanges define the content and ordering - of ISAKMP messages during communications between peers. Most - exchanges will include all the basic payload types - SA, KE, ID, SIG - - and may include others. The primary difference between exchange - types is the ordering of the messages and the payload ordering within - each message. While the ordering of payloads within messages is not - mandated, for processing efficiency it is RECOMMENDED that the - Security Association payload be the first payload within an exchange. - Processing of each payload within an exchange is described in section - 5. - - Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. - These exchanges provide different security protection for the - exchange itself and information exchanged. The diagrams in each of - the following sections show the message ordering for each exchange - type as well as the payloads included in each message, and provide - basic notes describing what has happened after each message exchange. - None of the examples include any "optional payloads", like - certificate and certificate request. Additionally, none of the - examples include an initial exchange of ISAKMP Headers (containing - initiator and responder cookies) which would provide protection - against clogging (see section 2.5.3). - - The defined exchanges are not meant to satisfy all DOI and key - exchange protocol requirements. If the defined exchanges meet the - DOI requirements, then they can be used as outlined. If the defined - exchanges do not meet the security requirements defined by the DOI, - then the DOI MUST specify new exchange type(s) and the valid - sequences of payloads that make up a successful exchange, and how to - build and interpret those payloads. All ISAKMP implementations MUST - implement the Informational Exchange and SHOULD implement the other - four exchanges. However, this is dependent on the definition of the - DOI and associated key exchange protocols. - - - - - - - -Maughan, et. al. Standards Track [Page 45] - -RFC 2408 ISAKMP November 1998 - - - As discussed above, these exchange types can be used in either phase - of negotiation. However, they may provide different security - properties in each of the phases. With each of these exchanges, the - combination of cookies and SPI fields identifies whether this - exchange is being used in the first or second phase of a negotiation. - -4.1.1 Notation - - The following notation is used to describe the ISAKMP exchange types, - shown in the next section, with the message formats and associated - payloads: - - HDR is an ISAKMP header whose exchange type defines the payload - orderings - SA is an SA negotiation payload with one or more Proposal and - Transform payloads. An initiator MAY provide multiple proposals - for negotiation; a responder MUST reply with only one. - KE is the key exchange payload. - IDx is the identity payload for "x". x can be: "ii" or "ir" - for the ISAKMP initiator and responder, respectively, or x can - be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), - for the user initiator and responder, respectively. - HASH is the hash payload. - SIG is the signature payload. The data to sign is exchange-specific. - AUTH is a generic authentication mechanism, such as HASH or SIG. - NONCE is the nonce payload. - '*' signifies payload encryption after the ISAKMP header. This - encryption MUST begin immediately after the ISAKMP header and - all payloads following the ISAKMP header MUST be encrypted. - - => signifies "initiator to responder" communication - <= signifies "responder to initiator" communication - -4.2 Security Association Establishment - - The Security Association, Proposal, and Transform payloads are used - to build ISAKMP messages for the negotiation and establishment of - SAs. An SA establishment message consists of a single SA payload - followed by at least one, and possibly many, Proposal payloads and at - least one, and possibly many, Transform payloads associated with each - Proposal payload. Because these payloads are considered together, - the SA payload will point to any following payloads and not to the - Proposal payload included with the SA payload. The SA Payload - contains the DOI and Situation for the proposed SA. Each Proposal - payload contains a Security Parameter Index (SPI) and ensures that - the SPI is associated with the Protocol-Id in accordance with the - Internet Security Architecture [SEC-ARCH]. Proposal payloads may or - may not have the same SPI, as this is implementation dependent. Each - - - -Maughan, et. al. Standards Track [Page 46] - -RFC 2408 ISAKMP November 1998 - - - Transform Payload contains the specific security mechanisms to be - used for the designated protocol. It is expected that the Proposal - and Transform payloads will be used only during SA establishment - negotiation. The creation of payloads for security association - negotiation and establishment described here in this section are - applicable for all ISAKMP exchanges described later in sections 4.4 - through 4.8. The examples shown in 4.2.1 contain only the SA, - Proposal, and Transform payloads and do not contain other payloads - that might exist for a given ISAKMP exchange. - - The Proposal payload provides the initiating entity with the - capability to present to the responding entity the security protocols - and associated security mechanisms for use with the security - association being negotiated. If the SA establishment negotiation is - for a combined protection suite consisting of multiple protocols, - then there MUST be multiple Proposal payloads each with the same - Proposal number. These proposals MUST be considered as a unit and - MUST NOT be separated by a proposal with a different proposal number. - The use of the same Proposal number in multiple Proposal payloads - provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. - The first example below shows an ESP AND AH protection suite. If the - SA establishment negotiation is for different protection suites, then - there MUST be multiple Proposal payloads each with a monotonically - increasing Proposal number. The different proposals MUST be - presented in the initiator's preference order. The use of different - Proposal numbers in multiple Proposal payloads provides a logical OR - operation, i.e. Proposal 1 OR Proposal 2, where each proposal may - have more than one protocol. The second example below shows either - an AH AND ESP protection suite OR just an ESP protection suite. Note - that the Next Payload field of the Proposal payload points to another - Proposal payload (if it exists). The existence of a Proposal payload - implies the existence of one or more Transform payloads. - - The Transform payload provides the initiating entity with the - capability to present to the responding entity multiple mechanisms, - or transforms, for a given protocol. The Proposal payload identifies - a Protocol for which services and mechanisms are being negotiated. - The Transform payload allows the initiating entity to present several - possible supported transforms for that proposed protocol. There may - be several transforms associated with a specific Proposal payload - each identified in a separate Transform payload. The multiple - transforms MUST be presented with monotonically increasing numbers in - the initiator's preference order. The receiving entity MUST select a - single transform for each protocol in a proposal or reject the entire - proposal. The use of the Transform number in multiple Transform - payloads provides a second level OR operation, i.e. Transform 1 OR - Transform 2 OR Transform 3. Example 1 below shows two possible - transforms for ESP and a single transform for AH. Example 2 below - - - -Maughan, et. al. Standards Track [Page 47] - -RFC 2408 ISAKMP November 1998 - - - shows one transform for AH AND one transform for ESP OR two - transforms for ESP alone. Note that the Next Payload field of the - Transform payload points to another Transform payload or 0. The - Proposal payload delineates the different proposals. - - When responding to a Security Association payload, the responder MUST - send a Security Association payload with the selected proposal, which - may consist of multiple Proposal payloads and their associated - Transform payloads. Each of the Proposal payloads MUST contain a - single Transform payload associated with the Protocol. The responder - SHOULD retain the Proposal # field in the Proposal payload and the - Transform # field in each Transform payload of the selected Proposal. - Retention of Proposal and Transform numbers should speed the - initiator's protocol processing by negating the need to compare the - respondor's selection with every offered option. These values enable - the initiator to perform the comparison directly and quickly. The - initiator MUST verify that the Security Association payload received - from the responder matches one of the proposals sent initially. - -4.2.1 Security Association Establishment Examples - - This example shows a Proposal for a combined protection suite with - two different protocols. The first protocol is presented with two - transforms supported by the proposer. The second protocol is - presented with a single transform. An example for this proposal - might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 - as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder - MUST select from the two transforms proposed for ESP. The resulting - protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, - depending on which ESP transform was selected by the responder. Note - this example is shown using the Base Exchange. - - 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 - /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Nonce ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -SA Pay ! Domain of Interpretation (DOI) ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! Situation ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Proposal ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! -Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SPI (variable) ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Transform! RESERVED ! Payload Length ! - - - -Maughan, et. al. Standards Track [Page 48] - -RFC 2408 ISAKMP November 1998 - - - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! -Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SPI (variable) ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - This second example shows a Proposal for two different protection - suites. The SA Payload was omitted for space reasons. The first - protection suite is presented with one transform for the first - protocol and one transform for the second protocol. The second - protection suite is presented with two transforms for a single - protocol. An example for this proposal might be: Proposal 1 with - Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with - Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1 - as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder - MUST select from the two different proposals. If the second Proposal - is selected, the responder MUST select from the two transforms for - ESP. The resulting protection suite will be either (1) MD5 AND 3DES - OR the selection between (2) DES OR (3) 3DES. - - 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 - /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Proposal ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! -Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SPI (variable) ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - - - -Maughan, et. al. Standards Track [Page 49] - -RFC 2408 ISAKMP November 1998 - - - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Proposal ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! -Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SPI (variable) ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2! -Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SPI (variable) ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = Transform! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / ! NP = 0 ! RESERVED ! Payload Length ! - / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! - \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! SA Attributes ! - \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -4.3 Security Association Modification - - Security Association modification within ISAKMP is accomplished by - creating a new SA and initiating communications using that new SA. - Deletion of the old SA can be done anytime after the new SA is - established. Deletion of the old SA is dependent on local security - policy. Modification of SAs by using a "Create New SA followed by - Delete Old SA" method is done to avoid potential vulnerabilities in - synchronizing modification of existing SA attributes. The procedure - for creating new SAs is outlined in section 4.2. The procedure for - deleting SAs is outlined in section 5.15. - - - - -Maughan, et. al. Standards Track [Page 50] - -RFC 2408 ISAKMP November 1998 - - - Modification of an ISAKMP SA (phase 1 negotiation) follows the same - procedure as creation of an ISAKMP SA. There is no relationship - between the two SAs and the initiator and responder cookie pairs - SHOULD be different, as outlined in section 2.5.3. - - Modification of a Protocol SA (phase 2 negotiation) follows the same - procedure as creation of a Protocol SA. The creation of a new SA is - protected by the existing ISAKMP SA. There is no relationship between - the two Protocol SAs. A protocol implementation SHOULD begin using - the newly created SA for outbound traffic and SHOULD continue to - support incoming traffic on the old SA until it is deleted or until - traffic is received under the protection of the newly created SA. As - stated previously in this section, deletion of an old SA is then - dependent on local security policy. - -4.4 Base Exchange - - The Base Exchange is designed to allow the Key Exchange and - Authentication related information to be transmitted together. - Combining the Key Exchange and Authentication-related information - into one message reduces the number of round-trips at the expense of - not providing identity protection. Identity protection is not - provided because identities are exchanged before a common shared - secret has been established and, therefore, encryption of the - identities is not possible. The following diagram shows the messages - with the possible payloads sent in each message and notes for an - example of the Base Exchange. - - BASE EXCHANGE - - # Initiator Direction Responder NOTE -(1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation - -(2) <= HDR; SA; NONCE - Basic SA agreed upon -(3) HDR; KE; => - IDii; AUTH Key Generated (by responder) - Initiator Identity Verified by - Responder -(4) <= HDR; KE; - IDir; AUTH - Responder Identity Verified by - Initiator Key Generated (by - initiator) SA established - - - - - - - -Maughan, et. al. Standards Track [Page 51] - -RFC 2408 ISAKMP November 1998 - - - In the first message (1), the initiator generates a proposal it - considers adequate to protect traffic for the given situation. The - Security Association, Proposal, and Transform payloads are included - in the Security Association payload (for notation purposes). Random - information which is used to guarantee liveness and protect against - replay attacks is also transmitted. Random information provided by - both parties SHOULD be used by the authentication mechanism to - provide shared proof of participation in the exchange. - - In the second message (2), the responder indicates the protection - suite it has accepted with the Security Association, Proposal, and - Transform payloads. Again, random information which is used to - guarantee liveness and protect against replay attacks is also - transmitted. Random information provided by both parties SHOULD be - used by the authentication mechanism to provide shared proof of - participation in the exchange. Local security policy dictates the - action of the responder if no proposed protection suite is accepted. - One possible action is the transmission of a Notify payload as part - of an Informational Exchange. - - In the third (3) and fourth (4) messages, the initiator and - responder, respectively, exchange keying material used to arrive at a - common shared secret and identification information. This - information is transmitted under the protection of the agreed upon - authentication function. Local security policy dictates the action - if an error occurs during these messages. One possible action is the - transmission of a Notify payload as part of an Informational - Exchange. - -4.5 Identity Protection Exchange - - The Identity Protection Exchange is designed to separate the Key - Exchange information from the Identity and Authentication related - information. Separating the Key Exchange from the Identity and - Authentication related information provides protection of the - communicating identities at the expense of two additional messages. - Identities are exchanged under the protection of a previously - established common shared secret. The following diagram shows the - messages with the possible payloads sent in each message and notes - for an example of the Identity Protection Exchange. - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 52] - -RFC 2408 ISAKMP November 1998 - - - IDENTITY PROTECTION EXCHANGE - - # Initiator Direction Responder NOTE -(1) HDR; SA => Begin ISAKMP-SA or - Proxy negotiation -(2) <= HDR; SA - Basic SA agreed upon -(3) HDR; KE; NONCE => -(4) <= HDR; KE; NONCE - Key Generated (by - Initiator and - Responder) -(5) HDR*; IDii; AUTH => - Initiator Identity - Verified by - Responder -(6) <= HDR*; IDir; AUTH - Responder Identity - Verified by - Initiator - SA established - - In the first message (1), the initiator generates a proposal it - considers adequate to protect traffic for the given situation. The - Security Association, Proposal, and Transform payloads are included - in the Security Association payload (for notation purposes). - - In the second message (2), the responder indicates the protection - suite it has accepted with the Security Association, Proposal, and - Transform payloads. Local security policy dictates the action of the - responder if no proposed protection suite is accepted. One possible - action is the transmission of a Notify payload as part of an - Informational Exchange. - - In the third (3) and fourth (4) messages, the initiator and - responder, respectively, exchange keying material used to arrive at a - common shared secret and random information which is used to - guarantee liveness and protect against replay attacks. Random - information provided by both parties SHOULD be used by the - authentication mechanism to provide shared proof of participation in - the exchange. Local security policy dictates the action if an error - occurs during these messages. One possible action is the - transmission of a Notify payload as part of an Informational - Exchange. - - In the fifth (5) and sixth (6) messages, the initiator and responder, - respectively, exchange identification information and the results of - the agreed upon authentication function. This information is - - - -Maughan, et. al. Standards Track [Page 53] - -RFC 2408 ISAKMP November 1998 - - - transmitted under the protection of the common shared secret. Local - security policy dictates the action if an error occurs during these - messages. One possible action is the transmission of a Notify - payload as part of an Informational Exchange. - -4.6 Authentication Only Exchange - - The Authentication Only Exchange is designed to allow only - Authentication related information to be transmitted. The benefit of - this exchange is the ability to perform only authentication without - the computational expense of computing keys. Using this exchange - during negotiation, none of the transmitted information will be - encrypted. However, the information may be encrypted in other - places. For example, if encryption is negotiated during the first - phase of a negotiation and the authentication only exchange is used - in the second phase of a negotiation, then the authentication only - exchange will be encrypted by the ISAKMP SAs negotiated in the first - phase. The following diagram shows the messages with possible - payloads sent in each message and notes for an example of the - Authentication Only Exchange. - - AUTHENTICATION ONLY EXCHANGE - - # Initiator Direction Responder NOTE -(1) HDR; SA; NONCE => Begin ISAKMP-SA or - Proxy negotiation -(2) <= HDR; SA; NONCE; - IDir; AUTH - Basic SA agreed upon - Responder Identity - Verified by Initiator -(3) HDR; IDii; AUTH => - Initiator Identity - Verified by Responder - SA established - - In the first message (1), the initiator generates a proposal it - considers adequate to protect traffic for the given situation. The - Security Association, Proposal, and Transform payloads are included - in the Security Association payload (for notation purposes). Random - information which is used to guarantee liveness and protect against - replay attacks is also transmitted. Random information provided by - both parties SHOULD be used by the authentication mechanism to - provide shared proof of participation in the exchange. - - In the second message (2), the responder indicates the protection - suite it has accepted with the Security Association, Proposal, and - Transform payloads. Again, random information which is used to - - - -Maughan, et. al. Standards Track [Page 54] - -RFC 2408 ISAKMP November 1998 - - - guarantee liveness and protect against replay attacks is also - transmitted. Random information provided by both parties SHOULD be - used by the authentication mechanism to provide shared proof of - participation in the exchange. Additionally, the responder transmits - identification information. All of this information is transmitted - under the protection of the agreed upon authentication function. - Local security policy dictates the action of the responder if no - proposed protection suite is accepted. One possible action is the - transmission of a Notify payload as part of an Informational - Exchange. - - In the third message (3), the initiator transmits identification - information. This information is transmitted under the protection of - the agreed upon authentication function. Local security policy - dictates the action if an error occurs during these messages. One - possible action is the transmission of a Notify payload as part of an - Informational Exchange. - -4.7 Aggressive Exchange - - The Aggressive Exchange is designed to allow the Security - Association, Key Exchange and Authentication related payloads to be - transmitted together. Combining the Security Association, Key - Exchange, and Authentication-related information into one message - reduces the number of round-trips at the expense of not providing - identity protection. Identity protection is not provided because - identities are exchanged before a common shared secret has been - established and, therefore, encryption of the identities is not - possible. Additionally, the Aggressive Exchange is attempting to - establish all security relevant information in a single exchange. - The following diagram shows the messages with possible payloads sent - in each message and notes for an example of the Aggressive Exchange. - - - - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 55] - -RFC 2408 ISAKMP November 1998 - - - AGGRESSIVE EXCHANGE - - # Initiator Direction Responder NOTE -(1) HDR; SA; KE; => Begin ISAKMP-SA or - Proxy negotiation - NONCE; IDii and Key Exchange - -(2) <= HDR; SA; KE; - NONCE; IDir; AUTH - Initiator Identity - Verified by Responder - Key Generated - Basic SA agreed upon -(3) HDR*; AUTH => - Responder Identity - Verified by Initiator - SA established - - In the first message (1), the initiator generates a proposal it - considers adequate to protect traffic for the given situation. The - Security Association, Proposal, and Transform payloads are included - in the Security Association payload (for notation purposes). There - can be only one Proposal and one Transform offered (i.e. no choices) - in order for the aggressive exchange to work. Keying material used - to arrive at a common shared secret and random information which is - used to guarantee liveness and protect against replay attacks are - also transmitted. Random information provided by both parties SHOULD - be used by the authentication mechanism to provide shared proof of - participation in the exchange. Additionally, the initiator transmits - identification information. - - In the second message (2), the responder indicates the protection - suite it has accepted with the Security Association, Proposal, and - Transform payloads. Keying material used to arrive at a common - shared secret and random information which is used to guarantee - liveness and protect against replay attacks is also transmitted. - Random information provided by both parties SHOULD be used by the - authentication mechanism to provide shared proof of participation in - the exchange. Additionally, the responder transmits identification - information. All of this information is transmitted under the - protection of the agreed upon authentication function. Local - security policy dictates the action of the responder if no proposed - protection suite is accepted. One possible action is the - transmission of a Notify payload as part of an Informational - Exchange. - - - - - - -Maughan, et. al. Standards Track [Page 56] - -RFC 2408 ISAKMP November 1998 - - - In the third (3) message, the initiator transmits the results of the - agreed upon authentication function. This information is transmitted - under the protection of the common shared secret. Local security - policy dictates the action if an error occurs during these messages. - One possible action is the transmission of a Notify payload as part - of an Informational Exchange. - -4.8 Informational Exchange - - The Informational Exchange is designed as a one-way transmittal of - information that can be used for security association management. - The following diagram shows the messages with possible payloads sent - in each message and notes for an example of the Informational - Exchange. - - INFORMATIONAL EXCHANGE - - # Initiator Direction Responder NOTE - (1) HDR*; N/D => Error Notification or Deletion - - In the first message (1), the initiator or responder transmits an - ISAKMP Notify or Delete payload. - - If the Informational Exchange occurs prior to the exchange of keying - meterial during an ISAKMP Phase 1 negotiation, there will be no - protection provided for the Informational Exchange. Once keying - material has been exchanged or an ISAKMP SA has been established, the - Informational Exchange MUST be transmitted under the protection - provided by the keying material or the ISAKMP SA. - - All exchanges are similar in that with the beginning of any exchange, - cryptographic synchronization MUST occur. The Informational Exchange - is an exchange and not an ISAKMP message. Thus, the generation of an - Message ID (MID) for an Informational Exchange SHOULD be independent - of IVs of other on-going communication. This will ensure - cryptographic synchronization is maintained for existing - communications and the Informational Exchange will be processed - correctly. The only exception to this is when the Commit Bit of the - ISAKMP Header is set. When the Commit Bit is set, the Message ID - field of the Informational Exchange MUST contain the Message ID of - the original ISAKMP Phase 2 SA negotiation, rather than a new Message - ID (MID). This is done to ensure that the Informational Exchange with - the CONNECTED Notify Message can be associated with the correct Phase - 2 SA. For a description of the Commit Bit, see section 3.1. - - - - - - - -Maughan, et. al. Standards Track [Page 57] - -RFC 2408 ISAKMP November 1998 - - -5 ISAKMP Payload Processing - - Section 3 describes the ISAKMP payloads. These payloads are used in - the exchanges described in section 4 and can be used in exchanges - defined for a specific DOI. This section describes the processing for - each of the payloads. This section suggests the logging of events to - a system audit file. This action is controlled by a system security - policy and is, therefore, only a suggested action. - -5.1 General Message Processing - - Every ISAKMP message has basic processing applied to insure protocol - reliability, and to minimize threats, such as denial of service and - replay attacks. All processing SHOULD include packet length checks - to insure the packet received is at least as long as the length given - in the ISAKMP Header. If the ISAKMP message length and the value in - the Payload Length field of the ISAKMP Header are not the same, then - the ISAKMP message MUST be rejected. The receiving entity (initiator - or responder) MUST do the following: - - 1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the - appropriate system audit file. - - 2. An Informational Exchange with a Notification payload containing - the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the - transmitting entity. This action is dictated by a system - security policy. - - When transmitting an ISAKMP message, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Set a timer and initialize a retry counter. - - NOTE: Implementations MUST NOT use a fixed timer. Instead, - transmission timer values should be adjusted dynamically based on - measured round trip times. In addition, successive - retransmissions of the same packet should be separated by - increasingly longer time intervals (e.g., exponential backoff). - - 2. If the timer expires, the ISAKMP message is resent and the retry - counter is decremented. - - 3. If the retry counter reaches zero (0), the event, RETRY LIMIT - REACHED, MAY be logged in the appropriate system audit file. - - 4. The ISAKMP protocol machine clears all states and returns to - IDLE. - - - - -Maughan, et. al. Standards Track [Page 58] - -RFC 2408 ISAKMP November 1998 - - -5.2 ISAKMP Header Processing - - When creating an ISAKMP message, the transmitting entity (initiator - or responder) MUST do the following: - - 1. Create the respective cookie. See section 2.5.3 for details. - - 2. Determine the relevant security characteristics of the session - (i.e. DOI and situation). - - 3. Construct an ISAKMP Header with fields as described in section - 3.1. - - 4. Construct other ISAKMP payloads, depending on the exchange type. - - 5. Transmit the message to the destination host as described in - section5.1. - - When an ISAKMP message is received, the receiving entity (initiator - or responder) MUST do the following: - - 1. Verify the Initiator and Responder "cookies". If the cookie - validation fails, the message is discarded and the following - actions are taken: - - (a) The event, INVALID COOKIE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-COOKIE message type MAY be sent to - the transmitting entity. This action is dictated by a - system security policy. - - 2. Check the Next Payload field to confirm it is valid. If the Next - Payload field validation fails, the message is discarded and the - following actions are taken: - - (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-PAYLOAD-TYPE message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - - 3. Check the Major and Minor Version fields to confirm they are - correct (see section 3.1). If the Version field validation - fails, the message is discarded and the following actions are - - - -Maughan, et. al. Standards Track [Page 59] - -RFC 2408 ISAKMP November 1998 - - - taken: - - (a) The event, INVALID ISAKMP VERSION, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-MAJOR-VERSION or INVALID-MINOR- - VERSION message type MAY be sent to the transmitting entity. - This action is dictated by a system security policy. - - 4. Check the Exchange Type field to confirm it is valid. If the - Exchange Type field validation fails, the message is discarded - and the following actions are taken: - - (a) The event, INVALID EXCHANGE TYPE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-EXCHANGE-TYPE message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 5. Check the Flags field to ensure it contains correct values. If - the Flags field validation fails, the message is discarded and - the following actions are taken: - - (a) The event, INVALID FLAGS, MAY be logged in the appropriate - systemaudit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-FLAGS message type MAY be sent to the - transmitting entity. This action is dictated by a system - security policy. - - 6. Check the Message ID field to ensure it contains correct values. - If the Message ID validation fails, the message is discarded and - the following actions are taken: - - (a) The event, INVALID MESSAGE ID, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-MESSAGE-ID message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - - 7. Processing of the ISAKMP message continues using the value in the - Next Payload field. - - - -Maughan, et. al. Standards Track [Page 60] - -RFC 2408 ISAKMP November 1998 - - -5.3 Generic Payload Header Processing - - When creating any of the ISAKMP Payloads described in sections 3.4 - through 3.15 a Generic Payload Header is placed at the beginning of - these payloads. When creating the Generic Payload Header, the - transmitting entity (initiator or responder) MUST do the following: - - 1. Place the value of the Next Payload in the Next Payload field. - These values are described in section 3.1. - - 2. Place the value zero (0) in the RESERVED field. - - 3. Place the length (in octets) of the payload in the Payload Length - field. - - 4. Construct the payloads as defined in the remainder of this - section. - - When any of the ISAKMP Payloads are received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Check the Next Payload field to confirm it is valid. If the Next - Payload field validation fails, the message is discarded and the - following actions are taken: - - (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-PAYLOAD-TYPE message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - - 2. Verify the RESERVED field contains the value zero. If the value - in the RESERVED field is not zero, the message is discarded and - the following actions are taken: - - (a) The event, INVALID RESERVED FIELD, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED - message type MAY be sent to the transmitting entity. This - action is dictated by a system security policy. - - 3. Process the remaining payloads as defined by the Next Payload - field. - - - - -Maughan, et. al. Standards Track [Page 61] - -RFC 2408 ISAKMP November 1998 - - -5.4 Security Association Payload Processing - - When creating a Security Association Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the Domain of Interpretation for which this negotiation - is being performed. - - 2. Determine the situation within the determined DOI for which this - negotiation is being performed. - - 3. Determine the proposal(s) and transform(s) within the situation. - These are described, respectively, in sections 3.5 and 3.6. - - 4. Construct a Security Association payload. - - 5. Transmit the message to the receiving entity as described in - section 5.1. - - When a Security Association payload is received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Determine if the Domain of Interpretation (DOI) is supported. If - the DOI determination fails, the message is discarded and the - following actions are taken: - - (a) The event, INVALID DOI, MAY be logged in the appropriate - system audit file. - - (b) An Informational Exchange with a Notification payload - containing the DOI-NOT-SUPPORTED message type MAY be sent to - the transmitting entity. This action is dictated by a - system security policy. - - 2. Determine if the given situation can be protected. If the - Situation determination fails, the message is discarded and the - following actions are taken: - - (a) The event, INVALID SITUATION, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the SITUATION-NOT-SUPPORTED message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 3. Process the remaining payloads (i.e. Proposal, Transform) of the - Security Association Payload. If the Security Association - - - -Maughan, et. al. Standards Track [Page 62] - -RFC 2408 ISAKMP November 1998 - - - Proposal (as described in sections 5.5 and 5.6) is not accepted, - then the following actions are taken: - - (a) The event, INVALID PROPOSAL, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the NO-PROPOSAL-CHOSEN message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - -5.5 Proposal Payload Processing - - When creating a Proposal Payload, the transmitting entity (initiator - or responder) MUST do the following: - - 1. Determine the Protocol for this proposal. - - 2. Determine the number of proposals to be offered for this protocol - and the number of transforms for each proposal. Transforms are - described in section 3.6. - - 3. Generate a unique pseudo-random SPI. - - 4. Construct a Proposal payload. - - When a Proposal payload is received, the receiving entity (initiator - or responder) MUST do the following: - - 1. Determine if the Protocol is supported. If the Protocol-ID field - is invalid, the payload is discarded and the following actions - are taken: - - (a) The event, INVALID PROTOCOL, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-PROTOCOL-ID message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - - 2. Determine if the SPI is valid. If the SPI is invalid, the - payload is discarded and the following actions are taken: - - (a) The event, INVALID SPI, MAY be logged in the appropriate - system audit file. - - - - - -Maughan, et. al. Standards Track [Page 63] - -RFC 2408 ISAKMP November 1998 - - - (b) An Informational Exchange with a Notification payload - containing the INVALID-SPI message type MAY be sent to the - transmitting entity. This action is dictated by a system - security policy. - - 3. Ensure the Proposals are presented according to the details given - in section 3.5 and 4.2. If the proposals are not formed - correctly, the following actions are taken: - - (a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are - logged in the appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED - message type MAY be sent to the transmitting entity. This - action is dictated by a system security policy. - - 4. Process the Proposal and Transform payloads as defined by the - Next Payload field. Examples of processing these payloads are - given in section 4.2.1. - -5.6 Transform Payload Processing - - When creating a Transform Payload, the transmitting entity (initiator - or responder) MUST do the following: - - 1. Determine the Transform # for this transform. - - 2. Determine the number of transforms to be offered for this - proposal. Transforms are described in sections 3.6. - - 3. Construct a Transform payload. - - When a Transform payload is received, the receiving entity (initiator - or responder) MUST do the following: - - 1. Determine if the Transform is supported. If the Transform-ID - field contains an unknown or unsupported value, then that - Transform payload MUST be ignored and MUST NOT cause the - generation of an INVALID TRANSFORM event. If the Transform-ID - field is invalid, the payload is discarded and the following - actions are taken: - - (a) The event, INVALID TRANSFORM, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-TRANSFORM-ID message type MAY be sent - - - -Maughan, et. al. Standards Track [Page 64] - -RFC 2408 ISAKMP November 1998 - - - to the transmitting entity. This action is dictated by a - system security policy. - - 2. Ensure the Transforms are presented according to the details - given in section 3.6 and 4.2. If the transforms are not formed - correctly, the following actions are taken: - - (a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM, - INVALID ATTRIBUTES, are logged in the appropriate system - audit file. - - (b) An Informational Exchange with a Notification payload - containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or - ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the - transmitting entity. This action is dictated by a system - security policy. - - 3. Process the subsequent Transform and Proposal payloads as defined - by the Next Payload field. Examples of processing these payloads - are given in section 4.2.1. - -5.7 Key Exchange Payload Processing - - When creating a Key Exchange Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the Key Exchange to be used as defined by the DOI. - - 2. Determine the usage of the Key Exchange Data field as defined by - the DOI. - - 3. Construct a Key Exchange payload. - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When a Key Exchange payload is received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Determine if the Key Exchange is supported. If the Key Exchange - determination fails, the message is discarded and the following - actions are taken: - - (a) The event, INVALID KEY INFORMATION, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-KEY-INFORMATION message type MAY be - - - -Maughan, et. al. Standards Track [Page 65] - -RFC 2408 ISAKMP November 1998 - - - sent to the transmitting entity. This action is dictated by - a system security policy. - -5.8 Identification Payload Processing - - When creating an Identification Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the Identification information to be used as defined by - the DOI (and possibly the situation). - - 2. Determine the usage of the Identification Data field as defined - by the DOI. - - 3. Construct an Identification payload. - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When an Identification payload is received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Determine if the Identification Type is supported. This may be - based on the DOI and Situation. If the Identification - determination fails, the message is discarded and the following - actions are taken: - - (a) The event, INVALID ID INFORMATION, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-ID-INFORMATION message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - -5.9 Certificate Payload Processing - - When creating a Certificate Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the Certificate Encoding to be used. This may be - specified by the DOI. - - 2. Ensure the existence of a certificate formatted as defined by the - Certificate Encoding. - - 3. Construct a Certificate payload. - - - - -Maughan, et. al. Standards Track [Page 66] - -RFC 2408 ISAKMP November 1998 - - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When a Certificate payload is received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Determine if the Certificate Encoding is supported. If the - Certificate Encoding is not supported, the payload is discarded - and the following actions are taken: - - (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-CERT-ENCODING message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 2. Process the Certificate Data field. If the Certificate Data is - invalid or improperly formatted, the payload is discarded and the - following actions are taken: - - (a) The event, INVALID CERTIFICATE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-CERTIFICATE message type MAY be sent - to the transmitting entity. This action is dictated by a - system security policy. - -5.10 Certificate Request Payload Processing - - When creating a Certificate Request Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the type of Certificate Encoding to be requested. This - may be specified by the DOI. - - 2. Determine the name of an acceptable Certificate Authority which - is to be requested (if applicable). - - 3. Construct a Certificate Request payload. - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When a Certificate Request payload is received, the receiving entity - (initiator or responder) MUST do the following: - - - -Maughan, et. al. Standards Track [Page 67] - -RFC 2408 ISAKMP November 1998 - - - 1. Determine if the Certificate Encoding is supported. If the - Certificate Encoding is invalid, the payload is discarded and the - following actions are taken: - - (a) The event, INVALID CERTIFICATE TYPE, MAY be logged in - the appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-CERT-ENCODING message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - If the Certificate Encoding is not supported, the payload is - discarded and the following actions are taken: - - (a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in - the appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the CERT-TYPE-UNSUPPORTED message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 2. Determine if the Certificate Authority is supported for the - specified Certificate Encoding. If the Certificate Authority is - invalid or improperly formatted, the payload is discarded and the - following actions are taken: - - (a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in - the appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-CERT-AUTHORITY message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 3. Process the Certificate Request. If a requested Certificate Type - with the specified Certificate Authority is not available, then - the payload is discarded and the following actions are taken: - - (a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the CERTIFICATE-UNAVAILABLE message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - - - -Maughan, et. al. Standards Track [Page 68] - -RFC 2408 ISAKMP November 1998 - - -5.11 Hash Payload Processing - - When creating a Hash Payload, the transmitting entity (initiator or - responder) MUST do the following: - - 1. Determine the Hash function to be used as defined by the SA - negotiation. - - 2. Determine the usage of the Hash Data field as defined by the DOI. - - 3. Construct a Hash payload. - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When a Hash payload is received, the receiving entity (initiator or - responder) MUST do the following: - - 1. Determine if the Hash is supported. If the Hash determination - fails, the message is discarded and the following actions are - taken: - - (a) The event, INVALID HASH INFORMATION, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-HASH-INFORMATION message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - - 2. Perform the Hash function as outlined in the DOI and/or Key - Exchange protocol documents. If the Hash function fails, the - message is discarded and the following actions are taken: - - (a) The event, INVALID HASH VALUE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the AUTHENTICATION-FAILED message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - -5.12 Signature Payload Processing - - When creating a Signature Payload, the transmitting entity (initiator - or responder) MUST do the following: - - - - - -Maughan, et. al. Standards Track [Page 69] - -RFC 2408 ISAKMP November 1998 - - - 1. Determine the Signature function to be used as defined by the SA - negotiation. - - 2. Determine the usage of the Signature Data field as defined by the - DOI. - - 3. Construct a Signature payload. - - 4. Transmit the message to the receiving entity as described in - section 5.1. - - When a Signature payload is received, the receiving entity (initiator - or responder) MUST do the following: - - 1. Determine if the Signature is supported. If the Signature - determination fails, the message is discarded and the following - actions are taken: - - (a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in - the appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the INVALID-SIGNATURE message type MAY be sent to - the transmitting entity. This action is dictated by a - system security policy. - - 2. Perform the Signature function as outlined in the DOI and/or Key - Exchange protocol documents. If the Signature function fails, - the message is discarded and the following actions are taken: - - (a) The event, INVALID SIGNATURE VALUE, MAY be logged in the - appropriate system audit file. - - (b) An Informational Exchange with a Notification payload - containing the AUTHENTICATION-FAILED message type MAY be - sent to the transmitting entity. This action is dictated by - a system security policy. - -5.13 Nonce Payload Processing - - When creating a Nonce Payload, the transmitting entity (initiator or - responder) MUST do the following: - - 1. Create a unique random value to be used as a nonce. - - 2. Construct a Nonce payload. - - - - - -Maughan, et. al. Standards Track [Page 70] - -RFC 2408 ISAKMP November 1998 - - - 3. Transmit the message to the receiving entity as described in - section 5.1. - - When a Nonce payload is received, the receiving entity (initiator or - responder) MUST do the following: - - 1. There are no specific procedures for handling Nonce payloads. - The procedures are defined by the exchange types (and possibly - the DOI and Key Exchange descriptions). - -5.14 Notification Payload Processing - - During communications it is possible that errors may occur. The - Informational Exchange with a Notify Payload provides a controlled - method of informing a peer entity that errors have occurred during - protocol processing. It is RECOMMENDED that Notify Payloads be sent - in a separate Informational Exchange rather than appending a Notify - Payload to an existing exchange. - - When creating a Notification Payload, the transmitting entity - (initiator or responder) MUST do the following: - - 1. Determine the DOI for this Notification. - - 2. Determine the Protocol-ID for this Notification. - - 3. Determine the SPI size based on the Protocol-ID field. This - field is necessary because different security protocols have - different SPI sizes. For example, ISAKMP combines the Initiator - and Responder cookie pair (16 octets) as a SPI, while ESP and AH - have 4 octet SPIs. - - 4. Determine the Notify Message Type based on the error or status - message desired. - - 5. Determine the SPI which is associated with this notification. - - 6. Determine if additional Notification Data is to be included. - This is additional information specified by the DOI. - - 7. Construct a Notification payload. - - 8. Transmit the message to the receiving entity as described in - section 5.1. - - Because the Informational Exchange with a Notification payload is a - unidirectional message a retransmission will not be performed. The - local security policy will dictate the procedures for continuing. - - - -Maughan, et. al. Standards Track [Page 71] - -RFC 2408 ISAKMP November 1998 - - - However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be - logged in the appropriate system audit file by the receiving entity. - - If the Informational Exchange occurs prior to the exchange of keying - material during an ISAKMP Phase 1 negotiation there will be no - protection provided for the Informational Exchange. Once the keying - material has been exchanged or the ISAKMP SA has been established, - the Informational Exchange MUST be transmitted under the protection - provided by the keying material or the ISAKMP SA. - - When a Notification payload is received, the receiving entity - (initiator or responder) MUST do the following: - - 1. Determine if the Informational Exchange has any protection - applied to it by checking the Encryption Bit and the - Authentication Only Bit in the ISAKMP Header. If the Encryption - Bit is set, i.e. the Informational Exchange is encrypted, then - the message MUST be decrypted using the (in-progress or - completed) ISAKMP SA. Once the decryption is complete the - processing can continue as described below. If the - Authentication Only Bit is set, then the message MUST be - authenticated using the (in-progress or completed) ISAKMP SA. - Once the authentication is completed, the processing can continue - as described below. If the Informational Exchange is not - encrypted or authentication, the payload processing can continue - as described below. - - 2. Determine if the Domain of Interpretation (DOI) is supported. If - the DOI determination fails, the payload is discarded and the - following action is taken: - - (a) The event, INVALID DOI, MAY be logged in the appropriate - system audit file. - - 3. Determine if the Protocol-Id is supported. If the Protocol-Id - determination fails, the payload is discarded and the following - action is taken: - - (a) The event, INVALID PROTOCOL-ID, MAY be logged in the - appropriate system audit file. - - 4. Determine if the SPI is valid. If the SPI is invalid, the - payload is discarded and the following action is taken: - - (a) The event, INVALID SPI, MAY be logged in the appropriate - system audit file. - - - - - -Maughan, et. al. Standards Track [Page 72] - -RFC 2408 ISAKMP November 1998 - - - 5. Determine if the Notify Message Type is valid. If the Notify - Message Type is invalid, the payload is discarded and the - following action is taken: - - (a) The event, INVALID MESSAGE TYPE, MAY be logged in the - appropriate system audit file. - - 6. Process the Notification payload, including additional - Notification Data, and take appropriate action, according to - local security policy. - -5.15 Delete Payload Processing - - During communications it is possible that hosts may be compromised or - that information may be intercepted during transmission. Determining - whether this has occurred is not an easy task and is outside the - scope of this memo. However, if it is discovered that transmissions - are being compromised, then it is necessary to establish a new SA and - delete the current SA. - - The Informational Exchange with a Delete Payload provides a - controlled method of informing a peer entity that the transmitting - entity has deleted the SA(s). Deletion of Security Associations MUST - always be performed under the protection of an ISAKMP SA. The - receiving entity SHOULD clean up its local SA database. However, - upon receipt of a Delete message the SAs listed in the Security - Parameter Index (SPI) field of the Delete payload cannot be used with - the transmitting entity. The SA Establishment procedure must be - invoked to re-establish secure communications. - - When creating a Delete Payload, the transmitting entity (initiator or - responder) MUST do the following: - - 1. Determine the DOI for this Deletion. - - 2. Determine the Protocol-ID for this Deletion. - - 3. Determine the SPI size based on the Protocol-ID field. This - field is necessary because different security protocols have - different SPI sizes. For example, ISAKMP combines the Initiator - and Responder cookie pair (16 octets) as a SPI, while ESP and AH - have 4 octet SPIs. - - 4. Determine the # of SPIs to be deleted for this protocol. - - 5. Determine the SPI(s) which is (are) associated with this - deletion. - - - - -Maughan, et. al. Standards Track [Page 73] - -RFC 2408 ISAKMP November 1998 - - - 6. Construct a Delete payload. - - 7. Transmit the message to the receiving entity as described in - section 5.1. - - Because the Informational Exchange with a Delete payload is a - unidirectional message a retransmission will not be performed. The - local security policy will dictate the procedures for continuing. - However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in - the appropriate system audit file by the receiving entity. - - As described above, the Informational Exchange with a Delete payload - MUST be transmitted under the protection provided by an ISAKMP SA. - - When a Delete payload is received, the receiving entity (initiator or - responder) MUST do the following: - - 1. Because the Informational Exchange is protected by some security - service (e.g. authentication for an Auth-Only SA, encryption for - other exchanges), the message MUST have these security services - applied using the ISAKMP SA. Once the security service processing - is complete the processing can continue as described below. Any - errors that occur during the security service processing will be - evident when checking information in the Delete payload. The - local security policy SHOULD dictate any action to be taken as a - result of security service processing errors. - - 2. Determine if the Domain of Interpretation (DOI) is supported. If - the DOI determination fails, the payload is discarded and the - following action is taken: - - (a) The event, INVALID DOI, MAY be logged in the appropriate - system audit file. - - 3. Determine if the Protocol-Id is supported. If the Protocol-Id - determination fails, the payload is discarded and the following - action is taken: - - (a) The event, INVALID PROTOCOL-ID, MAY be logged in the - appropriate system audit file. - - 4. Determine if the SPI is valid for each SPI included in the Delete - payload. For each SPI that is invalid, the following action is - taken: - - (a) The event, INVALID SPI, MAY be logged in the appropriate - system audit file. - - - - -Maughan, et. al. Standards Track [Page 74] - -RFC 2408 ISAKMP November 1998 - - - 5. Process the Delete payload and take appropriate action, according - to local security policy. As described above, one appropriate - action SHOULD include cleaning up the local SA database. - -6 Conclusions - - The Internet Security Association and Key Management Protocol - (ISAKMP) is a well designed protocol aimed at the Internet of the - future. The massive growth of the Internet will lead to great - diversity in network utilization, communications, security - requirements, and security mechanisms. ISAKMP contains all the - features that will be needed for this dynamic and expanding - communications environment. - - ISAKMP's Security Association (SA) feature coupled with - authentication and key establishment provides the security and - flexibility that will be needed for future growth and diversity. - This security diversity of multiple key exchange techniques, - encryption algorithms, authentication mechanisms, security services, - and security attributes will allow users to select the appropriate - security for their network, communications, and security needs. The - SA feature allows users to specify and negotiate security - requirements with other users. An additional benefit of supporting - multiple techniques in a single protocol is that as new techniques - are developed they can easily be added to the protocol. This - provides a path for the growth of Internet security services. ISAKMP - supports both publicly or privately defined SAs, making it ideal for - government, commercial, and private communications. - - ISAKMP provides the ability to establish SAs for multiple security - protocols and applications. These protocols and applications may be - session-oriented or sessionless. Having one SA establishment - protocol that supports multiple security protocols eliminates the - need for multiple, nearly identical authentication, key exchange and - SA establishment protocols when more than one security protocol is in - use or desired. Just as IP has provided the common networking layer - for the Internet, a common security establishment protocol is needed - if security is to become a reality on the Internet. ISAKMP provides - the common base that allows all other security protocols to - interoperate. - - ISAKMP follows good security design principles. It is not coupled to - other insecure transport protocols, therefore it is not vulnerable or - weakened by attacks on other protocols. Also, when more secure - transport protocols are developed, ISAKMP can be easily migrated to - them. ISAKMP also provides protection against protocol related - attacks. This protection provides the assurance that the SAs and - keys established are with the desired party and not with an attacker. - - - -Maughan, et. al. Standards Track [Page 75] - -RFC 2408 ISAKMP November 1998 - - - ISAKMP also follows good protocol design principles. Protocol - specific information only is in the protocol header, following the - design principles of IPv6. The data transported by the protocol is - separated into functional payloads. As the Internet grows and - evolves, new payloads to support new security functionality can be - added without modifying the entire protocol. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 76] - -RFC 2408 ISAKMP November 1998 - - -A ISAKMP Security Association Attributes - -A.1 Background/Rationale - - As detailed in previous sections, ISAKMP is designed to provide a - flexible and extensible framework for establishing and managing - Security Associations and cryptographic keys. The framework provided - by ISAKMP consists of header and payload definitions, exchange types - for guiding message and payload exchanges, and general processing - guidelines. ISAKMP does not define the mechanisms that will be used - to establish and manage Security Associations and cryptographic keys - in an authenticated and confidential manner. The definition of - mechanisms and their application is the purview of individual Domains - of Interpretation (DOIs). - - This section describes the ISAKMP values for the Internet IP Security - DOI, supported security protocols, and identification values for - ISAKMP Phase 1 negotiations. The Internet IP Security DOI is - MANDATORY to implement for IP Security. [Oakley] and [IKE] describe, - in detail, the mechanisms and their application for establishing and - managing Security Associations and cryptographic keys for IP - Security. - -A.2 Internet IP Security DOI Assigned Value - - As described in [IPDOI], the Internet IP Security DOI Assigned Number - is one (1). - -A.3 Supported Security Protocols - - Values for supported security protocols are specified in the most - recent "Assigned Numbers" RFC [STD-2]. Presented in the following - table are the values for the security protocols supported by ISAKMP - for the Internet IP Security DOI. - - - Protocol Assigned Value - RESERVED 0 - ISAKMP 1 - - All DOIs MUST reserve ISAKMP with a Protocol-ID of 1. All other - security protocols within that DOI will be numbered accordingly. - - Security protocol values 2-15359 are reserved to IANA for future use. - Values 15360-16383 are permanently reserved for private use amongst - mutually consenting implementations. Such private use values are - unlikely to be interoperable across different implementations. - - - - -Maughan, et. al. Standards Track [Page 77] - -RFC 2408 ISAKMP November 1998 - - -A.4 ISAKMP Identification Type Values - - The following table lists the assigned values for the Identification - Type field found in the Identification payload during a generic Phase - 1 exchange, which is not for a specific protocol. - - - ID Type Value - ID_IPV4_ADDR 0 - ID_IPV4_ADDR_SUBNET 1 - ID_IPV6_ADDR 2 - ID_IPV6_ADDR_SUBNET 3 - -A.4.1 ID_IPV4_ADDR - - The ID_IPV4_ADDR type specifies a single four (4) octet IPv4 address. - -A.4.2 ID_IPV4_ADDR_SUBNET - - The ID_IPV4_ADDR_SUBNET type specifies a range of IPv4 addresses, - represented by two four (4) octet values. The first value is an IPv4 - address. The second is an IPv4 network mask. Note that ones (1s) in - the network mask indicate that the corresponding bit in the address - is fixed, while zeros (0s) indicate a "wildcard" bit. - -A.4.3 ID_IPV6_ADDR - - The ID_IPV6_ADDR type specifies a single sixteen (16) octet IPv6 - address. - -A.4.4 ID_IPV6_ADDR_SUBNET - - The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses, - represented by two sixteen (16) octet values. The first value is an - IPv6 address. The second is an IPv6 network mask. Note that ones - (1s) in the network mask indicate that the corresponding bit in the - address is fixed, while zeros (0s) indicate a "wildcard" bit. - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 78] - -RFC 2408 ISAKMP November 1998 - - -B Defining a new Domain of Interpretation - - The Internet DOI may be sufficient to meet the security requirements - of a large portion of the internet community. However, some groups - may have a need to customize some aspect of a DOI, perhaps to add a - different set of cryptographic algorithms, or perhaps because they - want to make their security-relevant decisions based on something - other than a host id or user id. Also, a particular group may have a - need for a new exchange type, for example to support key management - for multicast groups. - - This section discusses guidelines for defining a new DOI. The full - specification for the Internet DOI can be found in [IPDOI]. - - Defining a new DOI is likely to be a time-consuming process. If at - all possible, it is recommended that the designer begin with an - existing DOI and customize only the parts that are unacceptable. - - If a designer chooses to start from scratch, the following MUST be - defined: - - o A "situation": the set of information that will be used to - determine the required security services. - - o The set of security policies that must be supported. - - o A scheme for naming security-relevant information, including - encryption algorithms, key exchange algorithms, etc. - - o A syntax for the specification of proposed security services, - attributes, and certificate authorities. - - o The specific formats of the various payload contents. - - o Additional exchange types, if required. - -B.1 Situation - - The situation is the basis for deciding how to protect a - communications channel. It must contain all of the data that will be - used to determine the types and strengths of protections applied in - an SA. For example, a US Department of Defense DOI would probably use - unpublished algorithms and have additional special attributes to - negotiate. These additional security attributes would be included in - the situation. - - - - - - -Maughan, et. al. Standards Track [Page 79] - -RFC 2408 ISAKMP November 1998 - - -B.2 Security Policies - - Security policies define how various types of information must be - categorized and protected. The DOI must define the set of security - policies supported, because both parties in a negotiation must trust - that the other party understands a situation, and will protect - information appropriately, both in transit and in storage. In a - corporate setting, for example, both parties in a negotiation must - agree to the meaning of the term "proprietary information" before - they can negotiate how to protect it. - - Note that including the required security policies in the DOI only - specifies that the participating hosts understand and implement those - policies in a full system context. - -B.3 Naming Schemes - - Any DOI must define a consistent way to name cryptographic - algorithms, certificate authorities, etc. This can usually be done - by using IANA naming conventions, perhaps with some private - extensions. - -B.4 Syntax for Specifying Security Services - - In addition to simply specifying how to name entities, the DOI must - also specify the format for complete proposals of how to protect - traffic under a given situation. - -B.5 Payload Specification - - The DOI must specify the format of each of the payload types. For - several of the payload types, ISAKMP has included fields that would - have to be present across all DOI (such as a certificate authority in - the certificate payload, or a key exchange identifier in the key - exchange payload). - -B.6 Defining new Exchange Types - - If the basic exchange types are inadequate to meet the requirements - within a DOI, a designer can define up to thirteen extra exchange - types per DOI. The designer creates a new exchange type by choosing - an unused exchange type value, and defining a sequence of messages - composed of strings of the ISAKMP payload types. - - Note that any new exchange types must be rigorously analyzed for - vulnerabilities. Since this is an expensive and imprecise - undertaking, a new exchange type should only be created when - absolutely necessary. - - - -Maughan, et. al. Standards Track [Page 80] - -RFC 2408 ISAKMP November 1998 - - -Security Considerations - - Cryptographic analysis techniques are improving at a steady pace. - The continuing improvement in processing power makes once - computationally prohibitive cryptographic attacks more realistic. - New cryptographic algorithms and public key generation techniques are - also being developed at a steady pace. New security services and - mechanisms are being developed at an accelerated pace. A consistent - method of choosing from a variety of security services and mechanisms - and to exchange attributes required by the mechanisms is important to - security in the complex structure of the Internet. However, a system - that locks itself into a single cryptographic algorithm, key exchange - technique, or security mechanism will become increasingly vulnerable - as time passes. - - UDP is an unreliable datagram protocol and therefore its use in - ISAKMP introduces a number of security considerations. Since UDP is - unreliable, but a key management protocol must be reliable, the - reliability is built into ISAKMP. While ISAKMP utilizes UDP as its - transport mechanism, it doesn't rely on any UDP information (e.g. - checksum, length) for its processing. - - Another issue that must be considered in the development of ISAKMP is - the effect of firewalls on the protocol. Many firewalls filter out - all UDP packets, making reliance on UDP questionable in certain - environments. - - A number of very important security considerations are presented in - [SEC-ARCH]. One bears repeating. Once a private session key is - created, it must be safely stored. Failure to properly protect the - private key from access both internal and external to the system - completely nullifies any protection provided by the IP Security - services. - -IANA Considerations - - This document contains many "magic" numbers to be maintained by the - IANA. This section explains the criteria to be used by the IANA to - assign additional numbers in each of these lists. - -Domain of Interpretation - - The Domain of Interpretation (DOI) is a 32-bit field which identifies - the domain under which the security association negotiation is taking - place. Requests for assignments of new DOIs must be accompanied by a - standards-track RFC which describes the specific domain. - - - - - -Maughan, et. al. Standards Track [Page 81] - -RFC 2408 ISAKMP November 1998 - - -Supported Security Protocols - - ISAKMP is designed to provide security association negotiation and - key management for many security protocols. Requests for identifiers - for additional security protocols must be accompanied by a - standards-track RFC which describes the security protocol and its - relationship to ISAKMP. - -Acknowledgements - - Dan Harkins, Dave Carrel, and Derrell Piper of Cisco Systems provided - design assistance with the protocol and coordination for the [IKE] - and [IPDOI] documents. - - Hilarie Orman, via the Oakley key exchange protocol, has - significantly influenced the design of ISAKMP. - - Marsha Gross, Bill Kutz, Mike Oehler, Pete Sell, and Ruth Taylor - provided significant input and review to this document. - - Scott Carlson ported the TIS DNSSEC prototype to FreeBSD for use with - the ISAKMP prototype. - - Jeff Turner and Steve Smalley contributed to the prototype - development and integration with ESP and AH. - - Mike Oehler and Pete Sell performed interoperability testing with - other ISAKMP implementors. - - Thanks to Carl Muckenhirn of SPARTA, Inc. for his assistance with - LaTeX. - -References - - [ANSI] ANSI, X9.42: Public Key Cryptography for the Financial - Services Industry -- Establishment of Symmetric Algorithm - Keys Using Diffie-Hellman, Working Draft, April 19, 1996. - - [BC] Ballardie, A., and J. Crowcroft, Multicast-specific - Security Threats and Countermeasures, Proceedings of 1995 - ISOC Symposium on Networks & Distributed Systems Security, - pp. 17-30, Internet Society, San Diego, CA, February 1995. - - [Berge] Berge, N., "UNINETT PCA Policy Statements", RFC 1875, - December 1995. - - - - - - -Maughan, et. al. Standards Track [Page 82] - -RFC 2408 ISAKMP November 1998 - - - [CW87] Clark, D.D. and D.R. Wilson, A Comparison of Commercial - and Military Computer Security Policies, Proceedings of - the IEEE Symposium on Security & Privacy, Oakland, CA, - 1987, pp. 184-193. - - [DNSSEC] D. Eastlake III, Domain Name System Protocol Security - Extensions, Work in Progress. - - [DOW92] Diffie, W., M.Wiener, P. Van Oorschot, Authentication and - Authenticated Key Exchanges, Designs, Codes, and - Cryptography, 2, 107-125, Kluwer Academic Publishers, - 1992. - - [IAB] Bellovin, S., "Report of the IAB Security Architecture - Workshop", RFC 2316, April 1998. - - [IKE] Harkins, D., and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IPDOI] Piper, D., "The Internet IP Security Domain of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [Karn] Karn, P., and B. Simpson, Photuris: Session Key - Management Protocol, Work in Progress. - - [Kent94] Steve Kent, IPSEC SMIB, e-mail to ipsec@ans.net, August - 10, 1994. - - [Oakley] Orman, H., "The Oakley Key Determination Protocol", RFC - 2412, November 1998. - - [RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic - Mail: Part II: Certificate-Based Key Management", RFC - 1422, February 1993. - - [RFC-1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC - 1949, May 1996. - - [RFC-2093] Harney, H., and C. Muckenhirn, "Group Key Management - Protocol (GKMP) Specification", RFC 2093, July 1997. - - [RFC-2094] Harney, H., and C. Muckenhirn, "Group Key Management - Protocol (GKMP) Architecture", RFC 2094, July 1997. - - [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - - -Maughan, et. al. Standards Track [Page 83] - -RFC 2408 ISAKMP November 1998 - - - [Schneier] Bruce Schneier, Applied Cryptography - Protocols, - Algorithms, and Source Code in C (Second Edition), John - Wiley & Sons, Inc., 1996. - - [SEC-ARCH] Atkinson, R., and S. Kent, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC - 1700, October 1994. See also: - http://www.iana.org/numbers.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 84] - -RFC 2408 ISAKMP November 1998 - - -Authors' Addresses - - Douglas Maughan - National Security Agency - ATTN: R23 - 9800 Savage Road - Ft. Meade, MD. 20755-6000 - - Phone: 301-688-0847 - EMail:wdm@tycho.ncsc.mil - - - Mark Schneider - National Security Agency - ATTN: R23 - 9800 Savage Road - Ft. Meade, MD. 20755-6000 - - Phone: 301-688-0851 - EMail:mss@tycho.ncsc.mil - - - Mark Schertler - Securify, Inc. - 2415-B Charleston Road - Mountain View, CA 94043 - - Phone: 650-934-9303 - EMail:mjs@securify.com - - - Jeff Turner - RABA Technologies, Inc. - 10500 Little Patuxent Parkway - Columbia, MD. 21044 - - Phone: 410-715-9399 - EMail:jeff.turner@raba.com - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 85] - -RFC 2408 ISAKMP November 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Maughan, et. al. Standards Track [Page 86] - diff --git a/doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt b/doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt deleted file mode 100644 index 9d3e6f80e..000000000 --- a/doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt +++ /dev/null @@ -1,2299 +0,0 @@ - - - - - - -Network Working Group D. Harkins -Request for Comments: 2409 D. Carrel -Category: Standards Track cisco Systems - November 1998 - - - The Internet Key Exchange (IKE) - -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 Internet Society (1998). All Rights Reserved. - -Table Of Contents - - 1 Abstract........................................................ 2 - 2 Discussion...................................................... 2 - 3 Terms and Definitions........................................... 3 - 3.1 Requirements Terminology...................................... 3 - 3.2 Notation...................................................... 3 - 3.3 Perfect Forward Secrecty...................................... 5 - 3.4 Security Association.......................................... 5 - 4 Introduction.................................................... 5 - 5 Exchanges....................................................... 8 - 5.1 Authentication with Digital Signatures........................ 10 - 5.2 Authentication with Public Key Encryption..................... 12 - 5.3 A Revised method of Authentication with Public Key Encryption. 13 - 5.4 Authentication with a Pre-Shared Key.......................... 16 - 5.5 Quick Mode.................................................... 16 - 5.6 New Group Mode................................................ 20 - 5.7 ISAKMP Informational Exchanges................................ 20 - 6 Oakley Groups................................................... 21 - 6.1 First Oakley Group............................................ 21 - 6.2 Second Oakley Group........................................... 22 - 6.3 Third Oakley Group............................................ 22 - 6.4 Fourth Oakley Group........................................... 23 - 7 Payload Explosion of Complete Exchange.......................... 23 - 7.1 Phase 1 with Main Mode........................................ 23 - 7.2 Phase 2 with Quick Mode....................................... 25 - 8 Perfect Forward Secrecy Example................................. 27 - 9 Implementation Hints............................................ 27 - - - -Harkins & Carrel Standards Track [Page 1] - -RFC 2409 IKE November 1998 - - - 10 Security Considerations........................................ 28 - 11 IANA Considerations............................................ 30 - 12 Acknowledgments................................................ 31 - 13 References..................................................... 31 - Appendix A........................................................ 33 - Appendix B........................................................ 37 - Authors' Addresses................................................ 40 - Authors' Note..................................................... 40 - Full Copyright Statement.......................................... 41 - -1. Abstract - - ISAKMP ([MSST98]) provides a framework for authentication and key - exchange but does not define them. ISAKMP is designed to be key - exchange independant; that is, it is designed to support many - different key exchanges. - - Oakley ([Orm96]) describes a series of key exchanges-- called - "modes"-- and details the services provided by each (e.g. perfect - forward secrecy for keys, identity protection, and authentication). - - SKEME ([SKEME]) describes a versatile key exchange technique which - provides anonymity, repudiability, and quick key refreshment. - - This document describes a protocol using part of Oakley and part of - SKEME in conjunction with ISAKMP to obtain authenticated keying - material for use with ISAKMP, and for other security associations - such as AH and ESP for the IETF IPsec DOI. - -2. Discussion - - This memo describes a hybrid protocol. The purpose is to negotiate, - and provide authenticated keying material for, security associations - in a protected manner. - - Processes which implement this memo can be used for negotiating - virtual private networks (VPNs) and also for providing a remote user - from a remote site (whose IP address need not be known beforehand) - access to a secure host or network. - - Client negotiation is supported. Client mode is where the - negotiating parties are not the endpoints for which security - association negotiation is taking place. When used in client mode, - the identities of the end parties remain hidden. - - - - - - - -Harkins & Carrel Standards Track [Page 2] - -RFC 2409 IKE November 1998 - - - This does not implement the entire Oakley protocol, but only a subset - necessary to satisfy its goals. It does not claim conformance or - compliance with the entire Oakley protocol nor is it dependant in any - way on the Oakley protocol. - - Likewise, this does not implement the entire SKEME protocol, but only - the method of public key encryption for authentication and its - concept of fast re-keying using an exchange of nonces. This protocol - is not dependant in any way on the SKEME protocol. - -3. Terms and Definitions - -3.1 Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [Bra97]. - -3.2 Notation - - The following notation is used throughout this memo. - - HDR is an ISAKMP header whose exchange type is the mode. When - writen as HDR* it indicates payload encryption. - - SA is an SA negotiation payload with one or more proposals. An - initiator MAY provide multiple proposals for negotiation; a - responder MUST reply with only one. - - <P>_b indicates the body of payload <P>-- the ISAKMP generic - vpayload is not included. - - SAi_b is the entire body of the SA payload (minus the ISAKMP - generic header)-- i.e. the DOI, situation, all proposals and all - transforms offered by the Initiator. - - CKY-I and CKY-R are the Initiator's cookie and the Responder's - cookie, respectively, from the ISAKMP header. - - g^xi and g^xr are the Diffie-Hellman ([DH]) public values of the - initiator and responder respectively. - - g^xy is the Diffie-Hellman shared secret. - - KE is the key exchange payload which contains the public - information exchanged in a Diffie-Hellman exchange. There is no - particular encoding (e.g. a TLV) used for the data of a KE payload. - - - - -Harkins & Carrel Standards Track [Page 3] - -RFC 2409 IKE November 1998 - - - Nx is the nonce payload; x can be: i or r for the ISAKMP initiator - and responder respectively. - - IDx is the identification payload for "x". x can be: "ii" or "ir" - for the ISAKMP initiator and responder respectively during phase - one negotiation; or "ui" or "ur" for the user initiator and - responder respectively during phase two. The ID payload format for - the Internet DOI is defined in [Pip97]. - - SIG is the signature payload. The data to sign is exchange- - specific. - - CERT is the certificate payload. - - HASH (and any derivitive such as HASH(2) or HASH_I) is the hash - payload. The contents of the hash are specific to the - authentication method. - - prf(key, msg) is the keyed pseudo-random function-- often a keyed - hash function-- used to generate a deterministic output that - appears pseudo-random. prf's are used both for key derivations and - for authentication (i.e. as a keyed MAC). (See [KBC96]). - - SKEYID is a string derived from secret material known only to the - active players in the exchange. - - SKEYID_e is the keying material used by the ISAKMP SA to protect - the confidentiality of its messages. - - SKEYID_a is the keying material used by the ISAKMP SA to - authenticate its messages. - - SKEYID_d is the keying material used to derive keys for non-ISAKMP - security associations. - - <x>y indicates that "x" is encrypted with the key "y". - - --> signifies "initiator to responder" communication (requests). - - <-- signifies "responder to initiator" communication (replies). - - | signifies concatenation of information-- e.g. X | Y is the - concatentation of X with Y. - - [x] indicates that x is optional. - - - - - - -Harkins & Carrel Standards Track [Page 4] - -RFC 2409 IKE November 1998 - - - Message encryption (when noted by a '*' after the ISAKMP header) MUST - begin immediately after the ISAKMP header. When communication is - protected, all payloads following the ISAKMP header MUST be - encrypted. Encryption keys are generated from SKEYID_e in a manner - that is defined for each algorithm. - -3.3 Perfect Forward Secrecy - - When used in the memo Perfect Forward Secrecy (PFS) refers to the - notion that compromise of a single key will permit access to only - data protected by a single key. For PFS to exist the key used to - protect transmission of data MUST NOT be used to derive any - additional keys, and if the key used to protect transmission of data - was derived from some other keying material, that material MUST NOT - be used to derive any more keys. - - Perfect Forward Secrecy for both keys and identities is provided in - this protocol. (Sections 5.5 and 8). - -3.4 Security Association - - A security association (SA) is a set of policy and key(s) used to - protect information. The ISAKMP SA is the shared policy and key(s) - used by the negotiating peers in this protocol to protect their - communication. - -4. Introduction - - Oakley and SKEME each define a method to establish an authenticated - key exchange. This includes payloads construction, the information - payloads carry, the order in which they are processed and how they - are used. - - While Oakley defines "modes", ISAKMP defines "phases". The - relationship between the two is very straightforward and IKE presents - different exchanges as modes which operate in one of two phases. - - Phase 1 is where the two ISAKMP peers establish a secure, - authenticated channel with which to communicate. This is called the - ISAKMP Security Association (SA). "Main Mode" and "Aggressive Mode" - each accomplish a phase 1 exchange. "Main Mode" and "Aggressive Mode" - MUST ONLY be used in phase 1. - - Phase 2 is where Security Associations are negotiated on behalf of - services such as IPsec or any other service which needs key material - and/or parameter negotiation. "Quick Mode" accomplishes a phase 2 - exchange. "Quick Mode" MUST ONLY be used in phase 2. - - - - -Harkins & Carrel Standards Track [Page 5] - -RFC 2409 IKE November 1998 - - - "New Group Mode" is not really a phase 1 or phase 2. It follows - phase 1, but serves to establish a new group which can be used in - future negotiations. "New Group Mode" MUST ONLY be used after phase - 1. - - The ISAKMP SA is bi-directional. That is, once established, either - party may initiate Quick Mode, Informational, and New Group Mode - Exchanges. Per the base ISAKMP document, the ISAKMP SA is identified - by the Initiator's cookie followed by the Responder's cookie-- the - role of each party in the phase 1 exchange dictates which cookie is - the Initiator's. The cookie order established by the phase 1 exchange - continues to identify the ISAKMP SA regardless of the direction the - Quick Mode, Informational, or New Group exchange. In other words, the - cookies MUST NOT swap places when the direction of the ISAKMP SA - changes. - - With the use of ISAKMP phases, an implementation can accomplish very - fast keying when necessary. A single phase 1 negotiation may be used - for more than one phase 2 negotiation. Additionally a single phase 2 - negotiation can request multiple Security Associations. With these - optimizations, an implementation can see less than one round trip per - SA as well as less than one DH exponentiation per SA. "Main Mode" - for phase 1 provides identity protection. When identity protection - is not needed, "Aggressive Mode" can be used to reduce round trips - even further. Developer hints for doing these optimizations are - included below. It should also be noted that using public key - encryption to authenticate an Aggressive Mode exchange will still - provide identity protection. - - This protocol does not define its own DOI per se. The ISAKMP SA, - established in phase 1, MAY use the DOI and situation from a non- - ISAKMP service (such as the IETF IPSec DOI [Pip97]). In this case an - implementation MAY choose to restrict use of the ISAKMP SA for - establishment of SAs for services of the same DOI. Alternately, an - ISAKMP SA MAY be established with the value zero in both the DOI and - situation (see [MSST98] for a description of these fields) and in - this case implementations will be free to establish security services - for any defined DOI using this ISAKMP SA. If a DOI of zero is used - for establishment of a phase 1 SA, the syntax of the identity - payloads used in phase 1 is that defined in [MSST98] and not from any - DOI-- e.g. [Pip97]-- which may further expand the syntax and - semantics of identities. - - The following attributes are used by IKE and are negotiated as part - of the ISAKMP Security Association. (These attributes pertain only - to the ISAKMP Security Association and not to any Security - Associations that ISAKMP may be negotiating on behalf of other - services.) - - - -Harkins & Carrel Standards Track [Page 6] - -RFC 2409 IKE November 1998 - - - - encryption algorithm - - - hash algorithm - - - authentication method - - - information about a group over which to do Diffie-Hellman. - - All of these attributes are mandatory and MUST be negotiated. In - addition, it is possible to optionally negotiate a psuedo-random - function ("prf"). (There are currently no negotiable pseudo-random - functions defined in this document. Private use attribute values can - be used for prf negotiation between consenting parties). If a "prf" - is not negotiation, the HMAC (see [KBC96]) version of the negotiated - hash algorithm is used as a pseudo-random function. Other non- - mandatory attributes are described in Appendix A. The selected hash - algorithm MUST support both native and HMAC modes. - - The Diffie-Hellman group MUST be either specified using a defined - group description (section 6) or by defining all attributes of a - group (section 5.6). Group attributes (such as group type or prime-- - see Appendix A) MUST NOT be offered in conjunction with a previously - defined group (either a reserved group description or a private use - description that is established after conclusion of a New Group Mode - exchange). - - IKE implementations MUST support the following attribute values: - - - DES [DES] in CBC mode with a weak, and semi-weak, key check - (weak and semi-weak keys are referenced in [Sch96] and listed in - Appendix A). The key is derived according to Appendix B. - - - MD5 [MD5] and SHA [SHA}. - - - Authentication via pre-shared keys. - - - MODP over default group number one (see below). - - In addition, IKE implementations SHOULD support: 3DES for encryption; - Tiger ([TIGER]) for hash; the Digital Signature Standard, RSA [RSA] - signatures and authentication with RSA public key encryption; and - MODP group number 2. IKE implementations MAY support any additional - encryption algorithms defined in Appendix A and MAY support ECP and - EC2N groups. - - The IKE modes described here MUST be implemented whenever the IETF - IPsec DOI [Pip97] is implemented. Other DOIs MAY use the modes - described here. - - - -Harkins & Carrel Standards Track [Page 7] - -RFC 2409 IKE November 1998 - - -5. Exchanges - - There are two basic methods used to establish an authenticated key - exchange: Main Mode and Aggressive Mode. Each generates authenticated - keying material from an ephemeral Diffie-Hellman exchange. Main Mode - MUST be implemented; Aggressive Mode SHOULD be implemented. In - addition, Quick Mode MUST be implemented as a mechanism to generate - fresh keying material and negotiate non-ISAKMP security services. In - addition, New Group Mode SHOULD be implemented as a mechanism to - define private groups for Diffie-Hellman exchanges. Implementations - MUST NOT switch exchange types in the middle of an exchange. - - Exchanges conform to standard ISAKMP payload syntax, attribute - encoding, timeouts and retransmits of messages, and informational - messages-- e.g a notify response is sent when, for example, a - proposal is unacceptable, or a signature verification or decryption - was unsuccessful, etc. - - The SA payload MUST precede all other payloads in a phase 1 exchange. - Except where otherwise noted, there are no requirements for ISAKMP - payloads in any message to be in any particular order. - - The Diffie-Hellman public value passed in a KE payload, in either a - phase 1 or phase 2 exchange, MUST be the length of the negotiated - Diffie-Hellman group enforced, if necessary, by pre-pending the value - with zeros. - - The length of nonce payload MUST be between 8 and 256 bytes - inclusive. - - Main Mode is an instantiation of the ISAKMP Identity Protect - Exchange: The first two messages negotiate policy; the next two - exchange Diffie-Hellman public values and ancillary data (e.g. - nonces) necessary for the exchange; and the last two messages - authenticate the Diffie-Hellman Exchange. The authentication method - negotiated as part of the initial ISAKMP exchange influences the - composition of the payloads but not their purpose. The XCHG for Main - Mode is ISAKMP Identity Protect. - - Similarly, Aggressive Mode is an instantiation of the ISAKMP - Aggressive Exchange. The first two messages negotiate policy, - exchange Diffie-Hellman public values and ancillary data necessary - for the exchange, and identities. In addition the second message - authenticates the responder. The third message authenticates the - initiator and provides a proof of participation in the exchange. The - XCHG for Aggressive Mode is ISAKMP Aggressive. The final message MAY - NOT be sent under protection of the ISAKMP SA allowing each party to - - - - -Harkins & Carrel Standards Track [Page 8] - -RFC 2409 IKE November 1998 - - - postpone exponentiation, if desired, until negotiation of this - exchange is complete. The graphic depictions of Aggressive Mode show - the final payload in the clear; it need not be. - - Exchanges in IKE are not open ended and have a fixed number of - messages. Receipt of a Certificate Request payload MUST NOT extend - the number of messages transmitted or expected. - - Security Association negotiation is limited with Aggressive Mode. Due - to message construction requirements the group in which the Diffie- - Hellman exchange is performed cannot be negotiated. In addition, - different authentication methods may further constrain attribute - negotiation. For example, authentication with public key encryption - cannot be negotiated and when using the revised method of public key - encryption for authentication the cipher and hash cannot be - negotiated. For situations where the rich attribute negotiation - capabilities of IKE are required Main Mode may be required. - - Quick Mode and New Group Mode have no analog in ISAKMP. The XCHG - values for Quick Mode and New Group Mode are defined in Appendix A. - - Main Mode, Aggressive Mode, and Quick Mode do security association - negotiation. Security Association offers take the form of Tranform - Payload(s) encapsulated in Proposal Payload(s) encapsulated in - Security Association (SA) payload(s). If multiple offers are being - made for phase 1 exchanges (Main Mode and Aggressive Mode) they MUST - take the form of multiple Transform Payloads for a single Proposal - Payload in a single SA payload. To put it another way, for phase 1 - exchanges there MUST NOT be multiple Proposal Payloads for a single - SA payload and there MUST NOT be multiple SA payloads. This document - does not proscribe such behavior on offers in phase 2 exchanges. - - There is no limit on the number of offers the initiator may send to - the responder but conformant implementations MAY choose to limit the - number of offers it will inspect for performance reasons. - - During security association negotiation, initiators present offers - for potential security associations to responders. Responders MUST - NOT modify attributes of any offer, attribute encoding excepted (see - Appendix A). If the initiator of an exchange notices that attribute - values have changed or attributes have been added or deleted from an - offer made, that response MUST be rejected. - - Four different authentication methods are allowed with either Main - Mode or Aggressive Mode-- digital signature, two forms of - authentication with public key encryption, or pre-shared key. The - value SKEYID is computed seperately for each authentication method. - - - - -Harkins & Carrel Standards Track [Page 9] - -RFC 2409 IKE November 1998 - - - For signatures: SKEYID = prf(Ni_b | Nr_b, g^xy) - For public key encryption: SKEYID = prf(hash(Ni_b | Nr_b), CKY-I | - CKY-R) - For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | - Nr_b) - - The result of either Main Mode or Aggressive Mode is three groups of - authenticated keying material: - - SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) - SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) - SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) - - and agreed upon policy to protect further communications. The values - of 0, 1, and 2 above are represented by a single octet. The key used - for encryption is derived from SKEYID_e in an algorithm-specific - manner (see appendix B). - - To authenticate either exchange the initiator of the protocol - generates HASH_I and the responder generates HASH_R where: - - HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) - HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b ) - - For authentication with digital signatures, HASH_I and HASH_R are - signed and verified; for authentication with either public key - encryption or pre-shared keys, HASH_I and HASH_R directly - authenticate the exchange. The entire ID payload (including ID type, - port, and protocol but excluding the generic header) is hashed into - both HASH_I and HASH_R. - - As mentioned above, the negotiated authentication method influences - the content and use of messages for Phase 1 Modes, but not their - intent. When using public keys for authentication, the Phase 1 - exchange can be accomplished either by using signatures or by using - public key encryption (if the algorithm supports it). Following are - Phase 1 exchanges with different authentication options. - -5.1 IKE Phase 1 Authenticated With Signatures - - Using signatures, the ancillary information exchanged during the - second roundtrip are nonces; the exchange is authenticated by signing - a mutually obtainable hash. Main Mode with signature authentication - is described as follows: - - - - - - - -Harkins & Carrel Standards Track [Page 10] - -RFC 2409 IKE November 1998 - - - Initiator Responder - ----------- ----------- - HDR, SA --> - <-- HDR, SA - HDR, KE, Ni --> - <-- HDR, KE, Nr - HDR*, IDii, [ CERT, ] SIG_I --> - <-- HDR*, IDir, [ CERT, ] SIG_R - - Aggressive mode with signatures in conjunction with ISAKMP is - described as follows: - - Initiator Responder - ----------- ----------- - HDR, SA, KE, Ni, IDii --> - <-- HDR, SA, KE, Nr, IDir, - [ CERT, ] SIG_R - HDR, [ CERT, ] SIG_I --> - - In both modes, the signed data, SIG_I or SIG_R, is the result of the - negotiated digital signature algorithm applied to HASH_I or HASH_R - respectively. - - In general the signature will be over HASH_I and HASH_R as above - using the negotiated prf, or the HMAC version of the negotiated hash - function (if no prf is negotiated). However, this can be overridden - for construction of the signature if the signature algorithm is tied - to a particular hash algorithm (e.g. DSS is only defined with SHA's - 160 bit output). In this case, the signature will be over HASH_I and - HASH_R as above, except using the HMAC version of the hash algorithm - associated with the signature method. The negotiated prf and hash - function would continue to be used for all other prescribed pseudo- - random functions. - - Since the hash algorithm used is already known there is no need to - encode its OID into the signature. In addition, there is no binding - between the OIDs used for RSA signatures in PKCS #1 and those used in - this document. Therefore, RSA signatures MUST be encoded as a private - key encryption in PKCS #1 format and not as a signature in PKCS #1 - format (which includes the OID of the hash algorithm). DSS signatures - MUST be encoded as r followed by s. - - One or more certificate payloads MAY be optionally passed. - - - - - - - - -Harkins & Carrel Standards Track [Page 11] - -RFC 2409 IKE November 1998 - - -5.2 Phase 1 Authenticated With Public Key Encryption - - Using public key encryption to authenticate the exchange, the - ancillary information exchanged is encrypted nonces. Each party's - ability to reconstruct a hash (proving that the other party decrypted - the nonce) authenticates the exchange. - - In order to perform the public key encryption, the initiator must - already have the responder's public key. In the case where the - responder has multiple public keys, a hash of the certificate the - initiator is using to encrypt the ancillary information is passed as - part of the third message. In this way the responder can determine - which corresponding private key to use to decrypt the encrypted - payloads and identity protection is retained. - - In addition to the nonce, the identities of the parties (IDii and - IDir) are also encrypted with the other party's public key. If the - authentication method is public key encryption, the nonce and - identity payloads MUST be encrypted with the public key of the other - party. Only the body of the payloads are encrypted, the payload - headers are left in the clear. - - When using encryption for authentication, Main Mode is defined as - follows. - - Initiator Responder - ----------- ----------- - HDR, SA --> - <-- HDR, SA - HDR, KE, [ HASH(1), ] - <IDii_b>PubKey_r, - <Ni_b>PubKey_r --> - HDR, KE, <IDir_b>PubKey_i, - <-- <Nr_b>PubKey_i - HDR*, HASH_I --> - <-- HDR*, HASH_R - - Aggressive Mode authenticated with encryption is described as - follows: - - Initiator Responder - ----------- ----------- - HDR, SA, [ HASH(1),] KE, - <IDii_b>Pubkey_r, - <Ni_b>Pubkey_r --> - HDR, SA, KE, <IDir_b>PubKey_i, - <-- <Nr_b>PubKey_i, HASH_R - HDR, HASH_I --> - - - -Harkins & Carrel Standards Track [Page 12] - -RFC 2409 IKE November 1998 - - - Where HASH(1) is a hash (using the negotiated hash function) of the - certificate which the initiator is using to encrypt the nonce and - identity. - - RSA encryption MUST be encoded in PKCS #1 format. While only the body - of the ID and nonce payloads is encrypted, the encrypted data must be - preceded by a valid ISAKMP generic header. The payload length is the - length of the entire encrypted payload plus header. The PKCS #1 - encoding allows for determination of the actual length of the - cleartext payload upon decryption. - - Using encryption for authentication provides for a plausably deniable - exchange. There is no proof (as with a digital signature) that the - conversation ever took place since each party can completely - reconstruct both sides of the exchange. In addition, security is - added to secret generation since an attacker would have to - successfully break not only the Diffie-Hellman exchange but also both - RSA encryptions. This exchange was motivated by [SKEME]. - - Note that, unlike other authentication methods, authentication with - public key encryption allows for identity protection with Aggressive - Mode. - -5.3 Phase 1 Authenticated With a Revised Mode of Public Key Encryption - - Authentication with Public Key Encryption has significant advantages - over authentication with signatures (see section 5.2 above). - Unfortunately, this is at the cost of 4 public key operations-- two - public key encryptions and two private key decryptions. This - authentication mode retains the advantages of authentication using - public key encryption but does so with half the public key - operations. - - In this mode, the nonce is still encrypted using the public key of - the peer, however the peer's identity (and the certificate if it is - sent) is encrypted using the negotiated symmetric encryption - algorithm (from the SA payload) with a key derived from the nonce. - This solution adds minimal complexity and state yet saves two costly - public key operations on each side. In addition, the Key Exchange - payload is also encrypted using the same derived key. This provides - additional protection against cryptanalysis of the Diffie-Hellman - exchange. - - As with the public key encryption method of authentication (section - 5.2), a HASH payload may be sent to identify a certificate if the - responder has multiple certificates which contain useable public keys - (e.g. if the certificate is not for signatures only, either due to - certificate restrictions or algorithmic restrictions). If the HASH - - - -Harkins & Carrel Standards Track [Page 13] - -RFC 2409 IKE November 1998 - - - payload is sent it MUST be the first payload of the second message - exchange and MUST be followed by the encrypted nonce. If the HASH - payload is not sent, the first payload of the second message exchange - MUST be the encrypted nonce. In addition, the initiator my optionally - send a certificate payload to provide the responder with a public key - with which to respond. - - When using the revised encryption mode for authentication, Main Mode - is defined as follows. - - Initiator Responder - ----------- ----------- - HDR, SA --> - <-- HDR, SA - HDR, [ HASH(1), ] - <Ni_b>Pubkey_r, - <KE_b>Ke_i, - <IDii_b>Ke_i, - [<<Cert-I_b>Ke_i] --> - HDR, <Nr_b>PubKey_i, - <KE_b>Ke_r, - <-- <IDir_b>Ke_r, - HDR*, HASH_I --> - <-- HDR*, HASH_R - - Aggressive Mode authenticated with the revised encryption method is - described as follows: - - Initiator Responder - ----------- ----------- - HDR, SA, [ HASH(1),] - <Ni_b>Pubkey_r, - <KE_b>Ke_i, <IDii_b>Ke_i - [, <Cert-I_b>Ke_i ] --> - HDR, SA, <Nr_b>PubKey_i, - <KE_b>Ke_r, <IDir_b>Ke_r, - <-- HASH_R - HDR, HASH_I --> - - where HASH(1) is identical to section 5.2. Ke_i and Ke_r are keys to - the symmetric encryption algorithm negotiated in the SA payload - exchange. Only the body of the payloads are encrypted (in both public - key and symmetric operations), the generic payload headers are left - in the clear. The payload length includes that added to perform - encryption. - - The symmetric cipher keys are derived from the decrypted nonces as - follows. First the values Ne_i and Ne_r are computed: - - - -Harkins & Carrel Standards Track [Page 14] - -RFC 2409 IKE November 1998 - - - Ne_i = prf(Ni_b, CKY-I) - Ne_r = prf(Nr_b, CKY-R) - - The keys Ke_i and Ke_r are then taken from Ne_i and Ne_r respectively - in the manner described in Appendix B used to derive symmetric keys - for use with the negotiated encryption algorithm. If the length of - the output of the negotiated prf is greater than or equal to the key - length requirements of the cipher, Ke_i and Ke_r are derived from the - most significant bits of Ne_i and Ne_r respectively. If the desired - length of Ke_i and Ke_r exceed the length of the output of the prf - the necessary number of bits is obtained by repeatedly feeding the - results of the prf back into itself and concatenating the result - until the necessary number has been achieved. For example, if the - negotiated encryption algorithm requires 320 bits of key and the - output of the prf is only 128 bits, Ke_i is the most significant 320 - bits of K, where - - K = K1 | K2 | K3 and - K1 = prf(Ne_i, 0) - K2 = prf(Ne_i, K1) - K3 = prf(Ne_i, K2) - - For brevity, only derivation of Ke_i is shown; Ke_r is identical. The - length of the value 0 in the computation of K1 is a single octet. - Note that Ne_i, Ne_r, Ke_i, and Ke_r are all ephemeral and MUST be - discarded after use. - - Save the requirements on the location of the optional HASH payload - and the mandatory nonce payload there are no further payload - requirements. All payloads-- in whatever order-- following the - encrypted nonce MUST be encrypted with Ke_i or Ke_r depending on the - direction. - - If CBC mode is used for the symmetric encryption then the - initialization vectors (IVs) are set as follows. The IV for - encrypting the first payload following the nonce is set to 0 (zero). - The IV for subsequent payloads encrypted with the ephemeral symmetric - cipher key, Ke_i, is the last ciphertext block of the previous - payload. Encrypted payloads are padded up to the nearest block size. - All padding bytes, except for the last one, contain 0x00. The last - byte of the padding contains the number of the padding bytes used, - excluding the last one. Note that this means there will always be - padding. - - - - - - - - -Harkins & Carrel Standards Track [Page 15] - -RFC 2409 IKE November 1998 - - -5.4 Phase 1 Authenticated With a Pre-Shared Key - - A key derived by some out-of-band mechanism may also be used to - authenticate the exchange. The actual establishment of this key is - out of the scope of this document. - - When doing a pre-shared key authentication, Main Mode is defined as - follows: - - Initiator Responder - ---------- ----------- - HDR, SA --> - <-- HDR, SA - HDR, KE, Ni --> - <-- HDR, KE, Nr - HDR*, IDii, HASH_I --> - <-- HDR*, IDir, HASH_R - - Aggressive mode with a pre-shared key is described as follows: - - Initiator Responder - ----------- ----------- - HDR, SA, KE, Ni, IDii --> - <-- HDR, SA, KE, Nr, IDir, HASH_R - HDR, HASH_I --> - - When using pre-shared key authentication with Main Mode the key can - only be identified by the IP address of the peers since HASH_I must - be computed before the initiator has processed IDir. Aggressive Mode - allows for a wider range of identifiers of the pre-shared secret to - be used. In addition, Aggressive Mode allows two parties to maintain - multiple, different pre-shared keys and identify the correct one for - a particular exchange. - -5.5 Phase 2 - Quick Mode - - Quick Mode is not a complete exchange itself (in that it is bound to - a phase 1 exchange), but is used as part of the SA negotiation - process (phase 2) to derive keying material and negotiate shared - policy for non-ISAKMP SAs. The information exchanged along with Quick - Mode MUST be protected by the ISAKMP SA-- i.e. all payloads except - the ISAKMP header are encrypted. In Quick Mode, a HASH payload MUST - immediately follow the ISAKMP header and a SA payload MUST - immediately follow the HASH. This HASH authenticates the message and - also provides liveliness proofs. - - - - - - -Harkins & Carrel Standards Track [Page 16] - -RFC 2409 IKE November 1998 - - - The message ID in the ISAKMP header identifies a Quick Mode in - progress for a particular ISAKMP SA which itself is identified by the - cookies in the ISAKMP header. Since each instance of a Quick Mode - uses a unique initialization vector (see Appendix B) it is possible - to have multiple simultaneous Quick Modes, based off a single ISAKMP - SA, in progress at any one time. - - Quick Mode is essentially a SA negotiation and an exchange of nonces - that provides replay protection. The nonces are used to generate - fresh key material and prevent replay attacks from generating bogus - security associations. An optional Key Exchange payload can be - exchanged to allow for an additional Diffie-Hellman exchange and - exponentiation per Quick Mode. While use of the key exchange payload - with Quick Mode is optional it MUST be supported. - - Base Quick Mode (without the KE payload) refreshes the keying - material derived from the exponentiation in phase 1. This does not - provide PFS. Using the optional KE payload, an additional - exponentiation is performed and PFS is provided for the keying - material. - - The identities of the SAs negotiated in Quick Mode are implicitly - assumed to be the IP addresses of the ISAKMP peers, without any - implied constraints on the protocol or port numbers allowed, unless - client identifiers are specified in Quick Mode. If ISAKMP is acting - as a client negotiator on behalf of another party, the identities of - the parties MUST be passed as IDci and then IDcr. Local policy will - dictate whether the proposals are acceptable for the identities - specified. If the client identities are not acceptable to the Quick - Mode responder (due to policy or other reasons), a Notify payload - with Notify Message Type INVALID-ID-INFORMATION (18) SHOULD be sent. - - The client identities are used to identify and direct traffic to the - appropriate tunnel in cases where multiple tunnels exist between two - peers and also to allow for unique and shared SAs with different - granularities. - - All offers made during a Quick Mode are logically related and must be - consistant. For example, if a KE payload is sent, the attribute - describing the Diffie-Hellman group (see section 6.1 and [Pip97]) - MUST be included in every transform of every proposal of every SA - being negotiated. Similarly, if client identities are used, they MUST - apply to every SA in the negotiation. - - Quick Mode is defined as follows: - - - - - - -Harkins & Carrel Standards Track [Page 17] - -RFC 2409 IKE November 1998 - - - Initiator Responder - ----------- ----------- - HDR*, HASH(1), SA, Ni - [, KE ] [, IDci, IDcr ] --> - <-- HDR*, HASH(2), SA, Nr - [, KE ] [, IDci, IDcr ] - HDR*, HASH(3) --> - - Where: - HASH(1) is the prf over the message id (M-ID) from the ISAKMP header - concatenated with the entire message that follows the hash including - all payload headers, but excluding any padding added for encryption. - HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni, - minus the payload header-- is added after M-ID but before the - complete message. The addition of the nonce to HASH(2) is for a - liveliness proof. HASH(3)-- for liveliness-- is the prf over the - value zero represented as a single octet, followed by a concatenation - of the message id and the two nonces-- the initiator's followed by - the responder's-- minus the payload header. In other words, the - hashes for the above exchange are: - - HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr ) - HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci | - IDcr ) - HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b) - - With the exception of the HASH, SA, and the optional ID payloads, - there are no payload ordering restrictions on Quick Mode. HASH(1) and - HASH(2) may differ from the illustration above if the order of - payloads in the message differs from the illustrative example or if - any optional payloads, for example a notify payload, have been - chained to the message. - - If PFS is not needed, and KE payloads are not exchanged, the new - keying material is defined as - - KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). - - If PFS is desired and KE payloads were exchanged, the new keying - material is defined as - - KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) - - where g(qm)^xy is the shared secret from the ephemeral Diffie-Hellman - exchange of this Quick Mode. - - In either case, "protocol" and "SPI" are from the ISAKMP Proposal - Payload that contained the negotiated Transform. - - - -Harkins & Carrel Standards Track [Page 18] - -RFC 2409 IKE November 1998 - - - A single SA negotiation results in two security assocations-- one - inbound and one outbound. Different SPIs for each SA (one chosen by - the initiator, the other by the responder) guarantee a different key - for each direction. The SPI chosen by the destination of the SA is - used to derive KEYMAT for that SA. - - For situations where the amount of keying material desired is greater - than that supplied by the prf, KEYMAT is expanded by feeding the - results of the prf back into itself and concatenating results until - the required keying material has been reached. In other words, - - KEYMAT = K1 | K2 | K3 | ... - where - K1 = prf(SKEYID_d, [ g(qm)^xy | ] protocol | SPI | Ni_b | Nr_b) - K2 = prf(SKEYID_d, K1 | [ g(qm)^xy | ] protocol | SPI | Ni_b | - Nr_b) - K3 = prf(SKEYID_d, K2 | [ g(qm)^xy | ] protocol | SPI | Ni_b | - Nr_b) - etc. - - This keying material (whether with PFS or without, and whether - derived directly or through concatenation) MUST be used with the - negotiated SA. It is up to the service to define how keys are derived - from the keying material. - - In the case of an ephemeral Diffie-Hellman exchange in Quick Mode, - the exponential (g(qm)^xy) is irretreivably removed from the current - state and SKEYID_e and SKEYID_a (derived from phase 1 negotiation) - continue to protect and authenticate the ISAKMP SA and SKEYID_d - continues to be used to derive keys. - - Using Quick Mode, multiple SA's and keys can be negotiated with one - exchange as follows: - - Initiator Responder - ----------- ----------- - HDR*, HASH(1), SA0, SA1, Ni, - [, KE ] [, IDci, IDcr ] --> - <-- HDR*, HASH(2), SA0, SA1, Nr, - [, KE ] [, IDci, IDcr ] - HDR*, HASH(3) --> - - The keying material is derived identically as in the case of a single - SA. In this case (negotiation of two SA payloads) the result would be - four security associations-- two each way for both SAs. - - - - - - -Harkins & Carrel Standards Track [Page 19] - -RFC 2409 IKE November 1998 - - -5.6 New Group Mode - - New Group Mode MUST NOT be used prior to establishment of an ISAKMP - SA. The description of a new group MUST only follow phase 1 - negotiation. (It is not a phase 2 exchange, though). - - Initiator Responder - ----------- ----------- - HDR*, HASH(1), SA --> - <-- HDR*, HASH(2), SA - - where HASH(1) is the prf output, using SKEYID_a as the key, and the - message-ID from the ISAKMP header concatenated with the entire SA - proposal, body and header, as the data; HASH(2) is the prf output, - using SKEYID_a as the key, and the message-ID from the ISAKMP header - concatenated with the reply as the data. In other words the hashes - for the above exchange are: - - HASH(1) = prf(SKEYID_a, M-ID | SA) - HASH(2) = prf(SKEYID_a, M-ID | SA) - - The proposal will specify the characteristics of the group (see - appendix A, "Attribute Assigned Numbers"). Group descriptions for - private Groups MUST be greater than or equal to 2^15. If the group - is not acceptable, the responder MUST reply with a Notify payload - with the message type set to ATTRIBUTES-NOT-SUPPORTED (13). - - ISAKMP implementations MAY require private groups to expire with the - SA under which they were established. - - Groups may be directly negotiated in the SA proposal with Main Mode. - To do this the component parts-- for a MODP group, the type, prime - and generator; for a EC2N group the type, the Irreducible Polynomial, - Group Generator One, Group Generator Two, Group Curve A, Group Curve - B and Group Order-- are passed as SA attributes (see Appendix A). - Alternately, the nature of the group can be hidden using New Group - Mode and only the group identifier is passed in the clear during - phase 1 negotiation. - -5.7 ISAKMP Informational Exchanges - - This protocol protects ISAKMP Informational Exchanges when possible. - Once the ISAKMP security association has been established (and - SKEYID_e and SKEYID_a have been generated) ISAKMP Information - Exchanges, when used with this protocol, are as follows: - - - - - - -Harkins & Carrel Standards Track [Page 20] - -RFC 2409 IKE November 1998 - - - Initiator Responder - ----------- ----------- - HDR*, HASH(1), N/D --> - - where N/D is either an ISAKMP Notify Payload or an ISAKMP Delete - Payload and HASH(1) is the prf output, using SKEYID_a as the key, and - a M-ID unique to this exchange concatenated with the entire - informational payload (either a Notify or Delete) as the data. In - other words, the hash for the above exchange is: - - HASH(1) = prf(SKEYID_a, M-ID | N/D) - - As noted the message ID in the ISAKMP header-- and used in the prf - computation-- is unique to this exchange and MUST NOT be the same as - the message ID of another phase 2 exchange which generated this - informational exchange. The derivation of the initialization vector, - used with SKEYID_e to encrypt this message, is described in Appendix - B. - - If the ISAKMP security association has not yet been established at - the time of the Informational Exchange, the exchange is done in the - clear without an accompanying HASH payload. - -6 Oakley Groups - - With IKE, the group in which to do the Diffie-Hellman exchange is - negotiated. Four groups-- values 1 through 4-- are defined below. - These groups originated with the Oakley protocol and are therefore - called "Oakley Groups". The attribute class for "Group" is defined in - Appendix A. All values 2^15 and higher are used for private group - identifiers. For a discussion on the strength of the default Oakley - groups please see the Security Considerations section below. - - These groups were all generated by Richard Schroeppel at the - University of Arizona. Properties of these groups are described in - [Orm96]. - -6.1 First Oakley Default Group - - Oakley implementations MUST support a MODP group with the following - prime and generator. 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 - - - - - - - -Harkins & Carrel Standards Track [Page 21] - -RFC 2409 IKE November 1998 - - - 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. - -6.2 Second Oakley Group - - IKE implementations SHOULD support a MODP group with the following - prime and generator. 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 (decimal) - -6.3 Third Oakley Group - - IKE implementations SHOULD support a EC2N group with the following - characteristics. This group is assigned id 3 (three). The curve is - based on the Galois Field GF[2^155]. The field size is 155. The - irreducible polynomial for the field is: - u^155 + u^62 + 1. - The equation for the elliptic curve is: - y^2 + xy = x^3 + ax^2 + b. - - Field Size: 155 - Group Prime/Irreducible Polynomial: - 0x0800000000000000000000004000000000000001 - Group Generator One: 0x7b - Group Curve A: 0x0 - Group Curve B: 0x07338f - - Group Order: 0X0800000000000000000057db5698537193aef944 - - The data in the KE payload when using this group is the value x from - the solution (x,y), the point on the curve chosen by taking the - randomly chosen secret Ka and computing Ka*P, where * is the - repetition of the group addition and double operations, P is the - curve point with x coordinate equal to generator 1 and the y - - - -Harkins & Carrel Standards Track [Page 22] - -RFC 2409 IKE November 1998 - - - coordinate determined from the defining equation. The equation of - curve is implicitly known by the Group Type and the A and B - coefficients. There are two possible values for the y coordinate; - either one can be used successfully (the two parties need not agree - on the selection). - -6.4 Fourth Oakley Group - - IKE implementations SHOULD support a EC2N group with the following - characteristics. This group is assigned id 4 (four). The curve is - based on the Galois Field GF[2^185]. The field size is 185. The - irreducible polynomial for the field is: - u^185 + u^69 + 1. The - equation for the elliptic curve is: - y^2 + xy = x^3 + ax^2 + b. - - Field Size: 185 - Group Prime/Irreducible Polynomial: - 0x020000000000000000000000000000200000000000000001 - Group Generator One: 0x18 - Group Curve A: 0x0 - Group Curve B: 0x1ee9 - - Group Order: 0X01ffffffffffffffffffffffdbf2f889b73e484175f94ebc - - The data in the KE payload when using this group will be identical to - that as when using Oakley Group 3 (three). - - Other groups can be defined using New Group Mode. These default - groups were generated by Richard Schroeppel at the University of - Arizona. Properties of these primes are described in [Orm96]. - -7. Payload Explosion for a Complete IKE Exchange - - This section illustrates how the IKE protocol is used to: - - - establish a secure and authenticated channel between ISAKMP - processes (phase 1); and - - - generate key material for, and negotiate, an IPsec SA (phase 2). - -7.1 Phase 1 using Main Mode - - The following diagram illustrates the payloads exchanged between the - two parties in the first round trip exchange. The initiator MAY - propose several proposals; the responder MUST reply with one. - - - - - -Harkins & Carrel Standards Track [Page 23] - -RFC 2409 IKE November 1998 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ISAKMP Header with XCHG of Main Mode, ~ - ~ and Next Payload of ISA_SA ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Situation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Proposal #1 ! PROTO_ISAKMP ! SPI size = 0 | # Transforms ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_TRANS ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Transform #1 ! KEY_OAKLEY | RESERVED2 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ prefered SA attributes ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Transform #2 ! KEY_OAKLEY | RESERVED2 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ alternate SA attributes ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The responder replies in kind but selects, and returns, one transform - proposal (the ISAKMP SA attributes). - - The second exchange consists of the following payloads: - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ISAKMP Header with XCHG of Main Mode, ~ - ~ and Next Payload of ISA_KE ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_NONCE ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ D-H Public Value (g^xi from initiator g^xr from responder) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Ni (from initiator) or Nr (from responder) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - -Harkins & Carrel Standards Track [Page 24] - -RFC 2409 IKE November 1998 - - - The shared keys, SKEYID_e and SKEYID_a, are now used to protect and - authenticate all further communication. Note that both SKEYID_e and - SKEYID_a are unauthenticated. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ISAKMP Header with XCHG of Main Mode, ~ - ~ and Next Payload of ISA_ID and the encryption bit set ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_SIG ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Identification Data of the ISAKMP negotiator ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ signature verified by the public key of the ID above ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The key exchange is authenticated over a signed hash as described in - section 5.1. Once the signature has been verified using the - authentication algorithm negotiated as part of the ISAKMP SA, the - shared keys, SKEYID_e and SKEYID_a can be marked as authenticated. - (For brevity, certificate payloads were not exchanged). - -7.2 Phase 2 using Quick Mode - - The following payloads are exchanged in the first round of Quick Mode - with ISAKMP SA negotiation. In this hypothetical exchange, the ISAKMP - negotiators are proxies for other parties which have requested - authentication. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ISAKMP Header with XCHG of Quick Mode, ~ - ~ Next Payload of ISA_HASH and the encryption bit set ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_SA ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ keyed hash of message ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_NONCE ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain Of Interpretation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Situation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Harkins & Carrel Standards Track [Page 25] - -RFC 2409 IKE November 1998 - - - ! Proposal #1 ! PROTO_IPSEC_AH! SPI size = 4 | # Transforms ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ SPI (4 octets) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_TRANS ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Transform #1 ! AH_SHA | RESERVED2 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! other SA attributes ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Transform #2 ! AH_MD5 | RESERVED2 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! other SA attributes ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_ID ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ nonce ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ISA_ID ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ID of source for which ISAKMP is a client ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ID of destination for which ISAKMP is a client ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - where the contents of the hash are described in 5.5 above. The - responder replies with a similar message which only contains one - transform-- the selected AH transform. Upon receipt, the initiator - can provide the key engine with the negotiated security association - and the keying material. As a check against replay attacks, the - responder waits until receipt of the next message. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ISAKMP Header with XCHG of Quick Mode, ~ - ~ Next Payload of ISA_HASH and the encryption bit set ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 0 ! RESERVED ! Payload Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ hash data ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - where the contents of the hash are described in 5.5 above. - - - - -Harkins & Carrel Standards Track [Page 26] - -RFC 2409 IKE November 1998 - - -8. Perfect Forward Secrecy Example - - This protocol can provide PFS of both keys and identities. The - identies of both the ISAKMP negotiating peer and, if applicable, the - identities for whom the peers are negotiating can be protected with - PFS. - - To provide Perfect Forward Secrecy of both keys and all identities, - two parties would perform the following: - - o A Main Mode Exchange to protect the identities of the ISAKMP - peers. - This establishes an ISAKMP SA. - o A Quick Mode Exchange to negotiate other security protocol - protection. - This establishes a SA on each end for this protocol. - o Delete the ISAKMP SA and its associated state. - - Since the key for use in the non-ISAKMP SA was derived from the - single ephemeral Diffie-Hellman exchange PFS is preserved. - - To provide Perfect Forward Secrecy of merely the keys of a non-ISAKMP - security association, it in not necessary to do a phase 1 exchange if - an ISAKMP SA exists between the two peers. A single Quick Mode in - which the optional KE payload is passed, and an additional Diffie- - Hellman exchange is performed, is all that is required. At this point - the state derived from this Quick Mode must be deleted from the - ISAKMP SA as described in section 5.5. - -9. Implementation Hints - - Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 - negotiations extremely quick. As long as the Phase 1 state remains - cached, and PFS is not needed, Phase 2 can proceed without any - exponentiation. How many Phase 2 negotiations can be performed for a - single Phase 1 is a local policy issue. The decision will depend on - the strength of the algorithms being used and level of trust in the - peer system. - - An implementation may wish to negotiate a range of SAs when - performing Quick Mode. By doing this they can speed up the "re- - keying". Quick Mode defines how KEYMAT is defined for a range of SAs. - When one peer feels it is time to change SAs they simply use the next - one within the stated range. A range of SAs can be established by - negotiating multiple SAs (identical attributes, different SPIs) with - one Quick Mode. - - - - - -Harkins & Carrel Standards Track [Page 27] - -RFC 2409 IKE November 1998 - - - An optimization that is often useful is to establish Security - Associations with peers before they are needed so that when they - become needed they are already in place. This ensures there would be - no delays due to key management before initial data transmission. - This optimization is easily implemented by setting up more than one - Security Association with a peer for each requested Security - Association and caching those not immediately used. - - Also, if an ISAKMP implementation is alerted that a SA will soon be - needed (e.g. to replace an existing SA that will expire in the near - future), then it can establish the new SA before that new SA is - needed. - - The base ISAKMP specification describes conditions in which one party - of the protocol may inform the other party of some activity-- either - deletion of a security association or in response to some error in - the protocol such as a signature verification failed or a payload - failed to decrypt. It is strongly suggested that these Informational - exchanges not be responded to under any circumstances. Such a - condition may result in a "notify war" in which failure to understand - a message results in a notify to the peer who cannot understand it - and sends his own notify back which is also not understood. - -10. Security Considerations - - This entire memo discusses a hybrid protocol, combining parts of - Oakley and parts of SKEME with ISAKMP, to negotiate, and derive - keying material for, security associations in a secure and - authenticated manner. - - Confidentiality is assured by the use of a negotiated encryption - algorithm. Authentication is assured by the use of a negotiated - method: a digital signature algorithm; a public key algorithm which - supports encryption; or, a pre-shared key. The confidentiality and - authentication of this exchange is only as good as the attributes - negotiated as part of the ISAKMP security association. - - Repeated re-keying using Quick Mode can consume the entropy of the - Diffie-Hellman shared secret. Implementors should take note of this - fact and set a limit on Quick Mode Exchanges between exponentiations. - This memo does not prescribe such a limit. - - Perfect Forward Secrecy (PFS) of both keying material and identities - is possible with this protocol. By specifying a Diffie-Hellman group, - and passing public values in KE payloads, ISAKMP peers can establish - PFS of keys-- the identities would be protected by SKEYID_e from the - ISAKMP SA and would therefore not be protected by PFS. If PFS of both - keying material and identities is desired, an ISAKMP peer MUST - - - -Harkins & Carrel Standards Track [Page 28] - -RFC 2409 IKE November 1998 - - - establish only one non-ISAKMP security association (e.g. IPsec - Security Association) per ISAKMP SA. PFS for keys and identities is - accomplished by deleting the ISAKMP SA (and optionally issuing a - DELETE message) upon establishment of the single non-ISAKMP SA. In - this way a phase one negotiation is uniquely tied to a single phase - two negotiation, and the ISAKMP SA established during phase one - negotiation is never used again. - - 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. The - default Diffie-Hellman group (number one) when used with a strong - random number generator and an exponent no less than 160 bits is - sufficient to use for DES. Groups two through four provide greater - security. Implementations should make note of these conservative - estimates when establishing policy and negotiating security - parameters. - - Note that these limitations are on the Diffie-Hellman groups - themselves. There is nothing in IKE which prohibits using stronger - groups nor is there anything which will dilute the strength obtained - from stronger groups. In fact, the extensible framework of IKE - encourages the definition of more groups; use of elliptical curve - groups will greatly increase strength using much smaller numbers. - - For situations where defined groups provide insufficient strength New - Group Mode can be used to exchange a Diffie-Hellman group which - provides the necessary strength. In is incumbent upon implementations - to check the primality in groups being offered and independently - arrive at strength estimates. - - It is assumed that the Diffie-Hellman exponents in this exchange 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. - - IKE exchanges maintain running initialization vectors (IV) where the - last ciphertext block of the last message is the IV for the next - message. To prevent retransmissions (or forged messages with valid - cookies) from causing exchanges to get out of sync IKE - implementations SHOULD NOT update their running IV until the - decrypted message has passed a basic sanity check and has been - determined to actually advance the IKE state machine-- i.e. it is not - a retransmission. - - - - - -Harkins & Carrel Standards Track [Page 29] - -RFC 2409 IKE November 1998 - - - While the last roundtrip of Main Mode (and optionally the last - message of Aggressive Mode) is encrypted it is not, strictly - speaking, authenticated. An active substitution attack on the - ciphertext could result in payload corruption. If such an attack - corrupts mandatory payloads it would be detected by an authentication - failure, but if it corrupts any optional payloads (e.g. notify - payloads chained onto the last message of a Main Mode exchange) it - might not be detectable. - -11. IANA Considerations - - This document contains many "magic numbers" to be maintained by the - IANA. This section explains the criteria to be used by the IANA to - assign additional numbers in each of these lists. - -11.1 Attribute Classes - - Attributes negotiated in this protocol are identified by their class. - Requests for assignment of new classes must be accompanied by a - standards-track RFC which describes the use of this attribute. - -11.2 Encryption Algorithm Class - - Values of the Encryption Algorithm Class define an encryption - algorithm to use when called for in this document. Requests for - assignment of new encryption algorithm values must be accompanied by - a reference to a standards-track or Informational RFC or a reference - to published cryptographic literature which describes this algorithm. - -11.3 Hash Algorithm - - Values of the Hash Algorithm Class define a hash algorithm to use - when called for in this document. Requests for assignment of new hash - algorithm values must be accompanied by a reference to a standards- - track or Informational RFC or a reference to published cryptographic - literature which describes this algorithm. Due to the key derivation - and key expansion uses of HMAC forms of hash algorithms in IKE, - requests for assignment of new hash algorithm values must take into - account the cryptographic properties-- e.g it's resistance to - collision-- of the hash algorithm itself. - -11.4 Group Description and Group Type - - Values of the Group Description Class identify a group to use in a - Diffie-Hellman exchange. Values of the Group Type Class define the - type of group. Requests for assignment of new groups must be - accompanied by a reference to a standards-track or Informational RFC - which describes this group. Requests for assignment of new group - - - -Harkins & Carrel Standards Track [Page 30] - -RFC 2409 IKE November 1998 - - - types must be accompanied by a reference to a standards-track or - Informational RFC or by a reference to published cryptographic or - mathmatical literature which describes the new type. - -11.5 Life Type - - Values of the Life Type Class define a type of lifetime to which the - ISAKMP Security Association applies. Requests for assignment of new - life types must be accompanied by a detailed description of the units - of this type and its expiry. - -12. Acknowledgements - - This document is the result of close consultation with Hugo Krawczyk, - Douglas Maughan, Hilarie Orman, Mark Schertler, Mark Schneider, and - Jeff Turner. It relies on protocols which were written by them. - Without their interest and dedication, this would not have been - written. - - Special thanks Rob Adams, Cheryl Madson, Derrell Piper, Harry Varnis, - and Elfed Weaver for technical input, encouragement, and various - sanity checks along the way. - - We would also like to thank the many members of the IPSec working - group that contributed to the development of this protocol over the - past year. - -13. References - - [CAST] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, - May 1997. - - [BLOW] Schneier, B., "The Blowfish Encryption Algorithm", Dr. - Dobb's Journal, v. 19, n. 4, April 1994. - - [Bra97] Bradner, S., "Key Words for use in RFCs to indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [DES] ANSI X3.106, "American National Standard for Information - Systems-Data Link Encryption", American National Standards - Institute, 1983. - - [DH] Diffie, W., and Hellman M., "New Directions in - Cryptography", IEEE Transactions on Information Theory, V. - IT-22, n. 6, June 1977. - - - - - - -Harkins & Carrel Standards Track [Page 31] - -RFC 2409 IKE November 1998 - - - [DSS] NIST, "Digital Signature Standard", FIPS 186, National - Institute of Standards and Technology, U.S. Department of - Commerce, May, 1994. - - [IDEA] Lai, X., "On the Design and Security of Block Ciphers," ETH - Series in Information Processing, v. 1, Konstanz: Hartung- - Gorre Verlag, 1992 - - [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. - - [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange - Mechanism for Internet", from IEEE Proceedings of the 1996 - Symposium on Network and Distributed Systems Security. - - [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, - April 1992. - - [MSST98] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, - "Internet Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [Orm96] Orman, H., "The Oakley Key Determination Protocol", RFC - 2412, November 1998. - - [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard", - November 1993. - - [Pip98] Piper, D., "The Internet IP Security Domain Of - Interpretation for ISAKMP", RFC 2407, November 1998. - - [RC5] Rivest, R., "The RC5 Encryption Algorithm", Dr. Dobb's - Journal, v. 20, n. 1, January 1995. - - [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for - Obtaining Digital Signatures and Public-Key Cryptosystems", - Communications of the ACM, v. 21, n. 2, February 1978. - - [Sch96] Schneier, B., "Applied Cryptography, Protocols, Algorithms, - and Source Code in C", 2nd edition. - - [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National Institue - of Standards and Technology, U.S. Department of Commerce, - May 1994. - - [TIGER] Anderson, R., and Biham, E., "Fast Software Encryption", - Springer LNCS v. 1039, 1996. - - - -Harkins & Carrel Standards Track [Page 32] - -RFC 2409 IKE November 1998 - - -Appendix A - - This is a list of DES Weak and Semi-Weak keys. The keys come from - [Sch96]. All keys are listed in hexidecimal. - - DES Weak Keys - 0101 0101 0101 0101 - 1F1F 1F1F E0E0 E0E0 - E0E0 E0E0 1F1F 1F1F - FEFE FEFE FEFE FEFE - - DES Semi-Weak Keys - 01FE 01FE 01FE 01FE - 1FE0 1FE0 0EF1 0EF1 - 01E0 01E0 01F1 01F1 - 1FFE 1FFE 0EFE 0EFE - 011F 011F 010E 010E - E0FE E0FE F1FE F1FE - - FE01 FE01 FE01 FE01 - E01F E01F F10E F10E - E001 E001 F101 F101 - FE1F FE1F FE0E FE0E - 1F01 1F01 0E01 0E01 - FEE0 FEE0 FEF1 FEF1 - - Attribute Assigned Numbers - - Attributes negotiated during phase one use the following definitions. - Phase two attributes are defined in the applicable DOI specification - (for example, IPsec attributes are defined in the IPsec DOI), with - the exception of a group description when Quick Mode includes an - ephemeral Diffie-Hellman exchange. Attribute types can be either - Basic (B) or Variable-length (V). Encoding of these attributes is - defined in the base ISAKMP specification as Type/Value (Basic) and - Type/Length/Value (Variable). - - Attributes described as basic MUST NOT be encoded as variable. - Variable length attributes MAY be encoded as basic attributes if - their value can fit into two octets. If this is the case, an - attribute offered as variable (or basic) by the initiator of this - protocol MAY be returned to the initiator as a basic (or variable). - - - - - - - - - -Harkins & Carrel Standards Track [Page 33] - -RFC 2409 IKE November 1998 - - - Attribute Classes - - class value type - ------------------------------------------------------------------- - Encryption Algorithm 1 B - Hash Algorithm 2 B - Authentication Method 3 B - Group Description 4 B - Group Type 5 B - Group Prime/Irreducible Polynomial 6 V - Group Generator One 7 V - Group Generator Two 8 V - Group Curve A 9 V - Group Curve B 10 V - Life Type 11 B - Life Duration 12 V - PRF 13 B - Key Length 14 B - Field Size 15 B - Group Order 16 V - - values 17-16383 are reserved to IANA. Values 16384-32767 are for - private use among mutually consenting parties. - - Class Values - - - Encryption Algorithm Defined In - DES-CBC 1 RFC 2405 - IDEA-CBC 2 - Blowfish-CBC 3 - RC5-R16-B64-CBC 4 - 3DES-CBC 5 - CAST-CBC 6 - - values 7-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. - - - Hash Algorithm Defined In - MD5 1 RFC 1321 - SHA 2 FIPS 180-1 - Tiger 3 See Reference [TIGER] - - values 4-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. - - - - - - - -Harkins & Carrel Standards Track [Page 34] - -RFC 2409 IKE November 1998 - - - - Authentication Method - pre-shared key 1 - DSS signatures 2 - RSA signatures 3 - Encryption with RSA 4 - Revised encryption with RSA 5 - - values 6-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. - - - Group Description - default 768-bit MODP group (section 6.1) 1 - - alternate 1024-bit MODP group (section 6.2) 2 - - EC2N group on GP[2^155] (section 6.3) 3 - - EC2N group on GP[2^185] (section 6.4) 4 - - values 5-32767 are reserved to IANA. Values 32768-65535 are for - private use among mutually consenting parties. - - - Group Type - MODP (modular exponentiation group) 1 - ECP (elliptic curve group over GF[P]) 2 - EC2N (elliptic curve group over GF[2^N]) 3 - - values 4-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. - - - Life Type - seconds 1 - kilobytes 2 - - values 3-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. For a given "Life - Type" the value of the "Life Duration" attribute defines the actual - length of the SA life-- either a number of seconds, or a number of - kbytes protected. - - - PRF - There are currently no pseudo-random functions defined. - - values 1-65000 are reserved to IANA. Values 65001-65535 are for - private use among mutually consenting parties. - - - - - - -Harkins & Carrel Standards Track [Page 35] - -RFC 2409 IKE November 1998 - - - - 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. - - - Field Size - - The field size, in bits, of a Diffie-Hellman group. - - - Group Order - - The group order of an elliptical curve group. Note the length of - this attribute depends on the field size. - - Additional Exchanges Defined-- XCHG values - Quick Mode 32 - New Group Mode 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Harkins & Carrel Standards Track [Page 36] - -RFC 2409 IKE November 1998 - - -Appendix B - - This appendix describes encryption details to be used ONLY when - encrypting ISAKMP messages. When a service (such as an IPSEC - transform) utilizes ISAKMP to generate keying material, all - encryption algorithm specific details (such as key and IV generation, - padding, etc...) MUST be defined by that service. ISAKMP does not - purport to ever produce keys that are suitable for any encryption - algorithm. ISAKMP produces the requested amount of keying material - from which the service MUST generate a suitable key. Details, such - as weak key checks, are the responsibility of the service. - - Use of negotiated PRFs may require the PRF output to be expanded due - to the PRF feedback mechanism employed by this document. For example, - if the (ficticious) DOORAK-MAC requires 24 bytes of key but produces - only 8 bytes of output, the output must be expanded three times - before being used as the key for another instance of itself. The - output of a PRF is expanded by feeding back the results of the PRF - into itself to generate successive blocks. These blocks are - concatenated until the requisite number of bytes has been acheived. - For example, for pre-shared key authentication with DOORAK-MAC as the - negotiated PRF: - - BLOCK1-8 = prf(pre-shared-key, Ni_b | Nr_b) - BLOCK9-16 = prf(pre-shared-key, BLOCK1-8 | Ni_b | Nr_b) - BLOCK17-24 = prf(pre-shared-key, BLOCK9-16 | Ni_b | Nr_b) - and - SKEYID = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 - - so therefore to derive SKEYID_d: - - BLOCK1-8 = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) - BLOCK9-16 = prf(SKEYID, BLOCK1-8 | g^xy | CKY-I | CKY-R | 0) - BLOCK17-24 = prf(SKEYID, BLOCK9-16 | g^xy | CKY-I | CKY-R | 0) - and - SKEYID_d = BLOCK1-8 | BLOCK9-16 | BLOCK17-24 - - Subsequent PRF derivations are done similarly. - - Encryption keys used to protect the ISAKMP SA are derived from - SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long - enough to supply all the necessary keying material an algorithm - requires, the key is derived from feeding the results of a pseudo- - random function into itself, concatenating the results, and taking - the highest necessary bits. - - - - - - -Harkins & Carrel Standards Track [Page 37] - -RFC 2409 IKE November 1998 - - - For example, if (ficticious) algorithm AKULA requires 320-bits of key - (and has no weak key check) and the prf used to generate SKEYID_e - only generates 120 bits of material, the key for AKULA, would be the - first 320-bits of Ka, where: - - Ka = K1 | K2 | K3 - and - K1 = prf(SKEYID_e, 0) - K2 = prf(SKEYID_e, K1) - K3 = prf(SKEYID_e, K2) - - where prf is the negotiated prf or the HMAC version of the negotiated - hash function (if no prf was negotiated) and 0 is represented by a - single octet. Each result of the prf provides 120 bits of material - for a total of 360 bits. AKULA would use the first 320 bits of that - 360 bit string. - - In phase 1, material for the initialization vector (IV material) for - CBC mode encryption algorithms is derived from a hash of a - concatenation of the initiator's public Diffie-Hellman value and the - responder's public Diffie-Hellman value using the negotiated hash - algorithm. This is used for the first message only. Each message - should be padded up to the nearest block size using bytes containing - 0x00. The message length in the header MUST include the length of the - pad since this reflects the size of the ciphertext. Subsequent - messages MUST use the last CBC encryption block from the previous - message as their initialization vector. - - In phase 2, material for the initialization vector for CBC mode - encryption of the first message of a Quick Mode exchange is derived - from a hash of a concatenation of the last phase 1 CBC output block - and the phase 2 message id using the negotiated hash algorithm. The - IV for subsequent messages within a Quick Mode exchange is the CBC - output block from the previous message. Padding and IVs for - subsequent messages are done as in phase 1. - - After the ISAKMP SA has been authenticated all Informational - Exchanges are encrypted using SKEYID_e. The initiaization vector for - these exchanges is derived in exactly the same fashion as that for a - Quick Mode-- i.e. it is derived from a hash of a concatenation of the - last phase 1 CBC output block and the message id from the ISAKMP - header of the Informational Exchange (not the message id from the - message that may have prompted the Informational Exchange). - - Note that the final phase 1 CBC output block, the result of - encryption/decryption of the last phase 1 message, must be retained - in the ISAKMP SA state to allow for generation of unique IVs for each - Quick Mode. Each post- phase 1 exchange (Quick Modes and - - - -Harkins & Carrel Standards Track [Page 38] - -RFC 2409 IKE November 1998 - - - Informational Exchanges) generates IVs independantly to prevent IVs - from getting out of sync when two different exchanges are started - simultaneously. - - In all cases, there is a single bidirectional cipher/IV context. - Having each Quick Mode and Informational Exchange maintain a unique - context prevents IVs from getting out of sync. - - The key for DES-CBC is derived from the first eight (8) non-weak and - non-semi-weak (see Appendix A) bytes of SKEYID_e. The IV is the first - 8 bytes of the IV material derived above. - - The key for IDEA-CBC is derived from the first sixteen (16) bytes of - SKEYID_e. The IV is the first eight (8) bytes of the IV material - derived above. - - The key for Blowfish-CBC is either the negotiated key size, or the - first fifty-six (56) bytes of a key (if no key size is negotiated) - derived in the aforementioned pseudo-random function feedback method. - The IV is the first eight (8) bytes of the IV material derived above. - - The key for RC5-R16-B64-CBC is the negotiated key size, or the first - sixteen (16) bytes of a key (if no key size is negotiated) derived - from the aforementioned pseudo-random function feedback method if - necessary. The IV is the first eight (8) bytes of the IV material - derived above. The number of rounds MUST be 16 and the block size - MUST be 64. - - The key for 3DES-CBC is the first twenty-four (24) bytes of a key - derived in the aforementioned pseudo-random function feedback method. - 3DES-CBC is an encrypt-decrypt-encrypt operation using the first, - middle, and last eight (8) bytes of the entire 3DES-CBC key. The IV - is the first eight (8) bytes of the IV material derived above. - - The key for CAST-CBC is either the negotiated key size, or the first - sixteen (16) bytes of a key derived in the aforementioned pseudo- - random function feedback method. The IV is the first eight (8) bytes - of the IV material derived above. - - Support for algorithms other than DES-CBC is purely optional. Some - optional algorithms may be subject to intellectual property claims. - - - - - - - - - - -Harkins & Carrel Standards Track [Page 39] - -RFC 2409 IKE November 1998 - - -Authors' Addresses - - Dan Harkins - cisco Systems - 170 W. Tasman Dr. - San Jose, California, 95134-1706 - United States of America - - Phone: +1 408 526 4000 - EMail: dharkins@cisco.com - - - Dave Carrel - 76 Lippard Ave. - San Francisco, CA 94131-2947 - United States of America - - Phone: +1 415 337 8469 - EMail: carrel@ipsec.org - -Authors' Note - - The authors encourage independent implementation, and - interoperability testing, of this hybrid protocol. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Harkins & Carrel Standards Track [Page 40] - -RFC 2409 IKE November 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Harkins & Carrel Standards Track [Page 41] - diff --git a/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt b/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt deleted file mode 100644 index 9169d78be..000000000 --- a/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt +++ /dev/null @@ -1,3083 +0,0 @@ - - - - - - -Network Working Group H. Orman -Request for Comments: 2412 Department of Computer Science -Category: Informational University of Arizona - November 1998 - - - The OAKLEY Key Determination Protocol - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - This document describes a protocol, named OAKLEY, by which two - authenticated parties can agree on secure and secret keying material. - The basic mechanism is the Diffie-Hellman key exchange algorithm. - - The OAKLEY protocol supports Perfect Forward Secrecy, compatibility - with the ISAKMP protocol for managing security associations, user- - defined abstract group structures for use with the Diffie-Hellman - algorithm, key updates, and incorporation of keys distributed via - out-of-band mechanisms. - -1. INTRODUCTION - - Key establishment is the heart of data protection that relies on - cryptography, and it is an essential component of the packet - protection mechanisms described in [RFC2401], for example. A - scalable and secure key distribution mechanism for the Internet is a - necessity. The goal of this protocol is to provide that mechanism, - coupled with a great deal of cryptographic strength. - - The Diffie-Hellman key exchange algorithm provides such a mechanism. - It allows two parties to agree on a shared value without requiring - encryption. The shared value is immediately available for use in - encrypting subsequent conversation, e.g. data transmission and/or - authentication. The STS protocol [STS] provides a demonstration of - how to embed the algorithm in a secure protocol, one that ensures - that in addition to securely sharing a secret, the two parties can be - sure of each other's identities, even when an active attacker exists. - - - - -Orman Informational [Page 1] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Because OAKLEY is a generic key exchange protocol, and because the - keys that it generates might be used for encrypting data with a long - privacy lifetime, 20 years or more, it is important that the - algorithms underlying the protocol be able to ensure the security of - the keys for that period of time, based on the best prediction - capabilities available for seeing into the mathematical future. The - protocol therefore has two options for adding to the difficulties - faced by an attacker who has a large amount of recorded key exchange - traffic at his disposal (a passive attacker). These options are - useful for deriving keys which will be used for encryption. - - The OAKLEY protocol is related to STS, sharing the similarity of - authenticating the Diffie-Hellman exponentials and using them for - determining a shared key, and also of achieving Perfect Forward - Secrecy for the shared key, but it differs from the STS protocol in - several ways. - - The first is the addition of a weak address validation mechanism - ("cookies", described by Phil Karn in the Photuris key exchange - protocol work in progress) to help avoid denial of service - attacks. - - The second extension is to allow the two parties to select - mutually agreeable supporting algorithms for the protocol: the - encryption method, the key derivation method, and the - authentication method. - - Thirdly, the authentication does not depend on encryption using - the Diffie-Hellman exponentials; instead, the authentication - validates the binding of the exponentials to the identities of the - parties. - - The protocol does not require the two parties compute the shared - exponentials prior to authentication. - - This protocol adds additional security to the derivation of keys - meant for use with encryption (as opposed to authentication) by - including a dependence on an additional algorithm. The derivation - of keys for encryption is made to depend not only on the Diffie- - Hellman algorithm, but also on the cryptographic method used to - securely authenticate the communicating parties to each other. - - Finally, this protocol explicitly defines how the two parties can - select the mathematical structures (group representation and - operation) for performing the Diffie-Hellman algorithm; they can - use standard groups or define their own. User-defined groups - provide an additional degree of long-term security. - - - - -Orman Informational [Page 2] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - OAKLEY has several options for distributing keys. In addition to the - classic Diffie-Hellman exchange, this protocol can be used to derive - a new key from an existing key and to distribute an externally - derived key by encrypting it. - - The protocol allows two parties to use all or some of the anti- - clogging and perfect forward secrecy features. It also permits the - use of authentication based on symmetric encryption or non-encryption - algorithms. This flexibility is included in order to allow the - parties to use the features that are best suited to their security - and performance requirements. - - This document draws extensively in spirit and approach from the - Photuris work in progress by Karn and Simpson (and from discussions - with the authors), specifics of the ISAKMP document by Schertler et - al. the ISAKMP protocol document, and it was also influenced by - papers by Paul van Oorschot and Hugo Krawcyzk. - -2. The Protocol Outline - -2.1 General Remarks - - The OAKLEY protocol is used to establish a shared key with an - assigned identifier and associated authenticated identities for the - two parties. The name of the key can be used later to derive - security associations for the RFC 2402 and RFC 2406 protocols (AH and - ESP) or to achieve other network security goals. - - Each key is associated with algorithms that are used for - authentication, privacy, and one-way functions. These are ancillary - algorithms for OAKLEY; their appearance in subsequent security - association definitions derived with other protocols is neither - required nor prohibited. - - The specification of the details of how to apply an algorithm to data - is called a transform. This document does not supply the transform - definitions; they will be in separate RFC's. - - The anti-clogging tokens, or "cookies", provide a weak form of source - address identification for both parties; the cookie exchange can be - completed before they perform the computationally expensive part of - the protocol (large integer exponentiations). - - It is important to note that OAKLEY uses the cookies for two - purposes: anti-clogging and key naming. The two parties to the - protocol each contribute one cookie at the initiation of key - establishment; the pair of cookies becomes the key identifier - (KEYID), a reusable name for the keying material. Because of this - - - -Orman Informational [Page 3] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - dual role, we will use the notation for the concatenation of the - cookies ("COOKIE-I, COOKIE-R") interchangeably with the symbol - "KEYID". - - OAKLEY is designed to be a compatible component of the ISAKMP - protocol [ISAKMP], which runs over the UDP protocol using a well- - known port (see the RFC on port assignments, STD02-RFC-1700). The - only technical requirement for the protocol environment is that the - underlying protocol stack must be able to supply the Internet address - of the remote party for each message. Thus, OAKLEY could, in theory, - be used directly over the IP protocol or over UDP, if suitable - protocol or port number assignments were available. - - The machine running OAKLEY must provide a good random number - generator, as described in [RANDOM], as the source of random numbers - required in this protocol description. Any mention of a "nonce" - implies that the nonce value is generated by such a generator. The - same is true for "pseudorandom" values. - -2.2 Notation - - The section describes the notation used in this document for message - sequences and content. - -2.2.1 Message descriptions - - The protocol exchanges below are written in an abbreviated notation - that is intended to convey the essential elements of the exchange in - a clear manner. A brief guide to the notation follows. The detailed - formats and assigned values are given in the appendices. - - In order to represent message exchanges succinctly, this document - uses an abbreviated notation that describes each message in terms of - its source and destination and relevant fields. - - Arrows ("->") indicate whether the message is sent from the initiator - to the responder, or vice versa ("<-"). - - The fields in the message are named and comma separated. The - protocol uses the convention that the first several fields constitute - a fixed header format for all messages. - - For example, consider a HYPOTHETICAL exchange of messages involving a - fixed format message, the four fixed fields being two "cookies", the - third field being a message type name, the fourth field being a - multi-precision integer representing a power of a number: - - - - - -Orman Informational [Page 4] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Initiator Responder - -> Cookie-I, 0, OK_KEYX, g^x -> - <- Cookie-R, Cookie-I, OK_KEYX, g^y <- - - The notation describes a two message sequence. The initiator begins - by sending a message with 4 fields to the responder; the first field - has the unspecified value "Cookie-I", second field has the numeric - value 0, the third field indicates the message type is OK_KEYX, the - fourth value is an abstract group element g to the x'th power. - - The second line indicates that the responder replies with value - "Cookie-R" in the first field, a copy of the "Cookie-I" value in the - second field, message type OK_KEYX, and the number g raised to the - y'th power. - - The value OK_KEYX is in capitals to indicate that it is a unique - constant (constants are defined in the appendices). - - Variable precision integers with length zero are null values for the - protocol. - - Sometimes the protocol will indicate that an entire payload (usually - the Key Exchange Payload) has null values. The payload is still - present in the message, for the purpose of simplifying parsing. - -2.2.2 Guide to symbols - - Cookie-I and Cookie-R (or CKY-I and CKY-R) are 64-bit pseudo-random - numbers. The generation method must ensure with high probability - that the numbers used for each IP remote address are unique over some - time period, such as one hour. - - KEYID is the concatenation of the initiator and responder cookies and - the domain of interpretation; it is the name of keying material. - - sKEYID is used to denote the keying material named by the KEYID. It - is never transmitted, but it is used in various calculations - performed by the two parties. - - OK_KEYX and OK_NEWGRP are distinct message types. - - IDP is a bit indicating whether or not material after the encryption - boundary (see appendix B), is encrypted. NIDP means not encrypted. - - g^x and g^y are encodings of group elements, where g is a special - group element indicated in the group description (see Appendix A) and - g^x indicates that element raised to the x'th power. The type of the - encoding is either a variable precision integer or a pair of such - - - -Orman Informational [Page 5] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - integers, as indicated in the group operation in the group - description. Note that we will write g^xy as a short-hand for - g^(xy). See Appendix F for references that describe implementing - large integer computations and the relationship between various group - definitions and basic arithmetic operations. - - EHAO is a list of encryption/hash/authentication choices. Each item - is a pair of values: a class name and an algorithm name. - - EHAS is a set of three items selected from the EHAO list, one from - each of the classes for encryption, hash, authentication. - - GRP is a name (32-bit value) for the group and its relevant - parameters: the size of the integers, the arithmetic operation, and - the generator element. There are a few pre-defined GRP's (for 768 - bit modular exponentiation groups, 1024 bit modexp, 2048 bit modexp, - 155-bit and 210-bit elliptic curves, see Appendix E), but - participants can share other group descriptions in a later protocol - stage (see the section NEW GROUP). It is important to separate - notion of the GRP from the group descriptor (Appendix A); the former - is a name for the latter. - - The symbol vertical bar "|" is used to denote concatenation of bit - strings. Fields are concatenated using their encoded form as they - appear in their payload. - - Ni and Nr are nonces selected by the initiator and responder, - respectively. - - ID(I) and ID(R) are the identities to be used in authenticating the - initiator and responder respectively. - - E{x}Ki indicates the encryption of x using the public key of the - initiator. Encryption is done using the algorithm associated with - the authentication method; usually this will be RSA. - - S{x}Ki indicates the signature over x using the private key (signing - key) of the initiator. Signing is done using the algorithm - associated with the authentication method; usually this will be RSA - or DSS. - - prf(a, b) denotes the result of applying pseudo-random function "a" - to data "b". One may think of "a" as a key or as a value that - characterizes the function prf; in the latter case it is the index - into a family of functions. Each function in the family provides a - "hash" or one-way mixing of the input. - - prf(0, b) denotes the application of a one-way function to data "b". - - - -Orman Informational [Page 6] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The similarity with the previous notation is deliberate and indicates - that a single algorithm, e.g. MD5, might will used for both purposes. - In the first case a "keyed" MD5 transform would be used with key "a"; - in the second case the transform would have the fixed key value zero, - resulting in a one-way function. - - The term "transform" is used to refer to functions defined in - auxiliary RFC's. The transform RFC's will be drawn from those - defined for IPSEC AH and ESP (see RFC 2401 for the overall - architecture encompassing these protocols). - -2.3 The Key Exchange Message Overview - - The goal of key exchange processing is the secure establishment of - common keying information state in the two parties. This state - information is a key name, secret keying material, the identification - of the two parties, and three algorithms for use during - authentication: encryption (for privacy of the identities of the two - parties), hashing (a pseudorandom function for protecting the - integrity of the messages and for authenticating message fields), and - authentication (the algorithm on which the mutual authentication of - the two parties is based). The encodings and meanings for these - choices are presented in Appendix B. - - The main mode exchange has five optional features: stateless cookie - exchange, perfect forward secrecy for the keying material, secrecy - for the identities, perfect forward secrecy for identity secrecy, use - of signatures (for non-repudiation). The two parties can use any - combination of these features. - - The general outline of processing is that the Initiator of the - exchange begins by specifying as much information as he wishes in his - first message. The Responder replies, supplying as much information - as he wishes. The two sides exchange messages, supplying more - information each time, until their requirements are satisfied. - - The choice of how much information to include in each message depends - on which options are desirable. For example, if stateless cookies - are not a requirement, and identity secrecy and perfect forward - secrecy for the keying material are not requirements, and if non- - repudiatable signatures are acceptable, then the exchange can be - completed in three messages. - - Additional features may increase the number of roundtrips needed for - the keying material determination. - - ISAKMP provides fields for specifying the security association - parameters for use with the AH and ESP protocols. These security - - - -Orman Informational [Page 7] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - association payload types are specified in the ISAKMP memo; the - payload types can be protected with OAKLEY keying material and - algorithms, but this document does not discuss their use. - -2.3.1 The Essential Key Exchange Message Fields - - There are 12 fields in an OAKLEY key exchange message. Not all the - fields are relevant in every message; if a field is not relevant it - can have a null value or not be present (no payload). - - CKY-I originator cookie. - CKY-R responder cookie. - MSGTYPE for key exchange, will be ISA_KE&AUTH_REQ or - ISA_KE&AUTH_REP; for new group definitions, - will be ISA_NEW_GROUP_REQ or ISA_NEW_GROUP_REP - GRP the name of the Diffie-Hellman group used for - the exchange - g^x (or g^y) variable length integer representing a power of - group generator - EHAO or EHAS encryption, hash, authentication functions, - offered and selectedj, respectively - IDP an indicator as to whether or not encryption with - g^xy follows (perfect forward secrecy for ID's) - ID(I) the identity for the Initiator - ID(R) the identity for the Responder - Ni nonce supplied by the Initiator - Nr nonce supplied by the Responder - - The construction of the cookies is implementation dependent. Phil - Karn has recommended making them the result of a one-way function - applied to a secret value (changed periodically), the local and - remote IP address, and the local and remote UDP port. In this way, - the cookies remain stateless and expire periodically. Note that with - OAKLEY, this would cause the KEYID's derived from the secret value to - also expire, necessitating the removal of any state information - associated with it. - - In order to support pre-distributed keys, we recommend that - implementations reserve some portion of their cookie space to - permanent keys. The encoding of these depends only on the local - implementation. - - The encryption functions used with OAKLEY must be cryptographic - transforms which guarantee privacy and integrity for the message - data. Merely using DES in CBC mode is not permissible. The - MANDATORY and OPTIONAL transforms will include any that satisfy this - criteria and are defined for use with RFC 2406 (ESP). - - - - -Orman Informational [Page 8] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The one-way (hash) functions used with OAKLEY must be cryptographic - transforms which can be used as either keyed hash (pseudo-random) or - non-keyed transforms. The MANDATORY and OPTIONAL transforms will - include any that are defined for use with RFC 2406 (AH). - - Where nonces are indicated, they will be variable precision integers - with an entropy value that matches the "strength" attribute of the - GRP used with the exchange. If no GRP is indicated, the nonces must - be at least 90 bits long. The pseudo-random generator for the nonce - material should start with initial data that has at least 90 bits of - entropy; see RFC 1750. - -2.3.1.1 Exponent Advice - - Ideally, the exponents will have at least 180 bits of entropy for - every key exchange. This ensures complete independence of keying - material between two exchanges (note that this applies if only one of - the parties chooses a random exponent). In practice, implementors - may wish to base several key exchanges on a single base value with - 180 bits of entropy and use one-way hash functions to guarantee that - exposure of one key will not compromise others. In this case, a good - recommendation is to keep the base values for nonces and cookies - separate from the base value for exponents, and to replace the base - value with a full 180 bits of entropy as frequently as possible. - - The values 0 and p-1 should not be used as exponent values; - implementors should be sure to check for these values, and they - should also refuse to accept the values 1 and p-1 from remote parties - (where p is the prime used to define a modular exponentiation group). - -2.3.2 Mapping to ISAKMP Message Structures - - All the OAKLEY message fields correspond to ISAKMP message payloads - or payload components. The relevant payload fields are the SA - payload, the AUTH payload, the Certificate Payload, the Key Exchange - Payload. The ISAKMP protocol framwork is a work in progress at this - time, and the exact mapping of Oakley message fields to ISAKMP - payloads is also in progress (to be known as the Resolution - document). - - Some of the ISAKMP header and payload fields will have constant - values when used with OAKLEY. The exact values to be used will be - published in a Domain of Interpretation document accompanying the - Resolution document. - - In the following we indicate where each OAKLEY field appears in the - ISAKMP message structure. These are recommended only; the Resolution - document will be the final authority on this mapping. - - - -Orman Informational [Page 9] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - CKY-I ISAKMP header - CKY-R ISAKMP header - MSGTYPE Message Type in ISAKMP header - GRP SA payload, Proposal section - g^x (or g^y) Key Exchange Payload, encoded as a variable - precision integer - EHAO and EHAS SA payload, Proposal section - IDP A bit in the RESERVED field in the AUTH header - ID(I) AUTH payload, Identity field - ID(R) AUTH payload, Identity field - Ni AUTH payload, Nonce Field - Nr AUTH payload, Nonce Field - S{...}Kx AUTH payload, Data Field - prf{K,...} AUTH payload, Data Field - -2.4 The Key Exchange Protocol - - The exact number and content of messages exchanged during an OAKLEY - key exchange depends on which options the Initiator and Responder - want to use. A key exchange can be completed with three or more - messages, depending on those options. - - The three components of the key determination protocol are the - - 1. cookie exchange (optionally stateless) - 2. Diffie-Hellman half-key exchange (optional, but essential for - perfect forward secrecy) - 3. authentication (options: privacy for ID's, privacy for ID's - with PFS, non-repudiatable) - - The initiator can supply as little information as a bare exchange - request, carrying no additional information. On the other hand the - initiator can begin by supplying all of the information necessary for - the responder to authenticate the request and complete the key - determination quickly, if the responder chooses to accept this - method. If not, the responder can reply with a minimal amount of - information (at the minimum, a cookie). - - The method of authentication can be digital signatures, public key - encryption, or an out-of-band symmetric key. The three different - methods lead to slight variations in the messages, and the variations - are illustrated by examples in this section. - - The Initiator is responsible for retransmitting messages if the - protocol does not terminate in a timely fashion. The Responder must - therefore avoid discarding reply information until it is acknowledged - by Initiator in the course of continuing the protocol. - - - - -Orman Informational [Page 10] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The remainder of this section contains examples demonstrating how to - use OAKLEY options. - -2.4.1 An Aggressive Example - - The following example indicates how two parties can complete a key - exchange in three messages. The identities are not secret, the - derived keying material is protected by PFS. - - By using digital signatures, the two parties will have a proof of - communication that can be recorded and presented later to a third - party. - - The keying material implied by the group exponentials is not needed - for completing the exchange. If it is desirable to defer the - computation, the implementation can save the "x" and "g^y" values and - mark the keying material as "uncomputed". It can be computed from - this information later. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> - ID(I), ID(R), Ni, 0, - S{ID(I) | ID(R) | Ni | 0 | GRP | g^x | 0 | EHAO}Ki - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, - ID(R), ID(I), Nr, Ni, - S{ID(R) | ID(I) | Nr | Ni | GRP | g^y | g^x | EHAS}Kr <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAS, NIDP, -> - ID(I), ID(R), Ni, Nr, - S{ID(I) | ID(R) | Ni | Nr | GRP | g^x | g^y | EHAS}Ki - - NB "NIDP" means that the PFS option for hiding identities is not used. - i.e., the identities are not encrypted using a key based on g^xy - - NB Fields are shown separated by commas in this document; they are - concatenated in the actual protocol messages using their encoded - forms as specified in the ISAKMP/Oakley Resolution document. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value - - sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). - - The processing outline for this exchange is as follows: - - - - - - - -Orman Informational [Page 11] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Initiation - - The Initiator generates a unique cookie and associates it with the - expected IP address of the responder, and its chosen state - information: GRP (the group identifier), a pseudo-randomly - selected exponent x, g^x, EHAO list, nonce, identities. The first - authentication choice in the EHAO list is an algorithm that - supports digital signatures, and this is used to sign the ID's and - the nonce and group id. The Initiator further - - notes that the key is in the initial state of "unauthenticated", - and - - sets a timer for possible retransmission and/or termination of the - request. - - When the Responder receives the message, he may choose to ignore all - the information and treat it as merely a request for a cookie, - creating no state. If CKY-I is not already in use by the source - address in the IP header, the responder generates a unique cookie, - CKY-R. The next steps depend on the Responder's preferences. The - minimal required response is to reply with the first cookie field set - to zero and CKY-R in the second field. For this example we will - assume that the responder is more aggressive (for the alternatives, - see section 6) and accepts the following: - - group with identifier GRP, - first authentication choice (which must be the digital signature - method used to sign the Initiator message), - lack of perfect forward secrecy for protecting the identities, - identity ID(I) and identity ID(R) - - In this example the Responder decides to accept all the information - offered by the initiator. It validates the signature over the signed - portion of the message, and associate the pair (CKY-I, CKY-R) with - the following state information: - - the source and destination network addresses of the message - - key state of "unauthenticated" - - the first algorithm from the authentication offer - - group GRP, a "y" exponent value in group GRP, and g^x from the - message - - the nonce Ni and a pseudorandomly selected value Nr - - - - -Orman Informational [Page 12] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - a timer for possible destruction of the state. - - The Responder computes g^y, forms the reply message, and then signs - the ID and nonce information with the private key of ID(R) and sends - it to the Initiator. In all exchanges, each party should make sure - that he neither offers nor accepts 1 or g^(p-1) as an exponential. - - In this example, to expedite the protocol, the Responder implicitly - accepts the first algorithm in the Authentication class of the EHAO - list. This because he cannot validate the Initiator signature - without accepting the algorithm for doing the signature. The - Responder's EHAS list will also reflect his acceptance. - - The Initiator receives the reply message and - validates that CKY-I is a valid association for the network - address of the incoming message, - - adds the CKY-R value to the state for the pair (CKY-I, network - address), and associates all state information with the pair - (CKY-I, CKY-R), - - validates the signature of the responder over the state - information (should validation fail, the message is discarded) - - adds g^y to its state information, - - saves the EHA selections in the state, - - optionally computes (g^y)^x (= g^xy) (this can be deferred until - after sending the reply message), - - sends the reply message, signed with the public key of ID(I), - - marks the KEYID (CKY-I|CKY-R) as authenticated, - - and composes the reply message and signature. - - When the Responder receives the Initiator message, and if the - signature is valid, it marks the key as being in the authenticated - state. It should compute g^xy and associate it with the KEYID. - - Note that although PFS for identity protection is not used, PFS for - the derived keying material is still present because the Diffie- - Hellman half-keys g^x and g^y are exchanged. - - Even if the Responder only accepts some of the Initiator information, - the Initiator will consider the protocol to be progressing. The - Initiator should assume that fields that were not accepted by the - - - -Orman Informational [Page 13] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Responder were not recorded by the Responder. - - If the Responder does not accept the aggressive exchange and selects - another algorithm for the A function, then the protocol will not - continue using the signature algorithm or the signature value from - the first message. - -2.4.1.1 Fields Not Present - - If the Responder does not accept all the fields offered by the - Initiator, he should include null values for those fields in his - response. Section 6 has guidelines on how to select fields in a - "left-to-right" manner. If a field is not accepted, then it and all - following fields must have null values. - - The Responder should not record any information that it does not - accept. If the ID's and nonces have null values, there will not be a - signature over these null values. - -2.4.1.2 Signature via Pseudo-Random Functions - - The aggressive example is written to suggest that public key - technology is used for the signatures. However, a pseudorandom - function can be used, if the parties have previously agreed to such a - scheme and have a shared key. - - If the first proposal in the EHAO list is an "existing key" method, - then the KEYID named in that proposal will supply the keying material - for the "signature" which is computed using the "H" algorithm - associated with the KEYID. - - Suppose the first proposal in EHAO is - EXISTING-KEY, 32 - and the "H" algorithm for KEYID 32 is MD5-HMAC, by prior negotiation. - The keying material is some string of bits, call it sK32. Then in - the first message in the aggressive exchange, where the signature - - S{ID(I), ID(R), Ni, 0, GRP, g^x, EHAO}Ki - - is indicated, the signature computation would be performed by - MD5-HMAC_func(KEY=sK32, DATA = ID(I) | ID(R) | Ni | 0 | GRP | g^x - | g^y | EHAO) (The exact definition of the algorithm corresponding - to "MD5-HMAC- func" will appear in the RFC defining that transform). - - The result of this computation appears in the Authentication payload. - - - - - - -Orman Informational [Page 14] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.4.2 An Aggressive Example With Hidden Identities - - The following example indicates how two parties can complete a key - exchange without using digital signatures. Public key cryptography - hides the identities during authentication. The group exponentials - are exchanged and authenticated, but the implied keying material - (g^xy) is not needed during the exchange. - - This exchange has an important difference from the previous signature - scheme --- in the first message, an identity for the responder is - indicated as cleartext: ID(R'). However, the identity hidden with - the public key cryptography is different: ID(R). This happens - because the Initiator must somehow tell the Responder which - public/private key pair to use for the decryption, but at the same - time, the identity is hidden by encryption with that public key. - - The Initiator might elect to forgo secrecy of the Responder identity, - but this is undesirable. Instead, if there is a well-known identity - for the Responder node, the public key for that identity can be used - to encrypt the actual Responder identity. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, GRP, g^x, EHAO, NIDP, -> - ID(R'), E{ID(I), ID(R), E{Ni}Kr}Kr' - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS, NIDP, - E{ID(R), ID(I), Nr}Ki, - prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS) <- - -> CKY-I, CKY-R, OK_KEYX, GRP, 0, 0, NIDP, - prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS) -> - - Kir = prf(0, Ni | Nr) - - NB "NIDP" means that the PFS option for hiding identities is not used. - - NB The ID(R') value is included in the Authentication payload as - described in Appendix B. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value sKEYID = prf(Ni | Nr, g^xy | CKY-I | CKY-R). - - The processing outline for this exchange is as follows: - - Initiation - The Initiator generates a unique cookie and associates it with the - expected IP address of the responder, and its chosen state - information: GRP, g^x, EHAO list. The first authentication choice - in the EHAO list is an algorithm that supports public key - - - -Orman Informational [Page 15] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - encryption. The Initiator also names the two identities to be - used for the connection and enters these into the state. A well- - known identity for the responder machine is also chosen, and the - public key for this identity is used to encrypt the nonce Ni and - the two connection identities. The Initiator further - - notes that the key is in the initial state of "unauthenticated", - and - - sets a timer for possible retransmission and/or termination of the - request. - - When the Responder receives the message, he may choose to ignore all - the information and treat it as merely a request for a cookie, - creating no state. - - If CKY-I is not already in use by the source address in the IP - header, the Responder generates a unique cookie, CKY-R. As before, - the next steps depend on the responder's preferences. The minimal - required response is a message with the first cookie field set to - zero and CKY-R in the second field. For this example we will assume - that responder is more aggressive and accepts the following: - - group GRP, first authentication choice (which must be the public - key encryption algorithm used to encrypt the payload), lack of - perfect forward secrecy for protecting the identities, identity - ID(I), identity ID(R) - - The Responder must decrypt the ID and nonce information, using the - private key for the R' ID. After this, the private key for the R ID - will be used to decrypt the nonce field. - - The Responder now associates the pair (CKY-I, CKY-R) with the - following state information: - - the source and destination network addresses of the message - - key state of "unauthenticated" - - the first algorithm from each class in the EHAO (encryption-hash- - authentication algorithm offers) list - - group GRP and a y and g^y value in group GRP - - the nonce Ni and a pseudorandomly selected value Nr - - a timer for possible destruction of the state. - - - - -Orman Informational [Page 16] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The Responder then encrypts the state information with the public key - of ID(I), forms the prf value, and sends it to the Initiator. - - The Initiator receives the reply message and - validates that CKY-I is a valid association for the network - address of the incoming message, - - adds the CKY-R value to the state for the pair (CKY-I, network - address), and associates all state information with the pair - (CKY-I, CKY-R), - - decrypts the ID and nonce information - - checks the prf calculation (should this fail, the message is - discarded) - - adds g^y to its state information, - - saves the EHA selections in the state, - - optionally computes (g^x)^y (= g^xy) (this may be deferred), and - - sends the reply message, encrypted with the public key of ID(R), - - and marks the KEYID (CKY-I|CKY-R) as authenticated. - - When the Responder receives this message, it marks the key as being - in the authenticated state. If it has not already done so, it should - compute g^xy and associate it with the KEYID. - - The secret keying material sKEYID = prf(Ni | Nr, g^xy | CKY-I | - CKY-R) - - Note that although PFS for identity protection is not used, PFS for - the derived keying material is still present because the Diffie- - Hellman half-keys g^x and g^y are exchanged. - -2.4.3 An Aggressive Example With Private Identities and Without Diffie- - Hellman - - Considerable computational expense can be avoided if perfect forward - secrecy is not a requirement for the session key derivation. The two - parties can exchange nonces and secret key parts to achieve the - authentication and derive keying material. The long-term privacy of - data protected with derived keying material is dependent on the - private keys of each of the parties. - - - - - -Orman Informational [Page 17] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - In this exchange, the GRP has the value 0 and the field for the group - exponential is used to hold a nonce value instead. - - As in the previous section, the first proposed algorithm must be a - public key encryption system; by responding with a cookie and a non- - zero exponential field, the Responder implicitly accepts the first - proposal and the lack of perfect forward secrecy for the identities - and derived keying material. - - Initiator Responder - --------- --------- - -> CKY-I, 0, OK_KEYX, 0, 0, EHAO, NIDP, -> - ID(R'), E{ID(I), ID(R), sKi}Kr', Ni - <- CKY-R, CKY-I, OK_KEYX, 0, 0, EHAS, NIDP, - E{ID(R), ID(I), sKr}Ki, Nr, - prf(Kir, ID(R) | ID(I) | Nr | Ni | EHAS) <- - -> CKY-I, CKY-R, OK_KEYX, EHAS, NIDP, - prf(Kir, ID(I) | ID(R) | Ni | Nr | EHAS) -> - - Kir = prf(0, sKi | sKr) - - NB The sKi and sKr values go into the nonce fields. The change in - notation is meant to emphasize that their entropy is critical to - setting the keying material. - - NB "NIDP" means that the PFS option for hiding identities is not - used. - - The result of this exchange is a key with KEYID = CKY-I|CKY-R and - value sKEYID = prf(Kir, CKY-I | CKY-R). - -2.4.3 A Conservative Example - - In this example the two parties are minimally aggressive; they use - the cookie exchange to delay creation of state, and they use perfect - forward secrecy to protect the identities. For this example, they - use public key encryption for authentication; digital signatures or - pre-shared keys can also be used, as illustrated previously. The - conservative example here does not change the use of nonces, prf's, - etc., but it does change how much information is transmitted in each - message. - - The responder considers the ability of the initiator to repeat CKY-R - as weak evidence that the message originates from a "live" - correspondent on the network and the correspondent is associated with - the initiator's network address. The initiator makes similar - assumptions when CKY-I is repeated to the initiator. - - - - -Orman Informational [Page 18] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - All messages must have either valid cookies or at least one zero - cookie. If both cookies are zero, this indicates a request for a - cookie; if only the initiator cookie is zero, it is a response to a - cookie request. - - Information in messages violating the cookie rules cannot be used for - any OAKLEY operations. - - Note that the Initiator and Responder must agree on one set of EHA - algorithms; there is not one set for the Responder and one for the - Initiator. The Initiator must include at least MD5 and DES in the - initial offer. - - Fields not indicated have null values. - - Initiator Responder - --------- --------- - -> 0, 0, OK_KEYX -> - <- 0, CKY-R, OK_KEYX <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, EHAO -> - <- CKY-R, CKY-I, OK_KEYX, GRP, g^y, EHAS <- - -> CKY-I, CKY-R, OK_KEYX, GRP, g^x, IDP*, - ID(I), ID(R), E{Ni}Kr, -> - <- CKY-R, CKY-I, OK_KEYX, GRP, 0 , 0, IDP, <- - E{Nr, Ni}Ki, ID(R), ID(I), - prf(Kir, ID(R) | ID(I) | GRP | g^y | g^x | EHAS ) - -> CKY-I, CKY-R, OK_KEYX, GRP, 0 , 0, IDP, - prf(Kir, ID(I) | ID(R) | GRP | g^x | g^y | EHAS ) -> - - Kir = prf(0, Ni | Nr) - - * when IDP is in effect, authentication payloads are encrypted with - the selected encryption algorithm using the keying material prf(0, - g^xy). (The transform defining the encryption algorithm will - define how to select key bits from the keying material.) This - encryption is in addition to and after any public key encryption. - See Appendix B. - - Note that in the first messages, several fields are omitted from - the description. These fields are present as null values. - - The first exchange allows the Responder to use stateless cookies; if - the responder generates cookies in a manner that allows him to - validate them without saving them, as in Photuris, then this is - possible. Even if the Initiator includes a cookie in his initial - request, the responder can still use stateless cookies by merely - omitting the CKY-I from his reply and by declining to record the - Initiator cookie until it appears in a later message. - - - -Orman Informational [Page 19] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - After the exchange is complete, both parties compute the shared key - material sKEYID as prf(Ni | Nr, g^xy | CKY-I | CKY-R) where "prf" is - the pseudo-random function in class "hash" selected in the EHA list. - - As with the cookies, each party considers the ability of the remote - side to repeat the Ni or Nr value as a proof that Ka, the public key - of party a, speaks for the remote party and establishes its identity. - - In analyzing this exchange, it is important to note that although the - IDP option ensures that the identities are protected with an - ephemeral key g^xy, the authentication itself does not depend on - g^xy. It is essential that the authentication steps validate the g^x - and g^y values, and it is thus imperative that the authentication not - involve a circular dependency on them. A third party could intervene - with a "man-in-middle" scheme to convince the initiator and responder - to use different g^xy values; although such an attack might result in - revealing the identities to the eavesdropper, the authentication - would fail. - -2.4.4 Extra Strength for Protection of Encryption Keys - - The nonces Ni and Nr are used to provide an extra dimension of - secrecy in deriving session keys. This makes the secrecy of the key - depend on two different problems: the discrete logarithm problem in - the group G, and the problem of breaking the nonce encryption scheme. - If RSA encryption is used, then this second problem is roughly - equivalent to factoring the RSA public keys of both the initiator and - responder. - - For authentication, the key type, the validation method, and the - certification requirement must be indicated. - -2.5 Identity and Authentication - -2.5.1 Identity - - In OAKLEY exchanges the Initiator offers Initiator and Responder ID's - -- the former is the claimed identity for the Initiator, and the - latter is the requested ID for the Responder. - - If neither ID is specified, the ID's are taken from the IP header - source and destination addresses. - - If the Initiator doesn't supply a responder ID, the Responder can - reply by naming any identity that the local policy allows. The - Initiator can refuse acceptance by terminating the exchange. - - - - - -Orman Informational [Page 20] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The Responder can also reply with a different ID than the Initiator - suggested; the Initiator can accept this implicitly by continuing the - exchange or refuse it by terminating (not replying). - -2.5.2 Authentication - - The authentication of principals to one another is at the heart of - any key exchange scheme. The Internet community must decide on a - scalable standard for solving this problem, and OAKLEY must make use - of that standard. At the time of this writing, there is no such - standard, though several are emerging. This document attempts to - describe how a handful of standards could be incorporated into - OAKLEY, without attempting to pick and choose among them. - - The following methods can appear in OAKLEY offers: - - a. Pre-shared Keys - When two parties have arranged for a trusted method of - distributing secret keys for their mutual authentication, they can - be used for authentication. This has obvious scaling problems for - large systems, but it is an acceptable interim solution for some - situations. Support for pre-shared keys is REQUIRED. - - The encryption, hash, and authentication algorithm for use with a - pre-shared key must be part of the state information distributed - with the key itself. - - The pre-shared keys have a KEYID and keying material sKEYID; the - KEYID is used in a pre-shared key authentication option offer. - There can be more than one pre-shared key offer in a list. - - Because the KEYID persists over different invocations of OAKLEY - (after a crash, etc.), it must occupy a reserved part of the KEYID - space for the two parties. A few bits can be set aside in each - party's "cookie space" to accommodate this. - - There is no certification authority for pre-shared keys. When a - pre-shared key is used to generate an authentication payload, the - certification authority is "None", the Authentication Type is - "Preshared", and the payload contains - - the KEYID, encoded as two 64-bit quantities, and the result of - applying the pseudorandom hash function to the message body - with the sKEYID forming the key for the function - - - - - - - -Orman Informational [Page 21] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - b. DNS public keys - Security extensions to the DNS protocol [DNSSEC] provide a - convenient way to access public key information, especially for - public keys associated with hosts. RSA keys are a requirement for - secure DNS implementations; extensions to allow optional DSS keys - are a near-term possibility. - - DNS KEY records have associated SIG records that are signed by a - zone authority, and a hierarchy of signatures back to the root - server establishes a foundation for trust. The SIG records - indicate the algorithm used for forming the signature. - - OAKLEY implementations must support the use of DNS KEY and SIG - records for authenticating with respect to IPv4 and IPv6 addresses - and fully qualified domain names. However, implementations are - not required to support any particular algorithm (RSA, DSS, etc.). - - c. RSA public keys w/o certification authority signature PGP - [Zimmerman] uses public keys with an informal method for - establishing trust. The format of PGP public keys and naming - methods will be described in a separate RFC. The RSA algorithm - can be used with PGP keys for either signing or encryption; the - authentication option should indicate either RSA-SIG or RSA-ENC, - respectively. Support for this is OPTIONAL. - - d.1 RSA public keys w/ certificates There are various formats and - naming conventions for public keys that are signed by one or more - certification authorities. The Public Key Interchange Protocol - discusses X.509 encodings and validation. Support for this is - OPTIONAL. - - d.2 DSS keys w/ certificates Encoding for the Digital Signature - Standard with X.509 is described in draft-ietf-ipsec-dss-cert- - 00.txt. Support for this is OPTIONAL; an ISAKMP Authentication - Type will be assigned. - -2.5.3 Validating Authentication Keys - - The combination of the Authentication algorithm, the Authentication - Authority, the Authentication Type, and a key (usually public) define - how to validate the messages with respect to the claimed identity. - The key information will be available either from a pre-shared key, - or from some kind of certification authority. - - Generally the certification authority produces a certificate binding - the entity name to a public key. OAKLEY implementations must be - prepared to fetch and validate certificates before using the public - key for OAKLEY authentication purposes. - - - -Orman Informational [Page 22] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The ISAKMP Authentication Payload defines the Authentication - Authority field for specifying the authority that must be apparent in - the trust hierarchy for authentication. - - Once an appropriate certificate is obtained (see 2.4.3), the - validation method will depend on the Authentication Type; if it is - PGP then the PGP signature validation routines can be called to - satisfy the local web-of-trust predicates; if it is RSA with X.509 - certificates, the certificate must be examined to see if the - certification authority signature can be validated, and if the - hierarchy is recognized by the local policy. - -2.5.4 Fetching Identity Objects - - In addition to interpreting the certificate or other data structure - that contains an identity, users of OAKLEY must face the task of - retrieving certificates that bind a public key to an identifier and - also retrieving auxiliary certificates for certifying authorities or - co-signers (as in the PGP web of trust). - - The ISAKMP Credentials Payload can be used to attach useful - certificates to OAKLEY messages. The Credentials Payload is defined - in Appendix B. - - Support for accessing and revoking public key certificates via the - Secure DNS protocol [SECDNS] is MANDATORY for OAKLEY implementations. - Other retrieval methods can be used when the AUTH class indicates a - preference. - - The Public Key Interchange Protocol discusses a full protocol that - might be used with X.509 encoded certificates. - -2.6 Interface to Cryptographic Transforms - - The keying material computed by the key exchange should have at least - 90 bits of entropy, which means that it must be at least 90 bits in - length. This may be more or less than is required for keying the - encryption and/or pseudorandom function transforms. - - The transforms used with OAKLEY should have auxiliary algorithms - which take a variable precision integer and turn it into keying - material of the appropriate length. For example, a DES algorithm - could take the low order 56 bits, a triple DES algorithm might use - the following: - - K1 = low 56 bits of md5(0|sKEYID) - K2 = low 56 bits of md5(1|sKEYID) - K3 = low 56 bits of md5(2|sKEYID) - - - -Orman Informational [Page 23] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The transforms will be called with the keying material encoded as a - variable precision integer, the length of the data, and the block of - memory with the data. Conversion of the keying material to a - transform key is the responsibility of the transform. - -2.7 Retransmission, Timeouts, and Error Messages - - If a response from the Responder is not elicited in an appropriate - amount of time, the message should be retransmitted by the Initiator. - These retransmissions must be handled gracefully by both parties; the - Responder must retain information for retransmitting until the - Initiator moves to the next message in the protocol or completes the - exchange. - - Informational error messages present a problem because they cannot be - authenticated using only the information present in an incomplete - exchange; for this reason, the parties may wish to establish a - default key for OAKLEY error messages. A possible method for - establishing such a key is described in Appendix B, under the use of - ISA_INIT message types. - - In the following the message type is OAKLEY Error, the KEYID supplies - the H algorithm and key for authenticating the message contents; this - value is carried in the Sig/Prf payload. - - The Error payload contains the error code and the contents of the - rejected message. - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 24] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ Initiator-Cookie ~ - / ! ! -KEYID +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - \ ! ! - ~ Responder-Cookie ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Domain of Interpretation ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Message Type ! Exch ! Vers ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! SPI (unused) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! SPI (unused) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Error Payload ! - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Sig/prf Payload - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The error message will contain the cookies as presented in the - offending message, the message type OAKLEY_ERROR, and the reason for - the error, followed by the rejected message. - - Error messages are informational only, and the correctness of the - protocol does not depend on them. - - Error reasons: - - TIMEOUT exchange has taken too long, state destroyed - AEH_ERROR an unknown algorithm appears in an offer - GROUP_NOT_SUPPORTED GRP named is not supported - EXPONENTIAL_UNACCEPTABLE exponential too large/small or is +-1 - SELECTION_NOT_OFFERED selection does not occur in offer - NO_ACCEPTABLE_OFFERS no offer meets host requirements - AUTHENTICATION_FAILURE signature or hash function fails - RESOURCE_EXCEEDED too many exchanges or too much state info - NO_EXCHANGE_IN_PROGRESS a reply received with no request in progress - - - - - - - -Orman Informational [Page 25] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.8 Additional Security for Privacy Keys: Private Groups - - If the two parties have need to use a Diffie-Hellman key - determination scheme that does not depend on the standard group - definitions, they have the option of establishing a private group. - The authentication need not be repeated, because this stage of the - protocol will be protected by a pre-existing authentication key. As - an extra security measure, the two parties will establish a private - name for the shared keying material, so even if they use exactly the - same group to communicate with other parties, the re-use will not be - apparent to passive attackers. - - Private groups have the advantage of making a widespread passive - attack much harder by increasing the number of groups that would have - to be exhaustively analyzed in order to recover a large number of - session keys. This contrasts with the case when only one or two - groups are ever used; in that case, one would expect that years and - years of session keys would be compromised. - - There are two technical challenges to face: how can a particular user - create a unique and appropriate group, and how can a second party - assure himself that the proposed group is reasonably secure? - - The security of a modular exponentiation group depends on the largest - prime factor of the group size. In order to maximize this, one can - choose "strong" or Sophie Germaine primes, P = 2Q + 1, where P and Q - are prime. However, if P = kQ + 1, where k is small, then the - strength of the group is still considerable. These groups are known - as Schnorr subgroups, and they can be found with much less - computational effort than Sophie-Germaine primes. - - Schnorr subgroups can also be validated efficiently by using probable - prime tests. - - It is also fairly easy to find P, k, and Q such that the largest - prime factor can be easily proven to be Q. - - We estimate that it would take about 10 minutes to find a new group - of about 2^1024 elements, and this could be done once a day by a - scheduled process; validating a group proposed by a remote party - would take perhaps a minute on a 25 MHz RISC machine or a 66 MHz CISC - machine. - - We note that validation is done only between previously mutually - authenticated parties, and that a new group definition always follows - and is protected by a key established using a well-known group. - There are five points to keep in mind: - - - - -Orman Informational [Page 26] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - a. The description and public identifier for the new group are - protected by the well-known group. - - b. The responder can reject the attempt to establish the new - group, either because he is too busy or because he cannot validate - the largest prime factor as being sufficiently large. - - c. The new modulus and generator can be cached for long periods of - time; they are not security critical and need not be associated - with ongoing activity. - - d. Generating a new g^x value periodically will be more expensive - if there are many groups cached; however, the importance of - frequently generating new g^x values is reduced, so the time - period can be lengthened correspondingly. - - e. All modular exponentiation groups have subgroups that are - weaker than the main group. For Sophie Germain primes, if the - generator is a square, then there are only two elements in the - subgroup: 1 and g^(-1) (same as g^(p-1)) which we have already - recommended avoiding. For Schnorr subgroups with k not equal to - 2, the subgroup can be avoided by checking that the exponential is - not a kth root of 1 (e^k != 1 mod p). - -2.8.1 Defining a New Group - - This section describes how to define a new group. The description of - the group is hidden from eavesdroppers, and the identifier assigned - to the group is unique to the two parties. Use of the new group for - Diffie-Hellman key exchanges is described in the next section. - - The secrecy of the description and the identifier increases the - difficulty of a passive attack, because if the group descriptor is - not known to the attacker, there is no straightforward and efficient - way to gain information about keys calculated using the group. - - Only the description of the new group need be encrypted in this - exchange. The hash algorithm is implied by the OAKLEY session named - by the group. The encryption is the encryption function of the - OAKLEY session. - - The descriptor of the new group is encoded in the new group payload. - The nonces are encoded in the Authentication Payload. - - Data beyond the encryption boundary is encrypted using the transform - named by the KEYID. - - - - - -Orman Informational [Page 27] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The following messages use the ISAKMP Key Exchange Identifier OAKLEY - New Group. - - To define a new modular exponentiation group: - - Initiator Responder - --------- ---------- - -> KEYID, -> - INEWGRP, - Desc(New Group), Na - prf(sKEYID, Desc(New Group) | Na) - - <- KEYID, - INEWGRPRS, - Na, Nb - prf(sKEYID, Na | Nb | Desc(New Group)) <- - - -> KEYID, - INEWGRPACK - prf(sKEYID, Nb | Na | Desc(New Group)) -> - - These messages are encrypted at the encryption boundary using the key - indicated. The hash value is placed in the "digital signature" field - (see Appendix B). - - New GRP identifier = trunc16(Na) | trunc16(Nb) - - (trunc16 indicates truncation to 16 bits; the initiator and - responder must use nonces that have distinct upper bits from any - used for current GRPID's) - - Desc(G) is the encoding of the descriptor for the group descriptor - (see Appendix A for the format of a group descriptor) - - The two parties must store the mapping between the new group - identifier GRP and the group descriptor Desc(New Group). They must - also note the identities used for the KEYID and copy these to the - state for the new group. - - Note that one could have the same group descriptor associated with - several KEYID's. Pre-calculation of g^x values may be done based - only on the group descriptor, not the private group name. - -2.8.2 Deriving a Key Using a Private Group - - Once a private group has been established, its group id can be used - in the key exchange messages in the GRP position. No changes to the - protocol are required. - - - -Orman Informational [Page 28] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.9 Quick Mode: New Keys From Old, - - When an authenticated KEYID and associated keying material sKEYID - already exist, it is easy to derive additional KEYID's and keys - sharing similar attributes (GRP, EHA, etc.) using only hashing - functions. The KEYID might be one that was derived in Main Mode, for - example. - - On the other hand, the authenticated key may be a manually - distributed key, one that is shared by the initiator and responder - via some means external to OAKLEY. If the distribution method has - formed the KEYID using appropriately unique values for the two halves - (CKY-I and CKY-R), then this method is applicable. - - In the following, the Key Exchange Identifier is OAKLEY Quick Mode. - The nonces are carried in the Authentication Payload, and the prf - value is carried in the Authentication Payload; the Authentication - Authority is "None" and the type is "Pre-Shared". - - The protocol is: - - Initiator Responder - --------- --------- - -> KEYID, INEWKRQ, Ni, prf(sKEYID, Ni) -> - <- KEYID, INEWKRS, Nr, prf(sKEYID, 1 | Nr | Ni) <- - -> KEYID, INEWKRP, 0, prf(sKEYID, 0 | Ni | Nr) -> - - The New KEYID, NKEYID, is Ni | Nr - - sNKEYID = prf(sKEYID, Ni | Nr ) - - The identities and EHA values associated with NKEYID are the same as - those associated with KEYID. - - Each party must validate the hash values before using the new key for - any purpose. - -2.10 Defining and Using Pre-Distributed Keys - - If a key and an associated key identifier and state information have - been distributed manually, then the key can be used for any OAKLEY - purpose. The key must be associated with the usual state - information: ID's and EHA algorithms. - - Local policy dictates when a manual key can be included in the OAKLEY - database. For example, only privileged users would be permitted to - introduce keys associated with privileged ID's, an unprivileged user - could only introduce keys associated with her own ID. - - - -Orman Informational [Page 29] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -2.11 Distribution of an External Key - - Once an OAKLEY session key and ancillary algorithms are established, - the keying material and the "H" algorithm can be used to distribute - an externally generated key and to assign a KEYID to it. - - In the following, KEYID represents an existing, authenticated OAKLEY - session key, and sNEWKEYID represents the externally generated keying - material. - - In the following, the Key Exchange Identifier is OAKLEY External - Mode. The Key Exchange Payload contains the new key, which is - protected - - Initiator Responder - --------- --------- - -> KEYID, IEXTKEY, Ni, prf(sKEYID, Ni) -> - <- KEYID, IEXTKEY, Nr, prf(sKEYID, 1 | Nr | Ni) <- - -> KEYID, IEXTKEY, Kir xor sNEWKEYID*, prf(Kir, sNEWKEYID | Ni | Nr) -> - - Kir = prf(sKEYID, Ni | Nr) - - * this field is carried in the Key Exchange Payload. - - Each party must validate the hash values using the "H" function in - the KEYID state before changing any key state information. - - The new key is recovered by the Responder by calculating the xor of - the field in the Authentication Payload with the Kir value. - - The new key identifier, naming the keying material sNEWKEYID, is - prf(sKEYID, 1 | Ni | Nr). - - Note that this exchange does not require encryption. Hugo Krawcyzk - suggested the method and noted its advantage. - -2.11.1 Cryptographic Strength Considerations - - The strength of the key used to distribute the external key must be - at least equal to the strength of the external key. Generally, this - means that the length of the sKEYID material must be greater than or - equal to the length of the sNEWKEYID material. - - The derivation of the external key, its strength or intended use are - not addressed by this protocol; the parties using the key must have - some other method for determining these properties. - - - - - -Orman Informational [Page 30] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - As of early 1996, it appears that for 90 bits of cryptographic - strength, one should use a modular exponentiation group modulus of - 2000 bits. For 128 bits of strength, a 3000 bit modulus is required. - -3. Specifying and Deriving Security Associations - - When a security association is defined, only the KEYID need be given. - The responder should be able to look up the state associated with the - KEYID value and find the appropriate keying material, sKEYID. - - Deriving keys for use with IPSEC protocols such as ESP or AH is a - subject covered in the ISAKMP/Oakley Resolution document. That - document also describes how to negotiate acceptable parameter sets - and identifiers for ESP and AH, and how to exactly calculate the - keying material for each instance of the protocols. Because the - basic keying material defined here (g^xy) may be used to derive keys - for several instances of ESP and AH, the exact mechanics of using - one-way functions to turn g^xy into several unique keys is essential - to correct usage. - -4. ISAKMP Compatibility - - OAKLEY uses ISAKMP header and payload formats, as described in the - text and in Appendix B. There are particular noteworthy extensions - beyond the version 4 draft. - -4.1 Authentication with Existing Keys - - In the case that two parties do not have suitable public key - mechanisms in place for authenticating each other, they can use keys - that were distributed manually. After establishment of these keys - and their associated state in OAKLEY, they can be used for - authentication modes that depend on signatures, e.g. Aggressive Mode. - - When an existing key is to appear in an offer list, it should be - indicated with an Authentication Algorithm of ISAKMP_EXISTING. This - value will be assigned in the ISAKMP RFC. - - When the authentication method is ISAKMP_EXISTING, the authentication - authority will have the value ISAKMP_AUTH_EXISTING; the value for - this field must not conflict with any authentication authority - registered with IANA and is defined in the ISAKMP RFC. - - - - - - - - - -Orman Informational [Page 31] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The authentication payload will have two parts: - - the KEYID for the pre-existing key - - the identifier for the party to be authenticated by the pre- - existing key. - - The pseudo-random function "H" in the state information for that - KEYID will be the signature algorithm, and it will use the keying - material for that key (sKEYID) when generating or checking the - validity of message data. - - E.g. if the existing key has an KEYID denoted by KID and 128 bits of - keying material denoted by sKID and "H" algorithm a transform named - HMAC, then to generate a "signature" for a data block, the output of - HMAC(sKID, data) will be the corresponding signature payload. - - The KEYID state will have the identities of the local and remote - parties for which the KEYID was assigned; it is up to the local - policy implementation to decide when it is appropriate to use such a - key for authenticating other parties. For example, a key distributed - for use between two Internet hosts A and B may be suitable for - authenticating all identities of the form "alice@A" and "bob@B". - -4.2 Third Party Authentication - - A local security policy might restrict key negotiation to trusted - parties. For example, two OAKLEY daemons running with equal - sensitivity labels on two machines might wish to be the sole arbiters - of key exchanges between users with that same sensitivity label. In - this case, some way of authenticating the provenance of key exchange - requests is needed. I.e., the identities of the two daemons should - be bound to a key, and that key will be used to form a "signature" - for the key exchange messages. - - The Signature Payload, in Appendix B, is for this purpose. This - payload names a KEYID that is in existence before the start of the - current exchange. The "H" transform for that KEYID is used to - calculate an integrity/authentication value for all payloads - preceding the signature. - - Local policy can dictate which KEYID's are appropriate for signing - further exchanges. - - - - - - - - -Orman Informational [Page 32] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -4.3 New Group Mode - - OAKLEY uses a new KEI for the exchange that defines a new group. - -5. Security Implementation Notes - - Timing attacks that are capable of recovering the exponent value used - in Diffie-Hellman calculations have been described by Paul Kocher - [Kocher]. In order to nullify the attack, implementors must take - pains to obscure the sequence of operations involved in carrying out - modular exponentiations. - - A "blinding factor" can accomplish this goal. A group element, r, is - chosen at random. When an exponent x is chosen, the value r^(-x) is - also calculated. Then, when calculating (g^y)^x, the implementation - will calculate this sequence: - - A = (rg^y) - B = A^x = (rg^y)^x = (r^x)(g^(xy)) - C = B*r^(-x) = (r^x)(r^-(x))(g^(xy)) = g^(xy) - - The blinding factor is only necessary if the exponent x is used more - than 100 times (estimate by Richard Schroeppel). - -6. OAKLEY Parsing and State Machine - - There are many pathways through OAKLEY, but they follow a left-to- - right parsing pattern of the message fields. - - The initiator decides on an initial message in the following order: - - 1. Offer a cookie. This is not necessary but it helps with - aggressive exchanges. - - 2. Pick a group. The choices are the well-known groups or any - private groups that may have been negotiated. The very first - exchange between two Oakley daemons with no common state must - involve a well-known group (0, meaning no group, is a well-known - group). Note that the group identifier, not the group descriptor, - is used in the message. - - If a non-null group will be used, it must be included with the - first message specifying EHAO. It need not be specified until - then. - - 3. If PFS will be used, pick an exponent x and present g^x. - - 4. Offer Encryption, Hash, and Authentication lists. - - - -Orman Informational [Page 33] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 5. Use PFS for hiding the identities - - If identity hiding is not used, then the initiator has this - option: - - 6. Name the identities and include authentication information - - The information in the authentication section depends on the first - authentication offer. In this aggressive exchange, the Initiator - hopes that the Responder will accept all the offered information and - the first authentication method. The authentication method - determines the authentication payload as follows: - - 1. Signing method. The signature will be applied to all the - offered information. - - 2. A public key encryption method. The algorithm will be used to - encrypt a nonce in the public key of the requested Responder - identity. There are two cases possible, depending on whether or - not identity hiding is used: - - a. No identity hiding. The ID's will appear as plaintext. - b. Identity hiding. A well-known ID, call it R', will appear - as plaintext in the authentication payload. It will be - followed by two ID's and a nonce; these will be encrypted using - the public key for R'. - - 3. A pre-existing key method. The pre-existing key will be used - to encrypt a nonce. If identity hiding is used, the ID's will be - encrypted in place in the payload, using the "E" algorithm - associated with the pre-existing key. - - The Responder can accept all, part or none of the initial message. - - The Responder accepts as many of the fields as he wishes, using the - same decision order as the initiator. At any step he can stop, - implicitly rejecting further fields (which will have null values in - his response message). The minimum response is a cookie and the GRP. - - 1. Accept cookie. The Responder may elect to record no state - information until the Initiator successfully replies with a cookie - chosen by the responder. If so, the Responder replies with a - cookie, the GRP, and no other information. - - 2. Accept GRP. If the group is not acceptable, the Responder will - not reply. The Responder may send an error message indicating the - the group is not acceptable (modulus too small, unknown - identifier, etc.) Note that "no group" has two meanings during - - - -Orman Informational [Page 34] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - the protocol: it may mean the group is not yet specified, or it - may mean that no group will be used (and thus PFS is not - possible). - - 3. Accept the g^x value. The Responder indicates his acceptance - of the g^x value by including his own g^y value in his reply. He - can postpone this by ignoring g^x and putting a zero length g^y - value in his reply. He can also reject the g^x value with an - error message. - - 4. Accept one element from each of the EHA lists. The acceptance - is indicated by a non-zero proposal. - - 5. If PFS for identity hiding is requested, then no further data - will follow. - - 6. If the authentication payload is present, and if the first item - in the offered authentication class is acceptable, then the - Responder must validate/decrypt the information in the - authentication payload and signature payload, if present. The - Responder should choose a nonce and reply using the same - authentication/hash algorithm as the Initiator used. - - The Initiator notes which information the Responder has accepted, - validates/decrypts any signed, hashed, or encrypted fields, and if - the data is acceptable, replies in accordance to the EHA methods - selected by the Responder. The Initiator replies are distinguished - from his initial message by the presence of the non-zero value for - the Responder cookie. - - The output of the signature or prf function will be encoded as a - variable precision integer as described in Appendix C. The KEYID - will indicate KEYID that names keying material and the Hash or - Signature function. - -7. The Credential Payload - - Useful certificates with public key information can be attached to - OAKLEY messages using Credential Payloads as defined in the ISAKMP - document. It should be noted that the identity protection option - applies to the credentials as well as the identities. - -Security Considerations - - The focus of this document is security; hence security considerations - permeate this memo. - - - - - -Orman Informational [Page 35] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Author's Address - - Hilarie K. Orman - Department of Computer Science - University of Arizona - - EMail: ho@darpa.mil - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 36] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX A Group Descriptors - - Three distinct group representations can be used with OAKLEY. Each - group is defined by its group operation and the kind of underlying - field used to represent group elements. The three types are modular - exponentiation groups (named MODP herein), elliptic curve groups over - the field GF[2^N] (named EC2N herein), and elliptic curve groups over - GF[P] (named ECP herein) For each representation, many distinct - realizations are possible, depending on parameter selection. - - With a few exceptions, all the parameters are transmitted as if they - were non-negative multi-precision integers, using the format defined - in this appendix (note, this is distinct from the encoding in - Appendix C). Every multi-precision integer has a prefixed length - field, even where this information is redundant. - - For the group type EC2N, the parameters are more properly thought of - as very long bit fields, but they are represented as multi-precision - integers, (with length fields, and right-justified). This is the - natural encoding. - - MODP means the classical modular exponentiation group, where the - operation is to calculate G^X (mod P). The group is defined by the - numeric parameters P and G. P must be a prime. G is often 2, but - may be a larger number. 2 <= G <= P-2. - - ECP is an elliptic curve group, modulo a prime number P. The - defining equation for this kind of group is - Y^2 = X^3 + AX + B The group operation is taking a multiple of an - elliptic-curve point. The group is defined by 5 numeric parameters: - The prime P, two curve parameters A and B, and a generator (X,Y). - A,B,X,Y are all interpreted mod P, and must be (non-negative) - integers less than P. They must satisfy the defining equation, - modulo P. - - EC2N is an elliptic curve group, over the finite field F[2^N]. The - defining equation for this kind of group is - Y^2 + XY = X^3 + AX^2 + B (This equation differs slightly from the - mod P case: it has an XY term, and an AX^2 term instead of an AX - term.) - - We must specify the field representation, and then the elliptic - curve. The field is specified by giving an irreducible polynomial - (mod 2) of degree N. This polynomial is represented as an integer of - size between 2^N and 2^(N+1), as if the defining polynomial were - evaluated at the value U=2. - - - - - -Orman Informational [Page 37] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - For example, the field defined by the polynomial U^155 + U^62 + 1 is - represented by the integer 2^155 + 2^62 + 1. The group is defined by - 4 more parameters, A,B,X,Y. These parameters are elements of the - field GF[2^N], and can be thought of as polynomials of degree < N, - with (mod 2) coefficients. They fit in N-bit fields, and are - represented as integers < 2^N, as if the polynomial were evaluated at - U=2. For example, the field element U^2 + 1 would be represented by - the integer 2^2+1, which is 5. The two parameters A and B define the - curve. A is frequently 0. B must not be 0. The parameters X and Y - select a point on the curve. The parameters A,B,X,Y must satisfy the - defining equation, modulo the defining polynomial, and mod 2. - - Group descriptor formats: - - Type of group: A two-byte field, - assigned values for the types "MODP", "ECP", "EC2N" - will be defined (see ISAKMP-04). - Size of a field element, in bits. This is either Ceiling(log2 P) - or the degree of the irreducible polynomial: a 32-bit integer. - The prime P or the irreducible field polynomial: a multi-precision - integer. - The generator: 1 or 2 values, multi-precision integers. - EC only: The parameters of the curve: 2 values, multi-precision - integers. - - The following parameters are Optional (each of these may appear - independently): - a value of 0 may be used as a place-holder to represent an unspecified - parameter; any number of the parameters may be sent, from 0 to 3. - - The largest prime factor: the encoded value that is the LPF of the - group size, a multi-precision integer. - - EC only: The order of the group: multi-precision integer. - (The group size for MODP is always P-1.) - - Strength of group: 32-bit integer. - The strength of the group is approximately the number of key-bits - protected. - It is determined by the log2 of the effort to attack the group. - It may change as we learn more about cryptography. - - This is a generic example for a "classic" modular exponentiation group: - Group type: "MODP" - Size of a field element in bits: Log2 (P) rounded *up*. A 32bit - integer. - Defining prime P: a multi-precision integer. - Generator G: a multi-precision integer. 2 <= G <= P-2. - - - -Orman Informational [Page 38] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - <optional> - Largest prime factor of P-1: the multi-precision integer Q - Strength of group: a 32-bit integer. We will specify a formula - for calculating this number (TBD). - - This is a generic example for an elliptic curve group, mod P: - Group type: "ECP" - Size of a field element in bits: Log2 (P) rounded *up*, - a 32 bit integer. - Defining prime P: a multi-precision integer. - Generator (X,Y): 2 multi-precision integers, each < P. - Parameters of the curve A,B: 2 multi-precision integers, each < P. - <optional> - Largest prime factor of the group order: a multi-precision integer. - Order of the group: a multi-precision integer. - Strength of group: a 32-bit integer. Formula TBD. - - This is a specific example for an elliptic curve group: - Group type: "EC2N" - Degree of the irreducible polynomial: 155 - Irreducible polynomial: U^155 + U^62 + 1, represented as the - multi-precision integer 2^155 + 2^62 + 1. - Generator (X,Y) : represented as 2 multi-precision integers, each - < 2^155. - For our present curve, these are (decimal) 123 and 456. Each is - represented as a multi-precision integer. - Parameters of the curve A,B: represented as 2 multi-precision - integers, each < 2^155. - For our present curve these are 0 and (decimal) 471951, represented - as two multi-precision integers. - - <optional> - Largest prime factor of the group order: - - 3805993847215893016155463826195386266397436443, - - represented as a multi-precision integer. - The order of the group: - - 45671926166590716193865565914344635196769237316 - - represented as a multi-precision integer. - - Strength of group: 76, represented as a 32-bit integer. - - The variable precision integer encoding for group descriptor fields - is the following. This is a slight variation on the format defined - in Appendix C in that a fixed 16-bit value is used first, and the - - - -Orman Informational [Page 39] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - length is limited to 16 bits. However, the interpretation is - otherwise identical. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! Fixed value (TBD) ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - . . - . Integer . - . . - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - The format of a group descriptor is: - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!1! Group Description ! MODP ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Field Size ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Prime ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Generator1 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Generator2 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Curve-p1 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Curve-p2 ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !1!0! Largest Prime Factor ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Orman Informational [Page 40] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - !1!0! Order of Group ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !0!0! Strength of Group ! Length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! MPI ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 41] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX B Message formats - - The encodings of Oakley messages into ISAKMP payloads is deferred to - the ISAKMP/Oakley Resolution document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 42] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX C Encoding a variable precision integer. - - Variable precision integers will be encoded as a 32-bit length field - followed by one or more 32-bit quantities containing the - representation of the integer, aligned with the most significant bit - in the first 32-bit item. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! length ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! first value word (most significant bits) ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ additional value words ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - An example of such an encoding is given below, for a number with 51 - bits of significance. The length field indicates that 2 32-bit - quantities follow. The most significant non-zero bit of the number - is in bit 13 of the first 32-bit quantity, the low order bits are in - the second 32-bit quantity. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! 1 0! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !0 0 0 0 0 0 0 0 0 0 0 0 0 1 x x x x x x x x x x x x x x x x x x! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - !x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - - - - - - - - - - -Orman Informational [Page 43] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX D Cryptographic strengths - - The Diffie-Hellman algorithm is used to compute keys that will be - used with symmetric algorithms. It should be no easier to break the - Diffie-Hellman computation than it is to do an exhaustive search over - the symmetric key space. A recent recommendation by an group of - cryptographers [Blaze] has recommended a symmetric key size of 75 - bits for a practical level of security. For 20 year security, they - recommend 90 bits. - - Based on that report, a conservative strategy for OAKLEY users would - be to ensure that their Diffie-Hellman computations were as secure as - at least a 90-bit key space. In order to accomplish this for modular - exponentiation groups, the size of the largest prime factor of the - modulus should be at least 180 bits, and the size of the modulus - should be at least 1400 bits. For elliptic curve groups, the LPF - should be at least 180 bits. - - If long-term secrecy of the encryption key is not an issue, then the - following parameters may be used for the modular exponentiation - group: 150 bits for the LPF, 980 bits for the modulus size. - - The modulus size alone does not determine the strength of the - Diffie-Hellman calculation; the size of the exponent used in - computing powers within the group is also important. The size of the - exponent in bits should be at least twice the size of any symmetric - key that will be derived from it. We recommend that ISAKMP - implementors use at least 180 bits of exponent (twice the size of a - 20-year symmetric key). - - The mathematical justification for these estimates can be found in - texts that estimate the effort for solving the discrete log problem, - a task that is strongly related to the efficiency of using the Number - Field Sieve for factoring large integers. Readers are referred to - [Stinson] and [Schneier]. - - - - - - - - - - - - - - - - -Orman Informational [Page 44] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -APPENDIX E The Well-Known Groups - - The group identifiers: - - 0 No group (used as a placeholder and for non-DH exchanges) - 1 A modular exponentiation group with a 768 bit modulus - 2 A modular exponentiation group with a 1024 bit modulus - 3 A modular exponentiation group with a 1536 bit modulus (TBD) - 4 An elliptic curve group over GF[2^155] - 5 An elliptic curve group over GF[2^185] - - values 2^31 and higher are used for private group identifiers - - Richard Schroeppel performed all the mathematical and computational - work for this appendix. - - Classical Diffie-Hellman Modular Exponentiation Groups - - The primes for groups 1 and 2 were selected to have certain - properties. The high order 64 bits are forced to 1. This helps the - classical remainder algorithm, because the trial quotient digit can - always be taken as the high order word of the dividend, possibly +1. - The low order 64 bits are forced to 1. This helps the Montgomery- - style remainder algorithms, because the multiplier digit can always - be taken to be the low order word of the dividend. The middle bits - are taken from the binary expansion of pi. This guarantees that they - are effectively random, while avoiding any suspicion that the primes - have secretly been selected to be weak. - - Because both primes are based on pi, there is a large section of - overlap in the hexadecimal representations of the two primes. The - primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also - prime), to have the maximum strength against the square-root attack - on the discrete logarithm problem. - - The starting trial numbers were repeatedly incremented by 2^64 until - suitable primes were located. - - Because these two primes are congruent to 7 (mod 8), 2 is a quadratic - residue of each prime. All powers of 2 will also be quadratic - residues. This prevents an opponent from learning the low order bit - of the Diffie-Hellman exponent (AKA the subgroup confinement - problem). Using 2 as a generator is efficient for some modular - exponentiation algorithms. [Note that 2 is technically not a - generator in the number theory sense, because it omits half of the - possible residues mod P. From a cryptographic viewpoint, this is a - virtue.] - - - - -Orman Informational [Page 45] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -E.1. Well-Known Group 1: A 768 bit prime - - The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its - decimal value is - 155251809230070893513091813125848175563133404943451431320235 - 119490296623994910210725866945387659164244291000768028886422 - 915080371891804634263272761303128298374438082089019628850917 - 0691316593175367469551763119843371637221007210577919 - - This has been rigorously verified as a prime. - - The representation of the group in OAKLEY is - - Type of group: "MODP" - Size of field element (bits): 768 - Prime modulus: 21 (decimal) - Length (32 bit words): 24 - Data (hex): - FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 - 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD - EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 - E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 24 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31D1B10 7FFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 00000042 - -E.2. Well-Known Group 2: A 1024 bit prime - - The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. - Its decimal value is - 179769313486231590770839156793787453197860296048756011706444 - 423684197180216158519368947833795864925541502180565485980503 - 646440548199239100050792877003355816639229553136239076508735 - 759914822574862575007425302077447712589550957937778424442426 - 617334727629299387668709205606050270810842907692932019128194 - - - -Orman Informational [Page 46] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 467627007 - - The primality of the number has been rigorously proven. - - The representation of the group in OAKLEY is - Type of group: "MODP" - Size of field element (bits): 1024 - Prime modulus: 21 (decimal) - Length (32 bit words): 32 - Data (hex): - 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 - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 32 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 - F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F67329C0 - FFFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000004D - -E.3. Well-Known Group 3: An Elliptic Curve Group Definition - - The curve is based on the Galois field GF[2^155] with 2^155 field - elements. The irreducible polynomial for the field is u^155 + u^62 + - 1. The equation for the elliptic curve is - - Y^2 + X Y = X^3 + A X + B - - X, Y, A, B are elements of the field. - - For the curve specified, A = 0 and - - B = u^18 + u^17 + u^16 + u^13 + u^12 + u^9 + u^8 + u^7 + u^3 + u^2 + - - - -Orman Informational [Page 47] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - u + 1. - - B is represented in binary as the bit string 1110011001110001111; in - decimal this is 471951, and in hex 7338F. - - The generator is a point (X,Y) on the curve (satisfying the curve - equation, mod 2 and modulo the field polynomial). - - X = u^6 + u^5 + u^4 + u^3 + u + 1 - - and - - Y = u^8 + u^7 + u^6 + u^3. - - The binary bit strings for X and Y are 1111011 and 111001000; in - decimal they are 123 and 456. - - The group order (the number of curve points) is - 45671926166590716193865565914344635196769237316 - which is 12 times the prime - - 3805993847215893016155463826195386266397436443. - (This prime has been rigorously proven.) The generating point (X,Y) - has order 4 times the prime; the generator is the triple of some - curve point. - - OAKLEY representation of this group: - Type of group: "EC2N" - Size of field element (bits): 155 - Irreducible field polynomial: 21 (decimal) - Length (32 bit words): 5 - Data (hex): - 08000000 00000000 00000000 40000000 00000001 - Generator: - X coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 7B - Y coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 1C8 - Elliptic curve parameters: - A parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 0 - B parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 7338F - - - - -Orman Informational [Page 48] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 5 - Data (hex): - 00AAAAAA AAAAAAAA AAAAB1FC F1E206F4 21A3EA1B - Group order: 25 (decimal) - Length (32 bit words): 5 - Data (hex): - 08000000 00000000 000057DB 56985371 93AEF944 - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000004C - -E.4. Well-Known Group 4: A Large Elliptic Curve Group Definition - - This curve is based on the Galois field GF[2^185] with 2^185 field - elements. The irreducible polynomial for the field is - - u^185 + u^69 + 1. - - The equation for the elliptic curve is - - Y^2 + X Y = X^3 + A X + B. - - X, Y, A, B are elements of the field. For the curve specified, A = 0 - and - - B = u^12 + u^11 + u^10 + u^9 + u^7 + u^6 + u^5 + u^3 + 1. - - B is represented in binary as the bit string 1111011101001; in - decimal this is 7913, and in hex 1EE9. - - The generator is a point (X,Y) on the curve (satisfying the curve - equation, mod 2 and modulo the field polynomial); - - X = u^4 + u^3 and Y = u^3 + u^2 + 1. - - The binary bit strings for X and Y are 11000 and 1101; in decimal - they are 24 and 13. The group order (the number of curve points) is - - 49039857307708443467467104857652682248052385001045053116, - - which is 4 times the prime - - 12259964326927110866866776214413170562013096250261263279. - - (This prime has been rigorously proven.) - - - -Orman Informational [Page 49] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - The generating point (X,Y) has order 2 times the prime; the generator - is the double of some curve point. - - OAKLEY representation of this group: - - Type of group: "EC2N" - Size of field element (bits): 185 - Irreducible field polynomial: 21 (decimal) - Length (32 bit words): 6 - Data (hex): - 02000000 00000000 00000000 00000020 00000000 00000001 - Generator: - X coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 18 - Y coordinate: 22 (decimal) - Length (32 bit words): 1 - Data (hex): D - Elliptic curve parameters: - A parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 0 - B parameter: 23 (decimal) - Length (32 bit words): 1 - Data (hex): 1EE9 - - Optional parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 6 - Data (hex): - 007FFFFF FFFFFFFF FFFFFFFF F6FCBE22 6DCF9210 5D7E53AF - Group order: 25 (decimal) - Length (32 bit words): 6 - Data (hex): - 01FFFFFF FFFFFFFF FFFFFFFF DBF2F889 B73E4841 75F94EBC - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000005B - -E.5. Well-Known Group 5: A 1536 bit prime - - The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 - }. - Its decimal value is - 241031242692103258855207602219756607485695054850245994265411 - 694195810883168261222889009385826134161467322714147790401219 - 650364895705058263194273070680500922306273474534107340669624 - - - -Orman Informational [Page 50] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - 601458936165977404102716924945320037872943417032584377865919 - 814376319377685986952408894019557734611984354530154704374720 - 774996976375008430892633929555996888245787241299381012913029 - 459299994792636526405928464720973038494721168143446471443848 - 8520940127459844288859336526896320919633919 - - The primality of the number has been rigorously proven. - - The representation of the group in OAKLEY is - Type of group: "MODP" - Size of field element (bits): 1536 - Prime modulus: 21 (decimal) - Length (32 bit words): 48 - Data (hex): - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - Generator: 22 (decimal) - Length (32 bit words): 1 - Data (hex): 2 - - Optional Parameters: - Group order largest prime factor: 24 (decimal) - Length (32 bit words): 48 - Data (hex): - 7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68 - 94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E - F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122 - F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6 - F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E - E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF - C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36 - B3861AA7 255E4C02 78BA3604 6511B993 FFFFFFFF FFFFFFFF - Strength of group: 26 (decimal) - Length (32 bit words) 1 - Data (hex): - 0000005B - - - - - - - - - -Orman Informational [Page 51] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Appendix F Implementing Group Operations - - The group operation must be implemented as a sequence of arithmetic - operations; the exact operations depend on the type of group. For - modular exponentiation groups, the operation is multi-precision - integer multiplication and remainders by the group modulus. See - Knuth Vol. 2 [Knuth] for a discussion of how to implement these for - large integers. Implementation recommendations for elliptic curve - group operations over GF[2^N] are described in [Schroeppel]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 52] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -BIBLIOGRAPHY - - [RFC2401] Atkinson, R., "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC2406] Atkinson, R., "IP Encapsulating Security Payload (ESP)", - RFC 2406, November 1998. - - [RFC2402] Atkinson, R., "IP Authentication Header", RFC 2402, - November 1998. - - [Blaze] Blaze, Matt et al., MINIMAL KEY LENGTHS FOR SYMMETRIC - CIPHERS TO PROVIDE ADEQUATE COMMERCIAL SECURITY. A - REPORT BY AN AD HOC GROUP OF CRYPTOGRAPHERS AND COMPUTER - SCIENTISTS... -- - http://www.bsa.org/policy/encryption/cryptographers.html - - [STS] W. Diffie, P.C. Van Oorschot, and M.J. Wiener, - "Authentication and Authenticated Key Exchanges," in - Designs, Codes and Cryptography, Kluwer Academic - Publishers, 1992, pp. 107 - - [SECDNS] Eastlake, D. and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065, January 1997. - - [Random] Eastlake, D., Crocker, S. and J. Schiller, "Randomness - Recommendations for Security", RFC 1750, December 1994. - - [Kocher] Kocher, Paul, Timing Attack, - http://www.cryptography.com/timingattack.old/timingattack.html - - [Knuth] Knuth, Donald E., The Art of Computer Programming, Vol. - 2, Seminumerical Algorithms, Addison Wesley, 1969. - - [Krawcyzk] Krawcyzk, Hugo, SKEME: A Versatile Secure Key Exchange - Mechanism for Internet, ISOC Secure Networks and - Distributed Systems Symposium, San Diego, 1996 - - [Schneier] Schneier, Bruce, Applied cryptography: protocols, - algorithms, and source code in C, Second edition, John - Wiley & Sons, Inc. 1995, ISBN 0-471-12845-7, hardcover. - ISBN 0-471-11709-9, softcover. - - [Schroeppel] Schroeppel, Richard, et al.; Fast Key Exchange with - Elliptic Curve Systems, Crypto '95, Santa Barbara, 1995. - Available on-line as - ftp://ftp.cs.arizona.edu/reports/1995/TR95-03.ps (and - .Z). - - - -Orman Informational [Page 53] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - - [Stinson] Stinson, Douglas, Cryptography Theory and Practice. CRC - Press, Inc., 2000, Corporate Blvd., Boca Raton, FL, - 33431-9868, ISBN 0-8493-8521-0, 1995 - - [Zimmerman] Philip Zimmermann, The Official Pgp User's Guide, - Published by MIT Press Trade, Publication date: June - 1995, ISBN: 0262740176 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 54] - -RFC 2412 The OAKLEY Key Determination Protocol November 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Orman Informational [Page 55] - diff --git a/doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt b/doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt deleted file mode 100644 index 54f6d5db5..000000000 --- a/doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt +++ /dev/null @@ -1,2187 +0,0 @@ - - - - - - -Network Working Group B. Kaliski -Request for Comments: 2437 J. Staddon -Obsoletes: 2313 RSA Laboratories -Category: Informational October 1998 - - - PKCS #1: RSA Cryptography Specifications - Version 2.0 - -Status of this Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Table of Contents - - 1. Introduction.....................................2 - 1.1 Overview.........................................3 - 2. Notation.........................................3 - 3. Key types........................................5 - 3.1 RSA public key...................................5 - 3.2 RSA private key..................................5 - 4. Data conversion primitives.......................6 - 4.1 I2OSP............................................6 - 4.2 OS2IP............................................7 - 5. Cryptographic primitives.........................8 - 5.1 Encryption and decryption primitives.............8 - 5.1.1 RSAEP............................................8 - 5.1.2 RSADP............................................9 - 5.2 Signature and verification primitives...........10 - 5.2.1 RSASP1..........................................10 - 5.2.2 RSAVP1..........................................11 - 6. Overview of schemes.............................11 - 7. Encryption schemes..............................12 - 7.1 RSAES-OAEP......................................13 - 7.1.1 Encryption operation............................13 - 7.1.2 Decryption operation............................14 - 7.2 RSAES-PKCS1-v1_5................................15 - 7.2.1 Encryption operation............................17 - 7.2.2 Decryption operation............................17 - 8. Signature schemes with appendix.................18 - 8.1 RSASSA-PKCS1-v1_5...............................19 - 8.1.1 Signature generation operation..................20 - - - -Kaliski & Staddon Informational [Page 1] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - 8.1.2 Signature verification operation................21 - 9. Encoding methods................................22 - 9.1 Encoding methods for encryption.................22 - 9.1.1 EME-OAEP........................................22 - 9.1.2 EME-PKCS1-v1_5..................................24 - 9.2 Encoding methods for signatures with appendix...26 - 9.2.1 EMSA-PKCS1-v1_5.................................26 - 10. Auxiliary Functions.............................27 - 10.1 Hash Functions..................................27 - 10.2 Mask Generation Functions.......................28 - 10.2.1 MGF1............................................28 - 11. ASN.1 syntax....................................29 - 11.1 Key representation..............................29 - 11.1.1 Public-key syntax...............................30 - 11.1.2 Private-key syntax..............................30 - 11.2 Scheme identification...........................31 - 11.2.1 Syntax for RSAES-OAEP...........................31 - 11.2.2 Syntax for RSAES-PKCS1-v1_5.....................32 - 11.2.3 Syntax for RSASSA-PKCS1-v1_5....................33 - 12 Patent Statement................................33 - 12.1 Patent statement for the RSA algorithm..........34 - 13. Revision history................................35 - 14. References......................................35 - Security Considerations.........................37 - Acknowledgements................................37 - Authors' Addresses..............................38 - Full Copyright Statement........................39 - -1. Introduction - - This memo is the successor to RFC 2313. This document provides - recommendations for the implementation of public-key cryptography - based on the RSA algorithm [18], covering the following aspects: - - -cryptographic primitives - -encryption schemes - -signature schemes with appendix - -ASN.1 syntax for representing keys and for identifying the - schemes - - The recommendations are intended for general application within - computer and communications systems, and as such include a fair - amount of flexibility. It is expected that application standards - based on these specifications may include additional constraints. The - recommendations are intended to be compatible with draft standards - currently being developed by the ANSI X9F1 [1] and IEEE P1363 working - groups [14]. This document supersedes PKCS #1 version 1.5 [20]. - - - - -Kaliski & Staddon Informational [Page 2] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Editor's note. It is expected that subsequent versions of PKCS #1 may - cover other aspects of the RSA algorithm such as key size, key - generation, key validation, and signature schemes with message - recovery. - -1.1 Overview - - The organization of this document is as follows: - - -Section 1 is an introduction. - -Section 2 defines some notation used in this document. - -Section 3 defines the RSA public and private key types. - -Sections 4 and 5 define several primitives, or basic mathematical - operations. Data conversion primitives are in Section 4, and - cryptographic primitives (encryption-decryption, - signature-verification) are in Section 5. - -Section 6, 7 and 8 deal with the encryption and signature schemes - in this document. Section 6 gives an overview. Section 7 defines - an OAEP-based [2] encryption scheme along with the method found - in PKCS #1 v1.5. Section 8 defines a signature scheme with - appendix; the method is identical to that of PKCS #1 v1.5. - -Section 9 defines the encoding methods for the encryption and - signature schemes in Sections 7 and 8. - -Section 10 defines the hash functions and the mask generation - function used in this document. - -Section 11 defines the ASN.1 syntax for the keys defined in - Section 3 and the schemes gives in Sections 7 and 8. - -Section 12 outlines the revision history of PKCS #1. - -Section 13 contains references to other publications and - standards. - -2. Notation - - (n, e) RSA public key - - c ciphertext representative, an integer between 0 and n-1 - - C ciphertext, an octet string - - d private exponent - - dP p's exponent, a positive integer such that: - e(dP)\equiv 1 (mod(p-1)) - - dQ q's exponent, a positive integer such that: - e(dQ)\equiv 1 (mod(q-1)) - - e public exponent - - - -Kaliski & Staddon Informational [Page 3] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - EM encoded message, an octet string - - emLen intended length in octets of an encoded message - - H hash value, an output of Hash - - Hash hash function - - hLen output length in octets of hash function Hash - - K RSA private key - - k length in octets of the modulus - - l intended length of octet string - - lcm(.,.) least common multiple of two - nonnegative integers - - m message representative, an integer between - 0 and n-1 - - M message, an octet string - - MGF mask generation function - - n modulus - - P encoding parameters, an octet string - - p,q prime factors of the modulus - - qInv CRT coefficient, a positive integer less - than p such: q(qInv)\equiv 1 (mod p) - - s signature representative, an integer - between 0 and n-1 - - S signature, an octet string - - x a nonnegative integer - - X an octet string corresponding to x - - \xor bitwise exclusive-or of two octet strings - - \lambda(n) lcm(p-1, q-1), where n = pq - - - - -Kaliski & Staddon Informational [Page 4] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - || concatenation operator - - ||.|| octet length operator - -3. Key types - - Two key types are employed in the primitives and schemes defined in - this document: RSA public key and RSA private key. Together, an RSA - public key and an RSA private key form an RSA key pair. - -3.1 RSA public key - - For the purposes of this document, an RSA public key consists of two - components: - - n, the modulus, a nonnegative integer - e, the public exponent, a nonnegative integer - - In a valid RSA public key, the modulus n is a product of two odd - primes p and q, and the public exponent e is an integer between 3 and - n-1 satisfying gcd (e, \lambda(n)) = 1, where \lambda(n) = lcm (p- - 1,q-1). A recommended syntax for interchanging RSA public keys - between implementations is given in Section 11.1.1; an - implementation's internal representation may differ. - -3.2 RSA private key - - For the purposes of this document, an RSA private key may have either - of two representations. - - 1. The first representation consists of the pair (n, d), where the - components have the following meanings: - - n, the modulus, a nonnegative integer - d, the private exponent, a nonnegative integer - - 2. The second representation consists of a quintuple (p, q, dP, dQ, - qInv), where the components have the following meanings: - - p, the first factor, a nonnegative integer - q, the second factor, a nonnegative integer - dP, the first factor's exponent, a nonnegative integer - dQ, the second factor's exponent, a nonnegative integer - qInv, the CRT coefficient, a nonnegative integer - - In a valid RSA private key with the first representation, the modulus - n is the same as in the corresponding public key and is the product - of two odd primes p and q, and the private exponent d is a positive - - - -Kaliski & Staddon Informational [Page 5] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - integer less than n satisfying: - - ed \equiv 1 (mod \lambda(n)) - - where e is the corresponding public exponent and \lambda(n) is as - defined above. - - In a valid RSA private key with the second representation, the two - factors p and q are the prime factors of the modulus n, the exponents - dP and dQ are positive integers less than p and q respectively - satisfying - - e(dP)\equiv 1(mod(p-1)) - e(dQ)\equiv 1(mod(q-1)), - - and the CRT coefficient qInv is a positive integer less than p - satisfying: - - q(qInv)\equiv 1 (mod p). - - A recommended syntax for interchanging RSA private keys between - implementations, which includes components from both representations, - is given in Section 11.1.2; an implementation's internal - representation may differ. - -4. Data conversion primitives - - Two data conversion primitives are employed in the schemes defined in - this document: - - I2OSP: Integer-to-Octet-String primitive - OS2IP: Octet-String-to-Integer primitive - - For the purposes of this document, and consistent with ASN.1 syntax, an - octet string is an ordered sequence of octets (eight-bit bytes). The - sequence is indexed from first (conventionally, leftmost) to last - (rightmost). For purposes of conversion to and from integers, the first - octet is considered the most significant in the following conversion - primitives - -4.1 I2OSP - - I2OSP converts a nonnegative integer to an octet string of a specified - length. - - I2OSP (x, l) - - - - - -Kaliski & Staddon Informational [Page 6] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Input: - x nonnegative integer to be converted - l intended length of the resulting octet string - - Output: - X corresponding octet string of length l; or - "integer too large" - - Steps: - - 1. If x>=256^l, output "integer too large" and stop. - - 2. Write the integer x in its unique l-digit representation base 256: - - x = x_{l-1}256^{l-1} + x_{l-2}256^{l-2} +... + x_1 256 + x_0 - - where 0 <= x_i < 256 (note that one or more leading digits will be - zero if x < 256^{l-1}). - - 3. Let the octet X_i have the value x_{l-i} for 1 <= i <= l. Output - the octet string: - - X = X_1 X_2 ... X_l. - -4.2 OS2IP - - OS2IP converts an octet string to a nonnegative integer. - - OS2IP (X) - - Input: - X octet string to be converted - - Output: - x corresponding nonnegative integer - - Steps: - - 1. Let X_1 X_2 ... X_l be the octets of X from first to last, and - let x{l-i} have value X_i for 1<= i <= l. - - 2. Let x = x{l-1} 256^{l-1} + x_{l-2} 256^{l-2} +...+ x_1 256 + x_0. - - 3. Output x. - - - - - - - -Kaliski & Staddon Informational [Page 7] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -5. Cryptographic primitives - - Cryptographic primitives are basic mathematical operations on which - cryptographic schemes can be built. They are intended for - implementation in hardware or as software modules, and are not - intended to provide security apart from a scheme. - - Four types of primitive are specified in this document, organized in - pairs: encryption and decryption; and signature and verification. - - The specifications of the primitives assume that certain conditions - are met by the inputs, in particular that public and private keys are - valid. - -5.1 Encryption and decryption primitives - - An encryption primitive produces a ciphertext representative from a - message representative under the control of a public key, and a - decryption primitive recovers the message representative from the - ciphertext representative under the control of the corresponding - private key. - - One pair of encryption and decryption primitives is employed in the - encryption schemes defined in this document and is specified here: - RSAEP/RSADP. RSAEP and RSADP involve the same mathematical operation, - with different keys as input. - - The primitives defined here are the same as in the draft IEEE P1363 - and are compatible with PKCS #1 v1.5. - - The main mathematical operation in each primitive is exponentiation. - -5.1.1 RSAEP - - RSAEP((n, e), m) - - Input: - (n, e) RSA public key - m message representative, an integer between 0 and n-1 - - Output: - c ciphertext representative, an integer between 0 and n-1; - or "message representative out of range" - - Assumptions: public key (n, e) is valid - - Steps: - - - - -Kaliski & Staddon Informational [Page 8] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - 1. If the message representative m is not between 0 and n-1, output - message representative out of range and stop. - - 2. Let c = m^e mod n. - - 3. Output c. - -5.1.2 RSADP - - RSADP (K, c) - - Input: - - K RSA private key, where K has one of the following forms - -a pair (n, d) - -a quintuple (p, q, dP, dQ, qInv) - c ciphertext representative, an integer between 0 and n-1 - - Output: - m message representative, an integer between 0 and n-1; or - "ciphertext representative out of range" - - Assumptions: private key K is valid - - Steps: - - 1. If the ciphertext representative c is not between 0 and n-1, - output "ciphertext representative out of range" and stop. - - 2. If the first form (n, d) of K is used: - - 2.1 Let m = c^d mod n. Else, if the second form (p, q, dP, - dQ, qInv) of K is used: - - 2.2 Let m_1 = c^dP mod p. - - 2.3 Let m_2 = c^dQ mod q. - - 2.4 Let h = qInv ( m_1 - m_2 ) mod p. - - 2.5 Let m = m_2 + hq. - - 3. Output m. - - - - - - - - -Kaliski & Staddon Informational [Page 9] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -5.2 Signature and verification primitives - - A signature primitive produces a signature representative from a - message representative under the control of a private key, and a - verification primitive recovers the message representative from the - signature representative under the control of the corresponding - public key. One pair of signature and verification primitives is - employed in the signature schemes defined in this document and is - specified here: RSASP1/RSAVP1. - - The primitives defined here are the same as in the draft IEEE P1363 - and are compatible with PKCS #1 v1.5. - - The main mathematical operation in each primitive is exponentiation, - as in the encryption and decryption primitives of Section 5.1. RSASP1 - and RSAVP1 are the same as RSADP and RSAEP except for the names of - their input and output arguments; they are distinguished as they are - intended for different purposes. - -5.2.1 RSASP1 - - RSASP1 (K, m) - - Input: - K RSA private key, where K has one of the following - forms: - -a pair (n, d) - -a quintuple (p, q, dP, dQ, qInv) - - m message representative, an integer between 0 and n-1 - - Output: - s signature representative, an integer between 0 and - n-1, or "message representative out of range" - - Assumptions: - private key K is valid - - Steps: - - 1. If the message representative m is not between 0 and n-1, output - "message representative out of range" and stop. - - 2. If the first form (n, d) of K is used: - - 2.1 Let s = m^d mod n. Else, if the second form (p, q, dP, - dQ, qInv) of K is used: - - - - -Kaliski & Staddon Informational [Page 10] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - 2.2 Let s_1 = m^dP mod p. - - 2.3 Let s_2 = m^dQ mod q. - - 2.4 Let h = qInv ( s_1 - s_2 ) mod p. - - 2.5 Let s = s_2 + hq. - - 3. Output S. - -5.2.2 RSAVP1 - - RSAVP1 ((n, e), s) - - Input: - (n, e) RSA public key - s signature representative, an integer between 0 and n-1 - - Output: - m message representative, an integer between 0 and n-1; - or "invalid" - - Assumptions: - public key (n, e) is valid - - Steps: - - 1. If the signature representative s is not between 0 and n-1, output - "invalid" and stop. - - 2. Let m = s^e mod n. - - 3. Output m. - -6. Overview of schemes - - A scheme combines cryptographic primitives and other techniques to - achieve a particular security goal. Two types of scheme are specified - in this document: encryption schemes and signature schemes with - appendix. - - The schemes specified in this document are limited in scope in that - their operations consist only of steps to process data with a key, - and do not include steps for obtaining or validating the key. Thus, - in addition to the scheme operations, an application will typically - include key management operations by which parties may select public - and private keys for a scheme operation. The specific additional - operations and other details are outside the scope of this document. - - - -Kaliski & Staddon Informational [Page 11] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - As was the case for the cryptographic primitives (Section 5), the - specifications of scheme operations assume that certain conditions - are met by the inputs, in particular that public and private keys are - valid. The behavior of an implementation is thus unspecified when a - key is invalid. The impact of such unspecified behavior depends on - the application. Possible means of addressing key validation include - explicit key validation by the application; key validation within the - public-key infrastructure; and assignment of liability for operations - performed with an invalid key to the party who generated the key. - -7. Encryption schemes - - An encryption scheme consists of an encryption operation and a - decryption operation, where the encryption operation produces a - ciphertext from a message with a recipient's public key, and the - decryption operation recovers the message from the ciphertext with - the recipient's corresponding private key. - - An encryption scheme can be employed in a variety of applications. A - typical application is a key establishment protocol, where the - message contains key material to be delivered confidentially from one - party to another. For instance, PKCS #7 [21] employs such a protocol - to deliver a content-encryption key from a sender to a recipient; the - encryption schemes defined here would be suitable key-encryption - algorithms in that context. - - Two encryption schemes are specified in this document: RSAES-OAEP and - RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; - RSAES-PKCS1-v1_5 is included only for compatibility with existing - applications, and is not recommended for new applications. - - The encryption schemes given here follow a general model similar to - that employed in IEEE P1363, by combining encryption and decryption - primitives with an encoding method for encryption. The encryption - operations apply a message encoding operation to a message to produce - an encoded message, which is then converted to an integer message - representative. An encryption primitive is applied to the message - representative to produce the ciphertext. Reversing this, the - decryption operations apply a decryption primitive to the ciphertext - to recover a message representative, which is then converted to an - octet string encoded message. A message decoding operation is applied - to the encoded message to recover the message and verify the - correctness of the decryption. - - - - - - - - -Kaliski & Staddon Informational [Page 12] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -7.1 RSAES-OAEP - - RSAES-OAEP combines the RSAEP and RSADP primitives (Sections 5.1.1 - and 5.1.2) with the EME-OAEP encoding method (Section 9.1.1) EME-OAEP - is based on the method found in [2]. It is compatible with the IFES - scheme defined in the draft P1363 where the encryption and decryption - primitives are IFEP-RSA and IFDP-RSA and the message encoding method - is EME-OAEP. RSAES-OAEP can operate on messages of length up to k-2- - 2hLen octets, where hLen is the length of the hash function output - for EME-OAEP and k is the length in octets of the recipient's RSA - modulus. Assuming that the hash function in EME-OAEP has appropriate - properties, and the key size is sufficiently large, RSAEP-OAEP - provides "plaintext-aware encryption," meaning that it is - computationally infeasible to obtain full or partial information - about a message from a ciphertext, and computationally infeasible to - generate a valid ciphertext without knowing the corresponding - message. Therefore, a chosen-ciphertext attack is ineffective - against a plaintext-aware encryption scheme such as RSAES-OAEP. - - Both the encryption and the decryption operations of RSAES-OAEP take - the value of the parameter string P as input. In this version of PKCS - #1, P is an octet string that is specified explicitly. See Section - 11.2.1 for the relevant ASN.1 syntax. We briefly note that to receive - the full security benefit of RSAES-OAEP, it should not be used in a - protocol involving RSAES-PKCS1-v1_5. It is possible that in a - protocol on which both encryption schemes are present, an adaptive - chosen ciphertext attack such as [4] would be useful. - - Both the encryption and the decryption operations of RSAES-OAEP take - the value of the parameter string P as input. In this version of PKCS - #1, P is an octet string that is specified explicitly. See Section - 11.2.1 for the relevant ASN.1 syntax. - -7.1.1 Encryption operation - - RSAES-OAEP-ENCRYPT ((n, e), M, P) - - Input: - (n, e) recipient's RSA public key - - M message to be encrypted, an octet string of length at - most k-2-2hLen, where k is the length in octets of the - modulus n and hLen is the length in octets of the hash - function output for EME-OAEP - - P encoding parameters, an octet string that may be empty - - - - - -Kaliski & Staddon Informational [Page 13] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Output: - C ciphertext, an octet string of length k; or "message too - long" - - Assumptions: public key (n, e) is valid - - Steps: - - 1. Apply the EME-OAEP encoding operation (Section 9.1.1.2) to the - message M and the encoding parameters P to produce an encoded message - EM of length k-1 octets: - - EM = EME-OAEP-ENCODE (M, P, k-1) - - If the encoding operation outputs "message too long," then output - "message too long" and stop. - - 2. Convert the encoded message EM to an integer message - representative m: m = OS2IP (EM) - - 3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public - key (n, e) and the message representative m to produce an integer - ciphertext representative c: - - c = RSAEP ((n, e), m) - - 4. Convert the ciphertext representative c to a ciphertext C of - length k octets: C = I2OSP (c, k) - - 5. Output the ciphertext C. - -7.1.2 Decryption operation - - RSAES-OAEP-DECRYPT (K, C, P) - - Input: - K recipient's RSA private key - C ciphertext to be decrypted, an octet string of length - k, where k is the length in octets of the modulus n - P encoding parameters, an octet string that may be empty - - Output: - M message, an octet string of length at most k-2-2hLen, - where hLen is the length in octets of the hash - function output for EME-OAEP; or "decryption error" - - - - - - -Kaliski & Staddon Informational [Page 14] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Steps: - - 1. If the length of the ciphertext C is not k octets, output - "decryption error" and stop. - - 2. Convert the ciphertext C to an integer ciphertext representative - c: c = OS2IP (C). - - 3. Apply the RSADP decryption primitive (Section 5.1.2) to the - private key K and the ciphertext representative c to produce an - integer message representative m: - - m = RSADP (K, c) - - If RSADP outputs "ciphertext out of range," then output "decryption - error" and stop. - - 4. Convert the message representative m to an encoded message EM of - length k-1 octets: EM = I2OSP (m, k-1) - - If I2OSP outputs "integer too large," then output "decryption error" - and stop. - - 5. Apply the EME-OAEP decoding operation to the encoded message EM - and the encoding parameters P to recover a message M: - - M = EME-OAEP-DECODE (EM, P) - - If the decoding operation outputs "decoding error," then output - "decryption error" and stop. - - 6. Output the message M. - - Note. It is important that the error messages output in steps 4 and 5 - be the same, otherwise an adversary may be able to extract useful - information from the type of error message received. Error message - information is used to mount a chosen-ciphertext attack on PKCS #1 - v1.5 encrypted messages in [4]. - -7.2 RSAES-PKCS1-v1_5 - - RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives with the - EME-PKCS1-v1_5 encoding method. It is the same as the encryption - scheme in PKCS #1 v1.5. RSAES-PKCS1-v1_5 can operate on messages of - length up to k-11 octets, although care should be taken to avoid - certain attacks on low-exponent RSA due to Coppersmith, et al. when - long messages are encrypted (see the third bullet in the notes below - and [7]). - - - -Kaliski & Staddon Informational [Page 15] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - RSAES-PKCS1-v1_5 does not provide "plaintext aware" encryption. In - particular, it is possible to generate valid ciphertexts without - knowing the corresponding plaintexts, with a reasonable probability - of success. This ability can be exploited in a chosen ciphertext - attack as shown in [4]. Therefore, if RSAES-PKCS1-v1_5 is to be used, - certain easily implemented countermeasures should be taken to thwart - the attack found in [4]. The addition of structure to the data to be - encoded, rigorous checking of PKCS #1 v1.5 conformance and other - redundancy in decrypted messages, and the consolidation of error - messages in a client-server protocol based on PKCS #1 v1.5 can all be - effective countermeasures and don't involve changes to a PKCS #1 - v1.5-based protocol. These and other countermeasures are discussed in - [5]. - - Notes. The following passages describe some security recommendations - pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from - version 1.5 of this document are included as well as new - recommendations motivated by cryptanalytic advances made in the - intervening years. - - -It is recommended that the pseudorandom octets in EME-PKCS1-v1_5 be - generated independently for each encryption process, especially if - the same data is input to more than one encryption process. Hastad's - results [13] are one motivation for this recommendation. - - -The padding string PS in EME-PKCS1-v1_5 is at least eight octets - long, which is a security condition for public-key operations that - prevents an attacker from recovering data by trying all possible - encryption blocks. - - -The pseudorandom octets can also help thwart an attack due to - Coppersmith et al. [7] when the size of the message to be encrypted - is kept small. The attack works on low-exponent RSA when similar - messages are encrypted with the same public key. More specifically, - in one flavor of the attack, when two inputs to RSAEP agree on a - large fraction of bits (8/9) and low-exponent RSA (e = 3) is used to - encrypt both of them, it may be possible to recover both inputs with - the attack. Another flavor of the attack is successful in decrypting - a single ciphertext when a large fraction (2/3) of the input to RSAEP - is already known. For typical applications, the message to be - encrypted is short (e.g., a 128-bit symmetric key) so not enough - information will be known or common between two messages to enable - the attack. However, if a long message is encrypted, or if part of a - message is known, then the attack may be a concern. In any case, the - RSAEP-OAEP scheme overcomes the attack. - - - - - - -Kaliski & Staddon Informational [Page 16] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -7.2.1 Encryption operation - - RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M) - - Input: - (n, e) recipient's RSA public key - M message to be encrypted, an octet string of length at - most k-11 octets, where k is the length in octets of the - modulus n - - Output: - C ciphertext, an octet string of length k; or "message too - long" - - Steps: - - 1. Apply the EME-PKCS1-v1_5 encoding operation (Section 9.1.2.1) to - the message M to produce an encoded message EM of length k-1 octets: - - EM = EME-PKCS1-V1_5-ENCODE (M, k-1) - - If the encoding operation outputs "message too long," then output - "message too long" and stop. - - 2. Convert the encoded message EM to an integer message - representative m: m = OS2IP (EM) - - 3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public - key (n, e) and the message representative m to produce an integer - ciphertext representative c: c = RSAEP ((n, e), m) - - 4. Convert the ciphertext representative c to a ciphertext C of - length k octets: C = I2OSP (c, k) - - 5. Output the ciphertext C. - -7.2.2 Decryption operation - - RSAES-PKCS1-V1_5-DECRYPT (K, C) - - Input: - K recipient's RSA private key - C ciphertext to be decrypted, an octet string of length k, - where k is the length in octets of the modulus n - - Output: - M message, an octet string of length at most k-11; or - "decryption error" - - - -Kaliski & Staddon Informational [Page 17] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Steps: - - 1. If the length of the ciphertext C is not k octets, output - "decryption error" and stop. - - 2. Convert the ciphertext C to an integer ciphertext representative - c: c = OS2IP (C). - - 3. Apply the RSADP decryption primitive to the private key (n, d) and - the ciphertext representative c to produce an integer message - representative m: m = RSADP ((n, d), c). - - If RSADP outputs "ciphertext out of range," then output "decryption - error" and stop. - - 4. Convert the message representative m to an encoded message EM of - length k-1 octets: EM = I2OSP (m, k-1) - - If I2OSP outputs "integer too large," then output "decryption error" - and stop. - - 5. Apply the EME-PKCS1-v1_5 decoding operation to the encoded message - EM to recover a message M: M = EME-PKCS1-V1_5-DECODE (EM). - - If the decoding operation outputs "decoding error," then output - "decryption error" and stop. - - 6. Output the message M. - - Note. It is important that only one type of error message is output - by EME-PKCS1-v1_5, as ensured by steps 4 and 5. If this is not done, - then an adversary may be able to use information extracted form the - type of error message received to mount a chosen-ciphertext attack - such as the one found in [4]. - -8. Signature schemes with appendix - - A signature scheme with appendix consists of a signature generation - operation and a signature verification operation, where the signature - generation operation produces a signature from a message with a - signer's private key, and the signature verification operation - verifies the signature on the message with the signer's corresponding - public key. To verify a signature constructed with this type of - scheme it is necessary to have the message itself. In this way, - signature schemes with appendix are distinguished from signature - schemes with message recovery, which are not supported in this - document. - - - - -Kaliski & Staddon Informational [Page 18] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - A signature scheme with appendix can be employed in a variety of - applications. For instance, X.509 [6] employs such a scheme to - authenticate the content of a certificate; the signature scheme with - appendix defined here would be a suitable signature algorithm in that - context. A related signature scheme could be employed in PKCS #7 - [21], although for technical reasons, the current version of PKCS #7 - separates a hash function from a signature scheme, which is different - than what is done here. - - One signature scheme with appendix is specified in this document: - RSASSA-PKCS1-v1_5. - - The signature scheme with appendix given here follows a general model - similar to that employed in IEEE P1363, by combining signature and - verification primitives with an encoding method for signatures. The - signature generation operations apply a message encoding operation to - a message to produce an encoded message, which is then converted to - an integer message representative. A signature primitive is then - applied to the message representative to produce the signature. The - signature verification operations apply a signature verification - primitive to the signature to recover a message representative, which - is then converted to an octet string. The message encoding operation - is again applied to the message, and the result is compared to the - recovered octet string. If there is a match, the signature is - considered valid. (Note that this approach assumes that the signature - and verification primitives have the message-recovery form and the - encoding method is deterministic, as is the case for RSASP1/RSAVP1 - and EMSA-PKCS1-v1_5. The signature generation and verification - operations have a different form in P1363 for other primitives and - encoding methods.) - - Editor's note. RSA Laboratories is investigating the possibility of - including a scheme based on the PSS encoding methods specified in - [3], which would be recommended for new applications. - -8.1 RSASSA-PKCS1-v1_5 - - RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the - EME-PKCS1-v1_5 encoding method. It is compatible with the IFSSA - scheme defined in the draft P1363 where the signature and - verification primitives are IFSP-RSA1 and IFVP-RSA1 and the message - encoding method is EMSA-PKCS1-v1_5 (which is not defined in P1363). - The length of messages on which RSASSA-PKCS1-v1_5 can operate is - either unrestricted or constrained by a very large number, depending - on the hash function underlying the message encoding method. - - - - - - -Kaliski & Staddon Informational [Page 19] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Assuming that the hash function in EMSA-PKCS1-v1_5 has appropriate - properties and the key size is sufficiently large, RSASSA-PKCS1-v1_5 - provides secure signatures, meaning that it is computationally - infeasible to generate a signature without knowing the private key, - and computationally infeasible to find a message with a given - signature or two messages with the same signature. Also, in the - encoding method EMSA-PKCS1-v1_5, a hash function identifier is - embedded in the encoding. Because of this feature, an adversary must - invert or find collisions of the particular hash function being used; - attacking a different hash function than the one selected by the - signer is not useful to the adversary. - -8.1.1 Signature generation operation - - RSASSA-PKCS1-V1_5-SIGN (K, M) - Input: - K signer's RSA private ke - M message to be signed, an octet string - - Output: - S signature, an octet string of length k, where k is the - length in octets of the modulus n; "message too long" or - "modulus too short" - Steps: - - 1. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to - the message M to produce an encoded message EM of length k-1 octets: - - EM = EMSA-PKCS1-V1_5-ENCODE (M, k-1) - - If the encoding operation outputs "message too long," then output - "message too long" and stop. If the encoding operation outputs - "intended encoded message length too short" then output "modulus too - short". - - 2. Convert the encoded message EM to an integer message - representative m: m = OS2IP (EM) - - 3. Apply the RSASP1 signature primitive (Section 5.2.1) to the - private key K and the message representative m to produce an integer - signature representative s: s = RSASP1 (K, m) - - 4. Convert the signature representative s to a signature S of length - k octets: S = I2OSP (s, k) - - 5. Output the signature S. - - - - - -Kaliski & Staddon Informational [Page 20] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -8.1.2 Signature verification operation - - RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S) - - Input: - (n, e) signer's RSA public key - M message whose signature is to be verified, an octet string - S signature to be verified, an octet string of length k, - where k is the length in octets of the modulus n - - Output: "valid signature," "invalid signature," or "message too - long", or "modulus too short" - - Steps: - - 1. If the length of the signature S is not k octets, output "invalid - signature" and stop. - - 2. Convert the signature S to an integer signature representative s: - - s = OS2IP (S) - - 3. Apply the RSAVP1 verification primitive (Section 5.2.2) to the - public key (n, e) and the signature representative s to produce an - integer message representative m: - - m = RSAVP1 ((n, e), s) If RSAVP1 outputs "invalid" - then output "invalid signature" and stop. - - 4. Convert the message representative m to an encoded message EM of - length k-1 octets: EM = I2OSP (m, k-1) - - If I2OSP outputs "integer too large," then output "invalid signature" - and stop. - - 5. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to - the message M to produce a second encoded message EM' of length k-1 - octets: - - EM' = EMSA-PKCS1-V1_5-ENCODE (M, k-1) - - If the encoding operation outputs "message too long," then output - "message too long" and stop. If the encoding operation outputs - "intended encoded message length too short" then output "modulus too - short". - - - - - - -Kaliski & Staddon Informational [Page 21] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - 6. Compare the encoded message EM and the second encoded message EM'. - If they are the same, output "valid signature"; otherwise, output - "invalid signature." - -9. Encoding methods - - Encoding methods consist of operations that map between octet string - messages and integer message representatives. - - Two types of encoding method are considered in this document: - encoding methods for encryption, encoding methods for signatures with - appendix. - -9.1 Encoding methods for encryption - - An encoding method for encryption consists of an encoding operation - and a decoding operation. An encoding operation maps a message M to a - message representative EM of a specified length; the decoding - operation maps a message representative EM back to a message. The - encoding and decoding operations are inverses. - - The message representative EM will typically have some structure that - can be verified by the decoding operation; the decoding operation - will output "decoding error" if the structure is not present. The - encoding operation may also introduce some randomness, so that - different applications of the encoding operation to the same message - will produce different representatives. - - Two encoding methods for encryption are employed in the encryption - schemes and are specified here: EME-OAEP and EME-PKCS1-v1_5. - -9.1.1 EME-OAEP - - This encoding method is parameterized by the choice of hash function - and mask generation function. Suggested hash and mask generation - functions are given in Section 10. This encoding method is based on - the method found in [2]. - -9.1.1.1 Encoding operation - - EME-OAEP-ENCODE (M, P, emLen) - - Options: - Hash hash function (hLen denotes the length in octet of the - hash function output) - MGF mask generation function - - - - - -Kaliski & Staddon Informational [Page 22] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Input: - M message to be encoded, an octet string of length at most - emLen-1-2hLen - P encoding parameters, an octet string - emLen intended length in octets of the encoded message, at least - 2hLen+1 - - Output: - EM encoded message, an octet string of length emLen; - "message too long" or "parameter string too long" - - Steps: - - 1. If the length of P is greater than the input limitation for the - hash function (2^61-1 octets for SHA-1) then output "parameter string - too long" and stop. - - 2. If ||M|| > emLen-2hLen-1 then output "message too long" and stop. - - 3. Generate an octet string PS consisting of emLen-||M||-2hLen-1 zero - octets. The length of PS may be 0. - - 4. Let pHash = Hash(P), an octet string of length hLen. - - 5. Concatenate pHash, PS, the message M, and other padding to form a - data block DB as: DB = pHash || PS || 01 || M - - 6. Generate a random octet string seed of length hLen. - - 7. Let dbMask = MGF(seed, emLen-hLen). - - 8. Let maskedDB = DB \xor dbMask. - - 9. Let seedMask = MGF(maskedDB, hLen). - - 10. Let maskedSeed = seed \xor seedMask. - - 11. Let EM = maskedSeed || maskedDB. - - 12. Output EM. - -9.1.1.2 Decoding operation EME-OAEP-DECODE (EM, P) - - Options: - Hash hash function (hLen denotes the length in octet of the hash - function output) - - MGF mask generation function - - - -Kaliski & Staddon Informational [Page 23] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Input: - - EM encoded message, an octet string of length at least 2hLen+1 - P encoding parameters, an octet string - - Output: - M recovered message, an octet string of length at most - ||EM||-1-2hLen; or "decoding error" - - Steps: - - 1. If the length of P is greater than the input limitation for the - hash function (2^61-1 octets for SHA-1) then output "parameter string - too long" and stop. - - 2. If ||EM|| < 2hLen+1, then output "decoding error" and stop. - - 3. Let maskedSeed be the first hLen octets of EM and let maskedDB be - the remaining ||EM|| - hLen octets. - - 4. Let seedMask = MGF(maskedDB, hLen). - - 5. Let seed = maskedSeed \xor seedMask. - - 6. Let dbMask = MGF(seed, ||EM|| - hLen). - - 7. Let DB = maskedDB \xor dbMask. - - 8. Let pHash = Hash(P), an octet string of length hLen. - - 9. Separate DB into an octet string pHash' consisting of the first - hLen octets of DB, a (possibly empty) octet string PS consisting of - consecutive zero octets following pHash', and a message M as: - - DB = pHash' || PS || 01 || M - - If there is no 01 octet to separate PS from M, output "decoding - error" and stop. - - 10. If pHash' does not equal pHash, output "decoding error" and stop. - - 11. Output M. - -9.1.2 EME-PKCS1-v1_5 - - This encoding method is the same as in PKCS #1 v1.5, Section 8: - Encryption Process. - - - - -Kaliski & Staddon Informational [Page 24] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -9.1.2.1 Encoding operation - - EME-PKCS1-V1_5-ENCODE (M, emLen) - - Input: - M message to be encoded, an octet string of length at most - emLen-10 - emLen intended length in octets of the encoded message - - Output: - EM encoded message, an octet string of length emLen; or - "message too long" - - Steps: - - 1. If the length of the message M is greater than emLen - 10 octets, - output "message too long" and stop. - - 2. Generate an octet string PS of length emLen-||M||-2 consisting of - pseudorandomly generated nonzero octets. The length of PS will be at - least 8 octets. - - 3. Concatenate PS, the message M, and other padding to form the - encoded message EM as: - - EM = 02 || PS || 00 || M - - 4. Output EM. - -9.1.2.2 Decoding operation - - EME-PKCS1-V1_5-DECODE (EM) - - Input: - EM encoded message, an octet string of length at least 10 - - Output: - M recovered message, an octet string of length at most - ||EM||-10; or "decoding error" - - Steps: - - 1. If the length of the encoded message EM is less than 10, output - "decoding error" and stop. - - 2. Separate the encoded message EM into an octet string PS consisting - of nonzero octets and a message M as: EM = 02 || PS || 00 || M. - - - - -Kaliski & Staddon Informational [Page 25] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - If the first octet of EM is not 02, or if there is no 00 octet to - separate PS from M, output "decoding error" and stop. - - 3. If the length of PS is less than 8 octets, output "decoding error" - and stop. - - 4. Output M. - -9.2 Encoding methods for signatures with appendix - - An encoding method for signatures with appendix, for the purposes of - this document, consists of an encoding operation. An encoding - operation maps a message M to a message representative EM of a - specified length. (In future versions of this document, encoding - methods may be added that also include a decoding operation.) - - One encoding method for signatures with appendix is employed in the - encryption schemes and is specified here: EMSA-PKCS1-v1_5. - -9.2.1 EMSA-PKCS1-v1_5 - - This encoding method only has an encoding operation. - - EMSA-PKCS1-v1_5-ENCODE (M, emLen) - - Option: - Hash hash function (hLen denotes the length in octet of the hash - function output) - - Input: - M message to be encoded - emLen intended length in octets of the encoded message, at least - ||T|| + 10, where T is the DER encoding of a certain value - computed during the encoding operation - - Output: - EM encoded message, an octet string of length emLen; or "message - too long" or "intended encoded message length too short" - - Steps: - - 1. Apply the hash function to the message M to produce a hash value - H: - - H = Hash(M). - - If the hash function outputs "message too long," then output "message - too long". - - - -Kaliski & Staddon Informational [Page 26] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - 2. Encode the algorithm ID for the hash function and the hash value - into an ASN.1 value of type DigestInfo (see Section 11) with the - Distinguished Encoding Rules (DER), where the type DigestInfo has the - syntax - - DigestInfo::=SEQUENCE{ - digestAlgorithm AlgorithmIdentifier, - digest OCTET STRING } - - The first field identifies the hash function and the second contains - the hash value. Let T be the DER encoding. - - 3. If emLen is less than ||T|| + 10 then output "intended encoded - message length too short". - - 4. Generate an octet string PS consisting of emLen-||T||-2 octets - with value FF (hexadecimal). The length of PS will be at least 8 - octets. - - 5. Concatenate PS, the DER encoding T, and other padding to form the - encoded message EM as: EM = 01 || PS || 00 || T - - 6. Output EM. - -10. Auxiliary Functions - - This section specifies the hash functions and the mask generation - functions that are mentioned in the encoding methods (Section 9). - -10.1 Hash Functions - - Hash functions are used in the operations contained in Sections 7, 8 - and 9. Hash functions are deterministic, meaning that the output is - completely determined by the input. Hash functions take octet strings - of variable length, and generate fixed length octet strings. The hash - functions used in the operations contained in Sections 7, 8 and 9 - should be collision resistant. This means that it is infeasible to - find two distinct inputs to the hash function that produce the same - output. A collision resistant hash function also has the desirable - property of being one-way; this means that given an output, it is - infeasible to find an input whose hash is the specified output. The - property of collision resistance is especially desirable for RSASSA- - PKCS1-v1_5, as it makes it infeasible to forge signatures. In - addition to the requirements, the hash function should yield a mask - generation function (Section 10.2) with pseudorandom output. - - - - - - -Kaliski & Staddon Informational [Page 27] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Three hash functions are recommended for the encoding methods in this - document: MD2 [15], MD5 [17], and SHA-1 [16]. For the EME-OAEP - encoding method, only SHA-1 is recommended. For the EMSA-PKCS1-v1_5 - encoding method, SHA-1 is recommended for new applications. MD2 and - MD5 are recommended only for compatibility with existing applications - based on PKCS #1 v1.5. - - The hash functions themselves are not defined here; readers are - referred to the appropriate references ([15], [17] and [16]). - - Note. Version 1.5 of this document also allowed for the use of MD4 in - signature schemes. The cryptanalysis of MD4 has progressed - significantly in the intervening years. For example, Dobbertin [10] - demonstrated how to find collisions for MD4 and that the first two - rounds of MD4 are not one-way [11]. Because of these results and - others (e.g. [9]), MD4 is no longer recommended. There have also been - advances in the cryptanalysis of MD2 and MD5, although not enough to - warrant removal from existing applications. Rogier and Chauvaud [19] - demonstrated how to find collisions in a modified version of MD2. No - one has demonstrated how to find collisions for the full MD5 - algorithm, although partial results have been found (e.g. [8]). For - new applications, to address these concerns, SHA-1 is preferred. - -10.2 Mask Generation Functions - - A mask generation function takes an octet string of variable length - and a desired output length as input, and outputs an octet string of - the desired length. There may be restrictions on the length of the - input and output octet strings, but such bounds are generally very - large. Mask generation functions are deterministic; the octet string - output is completely determined by the input octet string. The output - of a mask generation function should be pseudorandom, that is, if the - seed to the function is unknown, it should be infeasible to - distinguish the output from a truly random string. The plaintext- - awareness of RSAES-OAEP relies on the random nature of the output of - the mask generation function, which in turn relies on the random - nature of the underlying hash. - - One mask generation function is recommended for the encoding methods - in this document, and is defined here: MGF1, which is based on a hash - function. Future versions of this document may define other mask - generation functions. - -10.2.1 MGF1 - - MGF1 is a Mask Generation Function based on a hash function. - - MGF1 (Z, l) - - - -Kaliski & Staddon Informational [Page 28] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - Options: - Hash hash function (hLen denotes the length in octets of the hash - function output) - - Input: - Z seed from which mask is generated, an octet string - l intended length in octets of the mask, at most 2^32(hLen) - - Output: - mask mask, an octet string of length l; or "mask too long" - - Steps: - - 1.If l > 2^32(hLen), output "mask too long" and stop. - - 2.Let T be the empty octet string. - - 3.For counter from 0 to \lceil{l / hLen}\rceil-1, do the following: - - a.Convert counter to an octet string C of length 4 with the primitive - I2OSP: C = I2OSP (counter, 4) - - b.Concatenate the hash of the seed Z and C to the octet string T: T = - T || Hash (Z || C) - - 4.Output the leading l octets of T as the octet string mask. - -11. ASN.1 syntax - -11.1 Key representation - - This section defines ASN.1 object identifiers for RSA public and - private keys, and defines the types RSAPublicKey and RSAPrivateKey. - The intended application of these definitions includes X.509 - certificates, PKCS #8 [22], and PKCS #12 [23]. - - The object identifier rsaEncryption identifies RSA public and private - keys as defined in Sections 11.1.1 and 11.1.2. The parameters field - associated with this OID in an AlgorithmIdentifier shall have type - NULL. - - rsaEncryption OBJECT IDENTIFIER ::= {pkcs-1 1} - - All of the definitions in this section are the same as in PKCS #1 - v1.5. - - - - - - -Kaliski & Staddon Informational [Page 29] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -11.1.1 Public-key syntax - - An RSA public key should be represented with the ASN.1 type - RSAPublicKey: - - RSAPublicKey::=SEQUENCE{ - modulus INTEGER, -- n - publicExponent INTEGER -- e } - - (This type is specified in X.509 and is retained here for - compatibility.) - - The fields of type RSAPublicKey have the following meanings: - -modulus is the modulus n. - -publicExponent is the public exponent e. - -11.1.2 Private-key syntax - - An RSA private key should be represented with ASN.1 type - RSAPrivateKey: - - RSAPrivateKey ::= SEQUENCE { - version Version, - modulus INTEGER, -- n - publicExponent INTEGER, -- e - privateExponent INTEGER, -- d - prime1 INTEGER, -- p - prime2 INTEGER, -- q - exponent1 INTEGER, -- d mod (p-1) - exponent2 INTEGER, -- d mod (q-1) - coefficient INTEGER -- (inverse of q) mod p } - - Version ::= INTEGER - - The fields of type RSAPrivateKey have the following meanings: - - -version is the version number, for compatibility with future - revisions of this document. It shall be 0 for this version of the - document. - -modulus is the modulus n. - -publicExponent is the public exponent e. - -privateExponent is the private exponent d. - -prime1 is the prime factor p of n. - -prime2 is the prime factor q of n. - -exponent1 is d mod (p-1). - -exponent2 is d mod (q-1). - -coefficient is the Chinese Remainder Theorem coefficient q-1 mod p. - - - - -Kaliski & Staddon Informational [Page 30] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -11.2 Scheme identification - - This section defines object identifiers for the encryption and - signature schemes. The schemes compatible with PKCS #1 v1.5 have the - same definitions as in PKCS #1 v1.5. The intended application of - these definitions includes X.509 certificates and PKCS #7. - -11.2.1 Syntax for RSAES-OAEP - - The object identifier id-RSAES-OAEP identifies the RSAES-OAEP - encryption scheme. - - id-RSAES-OAEP OBJECT IDENTIFIER ::= {pkcs-1 7} - - The parameters field associated with this OID in an - AlgorithmIdentifier shall have type RSAEP-OAEP-params: - - RSAES-OAEP-params ::= SEQUENCE { - hashFunc [0] AlgorithmIdentifier {{oaepDigestAlgorithms}} - DEFAULT sha1Identifier, - maskGenFunc [1] AlgorithmIdentifier {{pkcs1MGFAlgorithms}} - DEFAULT mgf1SHA1Identifier, - pSourceFunc [2] AlgorithmIdentifier - {{pkcs1pSourceAlgorithms}} - DEFAULT pSpecifiedEmptyIdentifier } - - The fields of type RSAES-OAEP-params have the following meanings: - - -hashFunc identifies the hash function. It shall be an algorithm ID - with an OID in the set oaepDigestAlgorithms, which for this version - shall consist of id-sha1, identifying the SHA-1 hash function. The - parameters field for id-sha1 shall have type NULL. - - oaepDigestAlgorithms ALGORITHM-IDENTIFIER ::= { - {NULL IDENTIFIED BY id-sha1} } - - id-sha1 OBJECT IDENTIFIER ::= - {iso(1) identified-organization(3) oiw(14) secsig(3) - algorithms(2) 26} - - - The default hash function is SHA-1: - sha1Identifier ::= AlgorithmIdentifier {id-sha1, NULL} - - -maskGenFunc identifies the mask generation function. It shall be an - algorithm ID with an OID in the set pkcs1MGFAlgorithms, which for - this version shall consist of id-mgf1, identifying the MGF1 mask - generation function (see Section 10.2.1). The parameters field for - - - -Kaliski & Staddon Informational [Page 31] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - id-mgf1 shall have type AlgorithmIdentifier, identifying the hash - function on which MGF1 is based, where the OID for the hash function - shall be in the set oaepDigestAlgorithms. - - pkcs1MGFAlgorithms ALGORITHM-IDENTIFIER ::= { - {AlgorithmIdentifier {{oaepDigestAlgorithms}} IDENTIFIED - BY id-mgf1} } - - id-mgf1 OBJECT IDENTIFIER ::= {pkcs-1 8} - - The default mask generation function is MGF1 with SHA-1: - - mgf1SHA1Identifier ::= AlgorithmIdentifier { - id-mgf1, sha1Identifier } - - -pSourceFunc identifies the source (and possibly the value) of the - encoding parameters P. It shall be an algorithm ID with an OID in the - set pkcs1pSourceAlgorithms, which for this version shall consist of - id-pSpecified, indicating that the encoding parameters are specified - explicitly. The parameters field for id-pSpecified shall have type - OCTET STRING, containing the encoding parameters. - - pkcs1pSourceAlgorithms ALGORITHM-IDENTIFIER ::= { - {OCTET STRING IDENTIFIED BY id-pSpecified} } - - id-pSpecified OBJECT IDENTIFIER ::= {pkcs-1 9} - - The default encoding parameters is an empty string (so that pHash in - EME-OAEP will contain the hash of the empty string): - - pSpecifiedEmptyIdentifier ::= AlgorithmIdentifier { - id-pSpecified, OCTET STRING SIZE (0) } - - If all of the default values of the fields in RSAES-OAEP-params are - used, then the algorithm identifier will have the following value: - - RSAES-OAEP-Default-Identifier ::= AlgorithmIdentifier { - id-RSAES-OAEP, - {sha1Identifier, - mgf1SHA1Identifier, - pSpecifiedEmptyIdentifier } } - -11.2.2 Syntax for RSAES-PKCS1-v1_5 - - The object identifier rsaEncryption (Section 11.1) identifies the - RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated - with this OID in an AlgorithmIdentifier shall have type NULL. This is - the same as in PKCS #1 v1.5. - - - -Kaliski & Staddon Informational [Page 32] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - RsaEncryption OBJECT IDENTIFIER ::= {PKCS-1 1} - -11.2.3 Syntax for RSASSA-PKCS1-v1_5 - - The object identifier for RSASSA-PKCS1-v1_5 shall be one of the - following. The choice of OID depends on the choice of hash algorithm: - MD2, MD5 or SHA-1. Note that if either MD2 or MD5 is used then the - OID is just as in PKCS #1 v1.5. For each OID, the parameters field - associated with this OID in an AlgorithmIdentifier shall have type - NULL. - - If the hash function to be used is MD2, then the OID should be: - - md2WithRSAEncryption ::= {PKCS-1 2} - - If the hash function to be used is MD5, then the OID should be: - - md5WithRSAEncryption ::= {PKCS-1 4} - - If the hash function to be used is SHA-1, then the OID should be: - - sha1WithRSAEncryption ::= {pkcs-1 5} - - In the digestInfo type mentioned in Section 9.2.1 the OIDS for the - digest algorithm are the following: - - id-SHA1 OBJECT IDENTIFIER ::= - {iso(1) identified-organization(3) oiw(14) secsig(3) - algorithms(2) 26 } - - md2 OBJECT IDENTIFIER ::= - {iso(1) member-body(2) US(840) rsadsi(113549) - digestAlgorithm(2) 2} - - md5 OBJECT IDENTIFIER ::= - {iso(1) member-body(2) US(840) rsadsi(113549) - digestAlgorithm(2) 5} - - The parameters field of the digest algorithm has ASN.1 type NULL for - these OIDs. - -12. Patent statement - - The Internet Standards Process as defined in RFC 1310 requires a - written statement from the Patent holder that a license will be made - available to applicants under reasonable terms and conditions prior - to approving a specification as a Proposed, Draft or Internet - Standard. - - - -Kaliski & Staddon Informational [Page 33] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - The Internet Society, Internet Architecture Board, Internet - Engineering Steering Group and the Corporation for National Research - Initiatives take no position on the validity or scope of the - following patents and patent applications, nor on the appropriateness - of the terms of the assurance. The Internet Society and other groups - mentioned above have not made any determination as to any other - intellectual property rights which may apply to the practice of this - standard. Any further consideration of these matters is the user's - responsibility. - -12.1 Patent statement for the RSA algorithm - - The Massachusetts Institute of Technology has granted RSA Data - Security, Inc., exclusive sub-licensing rights to the following - patent issued in the United States: - - Cryptographic Communications System and Method ("RSA"), No. 4,405,829 - - RSA Data Security, Inc. has provided the following statement with - regard to this patent: - - It is RSA's business practice to make licenses to its patents - available on reasonable and nondiscriminatory terms. Accordingly, RSA - is willing, upon request, to grant non-exclusive licenses to such - patent on reasonable and non-discriminatory terms and conditions to - those who respect RSA's intellectual property rights and subject to - RSA's then current royalty rate for the patent licensed. The royalty - rate for the RSA patent is presently set at 2% of the licensee's - selling price for each product covered by the patent. Any requests - for license information may be directed to: - - Director of Licensing - RSA Data Security, Inc. - 2955 Campus Drive - Suite 400 - San Mateo, CA 94403 - - A license under RSA's patent(s) does not include any rights to know- - how or other technical information or license under other - intellectual property rights. Such license does not extend to any - activities which constitute infringement or inducement thereto. A - licensee must make his own determination as to whether a license is - necessary under patents of others. - - - - - - - - -Kaliski & Staddon Informational [Page 34] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -13. Revision history - - Versions 1.0-1.3 - - Versions 1.0-1.3 were distributed to participants in RSA Data - Security, Inc.'s Public-Key Cryptography Standards meetings in - February and March 1991. - - - Version 1.4 - - Version 1.4 was part of the June 3, 1991 initial public release of - PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop - document SEC-SIG-91-18. - - - Version 1.5 - - Version 1.5 incorporates several editorial changes, including updates - to the references and the addition of a revision history. The - following substantive changes were made: -Section 10: "MD4 with RSA" - signature and verification processes were added. - - -Section 11: md4WithRSAEncryption object identifier was added. - - Version 2.0 [DRAFT] - - Version 2.0 incorporates major editorial changes in terms of the - document structure, and introduces the RSAEP-OAEP encryption scheme. - This version continues to support the encryption and signature - processes in version 1.5, although the hash algorithm MD4 is no - longer allowed due to cryptanalytic advances in the intervening - years. - -14. References - - [1] ANSI, ANSI X9.44: Key Management Using Reversible Public Key - Cryptography for the Financial Services Industry. Work in - Progress. - - [2] M. Bellare and P. Rogaway. Optimal Asymmetric Encryption - How to - Encrypt with RSA. In Advances in Cryptology-Eurocrypt '94, pp. - 92-111, Springer-Verlag, 1994. - - [3] M. Bellare and P. Rogaway. The Exact Security of Digital - Signatures - How to Sign with RSA and Rabin. In Advances in - Cryptology-Eurocrypt '96, pp. 399-416, Springer-Verlag, 1996. - - - - -Kaliski & Staddon Informational [Page 35] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - [4] D. Bleichenbacher. Chosen Ciphertext Attacks against Protocols - Based on the RSA Encryption Standard PKCS #1. To appear in - Advances in Cryptology-Crypto '98. - - [5] D. Bleichenbacher, B. Kaliski and J. Staddon. Recent Results on - PKCS #1: RSA Encryption Standard. RSA Laboratories' Bulletin, - Number 7, June 24, 1998. - - [6] CCITT. Recommendation X.509: The Directory-Authentication - Framework. 1988. - - [7] D. Coppersmith, M. Franklin, J. Patarin and M. Reiter. Low- - Exponent RSA with Related Messages. In Advances in Cryptology- - Eurocrypt '96, pp. 1-9, Springer-Verlag, 1996 - - [8] B. Den Boer and Bosselaers. Collisions for the Compression - Function of MD5. In Advances in Cryptology-Eurocrypt '93, pp - 293-304, Springer-Verlag, 1994. - - [9] B. den Boer, and A. Bosselaers. An Attack on the Last Two Rounds - of MD4. In Advances in Cryptology-Crypto '91, pp.194-203, - Springer-Verlag, 1992. - - [10] H. Dobbertin. Cryptanalysis of MD4. Fast Software Encryption. - Lecture Notes in Computer Science, Springer-Verlag 1996, pp. - 55-72. - - [11] H. Dobbertin. Cryptanalysis of MD5 Compress. Presented at the - rump session of Eurocrypt `96, May 14, 1996 - - [12] H. Dobbertin.The First Two Rounds of MD4 are Not One-Way. Fast - Software Encryption. Lecture Notes in Computer Science, - Springer-Verlag 1998, pp. 284-292. - - [13] J. Hastad. Solving Simultaneous Modular Equations of Low Degree. - SIAM Journal of Computing, 17, 1988, pp. 336-341. - - [14] IEEE. IEEE P1363: Standard Specifications for Public Key - Cryptography. Draft Version 4. - - [15] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April - 1992. - - [16] National Institute of Standards and Technology (NIST). FIPS - Publication 180-1: Secure Hash Standard. April 1994. - - [17] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - - - -Kaliski & Staddon Informational [Page 36] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - - [18] R. Rivest, A. Shamir and L. Adleman. A Method for Obtaining - Digital Signatures and Public-Key Cryptosystems. Communications - of the ACM, 21(2), pp. 120-126, February 1978. - - [19] N. Rogier and P. Chauvaud. The Compression Function of MD2 is - not Collision Free. Presented at Selected Areas of Cryptography - `95. Carleton University, Ottawa, Canada. May 18-19, 1995. - - [20] RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 1.5, - November 1993. - - [21] RSA Laboratories. PKCS #7: Cryptographic Message Syntax - Standard. Version 1.5, November 1993. - - [22] RSA Laboratories. PKCS #8: Private-Key Information Syntax - Standard. Version 1.2, November 1993. - - [23] RSA Laboratories. PKCS #12: Personal Information Exchange Syntax - Standard. Version 1.0, Work in Progress, April 1997. - -Security Considerations - - Security issues are discussed throughout this memo. - -Acknowledgements - - This document is based on a contribution of RSA Laboratories, a - division of RSA Data Security, Inc. Any substantial use of the text - from this document must acknowledge RSA Data Security, Inc. RSA Data - Security, Inc. requests that all material mentioning or referencing - this document identify this as "RSA Data Security, Inc. PKCS #1 - v2.0". - - - - - - - - - - - - - - - - - - - -Kaliski & Staddon Informational [Page 37] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -Authors' Addresses - - Burt Kaliski - RSA Laboratories East - 20 Crosby Drive - Bedford, MA 01730 - - Phone: (617) 687-7000 - EMail: burt@rsa.com - - - Jessica Staddon - RSA Laboratories West - 2955 Campus Drive - Suite 400 - San Mateo, CA 94403 - - Phone: (650) 295-7600 - EMail: jstaddon@rsa.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kaliski & Staddon Informational [Page 38] - -RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - - - - - - - - - - - - - - - - - - - - - - - - -Kaliski & Staddon Informational [Page 39] - diff --git a/doc/ikev2/[RFC3280] - x509 Certificates.txt b/doc/ikev2/[RFC3280] - x509 Certificates.txt deleted file mode 100644 index 433908bb7..000000000 --- a/doc/ikev2/[RFC3280] - x509 Certificates.txt +++ /dev/null @@ -1,7227 +0,0 @@ - - - - - - -Network Working Group R. Housley -Request for Comments: 3280 RSA Laboratories -Obsoletes: 2459 W. Polk -Category: Standards Track NIST - W. Ford - VeriSign - D. Solo - Citigroup - April 2002 - - Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile - -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 Internet Society (2002). All Rights Reserved. - -Abstract - - This memo profiles the X.509 v3 certificate and X.509 v2 Certificate - Revocation List (CRL) for use in the Internet. An overview of this - approach and model are provided as an introduction. The X.509 v3 - certificate format is described in detail, with additional - information regarding the format and semantics of Internet name - forms. Standard certificate extensions are described and two - Internet-specific extensions are defined. A set of required - certificate extensions is specified. The X.509 v2 CRL format is - described in detail, and required extensions are defined. An - algorithm for X.509 certification path validation is described. An - ASN.1 module and examples are provided in the appendices. - -Table of Contents - - 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4 - 2 Requirements and Assumptions . . . . . . . . . . . . . . 5 - 2.1 Communication and Topology . . . . . . . . . . . . . . 6 - 2.2 Acceptability Criteria . . . . . . . . . . . . . . . . 6 - 2.3 User Expectations . . . . . . . . . . . . . . . . . . . 7 - 2.4 Administrator Expectations . . . . . . . . . . . . . . 7 - 3 Overview of Approach . . . . . . . . . . . . . . . . . . 7 - - - -Housley, et. al. Standards Track [Page 1] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - 3.1 X.509 Version 3 Certificate . . . . . . . . . . . . . . 8 - 3.2 Certification Paths and Trust . . . . . . . . . . . . . 9 - 3.3 Revocation . . . . . . . . . . . . . . . . . . . . . . 11 - 3.4 Operational Protocols . . . . . . . . . . . . . . . . . 13 - 3.5 Management Protocols . . . . . . . . . . . . . . . . . 13 - 4 Certificate and Certificate Extensions Profile . . . . . 14 - 4.1 Basic Certificate Fields . . . . . . . . . . . . . . . 15 - 4.1.1 Certificate Fields . . . . . . . . . . . . . . . . . 16 - 4.1.1.1 tbsCertificate . . . . . . . . . . . . . . . . . . 16 - 4.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 16 - 4.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 16 - 4.1.2 TBSCertificate . . . . . . . . . . . . . . . . . . . 17 - 4.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 17 - 4.1.2.2 Serial number . . . . . . . . . . . . . . . . . . . 17 - 4.1.2.3 Signature . . . . . . . . . . . . . . . . . . . . . 18 - 4.1.2.4 Issuer . . . . . . . . . . . . . . . . . . . . . . 18 - 4.1.2.5 Validity . . . . . . . . . . . . . . . . . . . . . 22 - 4.1.2.5.1 UTCTime . . . . . . . . . . . . . . . . . . . . . 22 - 4.1.2.5.2 GeneralizedTime . . . . . . . . . . . . . . . . . 22 - 4.1.2.6 Subject . . . . . . . . . . . . . . . . . . . . . . 23 - 4.1.2.7 Subject Public Key Info . . . . . . . . . . . . . . 24 - 4.1.2.8 Unique Identifiers . . . . . . . . . . . . . . . . 24 - 4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . . 24 - 4.2 Certificate Extensions . . . . . . . . . . . . . . . . 24 - 4.2.1 Standard Extensions . . . . . . . . . . . . . . . . . 25 - 4.2.1.1 Authority Key Identifier . . . . . . . . . . . . . 26 - 4.2.1.2 Subject Key Identifier . . . . . . . . . . . . . . 27 - 4.2.1.3 Key Usage . . . . . . . . . . . . . . . . . . . . . 28 - 4.2.1.4 Private Key Usage Period . . . . . . . . . . . . . 29 - 4.2.1.5 Certificate Policies . . . . . . . . . . . . . . . 30 - 4.2.1.6 Policy Mappings . . . . . . . . . . . . . . . . . . 33 - 4.2.1.7 Subject Alternative Name . . . . . . . . . . . . . 33 - 4.2.1.8 Issuer Alternative Name . . . . . . . . . . . . . . 36 - 4.2.1.9 Subject Directory Attributes . . . . . . . . . . . 36 - 4.2.1.10 Basic Constraints . . . . . . . . . . . . . . . . 36 - 4.2.1.11 Name Constraints . . . . . . . . . . . . . . . . . 37 - 4.2.1.12 Policy Constraints . . . . . . . . . . . . . . . . 40 - 4.2.1.13 Extended Key Usage . . . . . . . . . . . . . . . . 40 - 4.2.1.14 CRL Distribution Points . . . . . . . . . . . . . 42 - 4.2.1.15 Inhibit Any-Policy . . . . . . . . . . . . . . . . 44 - 4.2.1.16 Freshest CRL . . . . . . . . . . . . . . . . . . . 44 - 4.2.2 Internet Certificate Extensions . . . . . . . . . . . 45 - 4.2.2.1 Authority Information Access . . . . . . . . . . . 45 - 4.2.2.2 Subject Information Access . . . . . . . . . . . . 46 - 5 CRL and CRL Extensions Profile . . . . . . . . . . . . . 48 - 5.1 CRL Fields . . . . . . . . . . . . . . . . . . . . . . 49 - 5.1.1 CertificateList Fields . . . . . . . . . . . . . . . 50 - 5.1.1.1 tbsCertList . . . . . . . . . . . . . . . . . . . . 50 - - - -Housley, et. al. Standards Track [Page 2] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - 5.1.1.2 signatureAlgorithm . . . . . . . . . . . . . . . . 50 - 5.1.1.3 signatureValue . . . . . . . . . . . . . . . . . . 51 - 5.1.2 Certificate List "To Be Signed" . . . . . . . . . . . 51 - 5.1.2.1 Version . . . . . . . . . . . . . . . . . . . . . . 52 - 5.1.2.2 Signature . . . . . . . . . . . . . . . . . . . . . 52 - 5.1.2.3 Issuer Name . . . . . . . . . . . . . . . . . . . . 52 - 5.1.2.4 This Update . . . . . . . . . . . . . . . . . . . . 52 - 5.1.2.5 Next Update . . . . . . . . . . . . . . . . . . . . 53 - 5.1.2.6 Revoked Certificates . . . . . . . . . . . . . . . 53 - 5.1.2.7 Extensions . . . . . . . . . . . . . . . . . . . . 53 - 5.2 CRL Extensions . . . . . . . . . . . . . . . . . . . . 53 - 5.2.1 Authority Key Identifier . . . . . . . . . . . . . . 54 - 5.2.2 Issuer Alternative Name . . . . . . . . . . . . . . . 54 - 5.2.3 CRL Number . . . . . . . . . . . . . . . . . . . . . 55 - 5.2.4 Delta CRL Indicator . . . . . . . . . . . . . . . . . 55 - 5.2.5 Issuing Distribution Point . . . . . . . . . . . . . 58 - 5.2.6 Freshest CRL . . . . . . . . . . . . . . . . . . . . 59 - 5.3 CRL Entry Extensions . . . . . . . . . . . . . . . . . 60 - 5.3.1 Reason Code . . . . . . . . . . . . . . . . . . . . . 60 - 5.3.2 Hold Instruction Code . . . . . . . . . . . . . . . . 61 - 5.3.3 Invalidity Date . . . . . . . . . . . . . . . . . . . 62 - 5.3.4 Certificate Issuer . . . . . . . . . . . . . . . . . 62 - 6 Certificate Path Validation . . . . . . . . . . . . . . . 62 - 6.1 Basic Path Validation . . . . . . . . . . . . . . . . . 63 - 6.1.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 66 - 6.1.2 Initialization . . . . . . . . . . . . . . . . . . . 67 - 6.1.3 Basic Certificate Processing . . . . . . . . . . . . 70 - 6.1.4 Preparation for Certificate i+1 . . . . . . . . . . . 75 - 6.1.5 Wrap-up procedure . . . . . . . . . . . . . . . . . . 78 - 6.1.6 Outputs . . . . . . . . . . . . . . . . . . . . . . . 80 - 6.2 Extending Path Validation . . . . . . . . . . . . . . . 80 - 6.3 CRL Validation . . . . . . . . . . . . . . . . . . . . 81 - 6.3.1 Revocation Inputs . . . . . . . . . . . . . . . . . . 82 - 6.3.2 Initialization and Revocation State Variables . . . . 82 - 6.3.3 CRL Processing . . . . . . . . . . . . . . . . . . . 83 - 7 References . . . . . . . . . . . . . . . . . . . . . . . 86 - 8 Intellectual Property Rights . . . . . . . . . . . . . . 88 - 9 Security Considerations . . . . . . . . . . . . . . . . . 89 - Appendix A. ASN.1 Structures and OIDs . . . . . . . . . . . 92 - A.1 Explicitly Tagged Module, 1988 Syntax . . . . . . . . . 92 - A.2 Implicitly Tagged Module, 1988 Syntax . . . . . . . . . 105 - Appendix B. ASN.1 Notes . . . . . . . . . . . . . . . . . . 112 - Appendix C. Examples . . . . . . . . . . . . . . . . . . . 115 - C.1 DSA Self-Signed Certificate . . . . . . . . . . . . . . 115 - C.2 End Entity Certificate Using DSA . . . . . . . . . . . 119 - C.3 End Entity Certificate Using RSA . . . . . . . . . . . 122 - C.4 Certificate Revocation List . . . . . . . . . . . . . . 126 - Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128 - - - -Housley, et. al. Standards Track [Page 3] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Full Copyright Statement . . . . . . . . . . . . . . . . . . 129 - -1 Introduction - - This specification is one part of a family of standards for the X.509 - Public Key Infrastructure (PKI) for the Internet. - - This specification profiles the format and semantics of certificates - and certificate revocation lists (CRLs) for the Internet PKI. - Procedures are described for processing of certification paths in the - Internet environment. Finally, ASN.1 modules are provided in the - appendices for all data structures defined or referenced. - - Section 2 describes Internet PKI requirements, and the assumptions - which affect the scope of this document. Section 3 presents an - architectural model and describes its relationship to previous IETF - and ISO/IEC/ITU-T standards. In particular, this document's - relationship with the IETF PEM specifications and the ISO/IEC/ITU-T - X.509 documents are described. - - Section 4 profiles the X.509 version 3 certificate, and section 5 - profiles the X.509 version 2 CRL. The profiles include the - identification of ISO/IEC/ITU-T and ANSI extensions which may be - useful in the Internet PKI. The profiles are presented in the 1988 - Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 - syntax used in the most recent ISO/IEC/ITU-T standards. - - Section 6 includes certification path validation procedures. These - procedures are based upon the ISO/IEC/ITU-T definition. - Implementations are REQUIRED to derive the same results but are not - required to use the specified procedures. - - Procedures for identification and encoding of public key materials - and digital signatures are defined in [PKIXALGS]. Implementations of - this specification are not required to use any particular - cryptographic algorithms. However, conforming implementations which - use the algorithms identified in [PKIXALGS] MUST identify and encode - the public key materials and digital signatures as described in that - specification. - - Finally, three appendices are provided to aid implementers. Appendix - A contains all ASN.1 structures defined or referenced within this - specification. As above, the material is presented in the 1988 - ASN.1. Appendix B contains notes on less familiar features of the - ASN.1 notation used within this specification. Appendix C contains - examples of a conforming certificate and a conforming CRL. - - - - - -Housley, et. al. Standards Track [Page 4] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - This specification obsoletes RFC 2459. This specification differs - from RFC 2459 in five basic areas: - - * To promote interoperable implementations, a detailed algorithm - for certification path validation is included in section 6.1 of - this specification; RFC 2459 provided only a high-level - description of path validation. - - * An algorithm for determining the status of a certificate using - CRLs is provided in section 6.3 of this specification. This - material was not present in RFC 2459. - - * To accommodate new usage models, detailed information describing - the use of delta CRLs is provided in Section 5 of this - specification. - - * Identification and encoding of public key materials and digital - signatures are not included in this specification, but are now - described in a companion specification [PKIXALGS]. - - * Four additional extensions are specified: three certificate - extensions and one CRL extension. The certificate extensions are - subject info access, inhibit any-policy, and freshest CRL. The - freshest CRL extension is also defined as a CRL extension. - - * Throughout the specification, clarifications have been - introduced to enhance consistency with the ITU-T X.509 - specification. X.509 defines the certificate and CRL format as - well as many of the extensions that appear in this specification. - These changes were introduced to improve the likelihood of - interoperability between implementations based on this - specification with implementations based on the ITU-T - specification. - - 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. - -2 Requirements and Assumptions - - The goal of this specification is to develop a profile to facilitate - the use of X.509 certificates within Internet applications for those - communities wishing to make use of X.509 technology. Such - applications may include WWW, electronic mail, user authentication, - and IPsec. In order to relieve some of the obstacles to using X.509 - - - - - - -Housley, et. al. Standards Track [Page 5] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - certificates, this document defines a profile to promote the - development of certificate management systems; development of - application tools; and interoperability determined by policy. - - Some communities will need to supplement, or possibly replace, this - profile in order to meet the requirements of specialized application - domains or environments with additional authorization, assurance, or - operational requirements. However, for basic applications, common - representations of frequently used attributes are defined so that - application developers can obtain necessary information without - regard to the issuer of a particular certificate or certificate - revocation list (CRL). - - A certificate user should review the certificate policy generated by - the certification authority (CA) before relying on the authentication - or non-repudiation services associated with the public key in a - particular certificate. To this end, this standard does not - prescribe legally binding rules or duties. - - As supplemental authorization and attribute management tools emerge, - such as attribute certificates, it may be appropriate to limit the - authenticated attributes that are included in a certificate. These - other management tools may provide more appropriate methods of - conveying many authenticated attributes. - -2.1 Communication and Topology - - The users of certificates will operate in a wide range of - environments with respect to their communication topology, especially - users of secure electronic mail. This profile supports users without - high bandwidth, real-time IP connectivity, or high connection - availability. In addition, the profile allows for the presence of - firewall or other filtered communication. - - This profile does not assume the deployment of an X.500 Directory - system or a LDAP directory system. The profile does not prohibit the - use of an X.500 Directory or a LDAP directory; however, any means of - distributing certificates and certificate revocation lists (CRLs) may - be used. - -2.2 Acceptability Criteria - - The goal of the Internet Public Key Infrastructure (PKI) is to meet - the needs of deterministic, automated identification, authentication, - access control, and authorization functions. Support for these - services determines the attributes contained in the certificate as - well as the ancillary control information in the certificate such as - policy data and certification path constraints. - - - -Housley, et. al. Standards Track [Page 6] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -2.3 User Expectations - - Users of the Internet PKI are people and processes who use client - software and are the subjects named in certificates. These uses - include readers and writers of electronic mail, the clients for WWW - browsers, WWW servers, and the key manager for IPsec within a router. - This profile recognizes the limitations of the platforms these users - employ and the limitations in sophistication and attentiveness of the - users themselves. This manifests itself in minimal user - configuration responsibility (e.g., trusted CA keys, rules), explicit - platform usage constraints within the certificate, certification path - constraints which shield the user from many malicious actions, and - applications which sensibly automate validation functions. - -2.4 Administrator Expectations - - As with user expectations, the Internet PKI profile is structured to - support the individuals who generally operate CAs. Providing - administrators with unbounded choices increases the chances that a - subtle CA administrator mistake will result in broad compromise. - Also, unbounded choices greatly complicate the software that process - and validate the certificates created by the CA. - -3 Overview of Approach - - Following is a simplified view of the architectural model assumed by - the PKIX specifications. - - The components in this model are: - - end entity: user of PKI certificates and/or end user system that is - the subject of a certificate; - CA: certification authority; - RA: registration authority, i.e., an optional system to which - a CA delegates certain management functions; - CRL issuer: an optional system to which a CA delegates the - publication of certificate revocation lists; - repository: a system or collection of distributed systems that stores - certificates and CRLs and serves as a means of - distributing these certificates and CRLs to end entities. - - Note that an Attribute Authority (AA) might also choose to delegate - the publication of CRLs to a CRL issuer. - - - - - - - - -Housley, et. al. Standards Track [Page 7] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +---+ - | C | +------------+ - | e | <-------------------->| End entity | - | r | Operational +------------+ - | t | transactions ^ - | i | and management | Management - | f | transactions | transactions PKI - | i | | users - | c | v - | a | ======================= +--+------------+ ============== - | t | ^ ^ - | e | | | PKI - | | v | management - | & | +------+ | entities - | | <---------------------| RA |<----+ | - | C | Publish certificate +------+ | | - | R | | | - | L | | | - | | v v - | R | +------------+ - | e | <------------------------------| CA | - | p | Publish certificate +------------+ - | o | Publish CRL ^ ^ - | s | | | Management - | i | +------------+ | | transactions - | t | <--------------| CRL Issuer |<----+ | - | o | Publish CRL +------------+ v - | r | +------+ - | y | | CA | - +---+ +------+ - - Figure 1 - PKI Entities - -3.1 X.509 Version 3 Certificate - - Users of a public key require confidence that the associated private - key is owned by the correct remote subject (person or system) with - which an encryption or digital signature mechanism will be used. - This confidence is obtained through the use of public key - certificates, which are data structures that bind public key values - to subjects. The binding is asserted by having a trusted CA - digitally sign each certificate. The CA may base this assertion upon - technical means (a.k.a., proof of possession through a challenge- - response protocol), presentation of the private key, or on an - assertion by the subject. A certificate has a limited valid lifetime - which is indicated in its signed contents. Because a certificate's - signature and timeliness can be independently checked by a - certificate-using client, certificates can be distributed via - - - -Housley, et. al. Standards Track [Page 8] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - untrusted communications and server systems, and can be cached in - unsecured storage in certificate-using systems. - - ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first - published in 1988 as part of the X.500 Directory recommendations, - defines a standard certificate format [X.509]. The certificate - format in the 1988 standard is called the version 1 (v1) format. - When X.500 was revised in 1993, two more fields were added, resulting - in the version 2 (v2) format. - - The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, - include specifications for a public key infrastructure based on X.509 - v1 certificates [RFC 1422]. The experience gained in attempts to - deploy RFC 1422 made it clear that the v1 and v2 certificate formats - are deficient in several respects. Most importantly, more fields - were needed to carry information which PEM design and implementation - experience had proven necessary. In response to these new - requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version - 3 (v3) certificate format. The v3 format extends the v2 format by - adding provision for additional extension fields. Particular - extension field types may be specified in standards or may be defined - and registered by any organization or community. In June 1996, - standardization of the basic v3 format was completed [X.509]. - - ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions - for use in the v3 extensions field [X.509][X9.55]. These extensions - can convey such data as additional subject identification - information, key attribute information, policy information, and - certification path constraints. - - However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very - broad in their applicability. In order to develop interoperable - implementations of X.509 v3 systems for Internet use, it is necessary - to specify a profile for use of the X.509 v3 extensions tailored for - the Internet. It is one goal of this document to specify a profile - for Internet WWW, electronic mail, and IPsec applications. - Environments with additional requirements may build on this profile - or may replace it. - -3.2 Certification Paths and Trust - - A user of a security service requiring knowledge of a public key - generally needs to obtain and validate a certificate containing the - required public key. If the public key user does not already hold an - assured copy of the public key of the CA that signed the certificate, - the CA's name, and related information (such as the validity period - or name constraints), then it might need an additional certificate to - obtain that public key. In general, a chain of multiple certificates - - - -Housley, et. al. Standards Track [Page 9] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - may be needed, comprising a certificate of the public key owner (the - end entity) signed by one CA, and zero or more additional - certificates of CAs signed by other CAs. Such chains, called - certification paths, are required because a public key user is only - initialized with a limited number of assured CA public keys. - - There are different ways in which CAs might be configured in order - for public key users to be able to find certification paths. For - PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There - are three types of PEM certification authority: - - (a) Internet Policy Registration Authority (IPRA): This - authority, operated under the auspices of the Internet Society, - acts as the root of the PEM certification hierarchy at level 1. - It issues certificates only for the next level of authorities, - PCAs. All certification paths start with the IPRA. - - (b) Policy Certification Authorities (PCAs): PCAs are at level 2 - of the hierarchy, each PCA being certified by the IPRA. A PCA - shall establish and publish a statement of its policy with respect - to certifying users or subordinate certification authorities. - Distinct PCAs aim to satisfy different user needs. For example, - one PCA (an organizational PCA) might support the general - electronic mail needs of commercial organizations, and another PCA - (a high-assurance PCA) might have a more stringent policy designed - for satisfying legally binding digital signature requirements. - - (c) Certification Authorities (CAs): CAs are at level 3 of the - hierarchy and can also be at lower levels. Those at level 3 are - certified by PCAs. CAs represent, for example, particular - organizations, particular organizational units (e.g., departments, - groups, sections), or particular geographical areas. - - RFC 1422 furthermore has a name subordination rule which requires - that a CA can only issue certificates for entities whose names are - subordinate (in the X.500 naming tree) to the name of the CA itself. - The trust associated with a PEM certification path is implied by the - PCA name. The name subordination rule ensures that CAs below the PCA - are sensibly constrained as to the set of subordinate entities they - can certify (e.g., a CA for an organization can only certify entities - in that organization's name tree). Certificate user systems are able - to mechanically check that the name subordination rule has been - followed. - - The RFC 1422 uses the X.509 v1 certificate formats. The limitations - of X.509 v1 required imposition of several structural restrictions to - clearly associate policy information or restrict the utility of - certificates. These restrictions included: - - - -Housley, et. al. Standards Track [Page 10] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (a) a pure top-down hierarchy, with all certification paths - starting from IPRA; - - (b) a naming subordination rule restricting the names of a CA's - subjects; and - - (c) use of the PCA concept, which requires knowledge of - individual PCAs to be built into certificate chain verification - logic. Knowledge of individual PCAs was required to determine if - a chain could be accepted. - - With X.509 v3, most of the requirements addressed by RFC 1422 can be - addressed using certificate extensions, without a need to restrict - the CA structures used. In particular, the certificate extensions - relating to certificate policies obviate the need for PCAs and the - constraint extensions obviate the need for the name subordination - rule. As a result, this document supports a more flexible - architecture, including: - - (a) Certification paths start with a public key of a CA in a - user's own domain, or with the public key of the top of a - hierarchy. Starting with the public key of a CA in a user's own - domain has certain advantages. In some environments, the local - domain is the most trusted. - - (b) Name constraints may be imposed through explicit inclusion of - a name constraints extension in a certificate, but are not - required. - - (c) Policy extensions and policy mappings replace the PCA - concept, which permits a greater degree of automation. The - application can determine if the certification path is acceptable - based on the contents of the certificates instead of a priori - knowledge of PCAs. This permits automation of certification path - processing. - -3.3 Revocation - - When a certificate is issued, it is expected to be in use for its - entire validity period. However, various circumstances may cause a - certificate to become invalid prior to the expiration of the validity - period. Such circumstances include change of name, change of - association between subject and CA (e.g., an employee terminates - employment with an organization), and compromise or suspected - compromise of the corresponding private key. Under such - circumstances, the CA needs to revoke the certificate. - - - - - -Housley, et. al. Standards Track [Page 11] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - X.509 defines one method of certificate revocation. This method - involves each CA periodically issuing a signed data structure called - a certificate revocation list (CRL). A CRL is a time stamped list - identifying revoked certificates which is signed by a CA or CRL - issuer and made freely available in a public repository. Each - revoked certificate is identified in a CRL by its certificate serial - number. When a certificate-using system uses a certificate (e.g., - for verifying a remote user's digital signature), that system not - only checks the certificate signature and validity but also acquires - a suitably-recent CRL and checks that the certificate serial number - is not on that CRL. The meaning of "suitably-recent" may vary with - local policy, but it usually means the most recently-issued CRL. A - new CRL is issued on a regular periodic basis (e.g., hourly, daily, - or weekly). An entry is added to the CRL as part of the next update - following notification of revocation. An entry MUST NOT be removed - from the CRL until it appears on one regularly scheduled CRL issued - beyond the revoked certificate's validity period. - - An advantage of this revocation method is that CRLs may be - distributed by exactly the same means as certificates themselves, - namely, via untrusted servers and untrusted communications. - - One limitation of the CRL revocation method, using untrusted - communications and servers, is that the time granularity of - revocation is limited to the CRL issue period. For example, if a - revocation is reported now, that revocation will not be reliably - notified to certificate-using systems until all currently issued CRLs - are updated -- this may be up to one hour, one day, or one week - depending on the frequency that CRLs are issued. - - As with the X.509 v3 certificate format, in order to facilitate - interoperable implementations from multiple vendors, the X.509 v2 CRL - format needs to be profiled for Internet use. It is one goal of this - document to specify that profile. However, this profile does not - require the issuance of CRLs. Message formats and protocols - supporting on-line revocation notification are defined in other PKIX - specifications. On-line methods of revocation notification may be - applicable in some environments as an alternative to the X.509 CRL. - On-line revocation checking may significantly reduce the latency - between a revocation report and the distribution of the information - to relying parties. Once the CA accepts a revocation report as - authentic and valid, any query to the on-line service will correctly - reflect the certificate validation impacts of the revocation. - However, these methods impose new security requirements: the - certificate validator needs to trust the on-line validation service - while the repository does not need to be trusted. - - - - - -Housley, et. al. Standards Track [Page 12] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -3.4 Operational Protocols - - Operational protocols are required to deliver certificates and CRLs - (or status information) to certificate using client systems. - Provisions are needed for a variety of different means of certificate - and CRL delivery, including distribution procedures based on LDAP, - HTTP, FTP, and X.500. Operational protocols supporting these - functions are defined in other PKIX specifications. These - specifications may include definitions of message formats and - procedures for supporting all of the above operational environments, - including definitions of or references to appropriate MIME content - types. - -3.5 Management Protocols - - Management protocols are required to support on-line interactions - between PKI user and management entities. For example, a management - protocol might be used between a CA and a client system with which a - key pair is associated, or between two CAs which cross-certify each - other. The set of functions which potentially need to be supported - by management protocols include: - - (a) registration: This is the process whereby a user first makes - itself known to a CA (directly, or through an RA), prior to that - CA issuing a certificate or certificates for that user. - - (b) initialization: Before a client system can operate securely - it is necessary to install key materials which have the - appropriate relationship with keys stored elsewhere in the - infrastructure. For example, the client needs to be securely - initialized with the public key and other assured information of - the trusted CA(s), to be used in validating certificate paths. - - Furthermore, a client typically needs to be initialized with its - own key pair(s). - - (c) certification: This is the process in which a CA issues a - certificate for a user's public key, and returns that certificate - to the user's client system and/or posts that certificate in a - repository. - - (d) key pair recovery: As an option, user client key materials - (e.g., a user's private key used for encryption purposes) may be - backed up by a CA or a key backup system. If a user needs to - recover these backed up key materials (e.g., as a result of a - forgotten password or a lost key chain file), an on-line protocol - exchange may be needed to support such recovery. - - - - -Housley, et. al. Standards Track [Page 13] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (e) key pair update: All key pairs need to be updated regularly, - i.e., replaced with a new key pair, and new certificates issued. - - (f) revocation request: An authorized person advises a CA of an - abnormal situation requiring certificate revocation. - - (g) cross-certification: Two CAs exchange information used in - establishing a cross-certificate. A cross-certificate is a - certificate issued by one CA to another CA which contains a CA - signature key used for issuing certificates. - - Note that on-line protocols are not the only way of implementing the - above functions. For all functions there are off-line methods of - achieving the same result, and this specification does not mandate - use of on-line protocols. For example, when hardware tokens are - used, many of the functions may be achieved as part of the physical - token delivery. Furthermore, some of the above functions may be - combined into one protocol exchange. In particular, two or more of - the registration, initialization, and certification functions can be - combined into one protocol exchange. - - The PKIX series of specifications defines a set of standard message - formats supporting the above functions. The protocols for conveying - these messages in different environments (e.g., e-mail, file - transfer, and WWW) are described in those specifications. - -4 Certificate and Certificate Extensions Profile - - This section presents a profile for public key certificates that will - foster interoperability and a reusable PKI. This section is based - upon the X.509 v3 certificate format and the standard certificate - extensions defined in [X.509]. The ISO/IEC and ITU-T documents use - the 1997 version of ASN.1; while this document uses the 1988 ASN.1 - syntax, the encoded certificate and standard extensions are - equivalent. This section also defines private extensions required to - support a PKI for the Internet community. - - Certificates may be used in a wide range of applications and - environments covering a broad spectrum of interoperability goals and - a broader spectrum of operational and assurance requirements. The - goal of this document is to establish a common baseline for generic - applications requiring broad interoperability and limited special - purpose requirements. In particular, the emphasis will be on - supporting the use of X.509 v3 certificates for informal Internet - electronic mail, IPsec, and WWW applications. - - - - - - -Housley, et. al. Standards Track [Page 14] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.1 Basic Certificate Fields - - The X.509 v3 certificate basic syntax is as follows. For signature - calculation, the data that is to be signed is encoded using the ASN.1 - distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a - tag, length, value encoding system for each element. - - Certificate ::= SEQUENCE { - tbsCertificate TBSCertificate, - signatureAlgorithm AlgorithmIdentifier, - signatureValue BIT STRING } - - TBSCertificate ::= SEQUENCE { - version [0] EXPLICIT Version DEFAULT v1, - serialNumber CertificateSerialNumber, - signature AlgorithmIdentifier, - issuer Name, - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo, - issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - extensions [3] EXPLICIT Extensions OPTIONAL - -- If present, version MUST be v3 - } - - Version ::= INTEGER { v1(0), v2(1), v3(2) } - - CertificateSerialNumber ::= INTEGER - - Validity ::= SEQUENCE { - notBefore Time, - notAfter Time } - - Time ::= CHOICE { - utcTime UTCTime, - generalTime GeneralizedTime } - - UniqueIdentifier ::= BIT STRING - - SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING } - - Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension - - - - -Housley, et. al. Standards Track [Page 15] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Extension ::= SEQUENCE { - extnID OBJECT IDENTIFIER, - critical BOOLEAN DEFAULT FALSE, - extnValue OCTET STRING } - - The following items describe the X.509 v3 certificate for use in the - Internet. - -4.1.1 Certificate Fields - - The Certificate is a SEQUENCE of three required fields. The fields - are described in detail in the following subsections. - -4.1.1.1 tbsCertificate - - The field contains the names of the subject and issuer, a public key - associated with the subject, a validity period, and other associated - information. The fields are described in detail in section 4.1.2; - the tbsCertificate usually includes extensions which are described in - section 4.2. - -4.1.1.2 signatureAlgorithm - - The signatureAlgorithm field contains the identifier for the - cryptographic algorithm used by the CA to sign this certificate. - [PKIXALGS] lists supported signature algorithms, but other signature - algorithms MAY also be supported. - - An algorithm identifier is defined by the following ASN.1 structure: - - AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL } - - The algorithm identifier is used to identify a cryptographic - algorithm. The OBJECT IDENTIFIER component identifies the algorithm - (such as DSA with SHA-1). The contents of the optional parameters - field will vary according to the algorithm identified. - - This field MUST contain the same algorithm identifier as the - signature field in the sequence tbsCertificate (section 4.1.2.3). - -4.1.1.3 signatureValue - - The signatureValue field contains a digital signature computed upon - the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded - tbsCertificate is used as the input to the signature function. This - - - - -Housley, et. al. Standards Track [Page 16] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - signature value is encoded as a BIT STRING and included in the - signature field. The details of this process are specified for each - of algorithms listed in [PKIXALGS]. - - By generating this signature, a CA certifies the validity of the - information in the tbsCertificate field. In particular, the CA - certifies the binding between the public key material and the subject - of the certificate. - -4.1.2 TBSCertificate - - The sequence TBSCertificate contains information associated with the - subject of the certificate and the CA who issued it. Every - TBSCertificate contains the names of the subject and issuer, a public - key associated with the subject, a validity period, a version number, - and a serial number; some MAY contain optional unique identifier - fields. The remainder of this section describes the syntax and - semantics of these fields. A TBSCertificate usually includes - extensions. Extensions for the Internet PKI are described in Section - 4.2. - -4.1.2.1 Version - - This field describes the version of the encoded certificate. When - extensions are used, as expected in this profile, version MUST be 3 - (value is 2). If no extensions are present, but a UniqueIdentifier - is present, the version SHOULD be 2 (value is 1); however version MAY - be 3. If only basic fields are present, the version SHOULD be 1 (the - value is omitted from the certificate as the default value); however - the version MAY be 2 or 3. - - Implementations SHOULD be prepared to accept any version certificate. - At a minimum, conforming implementations MUST recognize version 3 - certificates. - - Generation of version 2 certificates is not expected by - implementations based on this profile. - -4.1.2.2 Serial number - - The serial number MUST be a positive integer assigned by the CA to - each certificate. It MUST be unique for each certificate issued by a - given CA (i.e., the issuer name and serial number identify a unique - certificate). CAs MUST force the serialNumber to be a non-negative - integer. - - - - - - -Housley, et. al. Standards Track [Page 17] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Given the uniqueness requirements above, serial numbers can be - expected to contain long integers. Certificate users MUST be able to - handle serialNumber values up to 20 octets. Conformant CAs MUST NOT - use serialNumber values longer than 20 octets. - - Note: Non-conforming CAs may issue certificates with serial numbers - that are negative, or zero. Certificate users SHOULD be prepared to - gracefully handle such certificates. - -4.1.2.3 Signature - - This field contains the algorithm identifier for the algorithm used - by the CA to sign the certificate. - - This field MUST contain the same algorithm identifier as the - signatureAlgorithm field in the sequence Certificate (section - 4.1.1.2). The contents of the optional parameters field will vary - according to the algorithm identified. [PKIXALGS] lists the - supported signature algorithms, but other signature algorithms MAY - also be supported. - -4.1.2.4 Issuer - - The issuer field identifies the entity who has signed and issued the - certificate. The issuer field MUST contain a non-empty distinguished - name (DN). The issuer field is defined as the X.501 type Name - [X.501]. Name is defined by the following ASN.1 structures: - - Name ::= CHOICE { - RDNSequence } - - RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - - RelativeDistinguishedName ::= - SET OF AttributeTypeAndValue - - AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - - AttributeType ::= OBJECT IDENTIFIER - - AttributeValue ::= ANY DEFINED BY AttributeType - - - - - - - - -Housley, et. al. Standards Track [Page 18] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - DirectoryString ::= CHOICE { - teletexString TeletexString (SIZE (1..MAX)), - printableString PrintableString (SIZE (1..MAX)), - universalString UniversalString (SIZE (1..MAX)), - utf8String UTF8String (SIZE (1..MAX)), - bmpString BMPString (SIZE (1..MAX)) } - - The Name describes a hierarchical name composed of attributes, such - as country name, and corresponding values, such as US. The type of - the component AttributeValue is determined by the AttributeType; in - general it will be a DirectoryString. - - The DirectoryString type is defined as a choice of PrintableString, - TeletexString, BMPString, UTF8String, and UniversalString. The - UTF8String encoding [RFC 2279] is the preferred encoding, and all - certificates issued after December 31, 2003 MUST use the UTF8String - encoding of DirectoryString (except as noted below). Until that - date, conforming CAs MUST choose from the following options when - creating a distinguished name, including their own: - - (a) if the character set is sufficient, the string MAY be - represented as a PrintableString; - - (b) failing (a), if the BMPString character set is sufficient the - string MAY be represented as a BMPString; and - - (c) failing (a) and (b), the string MUST be represented as a - UTF8String. If (a) or (b) is satisfied, the CA MAY still choose - to represent the string as a UTF8String. - - Exceptions to the December 31, 2003 UTF8 encoding requirements are as - follows: - - (a) CAs MAY issue "name rollover" certificates to support an - orderly migration to UTF8String encoding. Such certificates would - include the CA's UTF8String encoded name as issuer and and the old - name encoding as subject, or vice-versa. - - (b) As stated in section 4.1.2.6, the subject field MUST be - populated with a non-empty distinguished name matching the - contents of the issuer field in all certificates issued by the - subject CA regardless of encoding. - - The TeletexString and UniversalString are included for backward - compatibility, and SHOULD NOT be used for certificates for new - subjects. However, these types MAY be used in certificates where the - name was previously established. Certificate users SHOULD be - prepared to receive certificates with these types. - - - -Housley, et. al. Standards Track [Page 19] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - In addition, many legacy implementations support names encoded in the - ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as - TeletexString. TeletexString encodes a larger character set than ISO - 8859-1, but it encodes some characters differently. Implementations - SHOULD be prepared to handle both encodings. - - As noted above, distinguished names are composed of attributes. This - specification does not restrict the set of attribute types that may - appear in names. However, conforming implementations MUST be - prepared to receive certificates with issuer names containing the set - of attribute types defined below. This specification RECOMMENDS - support for additional attribute types. - - Standard sets of attributes have been defined in the X.500 series of - specifications [X.520]. Implementations of this specification MUST - be prepared to receive the following standard attribute types in - issuer and subject (section 4.1.2.6) names: - - * country, - * organization, - * organizational-unit, - * distinguished name qualifier, - * state or province name, - * common name (e.g., "Susan Housley"), and - * serial number. - - In addition, implementations of this specification SHOULD be prepared - to receive the following standard attribute types in issuer and - subject names: - - * locality, - * title, - * surname, - * given name, - * initials, - * pseudonym, and - * generation qualifier (e.g., "Jr.", "3rd", or "IV"). - - The syntax and associated object identifiers (OIDs) for these - attribute types are provided in the ASN.1 modules in Appendix A. - - In addition, implementations of this specification MUST be prepared - to receive the domainComponent attribute, as defined in [RFC 2247]. - The Domain Name System (DNS) provides a hierarchical resource - labeling system. This attribute provides a convenient mechanism for - organizations that wish to use DNs that parallel their DNS names. - This is not a replacement for the dNSName component of the - - - - -Housley, et. al. Standards Track [Page 20] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - alternative name field. Implementations are not required to convert - such names into DNS names. The syntax and associated OID for this - attribute type is provided in the ASN.1 modules in Appendix A. - - Certificate users MUST be prepared to process the issuer - distinguished name and subject distinguished name (section 4.1.2.6) - fields to perform name chaining for certification path validation - (section 6). Name chaining is performed by matching the issuer - distinguished name in one certificate with the subject name in a CA - certificate. - - This specification requires only a subset of the name comparison - functionality specified in the X.500 series of specifications. - Conforming implementations are REQUIRED to implement the following - name comparison rules: - - (a) attribute values encoded in different types (e.g., - PrintableString and BMPString) MAY be assumed to represent - different strings; - - (b) attribute values in types other than PrintableString are case - sensitive (this permits matching of attribute values as binary - objects); - - (c) attribute values in PrintableString are not case sensitive - (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and - - (d) attribute values in PrintableString are compared after - removing leading and trailing white space and converting internal - substrings of one or more consecutive white space characters to a - single space. - - These name comparison rules permit a certificate user to validate - certificates issued using languages or encodings unfamiliar to the - certificate user. - - In addition, implementations of this specification MAY use these - comparison rules to process unfamiliar attribute types for name - chaining. This allows implementations to process certificates with - unfamiliar attributes in the issuer name. - - Note that the comparison rules defined in the X.500 series of - specifications indicate that the character sets used to encode data - in distinguished names are irrelevant. The characters themselves are - compared without regard to encoding. Implementations of this profile - are permitted to use the comparison algorithm defined in the X.500 - series. Such an implementation will recognize a superset of name - matches recognized by the algorithm specified above. - - - -Housley, et. al. Standards Track [Page 21] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.1.2.5 Validity - - The certificate validity period is the time interval during which the - CA warrants that it will maintain information about the status of the - certificate. The field is represented as a SEQUENCE of two dates: - the date on which the certificate validity period begins (notBefore) - and the date on which the certificate validity period ends - (notAfter). Both notBefore and notAfter may be encoded as UTCTime or - GeneralizedTime. - - CAs conforming to this profile MUST always encode certificate - validity dates through the year 2049 as UTCTime; certificate validity - dates in 2050 or later MUST be encoded as GeneralizedTime. - - The validity period for a certificate is the period of time from - notBefore through notAfter, inclusive. - -4.1.2.5.1 UTCTime - - The universal time type, UTCTime, is a standard ASN.1 type intended - for representation of dates and time. UTCTime specifies the year - through the two low order digits and time is specified to the - precision of one minute or one second. UTCTime includes either Z - (for Zulu, or Greenwich Mean Time) or a time differential. - - For the purposes of this profile, UTCTime values MUST be expressed - Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are - YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming - systems MUST interpret the year field (YY) as follows: - - Where YY is greater than or equal to 50, the year SHALL be - interpreted as 19YY; and - - Where YY is less than 50, the year SHALL be interpreted as 20YY. - -4.1.2.5.2 GeneralizedTime - - The generalized time type, GeneralizedTime, is a standard ASN.1 type - for variable precision representation of time. Optionally, the - GeneralizedTime field can include a representation of the time - differential between local and Greenwich Mean Time. - - For the purposes of this profile, GeneralizedTime values MUST be - expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., - times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. - GeneralizedTime values MUST NOT include fractional seconds. - - - - - -Housley, et. al. Standards Track [Page 22] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.1.2.6 Subject - - The subject field identifies the entity associated with the public - key stored in the subject public key field. The subject name MAY be - carried in the subject field and/or the subjectAltName extension. If - the subject is a CA (e.g., the basic constraints extension, as - discussed in 4.2.1.10, is present and the value of cA is TRUE), then - the subject field MUST be populated with a non-empty distinguished - name matching the contents of the issuer field (section 4.1.2.4) in - all certificates issued by the subject CA. If the subject is a CRL - issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is - present and the value of cRLSign is TRUE) then the subject field MUST - be populated with a non-empty distinguished name matching the - contents of the issuer field (section 4.1.2.4) in all CRLs issued by - the subject CRL issuer. If subject naming information is present - only in the subjectAltName extension (e.g., a key bound only to an - email address or URI), then the subject name MUST be an empty - sequence and the subjectAltName extension MUST be critical. - - Where it is non-empty, the subject field MUST contain an X.500 - distinguished name (DN). The DN MUST be unique for each subject - entity certified by the one CA as defined by the issuer name field. - A CA MAY issue more than one certificate with the same DN to the same - subject entity. - - The subject name field is defined as the X.501 type Name. - Implementation requirements for this field are those defined for the - issuer field (section 4.1.2.4). When encoding attribute values of - type DirectoryString, the encoding rules for the issuer field MUST be - implemented. Implementations of this specification MUST be prepared - to receive subject names containing the attribute types required for - the issuer field. Implementations of this specification SHOULD be - prepared to receive subject names containing the recommended - attribute types for the issuer field. The syntax and associated - object identifiers (OIDs) for these attribute types are provided in - the ASN.1 modules in Appendix A. Implementations of this - specification MAY use these comparison rules to process unfamiliar - attribute types (i.e., for name chaining). This allows - implementations to process certificates with unfamiliar attributes in - the subject name. - - In addition, legacy implementations exist where an RFC 822 name is - embedded in the subject distinguished name as an EmailAddress - attribute. The attribute value for EmailAddress is of type IA5String - to permit inclusion of the character '@', which is not part of the - PrintableString character set. EmailAddress attribute values are not - case sensitive (e.g., "fanfeedback@redsox.com" is the same as - "FANFEEDBACK@REDSOX.COM"). - - - -Housley, et. al. Standards Track [Page 23] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Conforming implementations generating new certificates with - electronic mail addresses MUST use the rfc822Name in the subject - alternative name field (section 4.2.1.7) to describe such identities. - Simultaneous inclusion of the EmailAddress attribute in the subject - distinguished name to support legacy implementations is deprecated - but permitted. - -4.1.2.7 Subject Public Key Info - - This field is used to carry the public key and identify the algorithm - with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The - algorithm is identified using the AlgorithmIdentifier structure - specified in section 4.1.1.2. The object identifiers for the - supported algorithms and the methods for encoding the public key - materials (public key and parameters) are specified in [PKIXALGS]. - -4.1.2.8 Unique Identifiers - - These fields MUST only appear if the version is 2 or 3 (section - 4.1.2.1). These fields MUST NOT appear if the version is 1. The - subject and issuer unique identifiers are present in the certificate - to handle the possibility of reuse of subject and/or issuer names - over time. This profile RECOMMENDS that names not be reused for - different entities and that Internet certificates not make use of - unique identifiers. CAs conforming to this profile SHOULD NOT - generate certificates with unique identifiers. Applications - conforming to this profile SHOULD be capable of parsing unique - identifiers. - -4.1.2.9 Extensions - - This field MUST only appear if the version is 3 (section 4.1.2.1). - If present, this field is a SEQUENCE of one or more certificate - extensions. The format and content of certificate extensions in the - Internet PKI is defined in section 4.2. - -4.2 Certificate Extensions - - The extensions defined for X.509 v3 certificates provide methods for - associating additional attributes with users or public keys and for - managing a certification hierarchy. The X.509 v3 certificate format - also allows communities to define private extensions to carry - information unique to those communities. Each extension in a - certificate is designated as either critical or non-critical. A - certificate using system MUST reject the certificate if it encounters - a critical extension it does not recognize; however, a non-critical - extension MAY be ignored if it is not recognized. The following - sections present recommended extensions used within Internet - - - -Housley, et. al. Standards Track [Page 24] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - certificates and standard locations for information. Communities may - elect to use additional extensions; however, caution ought to be - exercised in adopting any critical extensions in certificates which - might prevent use in a general context. - - Each extension includes an OID and an ASN.1 structure. When an - extension appears in a certificate, the OID appears as the field - extnID and the corresponding ASN.1 encoded structure is the value of - the octet string extnValue. A certificate MUST NOT include more than - one instance of a particular extension. For example, a certificate - may contain only one authority key identifier extension (section - 4.2.1.1). An extension includes the boolean critical, with a default - value of FALSE. The text for each extension specifies the acceptable - values for the critical field. - - Conforming CAs MUST support key identifiers (sections 4.2.1.1 and - 4.2.1.2), basic constraints (section 4.2.1.10), key usage (section - 4.2.1.3), and certificate policies (section 4.2.1.5) extensions. If - the CA issues certificates with an empty sequence for the subject - field, the CA MUST support the subject alternative name extension - (section 4.2.1.7). Support for the remaining extensions is OPTIONAL. - Conforming CAs MAY support extensions that are not identified within - this specification; certificate issuers are cautioned that marking - such extensions as critical may inhibit interoperability. - - At a minimum, applications conforming to this profile MUST recognize - the following extensions: key usage (section 4.2.1.3), certificate - policies (section 4.2.1.5), the subject alternative name (section - 4.2.1.7), basic constraints (section 4.2.1.10), name constraints - (section 4.2.1.11), policy constraints (section 4.2.1.12), extended - key usage (section 4.2.1.13), and inhibit any-policy (section - 4.2.1.15). - - In addition, applications conforming to this profile SHOULD recognize - the authority and subject key identifier (sections 4.2.1.1 and - 4.2.1.2), and policy mapping (section 4.2.1.6) extensions. - -4.2.1 Standard Extensions - - This section identifies standard certificate extensions defined in - [X.509] for use in the Internet PKI. Each extension is associated - with an OID defined in [X.509]. These OIDs are members of the id-ce - arc, which is defined by the following: - - id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } - - - - - - -Housley, et. al. Standards Track [Page 25] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.2.1.1 Authority Key Identifier - - The authority key identifier extension provides a means of - identifying the public key corresponding to the private key used to - sign a certificate. This extension is used where an issuer has - multiple signing keys (either due to multiple concurrent key pairs or - due to changeover). The identification MAY be based on either the - key identifier (the subject key identifier in the issuer's - certificate) or on the issuer name and serial number. - - The keyIdentifier field of the authorityKeyIdentifier extension MUST - be included in all certificates generated by conforming CAs to - facilitate certification path construction. There is one exception; - where a CA distributes its public key in the form of a "self-signed" - certificate, the authority key identifier MAY be omitted. The - signature on a self-signed certificate is generated with the private - key associated with the certificate's subject public key. (This - proves that the issuer possesses both the public and private keys.) - In this case, the subject and authority key identifiers would be - identical, but only the subject key identifier is needed for - certification path building. - - The value of the keyIdentifier field SHOULD be derived from the - public key used to verify the certificate's signature or a method - that generates unique values. Two common methods for generating key - identifiers from the public key, and one common method for generating - unique values, are described in section 4.2.1.2. Where a key - identifier has not been previously established, this specification - RECOMMENDS use of one of these methods for generating keyIdentifiers. - Where a key identifier has been previously established, the CA SHOULD - use the previously established identifier. - - This profile RECOMMENDS support for the key identifier method by all - certificate users. - - This extension MUST NOT be marked critical. - - id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } - - AuthorityKeyIdentifier ::= SEQUENCE { - keyIdentifier [0] KeyIdentifier OPTIONAL, - authorityCertIssuer [1] GeneralNames OPTIONAL, - authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } - - KeyIdentifier ::= OCTET STRING - - - - - - -Housley, et. al. Standards Track [Page 26] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.2.1.2 Subject Key Identifier - - The subject key identifier extension provides a means of identifying - certificates that contain a particular public key. - - To facilitate certification path construction, this extension MUST - appear in all conforming CA certificates, that is, all certificates - including the basic constraints extension (section 4.2.1.10) where - the value of cA is TRUE. The value of the subject key identifier - MUST be the value placed in the key identifier field of the Authority - Key Identifier extension (section 4.2.1.1) of certificates issued by - the subject of this certificate. - - For CA certificates, subject key identifiers SHOULD be derived from - the public key or a method that generates unique values. Two common - methods for generating key identifiers from the public key are: - - (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the - value of the BIT STRING subjectPublicKey (excluding the tag, - length, and number of unused bits). - - (2) The keyIdentifier is composed of a four bit type field with - the value 0100 followed by the least significant 60 bits of the - SHA-1 hash of the value of the BIT STRING subjectPublicKey - (excluding the tag, length, and number of unused bit string bits). - - One common method for generating unique values is a monotonically - increasing sequence of integers. - - For end entity certificates, the subject key identifier extension - provides a means for identifying certificates containing the - particular public key used in an application. Where an end entity - has obtained multiple certificates, especially from multiple CAs, the - subject key identifier provides a means to quickly identify the set - of certificates containing a particular public key. To assist - applications in identifying the appropriate end entity certificate, - this extension SHOULD be included in all end entity certificates. - - For end entity certificates, subject key identifiers SHOULD be - derived from the public key. Two common methods for generating key - identifiers from the public key are identified above. - - Where a key identifier has not been previously established, this - specification RECOMMENDS use of one of these methods for generating - keyIdentifiers. Where a key identifier has been previously - established, the CA SHOULD use the previously established identifier. - - This extension MUST NOT be marked critical. - - - -Housley, et. al. Standards Track [Page 27] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } - - SubjectKeyIdentifier ::= KeyIdentifier - -4.2.1.3 Key Usage - - The key usage extension defines the purpose (e.g., encipherment, - signature, certificate signing) of the key contained in the - certificate. The usage restriction might be employed when a key that - could be used for more than one operation is to be restricted. For - example, when an RSA key should be used only to verify signatures on - objects other than public key certificates and CRLs, the - digitalSignature and/or nonRepudiation bits would be asserted. - Likewise, when an RSA key should be used only for key management, the - keyEncipherment bit would be asserted. - - This extension MUST appear in certificates that contain public keys - that are used to validate digital signatures on other public key - certificates or CRLs. When this extension appears, it SHOULD be - marked critical. - - id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } - - KeyUsage ::= BIT STRING { - digitalSignature (0), - nonRepudiation (1), - keyEncipherment (2), - dataEncipherment (3), - keyAgreement (4), - keyCertSign (5), - cRLSign (6), - encipherOnly (7), - decipherOnly (8) } - - Bits in the KeyUsage type are used as follows: - - The digitalSignature bit is asserted when the subject public key - is used with a digital signature mechanism to support security - services other than certificate signing (bit 5), or CRL signing - (bit 6). Digital signature mechanisms are often used for entity - authentication and data origin authentication with integrity. - - The nonRepudiation bit is asserted when the subject public key is - used to verify digital signatures used to provide a non- - repudiation service which protects against the signing entity - falsely denying some action, excluding certificate or CRL signing. - In the case of later conflict, a reliable third party may - determine the authenticity of the signed data. - - - -Housley, et. al. Standards Track [Page 28] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Further distinctions between the digitalSignature and - nonRepudiation bits may be provided in specific certificate - policies. - - The keyEncipherment bit is asserted when the subject public key is - used for key transport. For example, when an RSA key is to be - used for key management, then this bit is set. - - The dataEncipherment bit is asserted when the subject public key - is used for enciphering user data, other than cryptographic keys. - - The keyAgreement bit is asserted when the subject public key is - used for key agreement. For example, when a Diffie-Hellman key is - to be used for key management, then this bit is set. - - The keyCertSign bit is asserted when the subject public key is - used for verifying a signature on public key certificates. If the - keyCertSign bit is asserted, then the cA bit in the basic - constraints extension (section 4.2.1.10) MUST also be asserted. - - The cRLSign bit is asserted when the subject public key is used - for verifying a signature on certificate revocation list (e.g., a - CRL, delta CRL, or an ARL). This bit MUST be asserted in - certificates that are used to verify signatures on CRLs. - - The meaning of the encipherOnly bit is undefined in the absence of - the keyAgreement bit. When the encipherOnly bit is asserted and - the keyAgreement bit is also set, the subject public key may be - used only for enciphering data while performing key agreement. - - The meaning of the decipherOnly bit is undefined in the absence of - the keyAgreement bit. When the decipherOnly bit is asserted and - the keyAgreement bit is also set, the subject public key may be - used only for deciphering data while performing key agreement. - - This profile does not restrict the combinations of bits that may be - set in an instantiation of the keyUsage extension. However, - appropriate values for keyUsage extensions for particular algorithms - are specified in [PKIXALGS]. - -4.2.1.4 Private Key Usage Period - - This extension SHOULD NOT be used within the Internet PKI. CAs - conforming to this profile MUST NOT generate certificates that - include a critical private key usage period extension. - - - - - - -Housley, et. al. Standards Track [Page 29] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The private key usage period extension allows the certificate issuer - to specify a different validity period for the private key than the - certificate. This extension is intended for use with digital - signature keys. This extension consists of two optional components, - notBefore and notAfter. The private key associated with the - certificate SHOULD NOT be used to sign objects before or after the - times specified by the two components, respectively. CAs conforming - to this profile MUST NOT generate certificates with private key usage - period extensions unless at least one of the two components is - present and the extension is non-critical. - - Where used, notBefore and notAfter are represented as GeneralizedTime - and MUST be specified and interpreted as defined in section - 4.1.2.5.2. - - id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } - - PrivateKeyUsagePeriod ::= SEQUENCE { - notBefore [0] GeneralizedTime OPTIONAL, - notAfter [1] GeneralizedTime OPTIONAL } - -4.2.1.5 Certificate Policies - - The certificate policies extension contains a sequence of one or more - policy information terms, each of which consists of an object - identifier (OID) and optional qualifiers. Optional qualifiers, which - MAY be present, are not expected to change the definition of the - policy. - - In an end entity certificate, these policy information terms indicate - the policy under which the certificate has been issued and the - purposes for which the certificate may be used. In a CA certificate, - these policy information terms limit the set of policies for - certification paths which include this certificate. When a CA does - not wish to limit the set of policies for certification paths which - include this certificate, it MAY assert the special policy anyPolicy, - with a value of { 2 5 29 32 0 }. - - Applications with specific policy requirements are expected to have a - list of those policies which they will accept and to compare the - policy OIDs in the certificate to that list. If this extension is - critical, the path validation software MUST be able to interpret this - extension (including the optional qualifier), or MUST reject the - certificate. - - To promote interoperability, this profile RECOMMENDS that policy - information terms consist of only an OID. Where an OID alone is - insufficient, this profile strongly recommends that use of qualifiers - - - -Housley, et. al. Standards Track [Page 30] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - be limited to those identified in this section. When qualifiers are - used with the special policy anyPolicy, they MUST be limited to the - qualifiers identified in this section. - - This specification defines two policy qualifier types for use by - certificate policy writers and certificate issuers. The qualifier - types are the CPS Pointer and User Notice qualifiers. - - The CPS Pointer qualifier contains a pointer to a Certification - Practice Statement (CPS) published by the CA. The pointer is in the - form of a URI. Processing requirements for this qualifier are a - local matter. No action is mandated by this specification regardless - of the criticality value asserted for the extension. - - User notice is intended for display to a relying party when a - certificate is used. The application software SHOULD display all - user notices in all certificates of the certification path used, - except that if a notice is duplicated only one copy need be - displayed. To prevent such duplication, this qualifier SHOULD only - be present in end entity certificates and CA certificates issued to - other organizations. - - The user notice has two optional fields: the noticeRef field and the - explicitText field. - - The noticeRef field, if used, names an organization and - identifies, by number, a particular textual statement prepared by - that organization. For example, it might identify the - organization "CertsRUs" and notice number 1. In a typical - implementation, the application software will have a notice file - containing the current set of notices for CertsRUs; the - application will extract the notice text from the file and display - it. Messages MAY be multilingual, allowing the software to select - the particular language message for its own environment. - - An explicitText field includes the textual statement directly in - the certificate. The explicitText field is a string with a - maximum size of 200 characters. - - If both the noticeRef and explicitText options are included in the - one qualifier and if the application software can locate the notice - text indicated by the noticeRef option, then that text SHOULD be - displayed; otherwise, the explicitText string SHOULD be displayed. - - Note: While the explicitText has a maximum size of 200 characters, - some non-conforming CAs exceed this limit. Therefore, certificate - users SHOULD gracefully handle explicitText with more than 200 - characters. - - - -Housley, et. al. Standards Track [Page 31] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } - - anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 } - - certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation - - PolicyInformation ::= SEQUENCE { - policyIdentifier CertPolicyId, - policyQualifiers SEQUENCE SIZE (1..MAX) OF - PolicyQualifierInfo OPTIONAL } - - CertPolicyId ::= OBJECT IDENTIFIER - - PolicyQualifierInfo ::= SEQUENCE { - policyQualifierId PolicyQualifierId, - qualifier ANY DEFINED BY policyQualifierId } - - -- policyQualifierIds for Internet policy qualifiers - - id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } - id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } - id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } - - PolicyQualifierId ::= - OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) - - Qualifier ::= CHOICE { - cPSuri CPSuri, - userNotice UserNotice } - - CPSuri ::= IA5String - - UserNotice ::= SEQUENCE { - noticeRef NoticeReference OPTIONAL, - explicitText DisplayText OPTIONAL} - - NoticeReference ::= SEQUENCE { - organization DisplayText, - noticeNumbers SEQUENCE OF INTEGER } - - DisplayText ::= CHOICE { - ia5String IA5String (SIZE (1..200)), - visibleString VisibleString (SIZE (1..200)), - bmpString BMPString (SIZE (1..200)), - utf8String UTF8String (SIZE (1..200)) } - - - - - - -Housley, et. al. Standards Track [Page 32] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.2.1.6 Policy Mappings - - This extension is used in CA certificates. It lists one or more - pairs of OIDs; each pair includes an issuerDomainPolicy and a - subjectDomainPolicy. The pairing indicates the issuing CA considers - its issuerDomainPolicy equivalent to the subject CA's - subjectDomainPolicy. - - The issuing CA's users might accept an issuerDomainPolicy for certain - applications. The policy mapping defines the list of policies - associated with the subject CA that may be accepted as comparable to - the issuerDomainPolicy. - - Each issuerDomainPolicy named in the policy mapping extension SHOULD - also be asserted in a certificate policies extension in the same - certificate. Policies SHOULD NOT be mapped either to or from the - special value anyPolicy (section 4.2.1.5). - - This extension MAY be supported by CAs and/or applications, and it - MUST be non-critical. - - id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } - - PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - issuerDomainPolicy CertPolicyId, - subjectDomainPolicy CertPolicyId } - -4.2.1.7 Subject Alternative Name - - The subject alternative names extension allows additional identities - to be bound to the subject of the certificate. Defined options - include an Internet electronic mail address, a DNS name, an IP - address, and a uniform resource identifier (URI). Other options - exist, including completely local definitions. Multiple name forms, - and multiple instances of each name form, MAY be included. Whenever - such identities are to be bound into a certificate, the subject - alternative name (or issuer alternative name) extension MUST be used; - however, a DNS name MAY be represented in the subject field using the - domainComponent attribute as described in section 4.1.2.4. - - Because the subject alternative name is considered to be definitively - bound to the public key, all parts of the subject alternative name - MUST be verified by the CA. - - Further, if the only subject identity included in the certificate is - an alternative name form (e.g., an electronic mail address), then the - subject distinguished name MUST be empty (an empty sequence), and the - - - - -Housley, et. al. Standards Track [Page 33] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - subjectAltName extension MUST be present. If the subject field - contains an empty sequence, the subjectAltName extension MUST be - marked critical. - - When the subjectAltName extension contains an Internet mail address, - the address MUST be included as an rfc822Name. The format of an - rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822]. An - addr-spec has the form "local-part@domain". Note that an addr-spec - has no phrase (such as a common name) before it, has no comment (text - surrounded in parentheses) after it, and is not surrounded by "<" and - ">". Note that while upper and lower case letters are allowed in an - RFC 822 addr-spec, no significance is attached to the case. - - When the subjectAltName extension contains a iPAddress, the address - MUST be stored in the octet string in "network byte order," as - specified in RFC 791 [RFC 791]. The least significant bit (LSB) of - each octet is the LSB of the corresponding byte in the network - address. For IP Version 4, as specified in RFC 791, the octet string - MUST contain exactly four octets. For IP Version 6, as specified in - RFC 1883, the octet string MUST contain exactly sixteen octets [RFC - 1883]. - - When the subjectAltName extension contains a domain name system - label, the domain name MUST be stored in the dNSName (an IA5String). - The name MUST be in the "preferred name syntax," as specified by RFC - 1034 [RFC 1034]. Note that while upper and lower case letters are - allowed in domain names, no signifigance is attached to the case. In - addition, while the string " " is a legal domain name, subjectAltName - extensions with a dNSName of " " MUST NOT be used. Finally, the use - of the DNS representation for Internet mail addresses (wpolk.nist.gov - instead of wpolk@nist.gov) MUST NOT be used; such identities are to - be encoded as rfc822Name. - - Note: work is currently underway to specify domain names in - international character sets. Such names will likely not be - accommodated by IA5String. Once this work is complete, this profile - will be revisited and the appropriate functionality will be added. - - When the subjectAltName extension contains a URI, the name MUST be - stored in the uniformResourceIdentifier (an IA5String). The name - MUST NOT be a relative URL, and it MUST follow the URL syntax and - encoding rules specified in [RFC 1738]. The name MUST include both a - scheme (e.g., "http" or "ftp") and a scheme-specific-part. The - scheme-specific-part MUST include a fully qualified domain name or IP - address as the host. - - - - - - -Housley, et. al. Standards Track [Page 34] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - As specified in [RFC 1738], the scheme name is not case-sensitive - (e.g., "http" is equivalent to "HTTP"). The host part is also not - case-sensitive, but other components of the scheme-specific-part may - be case-sensitive. When comparing URIs, conforming implementations - MUST compare the scheme and host without regard to case, but assume - the remainder of the scheme-specific-part is case sensitive. - - When the subjectAltName extension contains a DN in the directoryName, - the DN MUST be unique for each subject entity certified by the one CA - as defined by the issuer name field. A CA MAY issue more than one - certificate with the same DN to the same subject entity. - - The subjectAltName MAY carry additional name types through the use of - the otherName field. The format and semantics of the name are - indicated through the OBJECT IDENTIFIER in the type-id field. The - name itself is conveyed as value field in otherName. For example, - Kerberos [RFC 1510] format names can be encoded into the otherName, - using using a Kerberos 5 principal name OID and a SEQUENCE of the - Realm and the PrincipalName. - - Subject alternative names MAY be constrained in the same manner as - subject distinguished names using the name constraints extension as - described in section 4.2.1.11. - - If the subjectAltName extension is present, the sequence MUST contain - at least one entry. Unlike the subject field, conforming CAs MUST - NOT issue certificates with subjectAltNames containing empty - GeneralName fields. For example, an rfc822Name is represented as an - IA5String. While an empty string is a valid IA5String, such an - rfc822Name is not permitted by this profile. The behavior of clients - that encounter such a certificate when processing a certificication - path is not defined by this profile. - - Finally, the semantics of subject alternative names that include - wildcard characters (e.g., as a placeholder for a set of names) are - not addressed by this specification. Applications with specific - requirements MAY use such names, but they must define the semantics. - - id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } - - SubjectAltName ::= GeneralNames - - GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName - - - - - - - - -Housley, et. al. Standards Track [Page 35] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - GeneralName ::= CHOICE { - otherName [0] OtherName, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] ORAddress, - directoryName [4] Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER } - - OtherName ::= SEQUENCE { - type-id OBJECT IDENTIFIER, - value [0] EXPLICIT ANY DEFINED BY type-id } - - EDIPartyName ::= SEQUENCE { - nameAssigner [0] DirectoryString OPTIONAL, - partyName [1] DirectoryString } - -4.2.1.8 Issuer Alternative Names - - As with 4.2.1.7, this extension is used to associate Internet style - identities with the certificate issuer. Issuer alternative names - MUST be encoded as in 4.2.1.7. - - Where present, this extension SHOULD NOT be marked critical. - - id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } - - IssuerAltName ::= GeneralNames - -4.2.1.9 Subject Directory Attributes - - The subject directory attributes extension is used to convey - identification attributes (e.g., nationality) of the subject. The - extension is defined as a sequence of one or more attributes. This - extension MUST be non-critical. - - id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } - - SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute - -4.2.1.10 Basic Constraints - - The basic constraints extension identifies whether the subject of the - certificate is a CA and the maximum depth of valid certification - paths that include this certificate. - - - - -Housley, et. al. Standards Track [Page 36] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The cA boolean indicates whether the certified public key belongs to - a CA. If the cA boolean is not asserted, then the keyCertSign bit in - the key usage extension MUST NOT be asserted. - - The pathLenConstraint field is meaningful only if the cA boolean is - asserted and the key usage extension asserts the keyCertSign bit - (section 4.2.1.3). In this case, it gives the maximum number of non- - self-issued intermediate certificates that may follow this - certificate in a valid certification path. A certificate is self- - issued if the DNs that appear in the subject and issuer fields are - identical and are not empty. (Note: The last certificate in the - certification path is not an intermediate certificate, and is not - included in this limit. Usually, the last certificate is an end - entity certificate, but it can be a CA certificate.) A - pathLenConstraint of zero indicates that only one more certificate - may follow in a valid certification path. Where it appears, the - pathLenConstraint field MUST be greater than or equal to zero. Where - pathLenConstraint does not appear, no limit is imposed. - - This extension MUST appear as a critical extension in all CA - certificates that contain public keys used to validate digital - signatures on certificates. This extension MAY appear as a critical - or non-critical extension in CA certificates that contain public keys - used exclusively for purposes other than validating digital - signatures on certificates. Such CA certificates include ones that - contain public keys used exclusively for validating digital - signatures on CRLs and ones that contain key management public keys - used with certificate enrollment protocols. This extension MAY - appear as a critical or non-critical extension in end entity - certificates. - - CAs MUST NOT include the pathLenConstraint field unless the cA - boolean is asserted and the key usage extension asserts the - keyCertSign bit. - - id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } - - BasicConstraints ::= SEQUENCE { - cA BOOLEAN DEFAULT FALSE, - pathLenConstraint INTEGER (0..MAX) OPTIONAL } - -4.2.1.11 Name Constraints - - The name constraints extension, which MUST be used only in a CA - certificate, indicates a name space within which all subject names in - subsequent certificates in a certification path MUST be located. - Restrictions apply to the subject distinguished name and apply to - subject alternative names. Restrictions apply only when the - - - -Housley, et. al. Standards Track [Page 37] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - specified name form is present. If no name of the type is in the - certificate, the certificate is acceptable. - - Name constraints are not applied to certificates whose issuer and - subject are identical (unless the certificate is the final - certificate in the path). (This could prevent CAs that use name - constraints from employing self-issued certificates to implement key - rollover.) - - Restrictions are defined in terms of permitted or excluded name - subtrees. Any name matching a restriction in the excludedSubtrees - field is invalid regardless of information appearing in the - permittedSubtrees. This extension MUST be critical. - - Within this profile, the minimum and maximum fields are not used with - any name forms, thus minimum MUST be zero, and maximum MUST be - absent. - - For URIs, the constraint applies to the host part of the name. The - constraint MAY specify a host or a domain. Examples would be - "foo.bar.com"; and ".xyz.com". When the the constraint begins with - a period, it MAY be expanded with one or more subdomains. That is, - the constraint ".xyz.com" is satisfied by both abc.xyz.com and - abc.def.xyz.com. However, the constraint ".xyz.com" is not satisfied - by "xyz.com". When the constraint does not begin with a period, it - specifies a host. - - A name constraint for Internet mail addresses MAY specify a - particular mailbox, all addresses at a particular host, or all - mailboxes in a domain. To indicate a particular mailbox, the - constraint is the complete mail address. For example, "root@xyz.com" - indicates the root mailbox on the host "xyz.com". To indicate all - Internet mail addresses on a particular host, the constraint is - specified as the host name. For example, the constraint "xyz.com" is - satisfied by any mail address at the host "xyz.com". To specify any - address within a domain, the constraint is specified with a leading - period (as with URIs). For example, ".xyz.com" indicates all the - Internet mail addresses in the domain "xyz.com", but not Internet - mail addresses on the host "xyz.com". - - DNS name restrictions are expressed as foo.bar.com. Any DNS name - that can be constructed by simply adding to the left hand side of the - name satisfies the name constraint. For example, www.foo.bar.com - would satisfy the constraint but foo1.bar.com would not. - - Legacy implementations exist where an RFC 822 name is embedded in the - subject distinguished name in an attribute of type EmailAddress - (section 4.1.2.6). When rfc822 names are constrained, but the - - - -Housley, et. al. Standards Track [Page 38] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - certificate does not include a subject alternative name, the rfc822 - name constraint MUST be applied to the attribute of type EmailAddress - in the subject distinguished name. The ASN.1 syntax for EmailAddress - and the corresponding OID are supplied in Appendix A. - - Restrictions of the form directoryName MUST be applied to the subject - field in the certificate and to the subjectAltName extensions of type - directoryName. Restrictions of the form x400Address MUST be applied - to subjectAltName extensions of type x400Address. - - When applying restrictions of the form directoryName, an - implementation MUST compare DN attributes. At a minimum, - implementations MUST perform the DN comparison rules specified in - Section 4.1.2.4. CAs issuing certificates with a restriction of the - form directoryName SHOULD NOT rely on implementation of the full ISO - DN name comparison algorithm. This implies name restrictions MUST be - stated identically to the encoding used in the subject field or - subjectAltName extension. - - The syntax of iPAddress MUST be as described in section 4.2.1.7 with - the following additions specifically for Name Constraints. For IPv4 - addresses, the ipAddress field of generalName MUST contain eight (8) - octets, encoded in the style of RFC 1519 (CIDR) to represent an - address range [RFC 1519]. For IPv6 addresses, the ipAddress field - MUST contain 32 octets similarly encoded. For example, a name - constraint for "class C" subnet 10.9.8.0 is represented as the octets - 0A 09 08 00 FF FF FF 00, representing the CIDR notation - 10.9.8.0/255.255.255.0. - - The syntax and semantics for name constraints for otherName, - ediPartyName, and registeredID are not defined by this specification. - - id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } - - NameConstraints ::= SEQUENCE { - permittedSubtrees [0] GeneralSubtrees OPTIONAL, - excludedSubtrees [1] GeneralSubtrees OPTIONAL } - - GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree - - GeneralSubtree ::= SEQUENCE { - base GeneralName, - minimum [0] BaseDistance DEFAULT 0, - maximum [1] BaseDistance OPTIONAL } - - BaseDistance ::= INTEGER (0..MAX) - - - - - -Housley, et. al. Standards Track [Page 39] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.2.1.12 Policy Constraints - - The policy constraints extension can be used in certificates issued - to CAs. The policy constraints extension constrains path validation - in two ways. It can be used to prohibit policy mapping or require - that each certificate in a path contain an acceptable policy - identifier. - - If the inhibitPolicyMapping field is present, the value indicates the - number of additional certificates that may appear in the path before - policy mapping is no longer permitted. For example, a value of one - indicates that policy mapping may be processed in certificates issued - by the subject of this certificate, but not in additional - certificates in the path. - - If the requireExplicitPolicy field is present, the value of - requireExplicitPolicy indicates the number of additional certificates - that may appear in the path before an explicit policy is required for - the entire path. When an explicit policy is required, it is - necessary for all certificates in the path to contain an acceptable - policy identifier in the certificate policies extension. An - acceptable policy identifier is the identifier of a policy required - by the user of the certification path or the identifier of a policy - which has been declared equivalent through policy mapping. - - Conforming CAs MUST NOT issue certificates where policy constraints - is a empty sequence. That is, at least one of the - inhibitPolicyMapping field or the requireExplicitPolicy field MUST be - present. The behavior of clients that encounter a empty policy - constraints field is not addressed in this profile. - - This extension MAY be critical or non-critical. - - id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } - - PolicyConstraints ::= SEQUENCE { - requireExplicitPolicy [0] SkipCerts OPTIONAL, - inhibitPolicyMapping [1] SkipCerts OPTIONAL } - - SkipCerts ::= INTEGER (0..MAX) - -4.2.1.13 Extended Key Usage - - This extension indicates one or more purposes for which the certified - public key may be used, in addition to or in place of the basic - purposes indicated in the key usage extension. In general, this - extension will appear only in end entity certificates. This - extension is defined as follows: - - - -Housley, et. al. Standards Track [Page 40] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } - - ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId - - KeyPurposeId ::= OBJECT IDENTIFIER - - Key purposes may be defined by any organization with a need. Object - identifiers used to identify key purposes MUST be assigned in - accordance with IANA or ITU-T Recommendation X.660 [X.660]. - - This extension MAY, at the option of the certificate issuer, be - either critical or non-critical. - - If the extension is present, then the certificate MUST only be used - for one of the purposes indicated. If multiple purposes are - indicated the application need not recognize all purposes indicated, - as long as the intended purpose is present. Certificate using - applications MAY require that a particular purpose be indicated in - order for the certificate to be acceptable to that application. - - If a CA includes extended key usages to satisfy such applications, - but does not wish to restrict usages of the key, the CA can include - the special keyPurposeID anyExtendedKeyUsage. If the - anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT - be critical. - - If a certificate contains both a key usage extension and an extended - key usage extension, then both extensions MUST be processed - independently and the certificate MUST only be used for a purpose - consistent with both extensions. If there is no purpose consistent - with both extensions, then the certificate MUST NOT be used for any - purpose. - - The following key usage purposes are defined: - - anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } - - id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } - - id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } - -- TLS WWW server authentication - -- Key usage bits that may be consistent: digitalSignature, - -- keyEncipherment or keyAgreement - - id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } - -- TLS WWW client authentication - -- Key usage bits that may be consistent: digitalSignature - -- and/or keyAgreement - - - -Housley, et. al. Standards Track [Page 41] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } - -- Signing of downloadable executable code - -- Key usage bits that may be consistent: digitalSignature - - id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } - -- E-mail protection - -- Key usage bits that may be consistent: digitalSignature, - -- nonRepudiation, and/or (keyEncipherment or keyAgreement) - - id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } - -- Binding the hash of an object to a time - -- Key usage bits that may be consistent: digitalSignature - -- and/or nonRepudiation - - id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } - -- Signing OCSP responses - -- Key usage bits that may be consistent: digitalSignature - -- and/or nonRepudiation - -4.2.1.14 CRL Distribution Points - - The CRL distribution points extension identifies how CRL information - is obtained. The extension SHOULD be non-critical, but this profile - RECOMMENDS support for this extension by CAs and applications. - Further discussion of CRL management is contained in section 5. - - The cRLDistributionPoints extension is a SEQUENCE of - DistributionPoint. A DistributionPoint consists of three fields, - each of which is optional: distributionPoint, reasons, and cRLIssuer. - While each of these fields is optional, a DistributionPoint MUST NOT - consist of only the reasons field; either distributionPoint or - cRLIssuer MUST be present. If the certificate issuer is not the CRL - issuer, then the cRLIssuer field MUST be present and contain the Name - of the CRL issuer. If the certificate issuer is also the CRL issuer, - then the cRLIssuer field MUST be omitted and the distributionPoint - field MUST be present. If the distributionPoint field is omitted, - cRLIssuer MUST be present and include a Name corresponding to an - X.500 or LDAP directory entry where the CRL is located. - - When the distributionPoint field is present, it contains either a - SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. - If the cRLDistributionPoints extension contains a general name of - type URI, the following semantics MUST be assumed: the URI is a - pointer to the current CRL for the associated reasons and will be - issued by the associated cRLIssuer. The expected values for the URI - are those defined in 4.2.1.7. Processing rules for other values are - not defined by this specification. - - - - -Housley, et. al. Standards Track [Page 42] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - If the DistributionPointName contains multiple values, each name - describes a different mechanism to obtain the same CRL. For example, - the same CRL could be available for retrieval through both LDAP and - HTTP. - - If the DistributionPointName contains the single value - nameRelativeToCRLIssuer, the value provides a distinguished name - fragment. The fragment is appended to the X.500 distinguished name - of the CRL issuer to obtain the distribution point name. If the - cRLIssuer field in the DistributionPoint is present, then the name - fragment is appended to the distinguished name that it contains; - otherwise, the name fragment is appended to the certificate issuer - distinguished name. The DistributionPointName MUST NOT use the - nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than - one distinguished name. - - If the DistributionPoint omits the reasons field, the CRL MUST - include revocation information for all reasons. - - The cRLIssuer identifies the entity who signs and issues the CRL. If - present, the cRLIssuer MUST contain at least one an X.500 - distinguished name (DN), and MAY also contain other name forms. - Since the cRLIssuer is compared to the CRL issuer name, the X.501 - type Name MUST follow the encoding rules for the issuer name field in - the certificate (section 4.1.2.4). - - id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } - - CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint - - DistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - reasons [1] ReasonFlags OPTIONAL, - cRLIssuer [2] GeneralNames OPTIONAL } - - DistributionPointName ::= CHOICE { - fullName [0] GeneralNames, - nameRelativeToCRLIssuer [1] RelativeDistinguishedName } - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 43] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - ReasonFlags ::= BIT STRING { - unused (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - privilegeWithdrawn (7), - aACompromise (8) } - -4.2.1.15 Inhibit Any-Policy - - The inhibit any-policy extension can be used in certificates issued - to CAs. The inhibit any-policy indicates that the special anyPolicy - OID, with the value { 2 5 29 32 0 }, is not considered an explicit - match for other certificate policies. The value indicates the number - of additional certificates that may appear in the path before - anyPolicy is no longer permitted. For example, a value of one - indicates that anyPolicy may be processed in certificates issued by - the subject of this certificate, but not in additional certificates - in the path. - - This extension MUST be critical. - - id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } - - InhibitAnyPolicy ::= SkipCerts - - SkipCerts ::= INTEGER (0..MAX) - -4.2.1.16 Freshest CRL (a.k.a. Delta CRL Distribution Point) - - The freshest CRL extension identifies how delta CRL information is - obtained. The extension MUST be non-critical. Further discussion of - CRL management is contained in section 5. - - The same syntax is used for this extension and the - cRLDistributionPoints extension, and is described in section - 4.2.1.14. The same conventions apply to both extensions. - - id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - - FreshestCRL ::= CRLDistributionPoints - - - - - - - -Housley, et. al. Standards Track [Page 44] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -4.2.2 Private Internet Extensions - - This section defines two extensions for use in the Internet Public - Key Infrastructure. These extensions may be used to direct - applications to on-line information about the issuing CA or the - subject. As the information may be available in multiple forms, each - extension is a sequence of IA5String values, each of which represents - a URI. The URI implicitly specifies the location and format of the - information and the method for obtaining the information. - - An object identifier is defined for the private extension. The - object identifier associated with the private extension is defined - under the arc id-pe within the arc id-pkix. Any future extensions - defined for the Internet PKI are also expected to be defined under - the arc id-pe. - - id-pkix OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) } - - id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } - -4.2.2.1 Authority Information Access - - The authority information access extension indicates how to access CA - information and services for the issuer of the certificate in which - the extension appears. Information and services may include on-line - validation services and CA policy data. (The location of CRLs is not - specified in this extension; that information is provided by the - cRLDistributionPoints extension.) This extension may be included in - end entity or CA certificates, and it MUST be non-critical. - - id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } - - AuthorityInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - - AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - - id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - - id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } - - id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } - - - - - -Housley, et. al. Standards Track [Page 45] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Each entry in the sequence AuthorityInfoAccessSyntax describes the - format and location of additional information provided by the CA that - issued the certificate in which this extension appears. The type and - format of the information is specified by the accessMethod field; the - accessLocation field specifies the location of the information. The - retrieval mechanism may be implied by the accessMethod or specified - by accessLocation. - - This profile defines two accessMethod OIDs: id-ad-caIssuers and - id-ad-ocsp. - - The id-ad-caIssuers OID is used when the additional information lists - CAs that have issued certificates superior to the CA that issued the - certificate containing this extension. The referenced CA issuers - description is intended to aid certificate users in the selection of - a certification path that terminates at a point trusted by the - certificate user. - - When id-ad-caIssuers appears as accessMethod, the accessLocation - field describes the referenced description server and the access - protocol to obtain the referenced description. The accessLocation - field is defined as a GeneralName, which can take several forms. - Where the information is available via http, ftp, or ldap, - accessLocation MUST be a uniformResourceIdentifier. Where the - information is available via the Directory Access Protocol (DAP), - accessLocation MUST be a directoryName. The entry for that - directoryName contains CA certificates in the crossCertificatePair - attribute. When the information is available via electronic mail, - accessLocation MUST be an rfc822Name. The semantics of other - id-ad-caIssuers accessLocation name forms are not defined. - - The id-ad-ocsp OID is used when revocation information for the - certificate containing this extension is available using the Online - Certificate Status Protocol (OCSP) [RFC 2560]. - - When id-ad-ocsp appears as accessMethod, the accessLocation field is - the location of the OCSP responder, using the conventions defined in - [RFC 2560]. - - Additional access descriptors may be defined in other PKIX - specifications. - -4.2.2.2 Subject Information Access - - The subject information access extension indicates how to access - information and services for the subject of the certificate in which - the extension appears. When the subject is a CA, information and - services may include certificate validation services and CA policy - - - -Housley, et. al. Standards Track [Page 46] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - data. When the subject is an end entity, the information describes - the type of services offered and how to access them. In this case, - the contents of this extension are defined in the protocol - specifications for the suported services. This extension may be - included in subject or CA certificates, and it MUST be non-critical. - - id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } - - SubjectInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - - AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - - Each entry in the sequence SubjectInfoAccessSyntax describes the - format and location of additional information provided by the subject - of the certificate in which this extension appears. The type and - format of the information is specified by the accessMethod field; the - accessLocation field specifies the location of the information. The - retrieval mechanism may be implied by the accessMethod or specified - by accessLocation. - - This profile defines one access method to be used when the subject is - a CA, and one access method to be used when the subject is an end - entity. Additional access methods may be defined in the future in - the protocol specifications for other services. - - The id-ad-caRepository OID is used when the subject is a CA, and - publishes its certificates and CRLs (if issued) in a repository. The - accessLocation field is defined as a GeneralName, which can take - several forms. Where the information is available via http, ftp, or - ldap, accessLocation MUST be a uniformResourceIdentifier. Where the - information is available via the directory access protocol (dap), - accessLocation MUST be a directoryName. When the information is - available via electronic mail, accessLocation MUST be an rfc822Name. - The semantics of other name forms of of accessLocation (when - accessMethod is id-ad-caRepository) are not defined by this - specification. - - The id-ad-timeStamping OID is used when the subject offers - timestamping services using the Time Stamp Protocol defined in - [PKIXTSA]. Where the timestamping services are available via http or - ftp, accessLocation MUST be a uniformResourceIdentifier. Where the - timestamping services are available via electronic mail, - accessLocation MUST be an rfc822Name. Where timestamping services - - - - - -Housley, et. al. Standards Track [Page 47] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - are available using TCP/IP, the dNSName or ipAddress name forms may - be used. The semantics of other name forms of accessLocation (when - accessMethod is id-ad-timeStamping) are not defined by this - specification. - - Additional access descriptors may be defined in other PKIX - specifications. - - id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - - id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } - - id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } - -5 CRL and CRL Extensions Profile - - As discussed above, one goal of this X.509 v2 CRL profile is to - foster the creation of an interoperable and reusable Internet PKI. - To achieve this goal, guidelines for the use of extensions are - specified, and some assumptions are made about the nature of - information included in the CRL. - - CRLs may be used in a wide range of applications and environments - covering a broad spectrum of interoperability goals and an even - broader spectrum of operational and assurance requirements. This - profile establishes a common baseline for generic applications - requiring broad interoperability. The profile defines a set of - information that can be expected in every CRL. Also, the profile - defines common locations within the CRL for frequently used - attributes as well as common representations for these attributes. - - CRL issuers issue CRLs. In general, the CRL issuer is the CA. CAs - publish CRLs to provide status information about the certificates - they issued. However, a CA may delegate this responsibility to - another trusted authority. Whenever the CRL issuer is not the CA - that issued the certificates, the CRL is referred to as an indirect - CRL. - - Each CRL has a particular scope. The CRL scope is the set of - certificates that could appear on a given CRL. For example, the - scope could be "all certificates issued by CA X", "all CA - certificates issued by CA X", "all certificates issued by CA X that - have been revoked for reasons of key compromise and CA compromise", - or could be a set of certificates based on arbitrary local - information, such as "all certificates issued to the NIST employees - located in Boulder". - - - - - -Housley, et. al. Standards Track [Page 48] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - A complete CRL lists all unexpired certificates, within its scope, - that have been revoked for one of the revocation reasons covered by - the CRL scope. The CRL issuer MAY also generate delta CRLs. A delta - CRL only lists those certificates, within its scope, whose revocation - status has changed since the issuance of a referenced complete CRL. - The referenced complete CRL is referred to as a base CRL. The scope - of a delta CRL MUST be the same as the base CRL that it references. - - This profile does not define any private Internet CRL extensions or - CRL entry extensions. - - Environments with additional or special purpose requirements may - build on this profile or may replace it. - - Conforming CAs are not required to issue CRLs if other revocation or - certificate status mechanisms are provided. When CRLs are issued, - the CRLs MUST be version 2 CRLs, include the date by which the next - CRL will be issued in the nextUpdate field (section 5.1.2.5), include - the CRL number extension (section 5.2.3), and include the authority - key identifier extension (section 5.2.1). Conforming applications - that support CRLs are REQUIRED to process both version 1 and version - 2 complete CRLs that provide revocation information for all - certificates issued by one CA. Conforming applications are NOT - REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs - with a scope other than all certificates issued by one CA. - -5.1 CRL Fields - - The X.509 v2 CRL syntax is as follows. For signature calculation, - the data that is to be signed is ASN.1 DER encoded. ASN.1 DER - encoding is a tag, length, value encoding system for each element. - - CertificateList ::= SEQUENCE { - tbsCertList TBSCertList, - signatureAlgorithm AlgorithmIdentifier, - signatureValue BIT STRING } - - - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 49] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - TBSCertList ::= SEQUENCE { - version Version OPTIONAL, - -- if present, MUST be v2 - signature AlgorithmIdentifier, - issuer Name, - thisUpdate Time, - nextUpdate Time OPTIONAL, - revokedCertificates SEQUENCE OF SEQUENCE { - userCertificate CertificateSerialNumber, - revocationDate Time, - crlEntryExtensions Extensions OPTIONAL - -- if present, MUST be v2 - } OPTIONAL, - crlExtensions [0] EXPLICIT Extensions OPTIONAL - -- if present, MUST be v2 - } - - -- Version, Time, CertificateSerialNumber, and Extensions - -- are all defined in the ASN.1 in section 4.1 - - -- AlgorithmIdentifier is defined in section 4.1.1.2 - - The following items describe the use of the X.509 v2 CRL in the - Internet PKI. - -5.1.1 CertificateList Fields - - The CertificateList is a SEQUENCE of three required fields. The - fields are described in detail in the following subsections. - -5.1.1.1 tbsCertList - - The first field in the sequence is the tbsCertList. This field is - itself a sequence containing the name of the issuer, issue date, - issue date of the next list, the optional list of revoked - certificates, and optional CRL extensions. When there are no revoked - certificates, the revoked certificates list is absent. When one or - more certificates are revoked, each entry on the revoked certificate - list is defined by a sequence of user certificate serial number, - revocation date, and optional CRL entry extensions. - -5.1.1.2 signatureAlgorithm - - The signatureAlgorithm field contains the algorithm identifier for - the algorithm used by the CRL issuer to sign the CertificateList. - The field is of type AlgorithmIdentifier, which is defined in section - 4.1.1.2. [PKIXALGS] lists the supported algorithms for this - specification, but other signature algorithms MAY also be supported. - - - -Housley, et. al. Standards Track [Page 50] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - This field MUST contain the same algorithm identifier as the - signature field in the sequence tbsCertList (section 5.1.2.2). - -5.1.1.3 signatureValue - - The signatureValue field contains a digital signature computed upon - the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList - is used as the input to the signature function. This signature value - is encoded as a BIT STRING and included in the CRL signatureValue - field. The details of this process are specified for each of the - supported algorithms in [PKIXALGS]. - - CAs that are also CRL issuers MAY use one private key to digitally - sign certificates and CRLs, or MAY use separate private keys to - digitally sign certificates and CRLs. When separate private keys are - employed, each of the public keys associated with these private keys - is placed in a separate certificate, one with the keyCertSign bit set - in the key usage extension, and one with the cRLSign bit set in the - key usage extension (section 4.2.1.3). When separate private keys - are employed, certificates issued by the CA contain one authority key - identifier, and the corresponding CRLs contain a different authority - key identifier. The use of separate CA certificates for validation - of certificate signatures and CRL signatures can offer improved - security characteristics; however, it imposes a burden on - applications, and it might limit interoperability. Many applications - construct a certification path, and then validate the certification - path (section 6). CRL checking in turn requires a separate - certification path to be constructed and validated for the CA's CRL - signature validation certificate. Applications that perform CRL - checking MUST support certification path validation when certificates - and CRLs are digitally signed with the same CA private key. These - applications SHOULD support certification path validation when - certificates and CRLs are digitally signed with different CA private - keys. - -5.1.2 Certificate List "To Be Signed" - - The certificate list to be signed, or TBSCertList, is a sequence of - required and optional fields. The required fields identify the CRL - issuer, the algorithm used to sign the CRL, the date and time the CRL - was issued, and the date and time by which the CRL issuer will issue - the next CRL. - - Optional fields include lists of revoked certificates and CRL - extensions. The revoked certificate list is optional to support the - case where a CA has not revoked any unexpired certificates that it - - - - - -Housley, et. al. Standards Track [Page 51] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - has issued. The profile requires conforming CRL issuers to use the - CRL number and authority key identifier CRL extensions in all CRLs - issued. - -5.1.2.1 Version - - This optional field describes the version of the encoded CRL. When - extensions are used, as required by this profile, this field MUST be - present and MUST specify version 2 (the integer value is 1). - -5.1.2.2 Signature - - This field contains the algorithm identifier for the algorithm used - to sign the CRL. [PKIXALGS] lists OIDs for the most popular - signature algorithms used in the Internet PKI. - - This field MUST contain the same algorithm identifier as the - signatureAlgorithm field in the sequence CertificateList (section - 5.1.1.2). - -5.1.2.3 Issuer Name - - The issuer name identifies the entity who has signed and issued the - CRL. The issuer identity is carried in the issuer name field. - Alternative name forms may also appear in the issuerAltName extension - (section 5.2.2). The issuer name field MUST contain an X.500 - distinguished name (DN). The issuer name field is defined as the - X.501 type Name, and MUST follow the encoding rules for the issuer - name field in the certificate (section 4.1.2.4). - -5.1.2.4 This Update - - This field indicates the issue date of this CRL. ThisUpdate may be - encoded as UTCTime or GeneralizedTime. - - CRL issuers conforming to this profile MUST encode thisUpdate as - UTCTime for dates through the year 2049. CRL issuers conforming to - this profile MUST encode thisUpdate as GeneralizedTime for dates in - the year 2050 or later. - - Where encoded as UTCTime, thisUpdate MUST be specified and - interpreted as defined in section 4.1.2.5.1. Where encoded as - GeneralizedTime, thisUpdate MUST be specified and interpreted as - defined in section 4.1.2.5.2. - - - - - - - -Housley, et. al. Standards Track [Page 52] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -5.1.2.5 Next Update - - This field indicates the date by which the next CRL will be issued. - The next CRL could be issued before the indicated date, but it will - not be issued any later than the indicated date. CRL issuers SHOULD - issue CRLs with a nextUpdate time equal to or later than all previous - CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. - - This profile requires inclusion of nextUpdate in all CRLs issued by - conforming CRL issuers. Note that the ASN.1 syntax of TBSCertList - describes this field as OPTIONAL, which is consistent with the ASN.1 - structure defined in [X.509]. The behavior of clients processing - CRLs which omit nextUpdate is not specified by this profile. - - CRL issuers conforming to this profile MUST encode nextUpdate as - UTCTime for dates through the year 2049. CRL issuers conforming to - this profile MUST encode nextUpdate as GeneralizedTime for dates in - the year 2050 or later. - - Where encoded as UTCTime, nextUpdate MUST be specified and - interpreted as defined in section 4.1.2.5.1. Where encoded as - GeneralizedTime, nextUpdate MUST be specified and interpreted as - defined in section 4.1.2.5.2. - -5.1.2.6 Revoked Certificates - - When there are no revoked certificates, the revoked certificates list - MUST be absent. Otherwise, revoked certificates are listed by their - serial numbers. Certificates revoked by the CA are uniquely - identified by the certificate serial number. The date on which the - revocation occurred is specified. The time for revocationDate MUST - be expressed as described in section 5.1.2.4. Additional information - may be supplied in CRL entry extensions; CRL entry extensions are - discussed in section 5.3. - -5.1.2.7 Extensions - - This field may only appear if the version is 2 (section 5.1.2.1). If - present, this field is a sequence of one or more CRL extensions. CRL - extensions are discussed in section 5.2. - -5.2 CRL Extensions - - The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 - CRLs [X.509] [X9.55] provide methods for associating additional - attributes with CRLs. The X.509 v2 CRL format also allows - communities to define private extensions to carry information unique - to those communities. Each extension in a CRL may be designated as - - - -Housley, et. al. Standards Track [Page 53] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - critical or non-critical. A CRL validation MUST fail if it - encounters a critical extension which it does not know how to - process. However, an unrecognized non-critical extension may be - ignored. The following subsections present those extensions used - within Internet CRLs. Communities may elect to include extensions in - CRLs which are not defined in this specification. However, caution - should be exercised in adopting any critical extensions in CRLs which - might be used in a general context. - - Conforming CRL issuers are REQUIRED to include the authority key - identifier (section 5.2.1) and the CRL number (section 5.2.3) - extensions in all CRLs issued. - -5.2.1 Authority Key Identifier - - The authority key identifier extension provides a means of - identifying the public key corresponding to the private key used to - sign a CRL. The identification can be based on either the key - identifier (the subject key identifier in the CRL signer's - certificate) or on the issuer name and serial number. This extension - is especially useful where an issuer has more than one signing key, - either due to multiple concurrent key pairs or due to changeover. - - Conforming CRL issuers MUST use the key identifier method, and MUST - include this extension in all CRLs issued. - - The syntax for this CRL extension is defined in section 4.2.1.1. - -5.2.2 Issuer Alternative Name - - The issuer alternative names extension allows additional identities - to be associated with the issuer of the CRL. Defined options include - an rfc822 name (electronic mail address), a DNS name, an IP address, - and a URI. Multiple instances of a name and multiple name forms may - be included. Whenever such identities are used, the issuer - alternative name extension MUST be used; however, a DNS name MAY be - represented in the issuer field using the domainComponent attribute - as described in section 4.1.2.4. - - The issuerAltName extension SHOULD NOT be marked critical. - - The OID and syntax for this CRL extension are defined in section - 4.2.1.8. - - - - - - - - -Housley, et. al. Standards Track [Page 54] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -5.2.3 CRL Number - - The CRL number is a non-critical CRL extension which conveys a - monotonically increasing sequence number for a given CRL scope and - CRL issuer. This extension allows users to easily determine when a - particular CRL supersedes another CRL. CRL numbers also support the - identification of complementary complete CRLs and delta CRLs. CRL - issuers conforming to this profile MUST include this extension in all - CRLs. - - If a CRL issuer generates delta CRLs in addition to complete CRLs for - a given scope, the complete CRLs and delta CRLs MUST share one - numbering sequence. If a delta CRL and a complete CRL that cover the - same scope are issued at the same time, they MUST have the same CRL - number and provide the same revocation information. That is, the - combination of the delta CRL and an acceptable complete CRL MUST - provide the same revocation information as the simultaneously issued - complete CRL. - - If a CRL issuer generates two CRLs (two complete CRLs, two delta - CRLs, or a complete CRL and a delta CRL) for the same scope at - different times, the two CRLs MUST NOT have the same CRL number. - That is, if the this update field (section 5.1.2.4) in the two CRLs - are not identical, the CRL numbers MUST be different. - - Given the requirements above, CRL numbers can be expected to contain - long integers. CRL verifiers MUST be able to handle CRLNumber values - up to 20 octets. Conformant CRL issuers MUST NOT use CRLNumber - values longer than 20 octets. - - id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } - - CRLNumber ::= INTEGER (0..MAX) - -5.2.4 Delta CRL Indicator - - The delta CRL indicator is a critical CRL extension that identifies a - CRL as being a delta CRL. Delta CRLs contain updates to revocation - information previously distributed, rather than all the information - that would appear in a complete CRL. The use of delta CRLs can - significantly reduce network load and processing time in some - environments. Delta CRLs are generally smaller than the CRLs they - update, so applications that obtain delta CRLs consume less network - bandwidth than applications that obtain the corresponding complete - CRLs. Applications which store revocation information in a format - other than the CRL structure can add new revocation information to - the local database without reprocessing information. - - - - -Housley, et. al. Standards Track [Page 55] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The delta CRL indicator extension contains the single value of type - BaseCRLNumber. The CRL number identifies the CRL, complete for a - given scope, that was used as the starting point in the generation of - this delta CRL. A conforming CRL issuer MUST publish the referenced - base CRL as a complete CRL. The delta CRL contains all updates to - the revocation status for that same scope. The combination of a - delta CRL plus the referenced base CRL is equivalent to a complete - CRL, for the applicable scope, at the time of publication of the - delta CRL. - - When a conforming CRL issuer generates a delta CRL, the delta CRL - MUST include a critical delta CRL indicator extension. - - When a delta CRL is issued, it MUST cover the same set of reasons and - the same set of certificates that were covered by the base CRL it - references. That is, the scope of the delta CRL MUST be the same as - the scope of the complete CRL referenced as the base. The referenced - base CRL and the delta CRL MUST omit the issuing distribution point - extension or contain identical issuing distribution point extensions. - Further, the CRL issuer MUST use the same private key to sign the - delta CRL and any complete CRL that it can be used to update. - - An application that supports delta CRLs can construct a CRL that is - complete for a given scope by combining a delta CRL for that scope - with either an issued CRL that is complete for that scope or a - locally constructed CRL that is complete for that scope. - - When a delta CRL is combined with a complete CRL or a locally - constructed CRL, the resulting locally constructed CRL has the CRL - number specified in the CRL number extension found in the delta CRL - used in its construction. In addition, the resulting locally - constructed CRL has the thisUpdate and nextUpdate times specified in - the corresponding fields of the delta CRL used in its construction. - In addition, the locally constructed CRL inherits the issuing - distribution point from the delta CRL. - - A complete CRL and a delta CRL MAY be combined if the following four - conditions are satisfied: - - (a) The complete CRL and delta CRL have the same issuer. - - (b) The complete CRL and delta CRL have the same scope. The two - CRLs have the same scope if either of the following conditions are - met: - - (1) The issuingDistributionPoint extension is omitted from - both the complete CRL and the delta CRL. - - - - -Housley, et. al. Standards Track [Page 56] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (2) The issuingDistributionPoint extension is present in both - the complete CRL and the delta CRL, and the values for each of - the fields in the extensions are the same in both CRLs. - - (c) The CRL number of the complete CRL is equal to or greater - than the BaseCRLNumber specified in the delta CRL. That is, the - complete CRL contains (at a minimum) all the revocation - information held by the referenced base CRL. - - (d) The CRL number of the complete CRL is less than the CRL - number of the delta CRL. That is, the delta CRL follows the - complete CRL in the numbering sequence. - - CRL issuers MUST ensure that the combination of a delta CRL and any - appropriate complete CRL accurately reflects the current revocation - status. The CRL issuer MUST include an entry in the delta CRL for - each certificate within the scope of the delta CRL whose status has - changed since the generation of the referenced base CRL: - - (a) If the certificate is revoked for a reason included in the - scope of the CRL, list the certificate as revoked. - - (b) If the certificate is valid and was listed on the referenced - base CRL or any subsequent CRL with reason code certificateHold, - and the reason code certificateHold is included in the scope of - the CRL, list the certificate with the reason code removeFromCRL. - - (c) If the certificate is revoked for a reason outside the scope - of the CRL, but the certificate was listed on the referenced base - CRL or any subsequent CRL with a reason code included in the scope - of this CRL, list the certificate as revoked but omit the reason - code. - - (d) If the certificate is revoked for a reason outside the scope - of the CRL and the certificate was neither listed on the - referenced base CRL nor any subsequent CRL with a reason code - included in the scope of this CRL, do not list the certificate on - this CRL. - - The status of a certificate is considered to have changed if it is - revoked, placed on hold, released from hold, or if its revocation - reason changes. - - It is appropriate to list a certificate with reason code - removeFromCRL on a delta CRL even if the certificate was not on hold - in the referenced base CRL. If the certificate was placed on hold in - - - - - -Housley, et. al. Standards Track [Page 57] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - any CRL issued after the base but before this delta CRL and then - released from hold, it MUST be listed on the delta CRL with - revocation reason removeFromCRL. - - A CRL issuer MAY optionally list a certificate on a delta CRL with - reason code removeFromCRL if the notAfter time specified in the - certificate precedes the thisUpdate time specified in the delta CRL - and the certificate was listed on the referenced base CRL or in any - CRL issued after the base but before this delta CRL. - - If a certificate revocation notice first appears on a delta CRL, then - it is possible for the certificate validity period to expire before - the next complete CRL for the same scope is issued. In this case, - the revocation notice MUST be included in all subsequent delta CRLs - until the revocation notice is included on at least one explicitly - issued complete CRL for this scope. - - An application that supports delta CRLs MUST be able to construct a - current complete CRL by combining a previously issued complete CRL - and the most current delta CRL. An application that supports delta - CRLs MAY also be able to construct a current complete CRL by - combining a previously locally constructed complete CRL and the - current delta CRL. A delta CRL is considered to be the current one - if the current time is between the times contained in the thisUpdate - and nextUpdate fields. Under some circumstances, the CRL issuer may - publish one or more delta CRLs before indicated by the nextUpdate - field. If more than one current delta CRL for a given scope is - encountered, the application SHOULD consider the one with the latest - value in thisUpdate to be the most current one. - - id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } - - BaseCRLNumber ::= CRLNumber - -5.2.5 Issuing Distribution Point - - The issuing distribution point is a critical CRL extension that - identifies the CRL distribution point and scope for a particular CRL, - and it indicates whether the CRL covers revocation for end entity - certificates only, CA certificates only, attribute certificates only, - - or a limited set of reason codes. Although the extension is - critical, conforming implementations are not required to support this - extension. - - - - - - - -Housley, et. al. Standards Track [Page 58] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The CRL is signed using the CRL issuer's private key. CRL - Distribution Points do not have their own key pairs. If the CRL is - stored in the X.500 Directory, it is stored in the Directory entry - corresponding to the CRL distribution point, which may be different - than the Directory entry of the CRL issuer. - - The reason codes associated with a distribution point MUST be - specified in onlySomeReasons. If onlySomeReasons does not appear, - the distribution point MUST contain revocations for all reason codes. - CAs may use CRL distribution points to partition the CRL on the basis - of compromise and routine revocation. In this case, the revocations - with reason code keyCompromise (1), cACompromise (2), and - aACompromise (8) appear in one distribution point, and the - revocations with other reason codes appear in another distribution - point. - - If the distributionPoint field is present and contains a URI, the - following semantics MUST be assumed: the object is a pointer to the - most current CRL issued by this CRL issuer. The URI schemes ftp, - http, mailto [RFC1738] and ldap [RFC1778] are defined for this - purpose. The URI MUST be an absolute pathname, not a relative - pathname, and MUST specify the host. - - If the distributionPoint field is absent, the CRL MUST contain - entries for all revoked unexpired certificates issued by the CRL - issuer, if any, within the scope of the CRL. - - The CRL issuer MUST assert the indirectCRL boolean, if the scope of - the CRL includes certificates issued by authorities other than the - CRL issuer. The authority responsible for each entry is indicated by - the certificate issuer CRL entry extension (section 5.3.4). - - id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } - - issuingDistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, - onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, - onlySomeReasons [3] ReasonFlags OPTIONAL, - indirectCRL [4] BOOLEAN DEFAULT FALSE, - onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } - -5.2.6 Freshest CRL (a.k.a. Delta CRL Distribution Point) - - The freshest CRL extension identifies how delta CRL information for - this complete CRL is obtained. The extension MUST be non-critical. - This extension MUST NOT appear in delta CRLs. - - - - -Housley, et. al. Standards Track [Page 59] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The same syntax is used for this extension as the - cRLDistributionPoints certificate extension, and is described in - section 4.2.1.14. However, only the distribution point field is - meaningful in this context. The reasons and CRLIssuer fields MUST be - omitted from this CRL extension. - - Each distribution point name provides the location at which a delta - CRL for this complete CRL can be found. The scope of these delta - CRLs MUST be the same as the scope of this complete CRL. The - contents of this CRL extension are only used to locate delta CRLs; - the contents are not used to validate the CRL or the referenced delta - CRLs. The encoding conventions defined for distribution points in - section 4.2.1.14 apply to this extension. - - id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - - FreshestCRL ::= CRLDistributionPoints - -5.3 CRL Entry Extensions - - The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for - X.509 v2 CRLs provide methods for associating additional attributes - with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also - allows communities to define private CRL entry extensions to carry - information unique to those communities. Each extension in a CRL - entry may be designated as critical or non-critical. A CRL - validation MUST fail if it encounters a critical CRL entry extension - which it does not know how to process. However, an unrecognized non- - critical CRL entry extension may be ignored. The following - subsections present recommended extensions used within Internet CRL - entries and standard locations for information. Communities may - elect to use additional CRL entry extensions; however, caution should - be exercised in adopting any critical extensions in CRL entries which - might be used in a general context. - - All CRL entry extensions used in this specification are non-critical. - Support for these extensions is optional for conforming CRL issuers - and applications. However, CRL issuers SHOULD include reason codes - (section 5.3.1) and invalidity dates (section 5.3.3) whenever this - information is available. - -5.3.1 Reason Code - - The reasonCode is a non-critical CRL entry extension that identifies - the reason for the certificate revocation. CRL issuers are strongly - encouraged to include meaningful reason codes in CRL entries; - however, the reason code CRL entry extension SHOULD be absent instead - of using the unspecified (0) reasonCode value. - - - -Housley, et. al. Standards Track [Page 60] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 } - - -- reasonCode ::= { CRLReason } - - CRLReason ::= ENUMERATED { - unspecified (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - removeFromCRL (8), - privilegeWithdrawn (9), - aACompromise (10) } - -5.3.2 Hold Instruction Code - - The hold instruction code is a non-critical CRL entry extension that - provides a registered instruction identifier which indicates the - action to be taken after encountering a certificate that has been - placed on hold. - - id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } - - holdInstructionCode ::= OBJECT IDENTIFIER - - The following instruction codes have been defined. Conforming - applications that process this extension MUST recognize the following - instruction codes. - - holdInstruction OBJECT IDENTIFIER ::= - { iso(1) member-body(2) us(840) x9-57(10040) 2 } - - id-holdinstruction-none OBJECT IDENTIFIER ::= {holdInstruction 1} - id-holdinstruction-callissuer - OBJECT IDENTIFIER ::= {holdInstruction 2} - id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} - - Conforming applications which encounter an id-holdinstruction- - callissuer MUST call the certificate issuer or reject the - certificate. Conforming applications which encounter an id- - holdinstruction-reject MUST reject the certificate. The hold - instruction id-holdinstruction-none is semantically equivalent to the - absence of a holdInstructionCode, and its use is strongly deprecated - for the Internet PKI. - - - - - -Housley, et. al. Standards Track [Page 61] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -5.3.3 Invalidity Date - - The invalidity date is a non-critical CRL entry extension that - provides the date on which it is known or suspected that the private - key was compromised or that the certificate otherwise became invalid. - This date may be earlier than the revocation date in the CRL entry, - which is the date at which the CA processed the revocation. When a - revocation is first posted by a CRL issuer in a CRL, the invalidity - date may precede the date of issue of earlier CRLs, but the - revocation date SHOULD NOT precede the date of issue of earlier CRLs. - Whenever this information is available, CRL issuers are strongly - encouraged to share it with CRL users. - - The GeneralizedTime values included in this field MUST be expressed - in Greenwich Mean Time (Zulu), and MUST be specified and interpreted - as defined in section 4.1.2.5.2. - - id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } - - invalidityDate ::= GeneralizedTime - -5.3.4 Certificate Issuer - - This CRL entry extension identifies the certificate issuer associated - with an entry in an indirect CRL, that is, a CRL that has the - indirectCRL indicator set in its issuing distribution point - extension. If this extension is not present on the first entry in an - indirect CRL, the certificate issuer defaults to the CRL issuer. On - subsequent entries in an indirect CRL, if this extension is not - present, the certificate issuer for the entry is the same as that for - the preceding entry. This field is defined as follows: - - id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } - - certificateIssuer ::= GeneralNames - - If used by conforming CRL issuers, this extension MUST always be - critical. If an implementation ignored this extension it could not - correctly attribute CRL entries to certificates. This specification - RECOMMENDS that implementations recognize this extension. - -6 Certification Path Validation - - Certification path validation procedures for the Internet PKI are - based on the algorithm supplied in [X.509]. Certification path - processing verifies the binding between the subject distinguished - name and/or subject alternative name and subject public key. The - binding is limited by constraints which are specified in the - - - -Housley, et. al. Standards Track [Page 62] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - certificates which comprise the path and inputs which are specified - by the relying party. The basic constraints and policy constraints - extensions allow the certification path processing logic to automate - the decision making process. - - This section describes an algorithm for validating certification - paths. Conforming implementations of this specification are not - required to implement this algorithm, but MUST provide functionality - equivalent to the external behavior resulting from this procedure. - Any algorithm may be used by a particular implementation so long as - it derives the correct result. - - In section 6.1, the text describes basic path validation. Valid - paths begin with certificates issued by a trust anchor. The - algorithm requires the public key of the CA, the CA's name, and any - constraints upon the set of paths which may be validated using this - key. - - The selection of a trust anchor is a matter of policy: it could be - the top CA in a hierarchical PKI; the CA that issued the verifier's - own certificate(s); or any other CA in a network PKI. The path - validation procedure is the same regardless of the choice of trust - anchor. In addition, different applications may rely on different - trust anchor, or may accept paths that begin with any of a set of - trust anchor. - - Section 6.2 describes methods for using the path validation algorithm - in specific implementations. Two specific cases are discussed: the - case where paths may begin with one of several trusted CAs; and where - compatibility with the PEM architecture is required. - - Section 6.3 describes the steps necessary to determine if a - certificate is revoked or on hold status when CRLs are the revocation - mechanism used by the certificate issuer. - -6.1 Basic Path Validation - - This text describes an algorithm for X.509 path processing. A - conformant implementation MUST include an X.509 path processing - procedure that is functionally equivalent to the external behavior of - this algorithm. However, support for some of the certificate - extensions processed in this algorithm are OPTIONAL for compliant - implementations. Clients that do not support these extensions MAY - omit the corresponding steps in the path validation algorithm. - - - - - - - -Housley, et. al. Standards Track [Page 63] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - For example, clients are NOT REQUIRED to support the policy mapping - extension. Clients that do not support this extension MAY omit the - path validation steps where policy mappings are processed. Note that - clients MUST reject the certificate if it contains an unsupported - critical extension. - - The algorithm presented in this section validates the certificate - with respect to the current date and time. A conformant - implementation MAY also support validation with respect to some point - in the past. Note that mechanisms are not available for validating a - certificate with respect to a time outside the certificate validity - period. - - The trust anchor is an input to the algorithm. There is no - requirement that the same trust anchor be used to validate all - certification paths. Different trust anchors MAY be used to validate - different paths, as discussed further in Section 6.2. - - The primary goal of path validation is to verify the binding between - a subject distinguished name or a subject alternative name and - subject public key, as represented in the end entity certificate, - based on the public key of the trust anchor. This requires obtaining - a sequence of certificates that support that binding. The procedure - performed to obtain this sequence of certificates is outside the - scope of this specification. - - To meet this goal, the path validation process verifies, among other - things, that a prospective certification path (a sequence of n - certificates) satisfies the following conditions: - - (a) for all x in {1, ..., n-1}, the subject of certificate x is - the issuer of certificate x+1; - - (b) certificate 1 is issued by the trust anchor; - - (c) certificate n is the certificate to be validated; and - - (d) for all x in {1, ..., n}, the certificate was valid at the - time in question. - - When the trust anchor is provided in the form of a self-signed - certificate, this self-signed certificate is not included as part of - the prospective certification path. Information about trust anchors - are provided as inputs to the certification path validation algorithm - (section 6.1.1). - - - - - - -Housley, et. al. Standards Track [Page 64] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - A particular certification path may not, however, be appropriate for - all applications. Therefore, an application MAY augment this - algorithm to further limit the set of valid paths. The path - validation process also determines the set of certificate policies - that are valid for this path, based on the certificate policies - extension, policy mapping extension, policy constraints extension, - and inhibit any-policy extension. To achieve this, the path - validation algorithm constructs a valid policy tree. If the set of - certificate policies that are valid for this path is not empty, then - the result will be a valid policy tree of depth n, otherwise the - result will be a null valid policy tree. - - A certificate is self-issued if the DNs that appear in the subject - and issuer fields are identical and are not empty. In general, the - issuer and subject of the certificates that make up a path are - different for each certificate. However, a CA may issue a - certificate to itself to support key rollover or changes in - certificate policies. These self-issued certificates are not counted - when evaluating path length or name constraints. - - This section presents the algorithm in four basic steps: (1) - initialization, (2) basic certificate processing, (3) preparation for - the next certificate, and (4) wrap-up. Steps (1) and (4) are - performed exactly once. Step (2) is performed for all certificates - in the path. Step (3) is performed for all certificates in the path - except the final certificate. Figure 2 provides a high-level - flowchart of this algorithm. - - - - - - - - - - - - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 65] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +-------+ - | START | - +-------+ - | - V - +----------------+ - | Initialization | - +----------------+ - | - +<--------------------+ - | | - V | - +----------------+ | - | Process Cert | | - +----------------+ | - | | - V | - +================+ | - | IF Last Cert | | - | in Path | | - +================+ | - | | | - THEN | | ELSE | - V V | - +----------------+ +----------------+ | - | Wrap up | | Prepare for | | - +----------------+ | Next Cert | | - | +----------------+ | - V | | - +-------+ +--------------+ - | STOP | - +-------+ - - - Figure 2. Certification Path Processing Flowchart - -6.1.1 Inputs - - This algorithm assumes the following seven inputs are provided to the - path processing logic: - - (a) a prospective certification path of length n. - - (b) the current date/time. - - - - - - - -Housley, et. al. Standards Track [Page 66] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (c) user-initial-policy-set: A set of certificate policy - identifiers naming the policies that are acceptable to the - certificate user. The user-initial-policy-set contains the - special value any-policy if the user is not concerned about - certificate policy. - - (d) trust anchor information, describing a CA that serves as a - trust anchor for the certification path. The trust anchor - information includes: - - (1) the trusted issuer name, - - (2) the trusted public key algorithm, - - (3) the trusted public key, and - - (4) optionally, the trusted public key parameters associated - with the public key. - - The trust anchor information may be provided to the path - processing procedure in the form of a self-signed certificate. - The trusted anchor information is trusted because it was delivered - to the path processing procedure by some trustworthy out-of-band - procedure. If the trusted public key algorithm requires - parameters, then the parameters are provided along with the - trusted public key. - - (e) initial-policy-mapping-inhibit, which indicates if policy - mapping is allowed in the certification path. - - (f) initial-explicit-policy, which indicates if the path must be - valid for at least one of the certificate policies in the user- - initial-policy-set. - - (g) initial-any-policy-inhibit, which indicates whether the - anyPolicy OID should be processed if it is included in a - certificate. - -6.1.2 Initialization - - This initialization phase establishes eleven state variables based - upon the seven inputs: - - (a) valid_policy_tree: A tree of certificate policies with their - optional qualifiers; each of the leaves of the tree represents a - valid policy at this stage in the certification path validation. - If valid policies exist at this stage in the certification path - validation, the depth of the tree is equal to the number of - - - -Housley, et. al. Standards Track [Page 67] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - certificates in the chain that have been processed. If valid - policies do not exist at this stage in the certification path - validation, the tree is set to NULL. Once the tree is set to - NULL, policy processing ceases. - - Each node in the valid_policy_tree includes four data objects: the - valid policy, a set of associated policy qualifiers, a set of one - or more expected policy values, and a criticality indicator. If - the node is at depth x, the components of the node have the - following semantics: - - (1) The valid_policy is a single policy OID representing a - valid policy for the path of length x. - - (2) The qualifier_set is a set of policy qualifiers associated - with the valid policy in certificate x. - - (3) The criticality_indicator indicates whether the - certificate policy extension in certificate x was marked as - critical. - - (4) The expected_policy_set contains one or more policy OIDs - that would satisfy this policy in the certificate x+1. - - The initial value of the valid_policy_tree is a single node with - valid_policy anyPolicy, an empty qualifier_set, an - expected_policy_set with the single value anyPolicy, and a - criticality_indicator of FALSE. This node is considered to be at - depth zero. - - Figure 3 is a graphic representation of the initial state of the - valid_policy_tree. Additional figures will use this format to - describe changes in the valid_policy_tree during path processing. - - +----------------+ - | anyPolicy | <---- valid_policy - +----------------+ - | {} | <---- qualifier_set - +----------------+ - | FALSE | <---- criticality_indicator - +----------------+ - | {anyPolicy} | <---- expected_policy_set - +----------------+ - - Figure 3. Initial value of the valid_policy_tree state variable - - - - - - -Housley, et. al. Standards Track [Page 68] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (b) permitted_subtrees: A set of root names for each name type - (e.g., X.500 distinguished names, email addresses, or ip - addresses) defining a set of subtrees within which all subject - names in subsequent certificates in the certification path MUST - fall. This variable includes a set for each name type: the - initial value for the set for Distinguished Names is the set of - all Distinguished names; the initial value for the set of RFC822 - names is the set of all RFC822 names, etc. - - (c) excluded_subtrees: A set of root names for each name type - (e.g., X.500 distinguished names, email addresses, or ip - addresses) defining a set of subtrees within which no subject name - in subsequent certificates in the certification path may fall. - This variable includes a set for each name type, and the initial - value for each set is empty. - - (d) explicit_policy: an integer which indicates if a non-NULL - valid_policy_tree is required. The integer indicates the number of - non-self-issued certificates to be processed before this - requirement is imposed. Once set, this variable may be decreased, - but may not be increased. That is, if a certificate in the path - requires a non-NULL valid_policy_tree, a later certificate can not - remove this requirement. If initial-explicit-policy is set, then - the initial value is 0, otherwise the initial value is n+1. - - (e) inhibit_any-policy: an integer which indicates whether the - anyPolicy policy identifier is considered a match. The integer - indicates the number of non-self-issued certificates to be - processed before the anyPolicy OID, if asserted in a certificate, - is ignored. Once set, this variable may be decreased, but may not - be increased. That is, if a certificate in the path inhibits - processing of anyPolicy, a later certificate can not permit it. - If initial-any-policy-inhibit is set, then the initial value is 0, - otherwise the initial value is n+1. - - (f) policy_mapping: an integer which indicates if policy mapping - is permitted. The integer indicates the number of non-self-issued - certificates to be processed before policy mapping is inhibited. - Once set, this variable may be decreased, but may not be - increased. That is, if a certificate in the path specifies policy - mapping is not permitted, it can not be overridden by a later - certificate. If initial-policy-mapping-inhibit is set, then the - initial value is 0, otherwise the initial value is n+1. - - (g) working_public_key_algorithm: the digital signature algorithm - used to verify the signature of a certificate. The - working_public_key_algorithm is initialized from the trusted - public key algorithm provided in the trust anchor information. - - - -Housley, et. al. Standards Track [Page 69] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (h) working_public_key: the public key used to verify the - signature of a certificate. The working_public_key is initialized - from the trusted public key provided in the trust anchor - information. - - (i) working_public_key_parameters: parameters associated with the - current public key, that may be required to verify a signature - (depending upon the algorithm). The working_public_key_parameters - variable is initialized from the trusted public key parameters - provided in the trust anchor information. - - (j) working_issuer_name: the issuer distinguished name expected - in the next certificate in the chain. The working_issuer_name is - initialized to the trusted issuer provided in the trust anchor - information. - - (k) max_path_length: this integer is initialized to n, is - decremented for each non-self-issued certificate in the path, and - may be reduced to the value in the path length constraint field - within the basic constraints extension of a CA certificate. - - Upon completion of the initialization steps, perform the basic - certificate processing steps specified in 6.1.3. - -6.1.3 Basic Certificate Processing - - The basic path processing actions to be performed for certificate i - (for all i in [1..n]) are listed below. - - (a) Verify the basic certificate information. The certificate - MUST satisfy each of the following: - - (1) The certificate was signed with the - working_public_key_algorithm using the working_public_key and - the working_public_key_parameters. - - (2) The certificate validity period includes the current time. - - (3) At the current time, the certificate is not revoked and is - not on hold status. This may be determined by obtaining the - appropriate CRL (section 6.3), status information, or by out- - of-band mechanisms. - - (4) The certificate issuer name is the working_issuer_name. - - - - - - - -Housley, et. al. Standards Track [Page 70] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (b) If certificate i is self-issued and it is not the final - certificate in the path, skip this step for certificate i. - Otherwise, verify that the subject name is within one of the - permitted_subtrees for X.500 distinguished names, and verify that - each of the alternative names in the subjectAltName extension - (critical or non-critical) is within one of the permitted_subtrees - for that name type. - - (c) If certificate i is self-issued and it is not the final - certificate in the path, skip this step for certificate i. - Otherwise, verify that the subject name is not within one of the - excluded_subtrees for X.500 distinguished names, and verify that - each of the alternative names in the subjectAltName extension - (critical or non-critical) is not within one of the - excluded_subtrees for that name type. - - (d) If the certificate policies extension is present in the - certificate and the valid_policy_tree is not NULL, process the - policy information by performing the following steps in order: - - (1) For each policy P not equal to anyPolicy in the - certificate policies extension, let P-OID denote the OID in - policy P and P-Q denote the qualifier set for policy P. - Perform the following steps in order: - - (i) If the valid_policy_tree includes a node of depth i-1 - where P-OID is in the expected_policy_set, create a child - node as follows: set the valid_policy to OID-P; set the - qualifier_set to P-Q, and set the expected_policy_set to - {P-OID}. - - For example, consider a valid_policy_tree with a node of - depth i-1 where the expected_policy_set is {Gold, White}. - Assume the certificate policies Gold and Silver appear in - the certificate policies extension of certificate i. The - Gold policy is matched but the Silver policy is not. This - rule will generate a child node of depth i for the Gold - policy. The result is shown as Figure 4. - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 71] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +-----------------+ - | Red | - +-----------------+ - | {} | - +-----------------+ node of depth i-1 - | FALSE | - +-----------------+ - | {Gold, White} | - +-----------------+ - | - | - | - V - +-----------------+ - | Gold | - +-----------------+ - | {} | - +-----------------+ node of depth i - | uninitialized | - +-----------------+ - | {Gold} | - +-----------------+ - - Figure 4. Processing an exact match - - (ii) If there was no match in step (i) and the - valid_policy_tree includes a node of depth i-1 with the - valid policy anyPolicy, generate a child node with the - following values: set the valid_policy to P-OID; set the - qualifier_set to P-Q, and set the expected_policy_set to - {P-OID}. - - For example, consider a valid_policy_tree with a node of - depth i-1 where the valid_policy is anyPolicy. Assume the - certificate policies Gold and Silver appear in the - certificate policies extension of certificate i. The Gold - policy does not have a qualifier, but the Silver policy has - the qualifier Q-Silver. If Gold and Silver were not matched - in (i) above, this rule will generate two child nodes of - depth i, one for each policy. The result is shown as Figure - 5. - - - - - - - - - - -Housley, et. al. Standards Track [Page 72] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +-----------------+ - | anyPolicy | - +-----------------+ - | {} | - +-----------------+ node of depth i-1 - | FALSE | - +-----------------+ - | {anyPolicy} | - +-----------------+ - / \ - / \ - / \ - / \ - +-----------------+ +-----------------+ - | Gold | | Silver | - +-----------------+ +-----------------+ - | {} | | {Q-Silver} | - +-----------------+ nodes of +-----------------+ - | uninitialized | depth i | uninitialized | - +-----------------+ +-----------------+ - | {Gold} | | {Silver} | - +-----------------+ +-----------------+ - - Figure 5. Processing unmatched policies when a leaf node - specifies anyPolicy - - (2) If the certificate policies extension includes the policy - anyPolicy with the qualifier set AP-Q and either (a) - inhibit_any-policy is greater than 0 or (b) i<n and the - certificate is self-issued, then: - - For each node in the valid_policy_tree of depth i-1, for each - value in the expected_policy_set (including anyPolicy) that - does not appear in a child node, create a child node with the - following values: set the valid_policy to the value from the - expected_policy_set in the parent node; set the qualifier_set - to AP-Q, and set the expected_policy_set to the value in the - valid_policy from this node. - - For example, consider a valid_policy_tree with a node of depth - i-1 where the expected_policy_set is {Gold, Silver}. Assume - anyPolicy appears in the certificate policies extension of - certificate i, but Gold and Silver do not. This rule will - generate two child nodes of depth i, one for each policy. The - result is shown below as Figure 6. - - - - - - -Housley, et. al. Standards Track [Page 73] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +-----------------+ - | Red | - +-----------------+ - | {} | - +-----------------+ node of depth i-1 - | FALSE | - +-----------------+ - | {Gold, Silver} | - +-----------------+ - / \ - / \ - / \ - / \ - +-----------------+ +-----------------+ - | Gold | | Silver | - +-----------------+ +-----------------+ - | {} | | {} | - +-----------------+ nodes of +-----------------+ - | uninitialized | depth i | uninitialized | - +-----------------+ +-----------------+ - | {Gold} | | {Silver} | - +-----------------+ +-----------------+ - - Figure 6. Processing unmatched policies when the certificate - policies extension specifies anyPolicy - - (3) If there is a node in the valid_policy_tree of depth i-1 - or less without any child nodes, delete that node. Repeat this - step until there are no nodes of depth i-1 or less without - children. - - For example, consider the valid_policy_tree shown in Figure 7 - below. The two nodes at depth i-1 that are marked with an 'X' - have no children, and are deleted. Applying this rule to the - resulting tree will cause the node at depth i-2 that is marked - with an 'Y' to be deleted. The following application of the - rule does not cause any nodes to be deleted, and this step is - complete. - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 74] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - +-----------+ - | | node of depth i-3 - +-----------+ - / | \ - / | \ - / | \ - +-----------+ +-----------+ +-----------+ - | | | | | Y | nodes of - +-----------+ +-----------+ +-----------+ depth i-2 - / \ | | - / \ | | - / \ | | - +-----------+ +-----------+ +-----------+ +-----------+ nodes of - | | | X | | | | X | depth - +-----------+ +-----------+ +-----------+ +-----------+ i-1 - | / | \ - | / | \ - | / | \ - +-----------+ +-----------+ +-----------+ +-----------+ nodes of - | | | | | | | | depth - +-----------+ +-----------+ +-----------+ +-----------+ i - - Figure 7. Pruning the valid_policy_tree - - (4) If the certificate policies extension was marked as - critical, set the criticality_indicator in all nodes of depth i - to TRUE. If the certificate policies extension was not marked - critical, set the criticality_indicator in all nodes of depth i - to FALSE. - - (e) If the certificate policies extension is not present, set the - valid_policy_tree to NULL. - - (f) Verify that either explicit_policy is greater than 0 or the - valid_policy_tree is not equal to NULL; - - If any of steps (a), (b), (c), or (f) fails, the procedure - terminates, returning a failure indication and an appropriate reason. - - If i is not equal to n, continue by performing the preparatory steps - listed in 6.1.4. If i is equal to n, perform the wrap-up steps - listed in 6.1.5. - -6.1.4 Preparation for Certificate i+1 - - To prepare for processing of certificate i+1, perform the following - steps for certificate i: - - - - -Housley, et. al. Standards Track [Page 75] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (a) If a policy mapping extension is present, verify that the - special value anyPolicy does not appear as an issuerDomainPolicy - or a subjectDomainPolicy. - - (b) If a policy mapping extension is present, then for each - issuerDomainPolicy ID-P in the policy mapping extension: - - (1) If the policy_mapping variable is greater than 0, for each - node in the valid_policy_tree of depth i where ID-P is the - valid_policy, set expected_policy_set to the set of - subjectDomainPolicy values that are specified as equivalent to - ID-P by the policy mapping extension. - - If no node of depth i in the valid_policy_tree has a - valid_policy of ID-P but there is a node of depth i with a - valid_policy of anyPolicy, then generate a child node of the - node of depth i-1 that has a valid_policy of anyPolicy as - follows: - - (i) set the valid_policy to ID-P; - - (ii) set the qualifier_set to the qualifier set of the - policy anyPolicy in the certificate policies extension of - certificate i; - - (iii) set the criticality_indicator to the criticality of - the certificate policies extension of certificate i; - - (iv) and set the expected_policy_set to the set of - subjectDomainPolicy values that are specified as equivalent - to ID-P by the policy mappings extension. - - (2) If the policy_mapping variable is equal to 0: - - (i) delete each node of depth i in the valid_policy_tree - where ID-P is the valid_policy. - - (ii) If there is a node in the valid_policy_tree of depth - i-1 or less without any child nodes, delete that node. - Repeat this step until there are no nodes of depth i-1 or - less without children. - - (c) Assign the certificate subject name to working_issuer_name. - - (d) Assign the certificate subjectPublicKey to - working_public_key. - - - - - -Housley, et. al. Standards Track [Page 76] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (e) If the subjectPublicKeyInfo field of the certificate contains - an algorithm field with non-null parameters, assign the parameters - to the working_public_key_parameters variable. - - If the subjectPublicKeyInfo field of the certificate contains an - algorithm field with null parameters or parameters are omitted, - compare the certificate subjectPublicKey algorithm to the - working_public_key_algorithm. If the certificate subjectPublicKey - algorithm and the working_public_key_algorithm are different, set - the working_public_key_parameters to null. - - (f) Assign the certificate subjectPublicKey algorithm to the - working_public_key_algorithm variable. - - (g) If a name constraints extension is included in the - certificate, modify the permitted_subtrees and excluded_subtrees - state variables as follows: - - (1) If permittedSubtrees is present in the certificate, set - the permitted_subtrees state variable to the intersection of - its previous value and the value indicated in the extension - field. If permittedSubtrees does not include a particular name - type, the permitted_subtrees state variable is unchanged for - that name type. For example, the intersection of nist.gov and - csrc.nist.gov is csrc.nist.gov. And, the intersection of - nist.gov and rsasecurity.com is the empty set. - - (2) If excludedSubtrees is present in the certificate, set the - excluded_subtrees state variable to the union of its previous - value and the value indicated in the extension field. If - excludedSubtrees does not include a particular name type, the - excluded_subtrees state variable is unchanged for that name - type. For example, the union of the name spaces nist.gov and - csrc.nist.gov is nist.gov. And, the union of nist.gov and - rsasecurity.com is both name spaces. - - (h) If the issuer and subject names are not identical: - - (1) If explicit_policy is not 0, decrement explicit_policy by - 1. - - (2) If policy_mapping is not 0, decrement policy_mapping by 1. - - (3) If inhibit_any-policy is not 0, decrement inhibit_any- - policy by 1. - - - - - - -Housley, et. al. Standards Track [Page 77] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (i) If a policy constraints extension is included in the - certificate, modify the explicit_policy and policy_mapping state - variables as follows: - - (1) If requireExplicitPolicy is present and is less than - explicit_policy, set explicit_policy to the value of - requireExplicitPolicy. - - (2) If inhibitPolicyMapping is present and is less than - policy_mapping, set policy_mapping to the value of - inhibitPolicyMapping. - - (j) If the inhibitAnyPolicy extension is included in the - certificate and is less than inhibit_any-policy, set inhibit_any- - policy to the value of inhibitAnyPolicy. - - (k) Verify that the certificate is a CA certificate (as specified - in a basicConstraints extension or as verified out-of-band). - - (l) If the certificate was not self-issued, verify that - max_path_length is greater than zero and decrement max_path_length - by 1. - - (m) If pathLengthConstraint is present in the certificate and is - less than max_path_length, set max_path_length to the value of - pathLengthConstraint. - - (n) If a key usage extension is present, verify that the - keyCertSign bit is set. - - (o) Recognize and process any other critical extension present in - the certificate. Process any other recognized non-critical - extension present in the certificate. - - If check (a), (k), (l), (n) or (o) fails, the procedure terminates, - returning a failure indication and an appropriate reason. - - If (a), (k), (l), (n) and (o) have completed successfully, increment - i and perform the basic certificate processing specified in 6.1.3. - -6.1.5 Wrap-up procedure - - To complete the processing of the end entity certificate, perform the - following steps for certificate n: - - (a) If certificate n was not self-issued and explicit_policy is - not 0, decrement explicit_policy by 1. - - - - -Housley, et. al. Standards Track [Page 78] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (b) If a policy constraints extension is included in the - certificate and requireExplicitPolicy is present and has a value - of 0, set the explicit_policy state variable to 0. - - (c) Assign the certificate subjectPublicKey to - working_public_key. - - (d) If the subjectPublicKeyInfo field of the certificate contains - an algorithm field with non-null parameters, assign the parameters - to the working_public_key_parameters variable. - - If the subjectPublicKeyInfo field of the certificate contains an - algorithm field with null parameters or parameters are omitted, - compare the certificate subjectPublicKey algorithm to the - working_public_key_algorithm. If the certificate subjectPublicKey - algorithm and the working_public_key_algorithm are different, set - the working_public_key_parameters to null. - - (e) Assign the certificate subjectPublicKey algorithm to the - working_public_key_algorithm variable. - - (f) Recognize and process any other critical extension present in - the certificate n. Process any other recognized non-critical - extension present in certificate n. - - (g) Calculate the intersection of the valid_policy_tree and the - user-initial-policy-set, as follows: - - (i) If the valid_policy_tree is NULL, the intersection is - NULL. - - (ii) If the valid_policy_tree is not NULL and the user- - initial-policy-set is any-policy, the intersection is the - entire valid_policy_tree. - - (iii) If the valid_policy_tree is not NULL and the user- - initial-policy-set is not any-policy, calculate the - intersection of the valid_policy_tree and the user-initial- - policy-set as follows: - - 1. Determine the set of policy nodes whose parent nodes - have a valid_policy of anyPolicy. This is the - valid_policy_node_set. - - 2. If the valid_policy of any node in the - valid_policy_node_set is not in the user-initial-policy-set - and is not anyPolicy, delete this node and all its children. - - - - -Housley, et. al. Standards Track [Page 79] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - 3. If the valid_policy_tree includes a node of depth n with - the valid_policy anyPolicy and the user-initial-policy-set - is not any-policy perform the following steps: - - a. Set P-Q to the qualifier_set in the node of depth n - with valid_policy anyPolicy. - - b. For each P-OID in the user-initial-policy-set that is - not the valid_policy of a node in the - valid_policy_node_set, create a child node whose parent - is the node of depth n-1 with the valid_policy anyPolicy. - Set the values in the child node as follows: set the - valid_policy to P-OID; set the qualifier_set to P-Q; copy - the criticality_indicator from the node of depth n with - the valid_policy anyPolicy; and set the - expected_policy_set to {P-OID}. - - c. Delete the node of depth n with the valid_policy - anyPolicy. - - 4. If there is a node in the valid_policy_tree of depth n-1 - or less without any child nodes, delete that node. Repeat - this step until there are no nodes of depth n-1 or less - without children. - - If either (1) the value of explicit_policy variable is greater than - zero, or (2) the valid_policy_tree is not NULL, then path processing - has succeeded. - -6.1.6 Outputs - - If path processing succeeds, the procedure terminates, returning a - success indication together with final value of the - valid_policy_tree, the working_public_key, the - working_public_key_algorithm, and the working_public_key_parameters. - -6.2 Using the Path Validation Algorithm - - The path validation algorithm describes the process of validating a - single certification path. While each certification path begins with - a specific trust anchor, there is no requirement that all - certification paths validated by a particular system share a single - trust anchor. An implementation that supports multiple trust anchors - MAY augment the algorithm presented in section 6.1 to further limit - the set of valid certification paths which begin with a particular - trust anchor. For example, an implementation MAY modify the - algorithm to apply name constraints to a specific trust anchor during - the initialization phase, or the application MAY require the presence - - - -Housley, et. al. Standards Track [Page 80] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - of a particular alternative name form in the end entity certificate, - or the application MAY impose requirements on application-specific - extensions. Thus, the path validation algorithm presented in section - 6.1 defines the minimum conditions for a path to be considered valid. - - The selection of one or more trusted CAs is a local decision. A - system may provide any one of its trusted CAs as the trust anchor for - a particular path. The inputs to the path validation algorithm may - be different for each path. The inputs used to process a path may - reflect application-specific requirements or limitations in the trust - accorded a particular trust anchor. For example, a trusted CA may - only be trusted for a particular certificate policy. This - restriction can be expressed through the inputs to the path - validation procedure. - - It is also possible to specify an extended version of the above - certification path processing procedure which results in default - behavior identical to the rules of PEM [RFC 1422]. In this extended - version, additional inputs to the procedure are a list of one or more - Policy Certification Authority (PCA) names and an indicator of the - position in the certification path where the PCA is expected. At the - nominated PCA position, the CA name is compared against this list. - If a recognized PCA name is found, then a constraint of - SubordinateToCA is implicitly assumed for the remainder of the - certification path and processing continues. If no valid PCA name is - found, and if the certification path cannot be validated on the basis - of identified policies, then the certification path is considered - invalid. - -6.3 CRL Validation - - This section describes the steps necessary to determine if a - certificate is revoked or on hold status when CRLs are the revocation - mechanism used by the certificate issuer. Conforming implementations - that support CRLs are not required to implement this algorithm, but - they MUST be functionally equivalent to the external behavior - resulting from this procedure. Any algorithm may be used by a - particular implementation so long as it derives the correct result. - - This algorithm assumes that all of the needed CRLs are available in a - local cache. Further, if the next update time of a CRL has passed, - the algorithm assumes a mechanism to fetch a current CRL and place it - in the local CRL cache. - - This algorithm defines a set of inputs, a set of state variables, and - processing steps that are performed for each certificate in the path. - The algorithm output is the revocation status of the certificate. - - - - -Housley, et. al. Standards Track [Page 81] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -6.3.1 Revocation Inputs - - To support revocation processing, the algorithm requires two inputs: - - (a) certificate: The algorithm requires the certificate serial - number and issuer name to determine whether a certificate is on a - particular CRL. The basicConstraints extension is used to - determine whether the supplied certificate is associated with a CA - or an end entity. If present, the algorithm uses the - cRLDistributionsPoint and freshestCRL extensions to determine - revocation status. - - (b) use-deltas: This boolean input determines whether delta CRLs - are applied to CRLs. - - Note that implementations supporting legacy PKIs, such as RFC 1422 - and X.509 version 1, will need an additional input indicating - whether the supplied certificate is associated with a CA or an end - entity. - -6.3.2 Initialization and Revocation State Variables - - To support CRL processing, the algorithm requires the following state - variables: - - (a) reasons_mask: This variable contains the set of revocation - reasons supported by the CRLs and delta CRLs processed so far. - The legal members of the set are the possible revocation reason - values: unspecified, keyCompromise, caCompromise, - affiliationChanged, superseded, cessationOfOperation, - certificateHold, privilegeWithdrawn, and aACompromise. The - special value all-reasons is used to denote the set of all legal - members. This variable is initialized to the empty set. - - (b) cert_status: This variable contains the status of the - certificate. This variable may be assigned one of the following - values: unspecified, keyCompromise, caCompromise, - affiliationChanged, superseded, cessationOfOperation, - certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise, - the special value UNREVOKED, or the special value UNDETERMINED. - This variable is initialized to the special value UNREVOKED. - - (c) interim_reasons_mask: This contains the set of revocation - reasons supported by the CRL or delta CRL currently being - processed. - - - - - - -Housley, et. al. Standards Track [Page 82] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - Note: In some environments, it is not necessary to check all reason - codes. For example, some environments are only concerned with - caCompromise and keyCompromise for CA certificates. This algorithm - checks all reason codes. Additional processing and state variables - may be necessary to limit the checking to a subset of the reason - codes. - -6.3.3 CRL Processing - - This algorithm begins by assuming the certificate is not revoked. - The algorithm checks one or more CRLs until either the certificate - status is determined to be revoked or sufficient CRLs have been - checked to cover all reason codes. - - For each distribution point (DP) in the certificate CRL distribution - points extension, for each corresponding CRL in the local CRL cache, - while ((reasons_mask is not all-reasons) and (cert_status is - UNREVOKED)) perform the following: - - (a) Update the local CRL cache by obtaining a complete CRL, a - delta CRL, or both, as required: - - (1) If the current time is after the value of the CRL next - update field, then do one of the following: - - (i) If use-deltas is set and either the certificate or the - CRL contains the freshest CRL extension, obtain a delta CRL - with the a next update value that is after the current time - and can be used to update the locally cached CRL as - specified in section 5.2.4. - - (ii) Update the local CRL cache with a current complete - CRL, verify that the current time is before the next update - value in the new CRL, and continue processing with the new - CRL. If use-deltas is set, then obtain the current delta - CRL that can be used to update the new locally cached - complete CRL as specified in section 5.2.4. - - (2) If the current time is before the value of the next update - field and use-deltas is set, then obtain the current delta CRL - that can be used to update the locally cached complete CRL as - specified in section 5.2.4. - - (b) Verify the issuer and scope of the complete CRL as follows: - - - - - - - -Housley, et. al. Standards Track [Page 83] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (1) If the DP includes cRLIssuer, then verify that the issuer - field in the complete CRL matches cRLIssuer in the DP and that - the complete CRL contains an issuing distribution point - extension with the indrectCRL boolean asserted. Otherwise, - verify that the CRL issuer matches the certificate issuer. - - (2) If the complete CRL includes an issuing distribution point - (IDP) CRL extension check the following: - - (i) If the distribution point name is present in the IDP - CRL extension and the distribution field is present in the - DP, then verify that one of the names in the IDP matches one - of the names in the DP. If the distribution point name is - present in the IDP CRL extension and the distribution field - is omitted from the DP, then verify that one of the names in - the IDP matches one of the names in the cRLIssuer field of - the DP. - - (ii) If the onlyContainsUserCerts boolean is asserted in - the IDP CRL extension, verify that the certificate does not - include the basic constraints extension with the cA boolean - asserted. - - (iii) If the onlyContainsCACerts boolean is asserted in the - IDP CRL extension, verify that the certificate includes the - basic constraints extension with the cA boolean asserted. - - (iv) Verify that the onlyContainsAttributeCerts boolean is - not asserted. - - (c) If use-deltas is set, verify the issuer and scope of the - delta CRL as follows: - - (1) Verify that the delta CRL issuer matches complete CRL - issuer. - - (2) If the complete CRL includes an issuing distribution point - (IDP) CRL extension, verify that the delta CRL contains a - matching IDP CRL extension. If the complete CRL omits an IDP - CRL extension, verify that the delta CRL also omits an IDP CRL - extension. - - (3) Verify that the delta CRL authority key identifier - extension matches complete CRL authority key identifier - extension. - - - - - - -Housley, et. al. Standards Track [Page 84] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (d) Compute the interim_reasons_mask for this CRL as follows: - - (1) If the issuing distribution point (IDP) CRL extension is - present and includes onlySomeReasons and the DP includes - reasons, then set interim_reasons_mask to the intersection of - reasons in the DP and onlySomeReasons in IDP CRL extension. - - (2) If the IDP CRL extension includes onlySomeReasons but the - DP omits reasons, then set interim_reasons_mask to the value of - onlySomeReasons in IDP CRL extension. - - (3) If the IDP CRL extension is not present or omits - onlySomeReasons but the DP includes reasons, then set - interim_reasons_mask to the value of DP reasons. - - (4) If the IDP CRL extension is not present or omits - onlySomeReasons and the DP omits reasons, then set - interim_reasons_mask to the special value all-reasons. - - (e) Verify that interim_reasons_mask includes one or more reasons - that is not included in the reasons_mask. - - (f) Obtain and validate the certification path for the complete CRL - issuer. If a key usage extension is present in the CRL issuer's - certificate, verify that the cRLSign bit is set. - - (g) Validate the signature on the complete CRL using the public key - validated in step (f). - - (h) If use-deltas is set, then validate the signature on the delta - CRL using the public key validated in step (f). - - (i) If use-deltas is set, then search for the certificate on the - delta CRL. If an entry is found that matches the certificate issuer - and serial number as described in section 5.3.4, then set the - cert_status variable to the indicated reason as follows: - - (1) If the reason code CRL entry extension is present, set the - cert_status variable to the value of the reason code CRL entry - extension. - - (2) If the reason code CRL entry extension is not present, set - the cert_status variable to the value unspecified. - - - - - - - - -Housley, et. al. Standards Track [Page 85] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (j) If (cert_status is UNREVOKED), then search for the - certificate on the complete CRL. If an entry is found that - matches the certificate issuer and serial number as described in - section 5.3.4, then set the cert_status variable to the indicated - reason as described in step (i). - - (k) If (cert_status is removeFromCRL), then set cert_status to - UNREVOKED. - - If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)), - then the revocation status has been determined, so return - cert_status. - - If the revocation status has not been determined, repeat the process - above with any available CRLs not specified in a distribution point - but issued by the certificate issuer. For the processing of such a - CRL, assume a DP with both the reasons and the cRLIssuer fields - omitted and a distribution point name of the certificate issuer. - That is, the sequence of names in fullName is generated from the - certificate issuer field as well as the certificate issuerAltName - extension. If the revocation status remains undetermined, then - return the cert_status UNDETERMINED. - -7 References - - [ISO 10646] ISO/IEC 10646-1:1993. International Standard -- - Information technology -- Universal Multiple-Octet Coded - Character Set (UCS) -- Part 1: Architecture and Basic - Multilingual Plane. - - [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [RFC 822] Crocker, D., "Standard for the format of ARPA Internet - text messages", STD 11, RFC 822, August 1982. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic - Mail: Part II: Certificate-Based Key Management," RFC - 1422, February 1993. - - [RFC 1423] Balenson, D., "Privacy Enhancement for Internet - Electronic Mail: Part III: Algorithms, Modes, and - Identifiers," RFC 1423, February 1993. - - - - - -Housley, et. al. Standards Track [Page 86] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network - Authentication Service (V5)," RFC 1510, September 1993. - - [RFC 1519] Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless - Inter-Domain Routing (CIDR): An Address Assignment and - Aggregation Strategy", RFC 1519, September 1993. - - [RFC 1738] Berners-Lee, T., L. Masinter and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [RFC 1778] Howes, T., S. Kille, W. Yeong and C. Robbins, "The String - Representation of Standard Attribute Syntaxes," RFC 1778, - March 1995. - - [RFC 1883] Deering, S. and R. Hinden. "Internet Protocol, Version 6 - (IPv6) Specification", RFC 1883, December 1995. - - [RFC 2044] F. Yergeau, F., "UTF-8, a transformation format of - Unicode and ISO 10646", RFC 2044, October 1996. - - [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S. - Sataluri, "Using Domains in LDAP/X.500 Distinguished - Names", RFC 2247, January 1998. - - [RFC 2252] Wahl, M., A. Coulbeck, T. Howes and S. Kille, - "Lightweight Directory Access Protocol (v3): Attribute - Syntax Definitions", RFC 2252, December 1997. - - [RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and - Languages", BCP 18, RFC 2277, January 1998. - - [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", RFC 2279, January 1998. - - [RFC 2459] Housley, R., W. Ford, W. Polk and D. Solo, "Internet - X.509 Public Key Infrastructure: Certificate and CRL - Profile", RFC 2459, January 1999. - - [RFC 2560] Myers, M., R. Ankney, A. Malpani, S. Galperin and C. - Adams, "Online Certificate Status Protocal - OCSP", June - 1999. - - [SDN.701] SDN.701, "Message Security Protocol 4.0", Revision A, - 1997-02-06. - - - - -Housley, et. al. Standards Track [Page 87] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - [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, June 1997. - - [X.520] ITU-T Recommendation X.520: Information Technology - Open - Systems Interconnection - The Directory: Selected - Attribute Types, 1993. - - [X.660] ITU-T Recommendation X.660 Information Technology - ASN.1 - encoding rules: Specification of Basic Encoding Rules - (BER), Canonical Encoding Rules (CER) and Distinguished - Encoding Rules (DER), 1997. - - [X.690] ITU-T Recommendation X.690 Information Technology - Open - Systems Interconnection - Procedures for the operation of - OSI Registration Authorities: General procedures, 1992. - - [X9.55] ANSI X9.55-1995, Public Key Cryptography For The - Financial Services Industry: Extensions To Public Key - Certificates And Certificate Revocation Lists, 8 - December, 1995. - - [PKIXALGS] Bassham, L., Polk, W. and R. Housley, "Algorithms and - Identifiers for the Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation - Lists (CRL) Profile", RFC 3279, April 2002. - - [PKIXTSA] Adams, C., Cain, P., Pinkas, D. and R. Zuccherato, - "Internet X.509 Public Key Infrastructure Time-Stamp - Protocol (TSP)", RFC 3161, August 2001. - -8 Intellectual Property Rights - - The IETF has been notified of intellectual property rights claimed in - regard to some or all of the specification contained in this - document. For more information consult the online list of claimed - rights (see http://www.ietf.org/ipr.html). - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - - - -Housley, et. al. Standards Track [Page 88] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - standards-related documentation can be found in BCP 11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - -9 Security Considerations - - The majority of this specification is devoted to the format and - content of certificates and CRLs. Since certificates and CRLs are - digitally signed, no additional integrity service is necessary. - Neither certificates nor CRLs need be kept secret, and unrestricted - and anonymous access to certificates and CRLs has no security - implications. - - However, security factors outside the scope of this specification - will affect the assurance provided to certificate users. This - section highlights critical issues to be considered by implementers, - administrators, and users. - - The procedures performed by CAs and RAs to validate the binding of - the subject's identity to their public key greatly affect the - assurance that ought to be placed in the certificate. Relying - parties might wish to review the CA's certificate practice statement. - This is particularly important when issuing certificates to other - CAs. - - The use of a single key pair for both signature and other purposes is - strongly discouraged. Use of separate key pairs for signature and - key management provides several benefits to the users. The - ramifications associated with loss or disclosure of a signature key - are different from loss or disclosure of a key management key. Using - separate key pairs permits a balanced and flexible response. - Similarly, different validity periods or key lengths for each key - pair may be appropriate in some application environments. - Unfortunately, some legacy applications (e.g., SSL) use a single key - pair for signature and key management. - - The protection afforded private keys is a critical security factor. - On a small scale, failure of users to protect their private keys will - permit an attacker to masquerade as them, or decrypt their personal - information. On a larger scale, compromise of a CA's private signing - key may have a catastrophic effect. If an attacker obtains the - private key unnoticed, the attacker may issue bogus certificates and - CRLs. Existence of bogus certificates and CRLs will undermine - confidence in the system. If such a compromise is detected, all - certificates issued to the compromised CA MUST be revoked, preventing - - - -Housley, et. al. Standards Track [Page 89] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - services between its users and users of other CAs. Rebuilding after - such a compromise will be problematic, so CAs are advised to - implement a combination of strong technical measures (e.g., tamper- - resistant cryptographic modules) and appropriate management - procedures (e.g., separation of duties) to avoid such an incident. - - Loss of a CA's private signing key may also be problematic. The CA - would not be able to produce CRLs or perform normal key rollover. - CAs SHOULD maintain secure backup for signing keys. The security of - the key backup procedures is a critical factor in avoiding key - compromise. - - The availability and freshness of revocation information affects the - degree of assurance that ought to be placed in a certificate. While - certificates expire naturally, events may occur during its natural - lifetime which negate the binding between the subject and public key. - If revocation information is untimely or unavailable, the assurance - associated with the binding is clearly reduced. Relying parties - might not be able to process every critical extension that can appear - in a CRL. CAs SHOULD take extra care when making revocation - information available only through CRLs that contain critical - extensions, particularly if support for those extensions is not - mandated by this profile. For example, if revocation information is - supplied using a combination of delta CRLs and full CRLs, and the - delta CRLs are issued more frequently than the full CRLs, then - relying parties that cannot handle the critical extensions related to - delta CRL processing will not be able to obtain the most recent - revocation information. Alternatively, if a full CRL is issued - whenever a delta CRL is issued, then timely revocation information - will be available to all relying parties. Similarly, implementations - of the certification path validation mechanism described in section 6 - that omit revocation checking provide less assurance than those that - support it. - - The certification path validation algorithm depends on the certain - knowledge of the public keys (and other information) about one or - more trusted CAs. The decision to trust a CA is an important - decision as it ultimately determines the trust afforded a - certificate. The authenticated distribution of trusted CA public - keys (usually in the form of a "self-signed" certificate) is a - security critical out-of-band process that is beyond the scope of - this specification. - - In addition, where a key compromise or CA failure occurs for a - trusted CA, the user will need to modify the information provided to - the path validation routine. Selection of too many trusted CAs makes - - - - - -Housley, et. al. Standards Track [Page 90] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - the trusted CA information difficult to maintain. On the other hand, - selection of only one trusted CA could limit users to a closed - community of users. - - The quality of implementations that process certificates also affects - the degree of assurance provided. The path validation algorithm - described in section 6 relies upon the integrity of the trusted CA - information, and especially the integrity of the public keys - associated with the trusted CAs. By substituting public keys for - which an attacker has the private key, an attacker could trick the - user into accepting false certificates. - - The binding between a key and certificate subject cannot be stronger - than the cryptographic module implementation and algorithms used to - generate the signature. Short key lengths or weak hash algorithms - will limit the utility of a certificate. CAs are encouraged to note - advances in cryptology so they can employ strong cryptographic - techniques. In addition, CAs SHOULD decline to issue certificates to - CAs or end entities that generate weak signatures. - - Inconsistent application of name comparison rules can result in - acceptance of invalid X.509 certification paths, or rejection of - valid ones. The X.500 series of specifications defines rules for - comparing distinguished names that require comparison of strings - without regard to case, character set, multi-character white space - substring, or leading and trailing white space. This specification - relaxes these requirements, requiring support for binary comparison - at a minimum. - - CAs MUST encode the distinguished name in the subject field of a CA - certificate identically to the distinguished name in the issuer field - in certificates issued by that CA. If CAs use different encodings, - implementations might fail to recognize name chains for paths that - include this certificate. As a consequence, valid paths could be - rejected. - - In addition, name constraints for distinguished names MUST be stated - identically to the encoding used in the subject field or - subjectAltName extension. If not, then name constraints stated as - excludedSubTrees will not match and invalid paths will be accepted - and name constraints expressed as permittedSubtrees will not match - and valid paths will be rejected. To avoid acceptance of invalid - paths, CAs SHOULD state name constraints for distinguished names as - permittedSubtrees wherever possible. - - - - - - - -Housley, et. al. Standards Track [Page 91] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -Appendix A. Psuedo-ASN.1 Structures and OIDs - - This section describes data objects used by conforming PKI components - in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and - 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with 1993 - UNIVERSAL Types UniversalString, BMPString and UTF8String. - - The ASN.1 syntax does not permit the inclusion of type statements in - the ASN.1 module, and the 1993 ASN.1 standard does not permit use of - the new UNIVERSAL types in modules using the 1988 syntax. As a - result, this module does not conform to either version of the ASN.1 - standard. - - This appendix may be converted into 1988 ASN.1 by replacing the - definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". - -A.1 Explicitly Tagged Module, 1988 Syntax - -PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } - -DEFINITIONS EXPLICIT TAGS ::= - -BEGIN - --- EXPORTS ALL -- - --- IMPORTS NONE -- - --- UNIVERSAL Types defined in 1993 and 1998 ASN.1 --- and required by this specification - -UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING - -- UniversalString is defined in ASN.1:1993 - -BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING - -- BMPString is the subtype of UniversalString and models - -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1 - -UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING - -- The content of this type conforms to RFC 2279. - --- PKIX specific OIDs - -id-pkix OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) } - - - - -Housley, et. al. Standards Track [Page 92] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- PKIX arcs - -id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } - -- arc for private certificate extensions -id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } - -- arc for policy qualifier types -id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } - -- arc for extended key purpose OIDS -id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - -- arc for access descriptors - --- policyQualifierIds for Internet policy qualifiers - -id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } - -- OID for CPS qualifier -id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } - -- OID for user notice qualifier - --- access descriptor definitions - -id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } -id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } -id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } -id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } - --- attribute data types - -Attribute ::= SEQUENCE { - type AttributeType, - values SET OF AttributeValue } - -- at least one value is required - -AttributeType ::= OBJECT IDENTIFIER - -AttributeValue ::= ANY - -AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - --- suggested naming attributes: Definition of the following --- information object set may be augmented to meet local --- requirements. Note that deleting members of the set may --- prevent interoperability with conforming implementations. --- presented in pairs: the AttributeType followed by the --- type definition for the corresponding AttributeValue ---Arc for standard naming attributes -id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } - - - -Housley, et. al. Standards Track [Page 93] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- Naming attributes of type X520name - -id-at-name AttributeType ::= { id-at 41 } -id-at-surname AttributeType ::= { id-at 4 } -id-at-givenName AttributeType ::= { id-at 42 } -id-at-initials AttributeType ::= { id-at 43 } -id-at-generationQualifier AttributeType ::= { id-at 44 } - -X520name ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-name)), - printableString PrintableString (SIZE (1..ub-name)), - universalString UniversalString (SIZE (1..ub-name)), - utf8String UTF8String (SIZE (1..ub-name)), - bmpString BMPString (SIZE (1..ub-name)) } - --- Naming attributes of type X520CommonName - -id-at-commonName AttributeType ::= { id-at 3 } - -X520CommonName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-common-name)), - printableString PrintableString (SIZE (1..ub-common-name)), - universalString UniversalString (SIZE (1..ub-common-name)), - utf8String UTF8String (SIZE (1..ub-common-name)), - bmpString BMPString (SIZE (1..ub-common-name)) } - --- Naming attributes of type X520LocalityName - -id-at-localityName AttributeType ::= { id-at 7 } - -X520LocalityName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-locality-name)), - printableString PrintableString (SIZE (1..ub-locality-name)), - universalString UniversalString (SIZE (1..ub-locality-name)), - utf8String UTF8String (SIZE (1..ub-locality-name)), - bmpString BMPString (SIZE (1..ub-locality-name)) } - --- Naming attributes of type X520StateOrProvinceName - -id-at-stateOrProvinceName AttributeType ::= { id-at 8 } - -X520StateOrProvinceName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-state-name)), - printableString PrintableString (SIZE (1..ub-state-name)), - universalString UniversalString (SIZE (1..ub-state-name)), - utf8String UTF8String (SIZE (1..ub-state-name)), - bmpString BMPString (SIZE(1..ub-state-name)) } - - - - -Housley, et. al. Standards Track [Page 94] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- Naming attributes of type X520OrganizationName - -id-at-organizationName AttributeType ::= { id-at 10 } - -X520OrganizationName ::= CHOICE { - teletexString TeletexString - (SIZE (1..ub-organization-name)), - printableString PrintableString - (SIZE (1..ub-organization-name)), - universalString UniversalString - (SIZE (1..ub-organization-name)), - utf8String UTF8String - (SIZE (1..ub-organization-name)), - bmpString BMPString - (SIZE (1..ub-organization-name)) } - --- Naming attributes of type X520OrganizationalUnitName - -id-at-organizationalUnitName AttributeType ::= { id-at 11 } - -X520OrganizationalUnitName ::= CHOICE { - teletexString TeletexString - (SIZE (1..ub-organizational-unit-name)), - printableString PrintableString - (SIZE (1..ub-organizational-unit-name)), - universalString UniversalString - (SIZE (1..ub-organizational-unit-name)), - utf8String UTF8String - (SIZE (1..ub-organizational-unit-name)), - bmpString BMPString - (SIZE (1..ub-organizational-unit-name)) } - --- Naming attributes of type X520Title - -id-at-title AttributeType ::= { id-at 12 } - -X520Title ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-title)), - printableString PrintableString (SIZE (1..ub-title)), - universalString UniversalString (SIZE (1..ub-title)), - utf8String UTF8String (SIZE (1..ub-title)), - bmpString BMPString (SIZE (1..ub-title)) } - --- Naming attributes of type X520dnQualifier - -id-at-dnQualifier AttributeType ::= { id-at 46 } - -X520dnQualifier ::= PrintableString - - - -Housley, et. al. Standards Track [Page 95] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- Naming attributes of type X520countryName (digraph from IS 3166) - -id-at-countryName AttributeType ::= { id-at 6 } - -X520countryName ::= PrintableString (SIZE (2)) - --- Naming attributes of type X520SerialNumber - -id-at-serialNumber AttributeType ::= { id-at 5 } - -X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) - --- Naming attributes of type X520Pseudonym - -id-at-pseudonym AttributeType ::= { id-at 65 } - -X520Pseudonym ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-pseudonym)), - printableString PrintableString (SIZE (1..ub-pseudonym)), - universalString UniversalString (SIZE (1..ub-pseudonym)), - utf8String UTF8String (SIZE (1..ub-pseudonym)), - bmpString BMPString (SIZE (1..ub-pseudonym)) } - --- Naming attributes of type DomainComponent (from RFC 2247) - -id-domainComponent AttributeType ::= - { 0 9 2342 19200300 100 1 25 } - -DomainComponent ::= IA5String - --- Legacy attributes - -pkcs-9 OBJECT IDENTIFIER ::= - { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } - -id-emailAddress AttributeType ::= { pkcs-9 1 } - -EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) - --- naming data types -- - -Name ::= CHOICE { -- only one possibility for now -- - rdnSequence RDNSequence } - -RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - -DistinguishedName ::= RDNSequence - - - - -Housley, et. al. Standards Track [Page 96] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -RelativeDistinguishedName ::= - SET SIZE (1 .. MAX) OF AttributeTypeAndValue - --- Directory string type -- - -DirectoryString ::= CHOICE { - teletexString TeletexString (SIZE (1..MAX)), - printableString PrintableString (SIZE (1..MAX)), - universalString UniversalString (SIZE (1..MAX)), - utf8String UTF8String (SIZE (1..MAX)), - bmpString BMPString (SIZE (1..MAX)) } - --- certificate and CRL specific structures begin here - -Certificate ::= SEQUENCE { - tbsCertificate TBSCertificate, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING } - -TBSCertificate ::= SEQUENCE { - version [0] Version DEFAULT v1, - serialNumber CertificateSerialNumber, - signature AlgorithmIdentifier, - issuer Name, - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo, - issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - extensions [3] Extensions OPTIONAL - -- If present, version MUST be v3 -- } - -Version ::= INTEGER { v1(0), v2(1), v3(2) } - -CertificateSerialNumber ::= INTEGER - -Validity ::= SEQUENCE { - notBefore Time, - notAfter Time } - -Time ::= CHOICE { - utcTime UTCTime, - generalTime GeneralizedTime } - -UniqueIdentifier ::= BIT STRING - - - - -Housley, et. al. Standards Track [Page 97] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING } - -Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension - -Extension ::= SEQUENCE { - extnID OBJECT IDENTIFIER, - critical BOOLEAN DEFAULT FALSE, - extnValue OCTET STRING } - --- CRL structures - -CertificateList ::= SEQUENCE { - tbsCertList TBSCertList, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING } - -TBSCertList ::= SEQUENCE { - version Version OPTIONAL, - -- if present, MUST be v2 - signature AlgorithmIdentifier, - issuer Name, - thisUpdate Time, - nextUpdate Time OPTIONAL, - revokedCertificates SEQUENCE OF SEQUENCE { - userCertificate CertificateSerialNumber, - revocationDate Time, - crlEntryExtensions Extensions OPTIONAL - -- if present, MUST be v2 - } OPTIONAL, - crlExtensions [0] Extensions OPTIONAL } - -- if present, MUST be v2 - --- Version, Time, CertificateSerialNumber, and Extensions were --- defined earlier for use in the certificate structure - -AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL } - -- contains a value of the type - -- registered for use with the - -- algorithm object identifier value - --- X.400 address syntax starts here - - - - - - -Housley, et. al. Standards Track [Page 98] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -ORAddress ::= SEQUENCE { - built-in-standard-attributes BuiltInStandardAttributes, - built-in-domain-defined-attributes - BuiltInDomainDefinedAttributes OPTIONAL, - -- see also teletex-domain-defined-attributes - extension-attributes ExtensionAttributes OPTIONAL } - --- Built-in Standard Attributes - -BuiltInStandardAttributes ::= SEQUENCE { - country-name CountryName OPTIONAL, - administration-domain-name AdministrationDomainName OPTIONAL, - network-address [0] IMPLICIT NetworkAddress OPTIONAL, - -- see also extended-network-address - terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, - private-domain-name [2] PrivateDomainName OPTIONAL, - organization-name [3] IMPLICIT OrganizationName OPTIONAL, - -- see also teletex-organization-name - numeric-user-identifier [4] IMPLICIT NumericUserIdentifier - OPTIONAL, - personal-name [5] IMPLICIT PersonalName OPTIONAL, - -- see also teletex-personal-name - organizational-unit-names [6] IMPLICIT OrganizationalUnitNames - OPTIONAL } - -- see also teletex-organizational-unit-names - -CountryName ::= [APPLICATION 1] CHOICE { - x121-dcc-code NumericString - (SIZE (ub-country-name-numeric-length)), - iso-3166-alpha2-code PrintableString - (SIZE (ub-country-name-alpha-length)) } - -AdministrationDomainName ::= [APPLICATION 2] CHOICE { - numeric NumericString (SIZE (0..ub-domain-name-length)), - printable PrintableString (SIZE (0..ub-domain-name-length)) } - -NetworkAddress ::= X121Address -- see also extended-network-address - -X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) - -TerminalIdentifier ::= PrintableString (SIZE -(1..ub-terminal-id-length)) - -PrivateDomainName ::= CHOICE { - numeric NumericString (SIZE (1..ub-domain-name-length)), - printable PrintableString (SIZE (1..ub-domain-name-length)) } - - - - - -Housley, et. al. Standards Track [Page 99] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -OrganizationName ::= PrintableString - (SIZE (1..ub-organization-name-length)) - -- see also teletex-organization-name - -NumericUserIdentifier ::= NumericString - (SIZE (1..ub-numeric-user-id-length)) - -PersonalName ::= SET { - surname [0] IMPLICIT PrintableString - (SIZE (1..ub-surname-length)), - given-name [1] IMPLICIT PrintableString - (SIZE (1..ub-given-name-length)) OPTIONAL, - initials [2] IMPLICIT PrintableString - (SIZE (1..ub-initials-length)) OPTIONAL, - generation-qualifier [3] IMPLICIT PrintableString - (SIZE (1..ub-generation-qualifier-length)) - OPTIONAL } - -- see also teletex-personal-name - -OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) - OF OrganizationalUnitName - -- see also teletex-organizational-unit-names - -OrganizationalUnitName ::= PrintableString (SIZE - (1..ub-organizational-unit-name-length)) - --- Built-in Domain-defined Attributes - -BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE - (1..ub-domain-defined-attributes) OF - BuiltInDomainDefinedAttribute - -BuiltInDomainDefinedAttribute ::= SEQUENCE { - type PrintableString (SIZE - (1..ub-domain-defined-attribute-type-length)), - value PrintableString (SIZE - (1..ub-domain-defined-attribute-value-length)) } - --- Extension Attributes - -ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF - ExtensionAttribute - -ExtensionAttribute ::= SEQUENCE { - extension-attribute-type [0] IMPLICIT INTEGER - (0..ub-extension-attributes), - extension-attribute-value [1] - ANY DEFINED BY extension-attribute-type } - - - -Housley, et. al. Standards Track [Page 100] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- Extension types and attribute values - -common-name INTEGER ::= 1 - -CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) - -teletex-common-name INTEGER ::= 2 - -TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) - -teletex-organization-name INTEGER ::= 3 - -TeletexOrganizationName ::= - TeletexString (SIZE (1..ub-organization-name-length)) - -teletex-personal-name INTEGER ::= 4 - -TeletexPersonalName ::= SET { - surname [0] IMPLICIT TeletexString - (SIZE (1..ub-surname-length)), - given-name [1] IMPLICIT TeletexString - (SIZE (1..ub-given-name-length)) OPTIONAL, - initials [2] IMPLICIT TeletexString - (SIZE (1..ub-initials-length)) OPTIONAL, - generation-qualifier [3] IMPLICIT TeletexString - (SIZE (1..ub-generation-qualifier-length)) - OPTIONAL } - -teletex-organizational-unit-names INTEGER ::= 5 - -TeletexOrganizationalUnitNames ::= SEQUENCE SIZE - (1..ub-organizational-units) OF TeletexOrganizationalUnitName - -TeletexOrganizationalUnitName ::= TeletexString - (SIZE (1..ub-organizational-unit-name-length)) - -pds-name INTEGER ::= 7 - -PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) - -physical-delivery-country-name INTEGER ::= 8 - -PhysicalDeliveryCountryName ::= CHOICE { - x121-dcc-code NumericString (SIZE -(ub-country-name-numeric-length)), - iso-3166-alpha2-code PrintableString - (SIZE (ub-country-name-alpha-length)) } - - - - -Housley, et. al. Standards Track [Page 101] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -postal-code INTEGER ::= 9 - -PostalCode ::= CHOICE { - numeric-code NumericString (SIZE (1..ub-postal-code-length)), - printable-code PrintableString (SIZE (1..ub-postal-code-length)) } - -physical-delivery-office-name INTEGER ::= 10 - -PhysicalDeliveryOfficeName ::= PDSParameter - -physical-delivery-office-number INTEGER ::= 11 - -PhysicalDeliveryOfficeNumber ::= PDSParameter - -extension-OR-address-components INTEGER ::= 12 - -ExtensionORAddressComponents ::= PDSParameter - -physical-delivery-personal-name INTEGER ::= 13 - -PhysicalDeliveryPersonalName ::= PDSParameter - -physical-delivery-organization-name INTEGER ::= 14 - -PhysicalDeliveryOrganizationName ::= PDSParameter - -extension-physical-delivery-address-components INTEGER ::= 15 - -ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter - -unformatted-postal-address INTEGER ::= 16 - -UnformattedPostalAddress ::= SET { - printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) - OF PrintableString (SIZE (1..ub-pds-parameter-length)) - OPTIONAL, - teletex-string TeletexString - (SIZE (1..ub-unformatted-address-length)) OPTIONAL } - -street-address INTEGER ::= 17 - -StreetAddress ::= PDSParameter - -post-office-box-address INTEGER ::= 18 - -PostOfficeBoxAddress ::= PDSParameter - -poste-restante-address INTEGER ::= 19 - - - -Housley, et. al. Standards Track [Page 102] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -PosteRestanteAddress ::= PDSParameter - -unique-postal-name INTEGER ::= 20 - -UniquePostalName ::= PDSParameter - -local-postal-attributes INTEGER ::= 21 - -LocalPostalAttributes ::= PDSParameter - -PDSParameter ::= SET { - printable-string PrintableString - (SIZE(1..ub-pds-parameter-length)) OPTIONAL, - teletex-string TeletexString - (SIZE(1..ub-pds-parameter-length)) OPTIONAL } - -extended-network-address INTEGER ::= 22 - -ExtendedNetworkAddress ::= CHOICE { - e163-4-address SEQUENCE { - number [0] IMPLICIT NumericString - (SIZE (1..ub-e163-4-number-length)), - sub-address [1] IMPLICIT NumericString - (SIZE (1..ub-e163-4-sub-address-length)) - OPTIONAL }, - psap-address [0] IMPLICIT PresentationAddress } - -PresentationAddress ::= SEQUENCE { - pSelector [0] EXPLICIT OCTET STRING OPTIONAL, - sSelector [1] EXPLICIT OCTET STRING OPTIONAL, - tSelector [2] EXPLICIT OCTET STRING OPTIONAL, - nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } - -terminal-type INTEGER ::= 23 - -TerminalType ::= INTEGER { - telex (3), - teletex (4), - g3-facsimile (5), - g4-facsimile (6), - ia5-terminal (7), - videotex (8) } (0..ub-integer-options) - --- Extension Domain-defined Attributes - -teletex-domain-defined-attributes INTEGER ::= 6 - - - - - -Housley, et. al. Standards Track [Page 103] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -TeletexDomainDefinedAttributes ::= SEQUENCE SIZE - (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute - -TeletexDomainDefinedAttribute ::= SEQUENCE { - type TeletexString - (SIZE (1..ub-domain-defined-attribute-type-length)), - value TeletexString - (SIZE (1..ub-domain-defined-attribute-value-length)) } - --- specifications of Upper Bounds MUST be regarded as mandatory --- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter --- Upper Bounds - --- Upper Bounds -ub-name INTEGER ::= 32768 -ub-common-name INTEGER ::= 64 -ub-locality-name INTEGER ::= 128 -ub-state-name INTEGER ::= 128 -ub-organization-name INTEGER ::= 64 -ub-organizational-unit-name INTEGER ::= 64 -ub-title INTEGER ::= 64 -ub-serial-number INTEGER ::= 64 -ub-match INTEGER ::= 128 -ub-emailaddress-length INTEGER ::= 128 -ub-common-name-length INTEGER ::= 64 -ub-country-name-alpha-length INTEGER ::= 2 -ub-country-name-numeric-length INTEGER ::= 3 -ub-domain-defined-attributes INTEGER ::= 4 -ub-domain-defined-attribute-type-length INTEGER ::= 8 -ub-domain-defined-attribute-value-length INTEGER ::= 128 -ub-domain-name-length INTEGER ::= 16 -ub-extension-attributes INTEGER ::= 256 -ub-e163-4-number-length INTEGER ::= 15 -ub-e163-4-sub-address-length INTEGER ::= 40 -ub-generation-qualifier-length INTEGER ::= 3 -ub-given-name-length INTEGER ::= 16 -ub-initials-length INTEGER ::= 5 -ub-integer-options INTEGER ::= 256 -ub-numeric-user-id-length INTEGER ::= 32 -ub-organization-name-length INTEGER ::= 64 -ub-organizational-unit-name-length INTEGER ::= 32 -ub-organizational-units INTEGER ::= 4 -ub-pds-name-length INTEGER ::= 16 -ub-pds-parameter-length INTEGER ::= 30 -ub-pds-physical-address-lines INTEGER ::= 6 -ub-postal-code-length INTEGER ::= 16 -ub-pseudonym INTEGER ::= 128 -ub-surname-length INTEGER ::= 40 - - - -Housley, et. al. Standards Track [Page 104] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -ub-terminal-id-length INTEGER ::= 24 -ub-unformatted-address-length INTEGER ::= 180 -ub-x121-address-length INTEGER ::= 16 - --- Note - upper bounds on string types, such as TeletexString, are --- measured in characters. Excepting PrintableString or IA5String, a --- significantly greater number of octets will be required to hold --- such a value. As a minimum, 16 octets, or twice the specified --- upper bound, whichever is the larger, should be allowed for --- TeletexString. For UTF8String or UniversalString at least four --- times the upper bound should be allowed. - -END - -A.2 Implicitly Tagged Module, 1988 Syntax - -PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } - -DEFINITIONS IMPLICIT TAGS ::= - -BEGIN - --- EXPORTS ALL -- - -IMPORTS - id-pe, id-kp, id-qt-unotice, id-qt-cps, - -- delete following line if "new" types are supported -- - BMPString, UTF8String, -- end "new" types -- - ORAddress, Name, RelativeDistinguishedName, - CertificateSerialNumber, Attribute, DirectoryString - FROM PKIX1Explicit88 { iso(1) identified-organization(3) - dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) }; - - --- ISO arc for standard certificate and CRL extensions - -id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} - --- authority key identifier OID and syntax - -id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } - - - - - - - - -Housley, et. al. Standards Track [Page 105] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -AuthorityKeyIdentifier ::= SEQUENCE { - keyIdentifier [0] KeyIdentifier OPTIONAL, - authorityCertIssuer [1] GeneralNames OPTIONAL, - authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } - -- authorityCertIssuer and authorityCertSerialNumber MUST both - -- be present or both be absent - -KeyIdentifier ::= OCTET STRING - --- subject key identifier OID and syntax - -id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } - -SubjectKeyIdentifier ::= KeyIdentifier - --- key usage extension OID and syntax - -id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } - -KeyUsage ::= BIT STRING { - digitalSignature (0), - nonRepudiation (1), - keyEncipherment (2), - dataEncipherment (3), - keyAgreement (4), - keyCertSign (5), - cRLSign (6), - encipherOnly (7), - decipherOnly (8) } - --- private key usage period extension OID and syntax - -id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } - -PrivateKeyUsagePeriod ::= SEQUENCE { - notBefore [0] GeneralizedTime OPTIONAL, - notAfter [1] GeneralizedTime OPTIONAL } - -- either notBefore or notAfter MUST be present - --- certificate policies extension OID and syntax - -id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } - -anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } - -CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation - -PolicyInformation ::= SEQUENCE { - - - -Housley, et. al. Standards Track [Page 106] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - policyIdentifier CertPolicyId, - policyQualifiers SEQUENCE SIZE (1..MAX) OF - PolicyQualifierInfo OPTIONAL } - -CertPolicyId ::= OBJECT IDENTIFIER - -PolicyQualifierInfo ::= SEQUENCE { - policyQualifierId PolicyQualifierId, - qualifier ANY DEFINED BY policyQualifierId } - --- Implementations that recognize additional policy qualifiers MUST --- augment the following definition for PolicyQualifierId - -PolicyQualifierId ::= - OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) - --- CPS pointer qualifier - -CPSuri ::= IA5String - --- user notice qualifier - -UserNotice ::= SEQUENCE { - noticeRef NoticeReference OPTIONAL, - explicitText DisplayText OPTIONAL} - -NoticeReference ::= SEQUENCE { - organization DisplayText, - noticeNumbers SEQUENCE OF INTEGER } - -DisplayText ::= CHOICE { - ia5String IA5String (SIZE (1..200)), - visibleString VisibleString (SIZE (1..200)), - bmpString BMPString (SIZE (1..200)), - utf8String UTF8String (SIZE (1..200)) } - --- policy mapping extension OID and syntax - -id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } - -PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - issuerDomainPolicy CertPolicyId, - subjectDomainPolicy CertPolicyId } - --- subject alternative name extension OID and syntax - -id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } - - - - -Housley, et. al. Standards Track [Page 107] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -SubjectAltName ::= GeneralNames - -GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName - -GeneralName ::= CHOICE { - otherName [0] AnotherName, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] ORAddress, - directoryName [4] Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER } - --- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as --- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax - -AnotherName ::= SEQUENCE { - type-id OBJECT IDENTIFIER, - value [0] EXPLICIT ANY DEFINED BY type-id } - -EDIPartyName ::= SEQUENCE { - nameAssigner [0] DirectoryString OPTIONAL, - partyName [1] DirectoryString } - --- issuer alternative name extension OID and syntax - -id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } - -IssuerAltName ::= GeneralNames - -id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } - -SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute - --- basic constraints extension OID and syntax - -id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } - -BasicConstraints ::= SEQUENCE { - cA BOOLEAN DEFAULT FALSE, - pathLenConstraint INTEGER (0..MAX) OPTIONAL } - --- name constraints extension OID and syntax - -id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } - - - - -Housley, et. al. Standards Track [Page 108] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -NameConstraints ::= SEQUENCE { - permittedSubtrees [0] GeneralSubtrees OPTIONAL, - excludedSubtrees [1] GeneralSubtrees OPTIONAL } - -GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree - -GeneralSubtree ::= SEQUENCE { - base GeneralName, - minimum [0] BaseDistance DEFAULT 0, - maximum [1] BaseDistance OPTIONAL } - -BaseDistance ::= INTEGER (0..MAX) - --- policy constraints extension OID and syntax - -id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } - -PolicyConstraints ::= SEQUENCE { - requireExplicitPolicy [0] SkipCerts OPTIONAL, - inhibitPolicyMapping [1] SkipCerts OPTIONAL } - -SkipCerts ::= INTEGER (0..MAX) - --- CRL distribution points extension OID and syntax - -id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} - -CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint - -DistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - reasons [1] ReasonFlags OPTIONAL, - cRLIssuer [2] GeneralNames OPTIONAL } - -DistributionPointName ::= CHOICE { - fullName [0] GeneralNames, - nameRelativeToCRLIssuer [1] RelativeDistinguishedName } - -ReasonFlags ::= BIT STRING { - unused (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - privilegeWithdrawn (7), - aACompromise (8) } - - - -Housley, et. al. Standards Track [Page 109] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - --- extended key usage extension OID and syntax - -id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} - -ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId - - -KeyPurposeId ::= OBJECT IDENTIFIER - --- permit unspecified key uses - -anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } - --- extended key purpose OIDs - -id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } -id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } -id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } -id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } -id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } - --- inhibit any policy OID and syntax - -id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } - -InhibitAnyPolicy ::= SkipCerts - --- freshest (delta)CRL extension OID and syntax - -id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - -FreshestCRL ::= CRLDistributionPoints - --- authority info access - -id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } - -AuthorityInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - -AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - --- subject info access - -id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } - - - -Housley, et. al. Standards Track [Page 110] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -SubjectInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - --- CRL number extension OID and syntax - -id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } - -CRLNumber ::= INTEGER (0..MAX) - --- issuing distribution point extension OID and syntax - -id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } - -IssuingDistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, - onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, - onlySomeReasons [3] ReasonFlags OPTIONAL, - indirectCRL [4] BOOLEAN DEFAULT FALSE, - onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } - -id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } - -BaseCRLNumber ::= CRLNumber - --- CRL reasons extension OID and syntax - -id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } - -CRLReason ::= ENUMERATED { - unspecified (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - removeFromCRL (8), - privilegeWithdrawn (9), - aACompromise (10) } - --- certificate issuer CRL entry extension OID and syntax - -id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } - -CertificateIssuer ::= GeneralNames - --- hold instruction extension OID and syntax - - - -Housley, et. al. Standards Track [Page 111] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } - -HoldInstructionCode ::= OBJECT IDENTIFIER - --- ANSI x9 holdinstructions - --- ANSI x9 arc holdinstruction arc - -holdInstruction OBJECT IDENTIFIER ::= - {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} - --- ANSI X9 holdinstructions referenced by this standard - -id-holdinstruction-none OBJECT IDENTIFIER ::= - {holdInstruction 1} -- deprecated - -id-holdinstruction-callissuer OBJECT IDENTIFIER ::= - {holdInstruction 2} - -id-holdinstruction-reject OBJECT IDENTIFIER ::= - {holdInstruction 3} - --- invalidity date CRL entry extension OID and syntax - -id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } - -InvalidityDate ::= GeneralizedTime - -END - -Appendix B. ASN.1 Notes - - CAs MUST force the serialNumber to be a non-negative integer, that - is, the sign bit in the DER encoding of the INTEGER value MUST be - zero - this can be done by adding a leading (leftmost) `00'H octet if - necessary. This removes a potential ambiguity in mapping between a - string of octets and an integer value. - - As noted in section 4.1.2.2, serial numbers can be expected to - contain long integers. Certificate users MUST be able to handle - serialNumber values up to 20 octets in length. Conformant CAs MUST - NOT use serialNumber values longer than 20 octets. - - As noted in section 5.2.3, CRL numbers can be expected to contain - long integers. CRL validators MUST be able to handle cRLNumber - values up to 20 octets in length. Conformant CRL issuers MUST NOT - use cRLNumber values longer than 20 octets. - - - - -Housley, et. al. Standards Track [Page 112] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 - constructs. A valid ASN.1 sequence will have zero or more entries. - The SIZE (1..MAX) construct constrains the sequence to have at least - one entry. MAX indicates the upper bound is unspecified. - Implementations are free to choose an upper bound that suits their - environment. - - The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt - as a subtype of INTEGER containing integers greater than or equal to - zero. The upper bound is unspecified. Implementations are free to - select an upper bound that suits their environment. - - The character string type PrintableString supports a very basic Latin - character set: the lower case letters 'a' through 'z', upper case - letters 'A' through 'Z', the digits '0' through '9', eleven special - characters ' = ( ) + , - . / : ? and space. - - Implementers should note that the at sign ('@') and underscore ('_') - characters are not supported by the ASN.1 type PrintableString. - These characters often appear in internet addresses. Such addresses - MUST be encoded using an ASN.1 type that supports them. They are - usually encoded as IA5String in either the emailAddress attribute - within a distinguished name or the rfc822Name field of GeneralName. - Conforming implementations MUST NOT encode strings which include - either the at sign or underscore character as PrintableString. - - The character string type TeletexString is a superset of - PrintableString. TeletexString supports a fairly standard (ASCII- - like) Latin character set, Latin characters with non-spacing accents - and Japanese characters. - - Named bit lists are BIT STRINGs where the values have been assigned - names. This specification makes use of named bit lists in the - definitions for the key usage, CRL distribution points and freshest - CRL certificate extensions, as well as the freshest CRL and issuing - distribution point CRL extensions. When DER encoding a named bit - list, trailing zeroes MUST be omitted. That is, the encoded value - ends with the last named bit that is set to one. - - The character string type UniversalString supports any of the - characters allowed by ISO 10646-1 [ISO 10646]. ISO 10646-1 is the - Universal multiple-octet coded Character Set (UCS). ISO 10646-1 - specifies the architecture and the "basic multilingual plane" -- a - large standard character set which includes all major world character - standards. - - - - - - -Housley, et. al. Standards Track [Page 113] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - The character string type UTF8String was introduced in the 1997 - version of ASN.1, and UTF8String was added to the list of choices for - DirectoryString in the 2001 version of X.520 [X.520]. UTF8String is - a universal type and has been assigned tag number 12. The content of - UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279 - [RFC 2279]. - - In anticipation of these changes, and in conformance with IETF Best - Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character - Sets and Languages, this document includes UTF8String as a choice in - DirectoryString and the CPS qualifier extensions. - - Implementers should note that the DER encoding of the SET OF values - requires ordering of the encodings of the values. In particular, - this issue arises with respect to distinguished names. - - Implementers should note that the DER encoding of SET or SEQUENCE - components whose value is the DEFAULT omit the component from the - encoded certificate or CRL. For example, a BasicConstraints - extension whose cA value is FALSE would omit the cA boolean from the - encoded certificate. - - Object Identifiers (OIDs) are used throughout this specification to - identify certificate policies, public key and signature algorithms, - certificate extensions, etc. There is no maximum size for OIDs. - This specification mandates support for OIDs which have arc elements - with values that are less than 2^28, that is, they MUST be between 0 - and 268,435,455, inclusive. This allows each arc element to be - represented within a single 32 bit word. Implementations MUST also - support OIDs where the length of the dotted decimal (see [RFC 2252], - section 4.1) string representation can be up to 100 bytes - (inclusive). Implementations MUST be able to handle OIDs with up to - 20 elements (inclusive). CAs SHOULD NOT issue certificates which - contain OIDs that exceed these requirements. Likewise, CRL issuers - SHOULD NOT issue CRLs which contain OIDs that exceed these - requirements. - - Implementors are warned that the X.500 standards community has - developed a series of extensibility rules. These rules determine - when an ASN.1 definition can be changed without assigning a new - object identifier (OID). For example, at least two extension - definitions included in RFC 2459 [RFC 2459], the predecessor to this - profile document, have different ASN.1 definitions in this - specification, but the same OID is used. If unknown elements appear - within an extension, and the extension is not marked critical, those - unknown elements ought to be ignored, as follows: - - (a) ignore all unknown bit name assignments within a bit string; - - - -Housley, et. al. Standards Track [Page 114] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (b) ignore all unknown named numbers in an ENUMERATED type or - INTEGER type that is being used in the enumerated style, provided - the number occurs as an optional element of a SET or SEQUENCE; and - - (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, - or in CHOICEs where the CHOICE is itself an optional element of a - SET or SEQUENCE. - - If an extension containing unexpected values is marked critical, the - implementation MUST reject the certificate or CRL containing the - unrecognized extension. - -Appendix C. Examples - - This section contains four examples: three certificates and a CRL. - The first two certificates and the CRL comprise a minimal - certification path. - - Section C.1 contains an annotated hex dump of a "self-signed" - certificate issued by a CA whose distinguished name is - cn=us,o=gov,ou=nist. The certificate contains a DSA public key with - parameters, and is signed by the corresponding DSA private key. - - Section C.2 contains an annotated hex dump of an end entity - certificate. The end entity certificate contains a DSA public key, - and is signed by the private key corresponding to the "self-signed" - certificate in section C.1. - - Section C.3 contains a dump of an end entity certificate which - contains an RSA public key and is signed with RSA and MD5. This - certificate is not part of the minimal certification path. - - Section C.4 contains an annotated hex dump of a CRL. The CRL is - issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and - the list of revoked certificates includes the end entity certificate - presented in C.2. - - The certificates were processed using Peter Gutman's dumpasn1 utility - to generate the output. The source for the dumpasn1 utility is - available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>. The - binaries for the certificates and CRLs are available at - <http://csrc.nist.gov/pki/pkixtools>. - -C.1 Certificate - - This section contains an annotated hex dump of a 699 byte version 3 - certificate. The certificate contains the following information: - (a) the serial number is 23 (17 hex); - - - -Housley, et. al. Standards Track [Page 115] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (b) the certificate is signed with DSA and the SHA-1 hash algorithm; - (c) the issuer's distinguished name is OU=NIST; O=gov; C=US - (d) and the subject's distinguished name is OU=NIST; O=gov; C=US - (e) the certificate was issued on June 30, 1997 and will expire on - December 31, 1997; - (f) the certificate contains a 1024 bit DSA public key with - parameters; - (g) the certificate contains a subject key identifier extension - generated using method (1) of section 4.2.1.2; and - (h) the certificate is a CA certificate (as indicated through the - basic constraints extension.) - - 0 30 699: SEQUENCE { - 4 30 635: SEQUENCE { - 8 A0 3: [0] { - 10 02 1: INTEGER 2 - : } - 13 02 1: INTEGER 17 - 16 30 9: SEQUENCE { - 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 27 30 42: SEQUENCE { - 29 31 11: SET { - 31 30 9: SEQUENCE { - 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) - 38 13 2: PrintableString 'US' - : } - : } - 42 31 12: SET { - 44 30 10: SEQUENCE { - 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) - 51 13 3: PrintableString 'gov' - : } - : } - 56 31 13: SET { - 58 30 11: SEQUENCE { - 60 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) - 65 13 4: PrintableString 'NIST' - : } - : } - : } - 71 30 30: SEQUENCE { - 73 17 13: UTCTime '970630000000Z' - 88 17 13: UTCTime '971231000000Z' - : } -103 30 42: SEQUENCE { -105 31 11: SET { - - - -Housley, et. al. Standards Track [Page 116] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -107 30 9: SEQUENCE { -109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) -114 13 2: PrintableString 'US' - : } - : } -118 31 12: SET { -120 30 10: SEQUENCE { -122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) -127 13 3: PrintableString 'gov' - : } - : } -132 31 13: SET { -134 30 11: SEQUENCE { -136 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) -141 13 4: PrintableString 'NIST' - : } - : } - : } -147 30 440: SEQUENCE { -151 30 300: SEQUENCE { -155 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) -164 30 287: SEQUENCE { -168 02 129: INTEGER - : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC - : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC - : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F - : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 - : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A - : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD - : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E - : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A - : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 - : 63 FE 43 -300 02 21: INTEGER - : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA - : 55 F7 7D 57 74 81 E5 -323 02 129: INTEGER - : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 - : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 - : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 - : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC - : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A - : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C - : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 - : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF - : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE - : 1E 57 18 - - - -Housley, et. al. Standards Track [Page 117] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - : } - : } -455 03 133: BIT STRING 0 unused bits, encapsulates { -459 02 129: INTEGER - : 00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04 - : 75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3 - : 03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1 - : 2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D - : FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6 - : 28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82 - : 2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E - : B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A - : 68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41 - : 7B C9 55 - : } - : } -591 A3 50: [3] { -593 30 48: SEQUENCE { -595 30 29: SEQUENCE { -597 06 3: OBJECT IDENTIFIER - : subjectKeyIdentifier (2 5 29 14) -602 04 22: OCTET STRING, encapsulates { -604 04 20: OCTET STRING - : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 - : 2C 29 49 F4 86 56 - : } - : } -626 30 15: SEQUENCE { -628 06 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) -633 01 1: BOOLEAN TRUE -636 04 5: OCTET STRING, encapsulates { -638 30 3: SEQUENCE { -640 01 1: BOOLEAN TRUE - : } - : } - : } - : } - : } - : } -643 30 9: SEQUENCE { -645 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } -654 03 47: BIT STRING 0 unused bits, encapsulates { -657 30 44: SEQUENCE { -659 02 20: INTEGER - : 43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1 - : 66 4C 83 CF 2D 77 -681 02 20: INTEGER - - - -Housley, et. al. Standards Track [Page 118] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - : 0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9 - : E1 8D A5 CC 3A D4 - : } - : } - : } - -C.2 Certificate - - This section contains an annotated hex dump of a 730 byte version 3 - certificate. The certificate contains the following information: - (a) the serial number is 18 (12 hex); - (b) the certificate is signed with DSA and the SHA-1 hash algorithm; - (c) the issuer's distinguished name is OU=nist; O=gov; C=US - (d) and the subject's distinguished name is CN=Tim Polk; OU=nist; - O=gov; C=US - (e) the certificate was valid from July 30, 1997 through December 1, - 1997; - (f) the certificate contains a 1024 bit DSA public key; - (g) the certificate is an end entity certificate, as the basic - constraints extension is not present; - (h) the certificate contains an authority key identifier extension - matching the subject key identifier of the certificate in Appendix - C.1; and - (i) the certificate includes one alternative name - an RFC 822 - address of "wpolk@nist.gov". - - 0 30 730: SEQUENCE { - 4 30 665: SEQUENCE { - 8 A0 3: [0] { - 10 02 1: INTEGER 2 - : } - 13 02 1: INTEGER 18 - 16 30 9: SEQUENCE { - 18 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 27 30 42: SEQUENCE { - 29 31 11: SET { - 31 30 9: SEQUENCE { - 33 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) - 38 13 2: PrintableString 'US' - : } - : } - 42 31 12: SET { - 44 30 10: SEQUENCE { - 46 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) - 51 13 3: PrintableString 'gov' - : } - : } - - - -Housley, et. al. Standards Track [Page 119] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - 56 31 13: SET { - 58 30 11: SEQUENCE { - 60 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) - 65 13 4: PrintableString 'NIST' - : } - : } - : } - 71 30 30: SEQUENCE { - 73 17 13: UTCTime '970730000000Z' - 88 17 13: UTCTime '971201000000Z' - : } - 103 30 61: SEQUENCE { - 105 31 11: SET { - 107 30 9: SEQUENCE { - 109 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) - 114 13 2: PrintableString 'US' - : } - : } - 118 31 12: SET { - 120 30 10: SEQUENCE { - 122 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) - 127 13 3: PrintableString 'gov' - : } - : } - 132 31 13: SET { - 134 30 11: SEQUENCE { - 136 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) - 141 13 4: PrintableString 'NIST' - : } - : } - 147 31 17: SET { - 149 30 15: SEQUENCE { - 151 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 156 13 8: PrintableString 'Tim Polk' - : } - : } - : } - 166 30 439: SEQUENCE { - 170 30 300: SEQUENCE { - 174 06 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) - 183 30 287: SEQUENCE { - 187 02 129: INTEGER - : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC - : FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC - : 48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F - : 22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64 - - - -Housley, et. al. Standards Track [Page 120] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - : 3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A - : C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD - : 35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E - : 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A - : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 - : 63 FE 43 - 319 02 21: INTEGER - : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA - : 55 F7 7D 57 74 81 E5 - 342 02 129: INTEGER - : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 - : C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92 - : 81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77 - : A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC - : 46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A - : 5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C - : 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2 - : 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF - : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE - : 1E 57 18 - : } - : } - 474 03 132: BIT STRING 0 unused bits, encapsulates { - 478 02 128: INTEGER - : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB - : A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C - : B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33 - : 37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A - : 9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7 - : 2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61 - : 35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24 - : 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC - : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 - : 95 BE - : } - : } - 609 A3 62: [3] { - 611 30 60: SEQUENCE { - 613 30 25: SEQUENCE { - 615 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) - 620 04 18: OCTET STRING, encapsulates { - 622 30 16: SEQUENCE { - 624 81 14: [1] 'wpolk@nist.gov' - : } - : } - : } - 640 30 31: SEQUENCE { - 642 06 3: OBJECT IDENTIFIER - - - -Housley, et. al. Standards Track [Page 121] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - : authorityKeyIdentifier (2 5 29 35) - 647 04 24: OCTET STRING, encapsulates { - 649 30 22: SEQUENCE { - 651 80 20: [0] - : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 - : 41 2C 29 49 F4 86 56 - : } - : } - : } - : } - : } - : } - 673 30 9: SEQUENCE { - 675 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 684 03 48: BIT STRING 0 unused bits, encapsulates { - 687 30 45: SEQUENCE { - 689 02 20: INTEGER - : 36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC - : 22 92 9F F4 F5 87 - 711 02 21: INTEGER - : 00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10 - : B4 A0 2E FF 22 5A 73 - : } - : } - : } - -C.3 End Entity Certificate Using RSA - - This section contains an annotated hex dump of a 654 byte version 3 - certificate. The certificate contains the following information: - (a) the serial number is 256; - (b) the certificate is signed with RSA and the SHA-1 hash algorithm; - (c) the issuer's distinguished name is OU=NIST; O=gov; C=US - (d) and the subject's distinguished name is CN=Tim Polk; OU=NIST; - O=gov; C=US - (e) the certificate was issued on May 21, 1996 at 09:58:26 and - expired on May 21, 1997 at 09:58:26; - (f) the certificate contains a 1024 bit RSA public key; - (g) the certificate is an end entity certificate (not a CA - certificate); - (h) the certificate includes an alternative subject name of - "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an - alternative issuer name of "<http://www.nist.gov/>" - both are URLs; - (i) the certificate include an authority key identifier extension - and a certificate policies extension specifying the policy OID - 2.16.840.1.101.3.2.1.48.9; and - - - - -Housley, et. al. Standards Track [Page 122] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - (j) the certificate includes a critical key usage extension - specifying that the public key is intended for verification of - digital signatures. - - 0 30 654: SEQUENCE { - 4 30 503: SEQUENCE { - 8 A0 3: [0] { - 10 02 1: INTEGER 2 - : } - 13 02 2: INTEGER 256 - 17 30 13: SEQUENCE { - 19 06 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 30 05 0: NULL - : } - 32 30 42: SEQUENCE { - 34 31 11: SET { - 36 30 9: SEQUENCE { - 38 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) - 43 13 2: PrintableString 'US' - : } - : } - 47 31 12: SET { - 49 30 10: SEQUENCE { - 51 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) - 56 13 3: PrintableString 'gov' - : } - : } - 61 31 13: SET { - 63 30 11: SEQUENCE { - 65 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) - 70 13 4: PrintableString 'NIST' - : } - : } - : } - 76 30 30: SEQUENCE { - 78 17 13: UTCTime '960521095826Z' - 93 17 13: UTCTime '970521095826Z' - : } -108 30 61: SEQUENCE { -110 31 11: SET { -112 30 9: SEQUENCE { -114 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) -119 13 2: PrintableString 'US' - : } - : } -123 31 12: SET { - - - -Housley, et. al. Standards Track [Page 123] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -125 30 10: SEQUENCE { -127 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) -132 13 3: PrintableString 'gov' - : } - : } -137 31 13: SET { -139 30 11: SEQUENCE { -141 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) -146 13 4: PrintableString 'NIST' - : } - : } -152 31 17: SET { -154 30 15: SEQUENCE { -156 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) -161 13 8: PrintableString 'Tim Polk' - : } - : } - : } -171 30 159: SEQUENCE { -174 30 13: SEQUENCE { -176 06 9: OBJECT IDENTIFIER - : rsaEncryption (1 2 840 113549 1 1 1) -187 05 0: NULL - : } -189 03 141: BIT STRING 0 unused bits, encapsulates { -193 30 137: SEQUENCE { -196 02 129: INTEGER - : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E - : 4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 - : EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77 - : 87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D - : 7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A - : 49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9 - : 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36 - : 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 - : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 - : 95 FF 23 -328 02 3: INTEGER 65537 - : } - : } - : } -333 A3 175: [3] { -336 30 172: SEQUENCE { -339 30 63: SEQUENCE { -341 06 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) -346 04 56: OCTET STRING, encapsulates { -348 30 54: SEQUENCE { - - - -Housley, et. al. Standards Track [Page 124] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -350 86 52: [6] - : 'http://www.itl.nist.gov/div893/staff/' - : 'polk/index.html' - : } - : } - : } -404 30 31: SEQUENCE { -406 06 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) -411 04 24: OCTET STRING, encapsulates { -413 30 22: SEQUENCE { -415 86 20: [6] 'http://www.nist.gov/' - : } - : } - : } -437 30 31: SEQUENCE { -439 06 3: OBJECT IDENTIFIER - : authorityKeyIdentifier (2 5 29 35) -444 04 24: OCTET STRING, encapsulates { -446 30 22: SEQUENCE { -448 80 20: [0] - : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E - : 70 6A 4A 20 84 2C 32 - : } - : } - : } -470 30 23: SEQUENCE { -472 06 3: OBJECT IDENTIFIER - : certificatePolicies (2 5 29 32) -477 04 16: OCTET STRING, encapsulates { -479 30 14: SEQUENCE { -481 30 12: SEQUENCE { -483 06 10: OBJECT IDENTIFIER - : '2 16 840 1 101 3 2 1 48 9' - : } - : } - : } - : } -495 30 14: SEQUENCE { -497 06 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) -502 01 1: BOOLEAN TRUE -505 04 4: OCTET STRING, encapsulates { -507 03 2: BIT STRING 7 unused bits - : '1'B (bit 0) - : } - : } - : } - : } - : } - - - -Housley, et. al. Standards Track [Page 125] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -511 30 13: SEQUENCE { -513 06 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) -524 05 0: NULL - : } -526 03 129: BIT STRING 0 unused bits - : 1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77 - : 6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47 - : 82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39 - : F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE - : 07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03 - : 40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6 - : E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08 - : BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06 - : 8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B - : 77 F3 - : } - -C.4 Certificate Revocation List - - This section contains an annotated hex dump of a version 2 CRL with - one extension (cRLNumber). The CRL was issued by OU=NIST; O=gov; - C=US on August 7, 1997; the next scheduled issuance was September 7, - 1997. The CRL includes one revoked certificates: serial number 18 - (12 hex), which was revoked on July 31, 1997 due to keyCompromise. - The CRL itself is number 18, and it was signed with DSA and SHA-1. - - 0 30 203: SEQUENCE { - 3 30 140: SEQUENCE { - 6 02 1: INTEGER 1 - 9 30 9: SEQUENCE { - 11 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 20 30 42: SEQUENCE { - 22 31 11: SET { - 24 30 9: SEQUENCE { - 26 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) - 31 13 2: PrintableString 'US' - : } - : } - 35 31 12: SET { - 37 30 10: SEQUENCE { - 39 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) - 44 13 3: PrintableString 'gov' - : } - : } - 49 31 13: SET { - 51 30 11: SEQUENCE { - - - -Housley, et. al. Standards Track [Page 126] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - - 53 06 3: OBJECT IDENTIFIER - : organizationalUnitName (2 5 4 11) - 58 13 4: PrintableString 'NIST' - : } - : } - : } - 64 17 13: UTCTime '970807000000Z' - 79 17 13: UTCTime '970907000000Z' - 94 30 34: SEQUENCE { - 96 30 32: SEQUENCE { - 98 02 1: INTEGER 18 -101 17 13: UTCTime '970731000000Z' -116 30 12: SEQUENCE { -118 30 10: SEQUENCE { -120 06 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) -125 04 3: OCTET STRING, encapsulates { -127 0A 1: ENUMERATED 1 - : } - : } - : } - : } - : } -130 A0 14: [0] { -132 30 12: SEQUENCE { -134 30 10: SEQUENCE { -136 06 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) -141 04 3: OCTET STRING, encapsulates { -143 02 1: INTEGER 12 - : } - : } - : } - : } - : } -146 30 9: SEQUENCE { -148 06 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } -157 03 47: BIT STRING 0 unused bits, encapsulates { -160 30 44: SEQUENCE { -162 02 20: INTEGER - : 22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6 - : 80 05 C0 3A 29 47 -184 02 20: INTEGER - : 59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B - : 96 16 B1 1F 46 5A - : } - : } - : } - - - - -Housley, et. al. Standards Track [Page 127] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -Author Addresses - - Russell Housley - RSA Laboratories - 918 Spring Knoll Drive - Herndon, VA 20170 - USA - - EMail: rhousley@rsasecurity.com - - Warwick Ford - VeriSign, Inc. - 401 Edgewater Place - Wakefield, MA 01880 - USA - - EMail: wford@verisign.com - - Tim Polk - NIST - Building 820, Room 426 - Gaithersburg, MD 20899 - USA - - EMail: wpolk@nist.gov - - David Solo - Citigroup - 909 Third Ave, 16th Floor - New York, NY 10043 - USA - - EMail: dsolo@alum.mit.edu - - - - - - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 128] - -RFC 3280 Internet X.509 Public Key Infrastructure April 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Housley, et. al. Standards Track [Page 129] - diff --git a/doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt b/doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt deleted file mode 100644 index 7b688a33f..000000000 --- a/doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group T. Kivinen -Request for Comments: 3526 M. Kojo -Category: Standards Track SSH Communications Security - May 2003 - - - More Modular Exponential (MODP) Diffie-Hellman groups - for Internet Key Exchange (IKE) - -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 Internet Society (2003). All Rights Reserved. - -Abstract - - This document defines new Modular Exponential (MODP) Groups for the - Internet Key Exchange (IKE) protocol. It documents the well known - and used 1536 bit group 5, and also defines new 2048, 3072, 4096, - 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. - The selection of the primes for theses groups follows the criteria - established by Richard Schroeppel. - -Table of Contents - - 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 - 2. 1536-bit MODP Group . . . . . . . . . . . . . . . . . . . 3 - 3. 2048-bit MODP Group . . . . . . . . . . . . . . . . . . . 3 - 4. 3072-bit MODP Group . . . . . . . . . . . . . . . . . . . 4 - 5. 4096-bit MODP Group . . . . . . . . . . . . . . . . . . . 5 - 6. 6144-bit MODP Group . . . . . . . . . . . . . . . . . . . 6 - 7. 8192-bit MODP Group . . . . . . . . . . . . . . . . . . . 6 - 8. Security Considerations . . . . . . . . . . . . . . . . . 8 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 - 10. Normative References. . . . . . . . . . . . . . . . . . . 8 - 11. Non-Normative References. . . . . . . . . . . . . . . . . 8 - 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . 9 - 13. Full Copyright Statement. . . . . . . . . . . . . . . . . 10 - - - - - - -Kivinen & Kojo Standards Track [Page 1] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -1. Introduction - - One of the important protocol parameters negotiated by Internet Key - Exchange (IKE) [RFC-2409] is the Diffie-Hellman "group" that will be - used for certain cryptographic operations. IKE currently defines 4 - groups. These groups are approximately as strong as a symmetric key - of 70-80 bits. - - The new Advanced Encryption Standard (AES) cipher [AES], which has - more strength, needs stronger groups. For the 128-bit AES we need - about a 3200-bit group [Orman01]. The 192 and 256-bit keys would - need groups that are about 8000 and 15400 bits respectively. Another - source [RSA13] [Rousseau00] estimates that the security equivalent - key size for the 192-bit symmetric cipher is 2500 bits instead of - 8000 bits, and the equivalent key size 256-bit symmetric cipher is - 4200 bits instead of 15400 bits. - - Because of this disagreement, we just specify different groups - without specifying which group should be used with 128, 192 or 256- - bit AES. With current hardware groups bigger than 8192-bits being - too slow for practical use, this document does not provide any groups - bigger than 8192-bits. - - The exponent size used in the Diffie-Hellman must be selected so that - it matches other parts of the system. It should not be the weakest - link in the security system. It should have double the entropy of - the strength of the entire system, i.e., if you use a group whose - strength is 128 bits, you must use more than 256 bits of randomness - in the exponent used in the Diffie-Hellman calculation. - - - - - - - - - - - - - - - - - - - - - - -Kivinen & Kojo Standards Track [Page 2] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -2. 1536-bit MODP Group - - The 1536 bit MODP group has been used for the implementations for - quite a long time, but was not defined in RFC 2409 (IKE). - Implementations have been using group 5 to designate this group, we - standardize that practice here. - - The prime is: 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 } - - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF - - The generator is: 2. - -3. 2048-bit MODP Group - - This group is assigned id 14. - - This prime is: 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 } - - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B - E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 - DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 - 15728E5A 8AACAA68 FFFFFFFF FFFFFFFF - - The generator is: 2. - - - - - - - - -Kivinen & Kojo Standards Track [Page 3] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -4. 3072-bit MODP Group - - This group is assigned id 15. - - This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] + 1690314 } - - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B - E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 - DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 - 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 - ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 - ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B - F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C - BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 - 43DB5BFC E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF - - The generator is: 2. - - - - - - - - - - - - - - - - - - - - - - - - - -Kivinen & Kojo Standards Track [Page 4] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -5. 4096-bit MODP Group - - This group is assigned id 16. - - This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] + 240904 } - - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B - E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 - DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 - 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 - ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 - ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B - F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C - BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 - 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 - 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA - 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 - 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED - 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 - 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199 - FFFFFFFF FFFFFFFF - - The generator is: 2. - - - - - - - - - - - - - - - - - - - -Kivinen & Kojo Standards Track [Page 5] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -6. 6144-bit MODP Group - - This group is assigned id 17. - - This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] + 929484 } - - 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 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 - FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C - 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718 - 3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D - 04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D - B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 - 1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C - BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC - E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26 - 99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB - 04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2 - 233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 - D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 - 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406 - AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918 - DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151 - 2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03 - F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F - BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA - CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B - B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632 - 387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E - 6DCC4024 FFFFFFFF FFFFFFFF - - The generator is: 2. - -7. 8192-bit MODP Group - - This group is assigned id 18. - - This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] + 4743158 } - - - - - - - -Kivinen & Kojo Standards Track [Page 6] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - - 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 ECE45B3D - C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F - 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D - 670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B - E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 - DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510 - 15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64 - ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7 - ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B - F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C - BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 - 43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 - 88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA - 2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6 - 287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED - 1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9 - 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492 - 36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD - F8FF9406 AD9E530E E5DB382F 413001AE B06A53ED 9027D831 - 179727B0 865A8918 DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B - DB7F1447 E6CC254B 33205151 2BD7AF42 6FB8F401 378CD2BF - 5983CA01 C64B92EC F032EA15 D1721D03 F482D7CE 6E74FEF6 - D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F BEC7E8F3 - 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA - CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 - 06A1D58B B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C - DA56C9EC 2EF29632 387FE8D7 6E3C0468 043E8F66 3F4860EE - 12BF2D5B 0B7474D6 E694F91E 6DBE1159 74A3926F 12FEE5E4 - 38777CB6 A932DF8C D8BEC4D0 73B931BA 3BC832B6 8D9DD300 - 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C 5AE4F568 - 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9 - 22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B - 4BCBC886 2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A - 062B3CF5 B3A278A6 6D2A13F8 3F44F82D DF310EE0 74AB6A36 - 4597E899 A0255DC1 64F31CC5 0846851D F9AB4819 5DED7EA1 - B1D510BD 7EE74D73 FAF36BC3 1ECFA268 359046F4 EB879F92 - 4009438B 481C6CD7 889A002E D5EE382B C9190DA6 FC026E47 - 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71 - 60C980DD 98EDD3DF FFFFFFFF FFFFFFFF - - The generator is: 2. - - - - -Kivinen & Kojo Standards Track [Page 7] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -8. Security Considerations - - This document describes new stronger groups to be used in IKE. The - strengths of the groups defined here are always estimates and there - are as many methods to estimate them as there are cryptographers. - For the strength estimates below we took the both ends of the scale - so the actual strength estimate is likely between the two numbers - given here. - - +--------+----------+---------------------+---------------------+ - | Group | Modulus | Strength Estimate 1 | Strength Estimate 2 | - | | +----------+----------+----------+----------+ - | | | | exponent | | exponent | - | | | in bits | size | in bits | size | - +--------+----------+----------+----------+----------+----------+ - | 5 | 1536-bit | 90 | 180- | 120 | 240- | - | 14 | 2048-bit | 110 | 220- | 160 | 320- | - | 15 | 3072-bit | 130 | 260- | 210 | 420- | - | 16 | 4096-bit | 150 | 300- | 240 | 480- | - | 17 | 6144-bit | 170 | 340- | 270 | 540- | - | 18 | 8192-bit | 190 | 380- | 310 | 620- | - +--------+----------+---------------------+---------------------+ - -9. IANA Considerations - - IKE [RFC-2409] defines 4 Diffie-Hellman Groups, numbered 1 through 4. - - This document defines a new group 5, and new groups from 14 to 18. - Requests for additional assignment are via "IETF Consensus" as - defined in RFC 2434 [RFC-2434]. Specifically, new groups are - expected to be documented in a Standards Track RFC. - -10. Normative References - - [RFC-2409] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - -11. Non-Normative References - - [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard - (AES)," November 2001. - http://csrc.nist.gov/publications/fips/fips197/fips- - 197.{ps,pdf} - - - - -Kivinen & Kojo Standards Track [Page 8] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - - [RFC-2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC - 2412, November 1998. - - [Orman01] Orman, H. and P. Hoffman, "Determining Strengths For - Public Keys Used For Exchanging Symmetric Keys", Work in - progress. - - [RSA13] Silverman, R. "RSA Bulleting #13: A Cost-Based Security - Analysis of Symmetric and Asymmetric Key Lengths", April - 2000, http://www.rsasecurity.com/rsalabs/bulletins/ - bulletin13.html - - [Rousseau00] Rousseau, F. "New Time and Space Based Key Size - Equivalents for RSA and Diffie-Hellman", December 2000, - http://www.sandelman.ottawa.on.ca/ipsec/2000/12/ - msg00045.html - -12. Authors' Addresses - - Tero Kivinen - SSH Communications Security Corp - Fredrikinkatu 42 - FIN-00100 HELSINKI - Finland - - EMail: kivinen@ssh.fi - - - Mika Kojo - HELSINKI - Finland - - EMail: mika.kojo@helsinki.fi - - - - - - - - - - - - - - - - - - -Kivinen & Kojo Standards Track [Page 9] - -RFC 3526 MODP Diffie-Hellman groups for IKE May 2003 - - -13. Full Copyright Statement - - Copyright (C) The Internet Society (2003). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Kivinen & Kojo Standards Track [Page 10] - diff --git a/doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt b/doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt deleted file mode 100644 index 4a8eba975..000000000 --- a/doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt +++ /dev/null @@ -1,5659 +0,0 @@ - - - - - - -Network Working Group S. Kent -Request for Comments: 4301 K. Seo -Obsoletes: 2401 BBN Technologies -Category: Standards Track December 2005 - - - Security Architecture for the Internet Protocol - -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 Internet Society (2005). - -Abstract - - This document describes an updated version of the "Security - Architecture for IP", which is designed to provide security services - for traffic at the IP layer. This document obsoletes RFC 2401 - (November 1998). - -Dedication - - This document is dedicated to the memory of Charlie Lynn, a long-time - senior colleague at BBN, who made very significant contributions to - the IPsec documents. - - - - - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 1] - -RFC 4301 Security Architecture for IP December 2005 - - -Table of Contents - - 1. Introduction ....................................................4 - 1.1. Summary of Contents of Document ............................4 - 1.2. Audience ...................................................4 - 1.3. Related Documents ..........................................5 - 2. Design Objectives ...............................................5 - 2.1. Goals/Objectives/Requirements/Problem Description ..........5 - 2.2. Caveats and Assumptions ....................................6 - 3. System Overview .................................................7 - 3.1. What IPsec Does ............................................7 - 3.2. How IPsec Works ............................................9 - 3.3. Where IPsec Can Be Implemented ............................10 - 4. Security Associations ..........................................11 - 4.1. Definition and Scope ......................................12 - 4.2. SA Functionality ..........................................16 - 4.3. Combining SAs .............................................17 - 4.4. Major IPsec Databases .....................................18 - 4.4.1. The Security Policy Database (SPD) .................19 - 4.4.1.1. Selectors .................................26 - 4.4.1.2. Structure of an SPD Entry .................30 - 4.4.1.3. More Regarding Fields Associated - with Next Layer Protocols .................32 - 4.4.2. Security Association Database (SAD) ................34 - 4.4.2.1. Data Items in the SAD .....................36 - 4.4.2.2. Relationship between SPD, PFP - flag, packet, and SAD .....................38 - 4.4.3. Peer Authorization Database (PAD) ..................43 - 4.4.3.1. PAD Entry IDs and Matching Rules ..........44 - 4.4.3.2. IKE Peer Authentication Data ..............45 - 4.4.3.3. Child SA Authorization Data ...............46 - 4.4.3.4. How the PAD Is Used .......................46 - 4.5. SA and Key Management .....................................47 - 4.5.1. Manual Techniques ..................................48 - 4.5.2. Automated SA and Key Management ....................48 - 4.5.3. Locating a Security Gateway ........................49 - 4.6. SAs and Multicast .........................................50 - 5. IP Traffic Processing ..........................................50 - 5.1. Outbound IP Traffic Processing - (protected-to-unprotected) ................................52 - 5.1.1. Handling an Outbound Packet That Must Be - Discarded ..........................................54 - 5.1.2. Header Construction for Tunnel Mode ................55 - 5.1.2.1. IPv4: Header Construction for - Tunnel Mode ...............................57 - 5.1.2.2. IPv6: Header Construction for - Tunnel Mode ...............................59 - 5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59 - - - -Kent & Seo Standards Track [Page 2] - -RFC 4301 Security Architecture for IP December 2005 - - - 6. ICMP Processing ................................................63 - 6.1. Processing ICMP Error Messages Directed to an - IPsec Implementation ......................................63 - 6.1.1. ICMP Error Messages Received on the - Unprotected Side of the Boundary ...................63 - 6.1.2. ICMP Error Messages Received on the - Protected Side of the Boundary .....................64 - 6.2. Processing Protected, Transit ICMP Error Messages .........64 - 7. Handling Fragments (on the protected side of the IPsec - boundary) ......................................................66 - 7.1. Tunnel Mode SAs that Carry Initial and Non-Initial - Fragments .................................................67 - 7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67 - 7.3. Stateful Fragment Checking ................................68 - 7.4. BYPASS/DISCARD Traffic ....................................69 - 8. Path MTU/DF Processing .........................................69 - 8.1. DF Bit ....................................................69 - 8.2. Path MTU (PMTU) Discovery .................................70 - 8.2.1. Propagation of PMTU ................................70 - 8.2.2. PMTU Aging .........................................71 - 9. Auditing .......................................................71 - 10. Conformance Requirements ......................................71 - 11. Security Considerations .......................................72 - 12. IANA Considerations ...........................................72 - 13. Differences from RFC 2401 .....................................72 - 14. Acknowledgements ..............................................75 - Appendix A: Glossary ..............................................76 - Appendix B: Decorrelation .........................................79 - B.1. Decorrelation Algorithm ...................................79 - Appendix C: ASN.1 for an SPD Entry ................................82 - Appendix D: Fragment Handling Rationale ...........................88 - D.1. Transport Mode and Fragments ..............................88 - D.2. Tunnel Mode and Fragments .................................89 - D.3. The Problem of Non-Initial Fragments ......................90 - D.4. BYPASS/DISCARD Traffic ....................................93 - D.5. Just say no to ports? .....................................94 - D.6. Other Suggested Solutions..................................94 - D.7. Consistency................................................95 - D.8. Conclusions................................................95 - Appendix E: Example of Supporting Nested SAs via SPD and - Forwarding Table Entries...............................96 - References.........................................................98 - Normative References............................................98 - Informative References..........................................99 - - - - - - - -Kent & Seo Standards Track [Page 3] - -RFC 4301 Security Architecture for IP December 2005 - - -1. Introduction - -1.1. Summary of Contents of Document - - This document specifies the base architecture for IPsec-compliant - systems. It describes how to provide a set of security services for - traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98] - environments. This document describes the requirements for systems - that implement IPsec, the fundamental elements of such systems, and - how the elements fit together and fit into the IP environment. It - also describes the security services offered by the IPsec protocols, - and how these services can be employed in the IP environment. This - document does not address all aspects of the IPsec architecture. - Other documents address additional architectural details in - specialized environments, e.g., use of IPsec in Network Address - Translation (NAT) environments and more comprehensive support for IP - multicast. The fundamental components of the IPsec security - architecture are discussed in terms of their underlying, required - functionality. Additional RFCs (see Section 1.3 for pointers to - other documents) define the protocols in (a), (c), and (d). - - a. Security Protocols -- Authentication Header (AH) and - Encapsulating Security Payload (ESP) - b. Security Associations -- what they are and how they work, - how they are managed, associated processing - c. Key Management -- manual and automated (The Internet Key - Exchange (IKE)) - d. Cryptographic algorithms for authentication and encryption - - This document is not a Security Architecture for the Internet; it - addresses security only at the IP layer, provided through the use of - a combination of cryptographic and protocol security mechanisms. - - The spelling "IPsec" is preferred and used throughout this and all - related IPsec standards. All other capitalizations of IPsec (e.g., - IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of - the sequence of letters "IPsec" should be understood to refer to the - IPsec protocols. - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in RFC 2119 [Bra97]. - -1.2. Audience - - The target audience for this document is primarily individuals who - implement this IP security technology or who architect systems that - will use this technology. Technically adept users of this technology - - - -Kent & Seo Standards Track [Page 4] - -RFC 4301 Security Architecture for IP December 2005 - - - (end users or system administrators) also are part of the target - audience. A glossary is provided in Appendix A to help fill in gaps - in background/vocabulary. This document assumes that the reader is - familiar with the Internet Protocol (IP), related networking - technology, and general information system security terms and - concepts. - -1.3. Related Documents - - As mentioned above, other documents provide detailed definitions of - some of the components of IPsec and of their interrelationship. They - include RFCs on the following topics: - - a. security protocols -- RFCs describing the Authentication - Header (AH) [Ken05b] and Encapsulating Security Payload - (ESP) [Ken05a] protocols. - b. cryptographic algorithms for integrity and encryption -- one - RFC that defines the mandatory, default algorithms for use - with AH and ESP [Eas05], a similar RFC that defines the - mandatory algorithms for use with IKEv2 [Sch05] plus a - separate RFC for each cryptographic algorithm. - c. automatic key management -- RFCs on "The Internet Key - Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic - Algorithms for Use in the Internet Key Exchange Version 2 - (IKEv2)" [Sch05]. - -2. Design Objectives - -2.1. Goals/Objectives/Requirements/Problem Description - - IPsec is designed to provide interoperable, high quality, - cryptographically-based security for IPv4 and IPv6. The set of - security services offered includes access control, connectionless - integrity, data origin authentication, detection and rejection of - replays (a form of partial sequence integrity), confidentiality (via - encryption), and limited traffic flow confidentiality. These - services are provided at the IP layer, offering protection in a - standard fashion for all protocols that may be carried over IP - (including IP itself). - - IPsec includes a specification for minimal firewall functionality, - since that is an essential aspect of access control at the IP layer. - Implementations are free to provide more sophisticated firewall - mechanisms, and to implement the IPsec-mandated functionality using - those more sophisticated mechanisms. (Note that interoperability may - suffer if additional firewall constraints on traffic flows are - imposed by an IPsec implementation but cannot be negotiated based on - the traffic selector features defined in this document and negotiated - - - -Kent & Seo Standards Track [Page 5] - -RFC 4301 Security Architecture for IP December 2005 - - - via IKEv2.) The IPsec firewall function makes use of the - cryptographically-enforced authentication and integrity provided for - all IPsec traffic to offer better access control than could be - obtained through use of a firewall (one not privy to IPsec internal - parameters) plus separate cryptographic protection. - - Most of the security services are provided through use of two traffic - security protocols, the Authentication Header (AH) and the - Encapsulating Security Payload (ESP), and through the use of - cryptographic key management procedures and protocols. The set of - IPsec protocols employed in a context, and the ways in which they are - employed, will be determined by the users/administrators in that - context. It is the goal of the IPsec architecture to ensure that - compliant implementations include the services and management - interfaces needed to meet the security requirements of a broad user - population. - - When IPsec is correctly implemented and deployed, it ought not - adversely affect users, hosts, and other Internet components that do - not employ IPsec for traffic protection. IPsec security protocols - (AH and ESP, and to a lesser extent, IKE) are designed to be - cryptographic algorithm independent. This modularity permits - selection of different sets of cryptographic algorithms as - appropriate, without affecting the other parts of the implementation. - For example, different user communities may select different sets of - cryptographic algorithms (creating cryptographically-enforced - cliques) if required. - - To facilitate interoperability in the global Internet, a set of - default cryptographic algorithms for use with AH and ESP is specified - in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2 - is specified in [Sch05]. [Eas05] and [Sch05] will be periodically - updated to keep pace with computational and cryptologic advances. By - specifying these algorithms in documents that are separate from the - AH, ESP, and IKEv2 specifications, these algorithms can be updated or - replaced without affecting the standardization progress of the rest - of the IPsec document suite. The use of these cryptographic - algorithms, in conjunction with IPsec traffic protection and key - management protocols, is intended to permit system and application - developers to deploy high quality, Internet-layer, cryptographic - security technology. - -2.2. Caveats and Assumptions - - The suite of IPsec protocols and associated default cryptographic - algorithms are designed to provide high quality security for Internet - traffic. However, the security offered by use of these protocols - ultimately depends on the quality of their implementation, which is - - - -Kent & Seo Standards Track [Page 6] - -RFC 4301 Security Architecture for IP December 2005 - - - outside the scope of this set of standards. Moreover, the security - of a computer system or network is a function of many factors, - including personnel, physical, procedural, compromising emanations, - and computer security practices. Thus, IPsec is only one part of an - overall system security architecture. - - Finally, the security afforded by the use of IPsec is critically - dependent on many aspects of the operating environment in which the - IPsec implementation executes. For example, defects in OS security, - poor quality of random number sources, sloppy system management - protocols and practices, etc., can all degrade the security provided - by IPsec. As above, none of these environmental attributes are - within the scope of this or other IPsec standards. - -3. System Overview - - This section provides a high level description of how IPsec works, - the components of the system, and how they fit together to provide - the security services noted above. The goal of this description is - to enable the reader to "picture" the overall process/system, see how - it fits into the IP environment, and to provide context for later - sections of this document, which describe each of the components in - more detail. - - An IPsec implementation operates in a host, as a security gateway - (SG), or as an independent device, affording protection to IP - traffic. (A security gateway is an intermediate system implementing - IPsec, e.g., a firewall or router that has been IPsec-enabled.) More - detail on these classes of implementations is provided later, in - Section 3.3. The protection offered by IPsec is based on requirements - defined by a Security Policy Database (SPD) established and - maintained by a user or system administrator, or by an application - operating within constraints established by either of the above. In - general, packets are selected for one of three processing actions - based on IP and next layer header information ("Selectors", Section - 4.4.1.1) matched against entries in the SPD. Each packet is either - PROTECTed using IPsec security services, DISCARDed, or allowed to - BYPASS IPsec protection, based on the applicable SPD policies - identified by the Selectors. - -3.1. What IPsec Does - - IPsec creates a boundary between unprotected and protected - interfaces, for a host or a network (see Figure 1 below). Traffic - traversing the boundary is subject to the access controls specified - by the user or administrator responsible for the IPsec configuration. - These controls indicate whether packets cross the boundary unimpeded, - are afforded security services via AH or ESP, or are discarded. - - - -Kent & Seo Standards Track [Page 7] - -RFC 4301 Security Architecture for IP December 2005 - - - IPsec security services are offered at the IP layer through selection - of appropriate security protocols, cryptographic algorithms, and - cryptographic keys. IPsec can be used to protect one or more "paths" - (a) between a pair of hosts, (b) between a pair of security gateways, - or (c) between a security gateway and a host. A compliant host - implementation MUST support (a) and (c) and a compliant security - gateway must support all three of these forms of connectivity, since - under certain circumstances a security gateway acts as a host. - - Unprotected - ^ ^ - | | - +-------------|-------|-------+ - | +-------+ | | | - | |Discard|<--| V | - | +-------+ |B +--------+ | - ................|y..| AH/ESP |..... IPsec Boundary - | +---+ |p +--------+ | - | |IKE|<----|a ^ | - | +---+ |s | | - | +-------+ |s | | - | |Discard|<--| | | - | +-------+ | | | - +-------------|-------|-------+ - | | - V V - Protected - - Figure 1. Top Level IPsec Processing Model - - In this diagram, "unprotected" refers to an interface that might also - be described as "black" or "ciphertext". Here, "protected" refers to - an interface that might also be described as "red" or "plaintext". - The protected interface noted above may be internal, e.g., in a host - implementation of IPsec, the protected interface may link to a socket - layer interface presented by the OS. In this document, the term - "inbound" refers to traffic entering an IPsec implementation via the - unprotected interface or emitted by the implementation on the - unprotected side of the boundary and directed towards the protected - interface. The term "outbound" refers to traffic entering the - implementation via the protected interface, or emitted by the - implementation on the protected side of the boundary and directed - toward the unprotected interface. An IPsec implementation may - support more than one interface on either or both sides of the - boundary. - - - - - - -Kent & Seo Standards Track [Page 8] - -RFC 4301 Security Architecture for IP December 2005 - - - Note the facilities for discarding traffic on either side of the - IPsec boundary, the BYPASS facility that allows traffic to transit - the boundary without cryptographic protection, and the reference to - IKE as a protected-side key and security management function. - - IPsec optionally supports negotiation of IP compression [SMPT01], - motivated in part by the observation that when encryption is employed - within IPsec, it prevents effective compression by lower protocol - layers. - -3.2. How IPsec Works - - IPsec uses two protocols to provide traffic security services -- - Authentication Header (AH) and Encapsulating Security Payload (ESP). - Both protocols are described in detail in their respective RFCs - [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY - support AH. (Support for AH has been downgraded to MAY because - experience has shown that there are very few contexts in which ESP - cannot provide the requisite security services. Note that ESP can be - used to provide only integrity, without confidentiality, making it - comparable to AH in most contexts.) - - o The IP Authentication Header (AH) [Ken05b] offers integrity and - data origin authentication, with optional (at the discretion of - the receiver) anti-replay features. - - o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers - the same set of services, and also offers confidentiality. Use of - ESP to provide confidentiality without integrity is NOT - RECOMMENDED. When ESP is used with confidentiality enabled, there - are provisions for limited traffic flow confidentiality, i.e., - provisions for concealing packet length, and for facilitating - efficient generation and discard of dummy packets. This - capability is likely to be effective primarily in virtual private - network (VPN) and overlay network contexts. - - o Both AH and ESP offer access control, enforced through the - distribution of cryptographic keys and the management of traffic - flows as dictated by the Security Policy Database (SPD, Section - 4.4.1). - - These protocols may be applied individually or in combination with - each other to provide IPv4 and IPv6 security services. However, most - security requirements can be met through the use of ESP by itself. - Each protocol supports two modes of use: transport mode and tunnel - mode. In transport mode, AH and ESP provide protection primarily for - - - - - -Kent & Seo Standards Track [Page 9] - -RFC 4301 Security Architecture for IP December 2005 - - - next layer protocols; in tunnel mode, AH and ESP are applied to - tunneled IP packets. The differences between the two modes are - discussed in Section 4.1. - - IPsec allows the user (or system administrator) to control the - granularity at which a security service is offered. For example, one - can create a single encrypted tunnel to carry all the traffic between - two security gateways, or a separate encrypted tunnel can be created - for each TCP connection between each pair of hosts communicating - across these gateways. IPsec, through the SPD management paradigm, - incorporates facilities for specifying: - - o which security protocol (AH or ESP) to employ, the mode (transport - or tunnel), security service options, what cryptographic - algorithms to use, and in what combinations to use the specified - protocols and services, and - - o the granularity at which protection should be applied. - - Because most of the security services provided by IPsec require the - use of cryptographic keys, IPsec relies on a separate set of - mechanisms for putting these keys in place. This document requires - support for both manual and automated distribution of keys. It - specifies a specific public-key based approach (IKEv2 [Kau05]) for - automated key management, but other automated key distribution - techniques MAY be used. - - Note: This document mandates support for several features for which - support is available in IKEv2 but not in IKEv1, e.g., negotiation of - an SA representing ranges of local and remote ports or negotiation of - multiple SAs with the same selectors. Therefore, this document - assumes use of IKEv2 or a key and security association management - system with comparable features. - -3.3. Where IPsec Can Be Implemented - - There are many ways in which IPsec may be implemented in a host, or - in conjunction with a router or firewall to create a security - gateway, or as an independent security device. - - a. IPsec may be integrated into the native IP stack. This requires - access to the IP source code and is applicable to both hosts and - security gateways, although native host implementations benefit - the most from this strategy, as explained later (Section 4.4.1, - paragraph 6; Section 4.4.1.1, last paragraph). - - - - - - -Kent & Seo Standards Track [Page 10] - -RFC 4301 Security Architecture for IP December 2005 - - - b. In a "bump-in-the-stack" (BITS) implementation, IPsec is - implemented "underneath" an existing implementation of an IP - protocol stack, between the native IP and the local network - drivers. Source code access for the IP stack is not required in - this context, making this implementation approach appropriate for - use with legacy systems. This approach, when it is adopted, is - usually employed in hosts. - - c. The use of a dedicated, inline security protocol processor is a - common design feature of systems used by the military, and of some - commercial systems as well. It is sometimes referred to as a - "bump-in-the-wire" (BITW) implementation. Such implementations - may be designed to serve either a host or a gateway. Usually, the - BITW device is itself IP addressable. When supporting a single - host, it may be quite analogous to a BITS implementation, but in - supporting a router or firewall, it must operate like a security - gateway. - - This document often talks in terms of use of IPsec by a host or a - security gateway, without regard to whether the implementation is - native, BITS, or BITW. When the distinctions among these - implementation options are significant, the document makes reference - to specific implementation approaches. - - A host implementation of IPsec may appear in devices that might not - be viewed as "hosts". For example, a router might employ IPsec to - protect routing protocols (e.g., BGP) and management functions (e.g., - Telnet), without affecting subscriber traffic traversing the router. - A security gateway might employ separate IPsec implementations to - protect its management traffic and subscriber traffic. The - architecture described in this document is very flexible. For - example, a computer with a full-featured, compliant, native OS IPsec - implementation should be capable of being configured to protect - resident (host) applications and to provide security gateway - protection for traffic traversing the computer. Such configuration - would make use of the forwarding tables and the SPD selection - function described in Sections 5.1 and 5.2. - -4. Security Associations - - This section defines Security Association management requirements for - all IPv6 implementations and for those IPv4 implementations that - implement AH, ESP, or both AH and ESP. The concept of a "Security - Association" (SA) is fundamental to IPsec. Both AH and ESP make use - of SAs, and a major function of IKE is the establishment and - maintenance of SAs. All implementations of AH or ESP MUST support - the concept of an SA as described below. The remainder of this - - - - -Kent & Seo Standards Track [Page 11] - -RFC 4301 Security Architecture for IP December 2005 - - - section describes various aspects of SA management, defining required - characteristics for SA policy management and SA management - techniques. - -4.1. Definition and Scope - - An SA is a simplex "connection" that affords security services to the - traffic carried by it. Security services are afforded to an SA by - the use of AH, or ESP, but not both. If both AH and ESP protection - are applied to a traffic stream, then two SAs must be created and - coordinated to effect protection through iterated application of the - security protocols. To secure typical, bi-directional communication - between two IPsec-enabled systems, a pair of SAs (one in each - direction) is required. IKE explicitly creates SA pairs in - recognition of this common usage requirement. - - For an SA used to carry unicast traffic, the Security Parameters - Index (SPI) by itself suffices to specify an SA. (For information on - the SPI, see Appendix A and the AH and ESP specifications [Ken05b, - Ken05a].) However, as a local matter, an implementation may choose - to use the SPI in conjunction with the IPsec protocol type (AH or - ESP) for SA identification. If an IPsec implementation supports - multicast, then it MUST support multicast SAs using the algorithm - below for mapping inbound IPsec datagrams to SAs. Implementations - that support only unicast traffic need not implement this de- - multiplexing algorithm. - - In many secure multicast architectures, e.g., [RFC3740], a central - Group Controller/Key Server unilaterally assigns the Group Security - Association's (GSA's) SPI. This SPI assignment is not negotiated or - coordinated with the key management (e.g., IKE) subsystems that - reside in the individual end systems that constitute the group. - Consequently, it is possible that a GSA and a unicast SA can - simultaneously use the same SPI. A multicast-capable IPsec - implementation MUST correctly de-multiplex inbound traffic even in - the context of SPI collisions. - - Each entry in the SA Database (SAD) (Section 4.4.2) must indicate - whether the SA lookup makes use of the destination IP address, or the - destination and source IP addresses, in addition to the SPI. For - multicast SAs, the protocol field is not employed for SA lookups. - For each inbound, IPsec-protected packet, an implementation must - conduct its search of the SAD such that it finds the entry that - matches the "longest" SA identifier. In this context, if two or more - SAD entries match based on the SPI value, then the entry that also - matches based on destination address, or destination and source - address (as indicated in the SAD entry) is the "longest" match. This - implies a logical ordering of the SAD search as follows: - - - -Kent & Seo Standards Track [Page 12] - -RFC 4301 Security Architecture for IP December 2005 - - - 1. Search the SAD for a match on the combination of SPI, - destination address, and source address. If an SAD entry - matches, then process the inbound packet with that - matching SAD entry. Otherwise, proceed to step 2. - - 2. Search the SAD for a match on both SPI and destination address. - If the SAD entry matches, then process the inbound packet - with that matching SAD entry. Otherwise, proceed to step 3. - - 3. Search the SAD for a match on only SPI if the receiver has - chosen to maintain a single SPI space for AH and ESP, and on - both SPI and protocol, otherwise. If an SAD entry matches, - then process the inbound packet with that matching SAD entry. - Otherwise, discard the packet and log an auditable event. - - In practice, an implementation may choose any method (or none at all) - to accelerate this search, although its externally visible behavior - MUST be functionally equivalent to having searched the SAD in the - above order. For example, a software-based implementation could - index into a hash table by the SPI. The SAD entries in each hash - table bucket's linked list could be kept sorted to have those SAD - entries with the longest SA identifiers first in that linked list. - Those SAD entries having the shortest SA identifiers could be sorted - so that they are the last entries in the linked list. A - hardware-based implementation may be able to effect the longest match - search intrinsically, using commonly available Ternary - Content-Addressable Memory (TCAM) features. - - The indication of whether source and destination address matching is - required to map inbound IPsec traffic to SAs MUST be set either as a - side effect of manual SA configuration or via negotiation using an SA - management protocol, e.g., IKE or Group Domain of Interpretation - (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03] - groups use a 3-tuple SA identifier composed of an SPI, a destination - multicast address, and source address. An Any-Source Multicast group - SA requires only an SPI and a destination multicast address as an - identifier. - - If different classes of traffic (distinguished by Differentiated - Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on - the same SA, and if the receiver is employing the optional - anti-replay feature available in both AH and ESP, this could result - in inappropriate discarding of lower priority packets due to the - windowing mechanism used by this feature. Therefore, a sender SHOULD - put traffic of different classes, but with the same selector values, - on different SAs to support Quality of Service (QoS) appropriately. - To permit this, the IPsec implementation MUST permit establishment - and maintenance of multiple SAs between a given sender and receiver, - - - -Kent & Seo Standards Track [Page 13] - -RFC 4301 Security Architecture for IP December 2005 - - - with the same selectors. Distribution of traffic among these - parallel SAs to support QoS is locally determined by the sender and - is not negotiated by IKE. The receiver MUST process the packets from - the different SAs without prejudice. These requirements apply to - both transport and tunnel mode SAs. In the case of tunnel mode SAs, - the DSCP values in question appear in the inner IP header. In - transport mode, the DSCP value might change en route, but this should - not cause problems with respect to IPsec processing since the value - is not employed for SA selection and MUST NOT be checked as part of - SA/packet validation. However, if significant re-ordering of packets - occurs in an SA, e.g., as a result of changes to DSCP values en - route, this may trigger packet discarding by a receiver due to - application of the anti-replay mechanism. - - DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit - Congestion Notification (ECN) [RaFlBl01] fields are not "selectors", - as that term in used in this architecture, the sender will need a - mechanism to direct packets with a given (set of) DSCP values to the - appropriate SA. This mechanism might be termed a "classifier". - - As noted above, two types of SAs are defined: transport mode and - tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose - to require that both SAs in a pair be of the same mode, transport or - tunnel. - - A transport mode SA is an SA typically employed between a pair of - hosts to provide end-to-end security services. When security is - desired between two intermediate systems along a path (vs. end-to-end - use of IPsec), transport mode MAY be used between security gateways - or between a security gateway and a host. In the case where - transport mode is used between security gateways or between a - security gateway and a host, transport mode may be used to support - in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing - Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing - [ToEgWa04]) over transport mode SAs. To clarify, the use of - transport mode by an intermediate system (e.g., a security gateway) - is permitted only when applied to packets whose source address (for - outbound packets) or destination address (for inbound packets) is an - address belonging to the intermediate system itself. The access - control functions that are an important part of IPsec are - significantly limited in this context, as they cannot be applied to - the end-to-end headers of the packets that traverse a transport mode - SA used in this fashion. Thus, this way of using transport mode - should be evaluated carefully before being employed in a specific - context. - - - - - - -Kent & Seo Standards Track [Page 14] - -RFC 4301 Security Architecture for IP December 2005 - - - In IPv4, a transport mode security protocol header appears - immediately after the IP header and any options, and before any next - layer protocols (e.g., TCP or UDP). In IPv6, the security protocol - header appears after the base IP header and selected extension - headers, but may appear before or after destination options; it MUST - appear before next layer protocols (e.g., TCP, UDP, Stream Control - Transmission Protocol (SCTP)). In the case of ESP, a transport mode - SA provides security services only for these next layer protocols, - not for the IP header or any extension headers preceding the ESP - header. In the case of AH, the protection is also extended to - selected portions of the IP header preceding it, selected portions of - extension headers, and selected options (contained in the IPv4 - header, IPv6 Hop-by-Hop extension header, or IPv6 Destination - extension headers). For more details on the coverage afforded by AH, - see the AH specification [Ken05b]. - - A tunnel mode SA is essentially an SA applied to an IP tunnel, with - the access controls applied to the headers of the traffic inside the - tunnel. Two hosts MAY establish a tunnel mode SA between themselves. - Aside from the two exceptions below, whenever either end of a - security association is a security gateway, the SA MUST be tunnel - mode. Thus, an SA between two security gateways is typically a - tunnel mode SA, as is an SA between a host and a security gateway. - The two exceptions are as follows. - - o Where traffic is destined for a security gateway, e.g., Simple - Network Management Protocol (SNMP) commands, the security gateway - is acting as a host and transport mode is allowed. In this case, - the SA terminates at a host (management) function within a - security gateway and thus merits different treatment. - - o As noted above, security gateways MAY support a transport mode SA - to provide security for IP traffic between two intermediate - systems along a path, e.g., between a host and a security gateway - or between two security gateways. - - Several concerns motivate the use of tunnel mode for an SA involving - a security gateway. For example, if there are multiple paths (e.g., - via different security gateways) to the same destination behind a - security gateway, it is important that an IPsec packet be sent to the - security gateway with which the SA was negotiated. Similarly, a - packet that might be fragmented en route must have all the fragments - delivered to the same IPsec instance for reassembly prior to - cryptographic processing. Also, when a fragment is processed by - IPsec and transmitted, then fragmented en route, it is critical that - there be inner and outer headers to retain the fragmentation state - data for the pre- and post-IPsec packet formats. Hence there are - several reasons for employing tunnel mode when either end of an SA is - - - -Kent & Seo Standards Track [Page 15] - -RFC 4301 Security Architecture for IP December 2005 - - - a security gateway. (Use of an IP-in-IP tunnel in conjunction with - transport mode can also address these fragmentation issues. However, - this configuration limits the ability of IPsec to enforce access - control policies on traffic.) - - Note: AH and ESP cannot be applied using transport mode to IPv4 - packets that are fragments. Only tunnel mode can be employed in such - cases. For IPv6, it would be feasible to carry a plaintext fragment - on a transport mode SA; however, for simplicity, this restriction - also applies to IPv6 packets. See Section 7 for more details on - handling plaintext fragments on the protected side of the IPsec - barrier. - - For a tunnel mode SA, there is an "outer" IP header that specifies - the IPsec processing source and destination, plus an "inner" IP - header that specifies the (apparently) ultimate source and - destination for the packet. The security protocol header appears - after the outer IP header, and before the inner IP header. If AH is - employed in tunnel mode, portions of the outer IP header are afforded - protection (as above), as well as all of the tunneled IP packet - (i.e., all of the inner IP header is protected, as well as next layer - protocols). If ESP is employed, the protection is afforded only to - the tunneled packet, not to the outer header. - - In summary, - - a) A host implementation of IPsec MUST support both transport and - tunnel mode. This is true for native, BITS, and BITW - implementations for hosts. - - b) A security gateway MUST support tunnel mode and MAY support - transport mode. If it supports transport mode, that should be - used only when the security gateway is acting as a host, e.g., for - network management, or to provide security between two - intermediate systems along a path. - -4.2. SA Functionality - - The set of security services offered by an SA depends on the security - protocol selected, the SA mode, the endpoints of the SA, and the - election of optional services within the protocol. - - For example, both AH and ESP offer integrity and authentication - services, but the coverage differs for each protocol and differs for - transport vs. tunnel mode. If the integrity of an IPv4 option or - IPv6 extension header must be protected en route between sender and - receiver, AH can provide this service, except for IP or extension - headers that may change in a fashion not predictable by the sender. - - - -Kent & Seo Standards Track [Page 16] - -RFC 4301 Security Architecture for IP December 2005 - - - However, the same security may be achieved in some contexts by - applying ESP to a tunnel carrying a packet. - - The granularity of access control provided is determined by the - choice of the selectors that define each SA. Moreover, the - authentication means employed by IPsec peers, e.g., during creation - of an IKE (vs. child) SA also affects the granularity of the access - control afforded. - - If confidentiality is selected, then an ESP (tunnel mode) SA between - two security gateways can offer partial traffic flow confidentiality. - The use of tunnel mode allows the inner IP headers to be encrypted, - concealing the identities of the (ultimate) traffic source and - destination. Moreover, ESP payload padding also can be invoked to - hide the size of the packets, further concealing the external - characteristics of the traffic. Similar traffic flow confidentiality - services may be offered when a mobile user is assigned a dynamic IP - address in a dialup context, and establishes a (tunnel mode) ESP SA - to a corporate firewall (acting as a security gateway). Note that - fine-granularity SAs generally are more vulnerable to traffic - analysis than coarse-granularity ones that are carrying traffic from - many subscribers. - - Note: A compliant implementation MUST NOT allow instantiation of an - ESP SA that employs both NULL encryption and no integrity algorithm. - An attempt to negotiate such an SA is an auditable event by both - initiator and responder. The audit log entry for this event SHOULD - include the current date/time, local IKE IP address, and remote IKE - IP address. The initiator SHOULD record the relevant SPD entry. - -4.3. Combining SAs - - This document does not require support for nested security - associations or for what RFC 2401 [RFC2401] called "SA bundles". - These features still can be effected by appropriate configuration of - both the SPD and the local forwarding functions (for inbound and - outbound traffic), but this capability is outside of the IPsec module - and thus the scope of this specification. As a result, management of - nested/bundled SAs is potentially more complex and less assured than - under the model implied by RFC 2401 [RFC2401]. An implementation - that provides support for nested SAs SHOULD provide a management - interface that enables a user or administrator to express the nesting - requirement, and then create the appropriate SPD entries and - forwarding table entries to effect the requisite processing. (See - Appendix E for an example of how to configure nested SAs.) - - - - - - -Kent & Seo Standards Track [Page 17] - -RFC 4301 Security Architecture for IP December 2005 - - -4.4. Major IPsec Databases - - Many of the details associated with processing IP traffic in an IPsec - implementation are largely a local matter, not subject to - standardization. However, some external aspects of the processing - must be standardized to ensure interoperability and to provide a - minimum management capability that is essential for productive use of - IPsec. This section describes a general model for processing IP - traffic relative to IPsec functionality, in support of these - interoperability and functionality goals. The model described below - is nominal; implementations need not match details of this model as - presented, but the external behavior of implementations MUST - correspond to the externally observable characteristics of this model - in order to be compliant. - - There are three nominal databases in this model: the Security Policy - Database (SPD), the Security Association Database (SAD), and the Peer - Authorization Database (PAD). The first specifies the policies that - determine the disposition of all IP traffic inbound or outbound from - a host or security gateway (Section 4.4.1). The second database - contains parameters that are associated with each established (keyed) - SA (Section 4.4.2). The third database, the PAD, provides a link - between an SA management protocol (such as IKE) and the SPD (Section - 4.4.3). - - Multiple Separate IPsec Contexts - - If an IPsec implementation acts as a security gateway for multiple - subscribers, it MAY implement multiple separate IPsec contexts. - Each context MAY have and MAY use completely independent - identities, policies, key management SAs, and/or IPsec SAs. This - is for the most part a local implementation matter. However, a - means for associating inbound (SA) proposals with local contexts - is required. To this end, if supported by the key management - protocol in use, context identifiers MAY be conveyed from - initiator to responder in the signaling messages, with the result - that IPsec SAs are created with a binding to a particular context. - For example, a security gateway that provides VPN service to - multiple customers will be able to associate each customer's - traffic with the correct VPN. - - Forwarding vs Security Decisions - - The IPsec model described here embodies a clear separation between - forwarding (routing) and security decisions, to accommodate a wide - range of contexts where IPsec may be employed. Forwarding may be - trivial, in the case where there are only two interfaces, or it - may be complex, e.g., if the context in which IPsec is implemented - - - -Kent & Seo Standards Track [Page 18] - -RFC 4301 Security Architecture for IP December 2005 - - - employs a sophisticated forwarding function. IPsec assumes only - that outbound and inbound traffic that has passed through IPsec - processing is forwarded in a fashion consistent with the context - in which IPsec is implemented. Support for nested SAs is - optional; if required, it requires coordination between forwarding - tables and SPD entries to cause a packet to traverse the IPsec - boundary more than once. - - "Local" vs "Remote" - - In this document, with respect to IP addresses and ports, the - terms "Local" and "Remote" are used for policy rules. "Local" - refers to the entity being protected by an IPsec implementation, - i.e., the "source" address/port of outbound packets or the - "destination" address/port of inbound packets. "Remote" refers to - a peer entity or peer entities. The terms "source" and - "destination" are used for packet header fields. - - "Non-initial" vs "Initial" Fragments - - Throughout this document, the phrase "non-initial fragments" is - used to mean fragments that do not contain all of the selector - values that may be needed for access control (e.g., they might not - contain Next Layer Protocol, source and destination ports, ICMP - message type/code, Mobility Header type). And the phrase "initial - fragment" is used to mean a fragment that contains all the - selector values needed for access control. However, it should be - noted that for IPv6, which fragment contains the Next Layer - Protocol and ports (or ICMP message type/code or Mobility Header - type [Mobip]) will depend on the kind and number of extension - headers present. The "initial fragment" might not be the first - fragment, in this context. - -4.4.1. The Security Policy Database (SPD) - - An SA is a management construct used to enforce security policy for - traffic crossing the IPsec boundary. Thus, an essential element of - SA processing is an underlying Security Policy Database (SPD) that - specifies what services are to be offered to IP datagrams and in what - fashion. The form of the database and its interface are outside the - scope of this specification. However, this section specifies minimum - management functionality that must be provided, to allow a user or - system administrator to control whether and how IPsec is applied to - traffic transmitted or received by a host or transiting a security - gateway. The SPD, or relevant caches, must be consulted during the - processing of all traffic (inbound and outbound), including traffic - not protected by IPsec, that traverses the IPsec boundary. This - includes IPsec management traffic such as IKE. An IPsec - - - -Kent & Seo Standards Track [Page 19] - -RFC 4301 Security Architecture for IP December 2005 - - - implementation MUST have at least one SPD, and it MAY support - multiple SPDs, if appropriate for the context in which the IPsec - implementation operates. There is no requirement to maintain SPDs on - a per-interface basis, as was specified in RFC 2401 [RFC2401]. - However, if an implementation supports multiple SPDs, then it MUST - include an explicit SPD selection function that is invoked to select - the appropriate SPD for outbound traffic processing. The inputs to - this function are the outbound packet and any local metadata (e.g., - the interface via which the packet arrived) required to effect the - SPD selection function. The output of the function is an SPD - identifier (SPD-ID). - - The SPD is an ordered database, consistent with the use of Access - Control Lists (ACLs) or packet filters in firewalls, routers, etc. - The ordering requirement arises because entries often will overlap - due to the presence of (non-trivial) ranges as values for selectors. - Thus, a user or administrator MUST be able to order the entries to - express a desired access control policy. There is no way to impose a - general, canonical order on SPD entries, because of the allowed use - of wildcards for selector values and because the different types of - selectors are not hierarchically related. - - Processing Choices: DISCARD, BYPASS, PROTECT - - An SPD must discriminate among traffic that is afforded IPsec - protection and traffic that is allowed to bypass IPsec. This - applies to the IPsec protection to be applied by a sender and to - the IPsec protection that must be present at the receiver. For - any outbound or inbound datagram, three processing choices are - possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The - first choice refers to traffic that is not allowed to traverse the - IPsec boundary (in the specified direction). The second choice - refers to traffic that is allowed to cross the IPsec boundary - without IPsec protection. The third choice refers to traffic that - is afforded IPsec protection, and for such traffic the SPD must - specify the security protocols to be employed, their mode, - security service options, and the cryptographic algorithms to be - used. - - SPD-S, SPD-I, SPD-O - - An SPD is logically divided into three pieces. The SPD-S (secure - traffic) contains entries for all traffic subject to IPsec - protection. SPD-O (outbound) contains entries for all outbound - traffic that is to be bypassed or discarded. SPD-I (inbound) is - applied to inbound traffic that will be bypassed or discarded. - All three of these can be decorrelated (with the exception noted - above for native host implementations) to facilitate caching. If - - - -Kent & Seo Standards Track [Page 20] - -RFC 4301 Security Architecture for IP December 2005 - - - an IPsec implementation supports only one SPD, then the SPD - consists of all three parts. If multiple SPDs are supported, some - of them may be partial, e.g., some SPDs might contain only SPD-I - entries, to control inbound bypassed traffic on a per-interface - basis. The split allows SPD-I to be consulted without having to - consult SPD-S, for such traffic. Since the SPD-I is just a part - of the SPD, if a packet that is looked up in the SPD-I cannot be - matched to an entry there, then the packet MUST be discarded. - Note that for outbound traffic, if a match is not found in SPD-S, - then SPD-O must be checked to see if the traffic should be - bypassed. Similarly, if SPD-O is checked first and no match is - found, then SPD-S must be checked. In an ordered, - non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O - are interleaved. So there is one lookup in the SPD. - - SPD Entries - - Each SPD entry specifies packet disposition as BYPASS, DISCARD, or - PROTECT. The entry is keyed by a list of one or more selectors. - The SPD contains an ordered list of these entries. The required - selector types are defined in Section 4.4.1.1. These selectors are - used to define the granularity of the SAs that are created in - response to an outbound packet or in response to a proposal from a - peer. The detailed structure of an SPD entry is described in - Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that - matches anything that is otherwise unmatched, and discards it. - - The SPD MUST permit a user or administrator to specify policy - entries as follows: - - - SPD-I: For inbound traffic that is to be bypassed or discarded, - the entry consists of the values of the selectors that apply to - the traffic to be bypassed or discarded. - - - SPD-O: For outbound traffic that is to be bypassed or - discarded, the entry consists of the values of the selectors - that apply to the traffic to be bypassed or discarded. - - - SPD-S: For traffic that is to be protected using IPsec, the - entry consists of the values of the selectors that apply to the - traffic to be protected via AH or ESP, controls on how to - create SAs based on these selectors, and the parameters needed - to effect this protection (e.g., algorithms, modes, etc.). Note - that an SPD-S entry also contains information such as "populate - from packet" (PFP) flag (see paragraphs below on "How To Derive - the Values for an SAD entry") and bits indicating whether the - - - - - -Kent & Seo Standards Track [Page 21] - -RFC 4301 Security Architecture for IP December 2005 - - - SA lookup makes use of the local and remote IP addresses in - addition to the SPI (see AH [Ken05b] or ESP [Ken05a] - specifications). - - Representing Directionality in an SPD Entry - - For traffic protected by IPsec, the Local and Remote address and - ports in an SPD entry are swapped to represent directionality, - consistent with IKE conventions. In general, the protocols that - IPsec deals with have the property of requiring symmetric SAs with - flipped Local/Remote IP addresses. However, for ICMP, there is - often no such bi-directional authorization requirement. - Nonetheless, for the sake of uniformity and simplicity, SPD - entries for ICMP are specified in the same way as for other - protocols. Note also that for ICMP, Mobility Header, and - non-initial fragments, there are no port fields in these packets. - ICMP has message type and code and Mobility Header has mobility - header type. Thus, SPD entries have provisions for expressing - access controls appropriate for these protocols, in lieu of the - normal port field controls. For bypassed or discarded traffic, - separate inbound and outbound entries are supported, e.g., to - permit unidirectional flows if required. - - OPAQUE and ANY - - For each selector in an SPD entry, in addition to the literal - values that define a match, there are two special values: ANY and - OPAQUE. ANY is a wildcard that matches any value in the - corresponding field of the packet, or that matches packets where - that field is not present or is obscured. OPAQUE indicates that - the corresponding selector field is not available for examination - because it may not be present in a fragment, it does not exist for - the given Next Layer Protocol, or prior application of IPsec may - have encrypted the value. The ANY value encompasses the OPAQUE - value. Thus, OPAQUE need be used only when it is necessary to - distinguish between the case of any allowed value for a field, vs. - the absence or unavailability (e.g., due to encryption) of the - field. - - How to Derive the Values for an SAD Entry - - For each selector in an SPD entry, the entry specifies how to - derive the corresponding values for a new SA Database (SAD, see - Section 4.4.2) entry from those in the SPD and the packet. The - goal is to allow an SAD entry and an SPD cache entry to be created - based on specific selector values from the packet, or from the - matching SPD entry. For outbound traffic, there are SPD-S cache - entries and SPD-O cache entries. For inbound traffic not - - - -Kent & Seo Standards Track [Page 22] - -RFC 4301 Security Architecture for IP December 2005 - - - protected by IPsec, there are SPD-I cache entries and there is the - SAD, which represents the cache for inbound IPsec-protected - traffic (see Section 4.4.2). If IPsec processing is specified for - an entry, a "populate from packet" (PFP) flag may be asserted for - one or more of the selectors in the SPD entry (Local IP address; - Remote IP address; Next Layer Protocol; and, depending on Next - Layer Protocol, Local port and Remote port, or ICMP type/code, or - Mobility Header type). If asserted for a given selector X, the - flag indicates that the SA to be created should take its value for - X from the value in the packet. Otherwise, the SA should take its - value(s) for X from the value(s) in the SPD entry. Note: In the - non-PFP case, the selector values negotiated by the SA management - protocol (e.g., IKEv2) may be a subset of those in the SPD entry, - depending on the SPD policy of the peer. Also, whether a single - flag is used for, e.g., source port, ICMP type/code, and Mobility - Header (MH) type, or a separate flag is used for each, is a local - matter. - - The following example illustrates the use of the PFP flag in the - context of a security gateway or a BITS/BITW implementation. - Consider an SPD entry where the allowed value for Remote address - is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an - outbound packet arrives with a destination address of 192.0.2.3, - and there is no extant SA to carry this packet. The value used - for the SA created to transmit this packet could be either of the - two values shown below, depending on what the SPD entry for this - selector says is the source of the selector value: - - PFP flag value example of new - for the Remote SAD dest. address - addr. selector selector value - --------------- ------------ - a. PFP TRUE 192.0.2.3 (one host) - b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts) - - Note that if the SPD entry above had a value of ANY for the Remote - address, then the SAD selector value would have to be ANY for case - (b), but would still be as illustrated for case (a). Thus, the - PFP flag can be used to prohibit sharing of an SA, even among - packets that match the same SPD entry. - - Management Interface - - For every IPsec implementation, there MUST be a management - interface that allows a user or system administrator to manage the - SPD. The interface must allow the user (or administrator) to - specify the security processing to be applied to every packet that - traverses the IPsec boundary. (In a native host IPsec - - - -Kent & Seo Standards Track [Page 23] - -RFC 4301 Security Architecture for IP December 2005 - - - implementation making use of a socket interface, the SPD may not - need to be consulted on a per-packet basis, as noted at the end of - Section 4.4.1.1 and in Section 5.) The management interface for - the SPD MUST allow creation of entries consistent with the - selectors defined in Section 4.4.1.1, and MUST support (total) - ordering of these entries, as seen via this interface. The SPD - entries' selectors are analogous to the ACL or packet filters - commonly found in a stateless firewall or packet filtering router - and which are currently managed this way. - - In host systems, applications MAY be allowed to create SPD - entries. (The means of signaling such requests to the IPsec - implementation are outside the scope of this standard.) However, - the system administrator MUST be able to specify whether or not a - user or application can override (default) system policies. The - form of the management interface is not specified by this document - and may differ for hosts vs. security gateways, and within hosts - the interface may differ for socket-based vs. BITS - implementations. However, this document does specify a standard - set of SPD elements that all IPsec implementations MUST support. - - Decorrelation - - The processing model described in this document assumes the - ability to decorrelate overlapping SPD entries to permit caching, - which enables more efficient processing of outbound traffic in - security gateways and BITS/BITW implementations. Decorrelation - [CoSa04] is only a means of improving performance and simplifying - the processing description. This RFC does not require a compliant - implementation to make use of decorrelation. For example, native - host implementations typically make use of caching implicitly - because they bind SAs to socket interfaces, and thus there is no - requirement to be able to decorrelate SPD entries in these - implementations. - - Note: Unless otherwise qualified, the use of "SPD" refers to the - body of policy information in both ordered or decorrelated - (unordered) state. Appendix B provides an algorithm that can be - used to decorrelate SPD entries, but any algorithm that produces - equivalent output may be used. Note that when an SPD entry is - decorrelated all the resulting entries MUST be linked together, so - that all members of the group derived from an individual, SPD - entry (prior to decorrelation) can all be placed into caches and - into the SAD at the same time. For example, suppose one starts - with an entry A (from an ordered SPD) that when decorrelated, - yields entries A1, A2, and A3. When a packet comes along that - matches, say A2, and triggers the creation of an SA, the SA - management protocol (e.g., IKEv2) negotiates A. And all 3 - - - -Kent & Seo Standards Track [Page 24] - -RFC 4301 Security Architecture for IP December 2005 - - - decorrelated entries, A1, A2, and A3, are placed in the - appropriate SPD-S cache and linked to the SA. The intent is that - use of a decorrelated SPD ought not to create more SAs than would - have resulted from use of a not-decorrelated SPD. - - If a decorrelated SPD is employed, there are three options for - what an initiator sends to a peer via an SA management protocol - (e.g., IKE). By sending the complete set of linked, decorrelated - entries that were selected from the SPD, a peer is given the best - possible information to enable selection of the appropriate SPD - entry at its end, especially if the peer has also decorrelated its - SPD. However, if a large number of decorrelated entries are - linked, this may create large packets for SA negotiation, and - hence fragmentation problems for the SA management protocol. - - Alternatively, the original entry from the (correlated) SPD may be - retained and passed to the SA management protocol. Passing the - correlated SPD entry keeps the use of a decorrelated SPD a local - matter, not visible to peers, and avoids possible fragmentation - concerns, although it provides less precise information to a - responder for matching against the responder's SPD. - - An intermediate approach is to send a subset of the complete set - of linked, decorrelated SPD entries. This approach can avoid the - fragmentation problems cited above yet provide better information - than the original, correlated entry. The major shortcoming of - this approach is that it may cause additional SAs to be created - later, since only a subset of the linked, decorrelated entries are - sent to a peer. Implementers are free to employ any of the - approaches cited above. - - A responder uses the traffic selector proposals it receives via an - SA management protocol to select an appropriate entry in its SPD. - The intent of the matching is to select an SPD entry and create an - SA that most closely matches the intent of the initiator, so that - traffic traversing the resulting SA will be accepted at both ends. - If the responder employs a decorrelated SPD, it SHOULD use the - decorrelated SPD entries for matching, as this will generally - result in creation of SAs that are more likely to match the intent - of both peers. If the responder has a correlated SPD, then it - SHOULD match the proposals against the correlated entries. For - IKEv2, use of a decorrelated SPD offers the best opportunity for a - responder to generate a "narrowed" response. - - In all cases, when a decorrelated SPD is available, the - decorrelated entries are used to populate the SPD-S cache. If the - SPD is not decorrelated, caching is not allowed and an ordered - - - - -Kent & Seo Standards Track [Page 25] - -RFC 4301 Security Architecture for IP December 2005 - - - search of SPD MUST be performed to verify that inbound traffic - arriving on an SA is consistent with the access control policy - expressed in the SPD. - - Handling Changes to the SPD While the System Is Running - - If a change is made to the SPD while the system is running, a - check SHOULD be made of the effect of this change on extant SAs. - An implementation SHOULD check the impact of an SPD change on - extant SAs and SHOULD provide a user/administrator with a - mechanism for configuring what actions to take, e.g., delete an - affected SA, allow an affected SA to continue unchanged, etc. - -4.4.1.1. Selectors - - An SA may be fine-grained or coarse-grained, depending on the - selectors used to define the set of traffic for the SA. For example, - all traffic between two hosts may be carried via a single SA, and - afforded a uniform set of security services. Alternatively, traffic - between a pair of hosts might be spread over multiple SAs, depending - on the applications being used (as defined by the Next Layer Protocol - and related fields, e.g., ports), with different security services - offered by different SAs. Similarly, all traffic between a pair of - security gateways could be carried on a single SA, or one SA could be - assigned for each communicating host pair. The following selector - parameters MUST be supported by all IPsec implementations to - facilitate control of SA granularity. Note that both Local and - Remote addresses should either be IPv4 or IPv6, but not a mix of - address types. Also, note that the Local/Remote port selectors (and - ICMP message type and code, and Mobility Header type) may be labeled - as OPAQUE to accommodate situations where these fields are - inaccessible due to packet fragmentation. - - - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges - of IP addresses (unicast, broadcast (IPv4 only)). This - structure allows expression of a single IP address (via a - trivial range), or a list of addresses (each a trivial range), - or a range of addresses (low and high values, inclusive), as - well as the most generic form of a list of ranges. Address - ranges are used to support more than one remote system sharing - the same SA, e.g., behind a security gateway. - - - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of - IP addresses (unicast, broadcast (IPv4 only)). This structure - allows expression of a single IP address (via a trivial range), - or a list of addresses (each a trivial range), or a range of - addresses (low and high values, inclusive), as well as the most - generic form of a list of ranges. Address ranges are used to - - - -Kent & Seo Standards Track [Page 26] - -RFC 4301 Security Architecture for IP December 2005 - - - support more than one source system sharing the same SA, e.g., - behind a security gateway. Local refers to the address(es) - being protected by this implementation (or policy entry). - - Note: The SPD does not include support for multicast address - entries. To support multicast SAs, an implementation should - make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD - entries require a different structure, i.e., one cannot use the - symmetric relationship associated with local and remote address - values for unicast SAs in a multicast context. Specifically, - outbound traffic directed to a multicast address on an SA would - not be received on a companion, inbound SA with the multicast - address as the source. - - - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the - IPv6 "Next Header" fields. This is an individual protocol - number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol - is whatever comes after any IP extension headers that are - present. To simplify locating the Next Layer Protocol, there - SHOULD be a mechanism for configuring which IPv6 extension - headers to skip. The default configuration for which protocols - to skip SHOULD include the following protocols: 0 (Hop-by-hop - options), 43 (Routing Header), 44 (Fragmentation Header), and 60 - (Destination Options). Note: The default list does NOT include - 51 (AH) or 50 (ESP). From a selector lookup point of view, - IPsec treats AH and ESP as Next Layer Protocols. - - Several additional selectors depend on the Next Layer Protocol - value: - - * If the Next Layer Protocol uses two ports (as do TCP, UDP, - SCTP, and others), then there are selectors for Local and - Remote Ports. Each of these selectors has a list of ranges - of values. Note that the Local and Remote ports may not be - available in the case of receipt of a fragmented packet or if - the port fields have been protected by IPsec (encrypted); - thus, a value of OPAQUE also MUST be supported. Note: In a - non-initial fragment, port values will not be available. If - a port selector specifies a value other than ANY or OPAQUE, - it cannot match packets that are non-initial fragments. If - the SA requires a port value other than ANY or OPAQUE, an - arriving fragment without ports MUST be discarded. (See - Section 7, "Handling Fragments".) - - * If the Next Layer Protocol is a Mobility Header, then there - is a selector for IPv6 Mobility Header message type (MH type) - [Mobip]. This is an 8-bit value that identifies a particular - mobility message. Note that the MH type may not be available - - - -Kent & Seo Standards Track [Page 27] - -RFC 4301 Security Architecture for IP December 2005 - - - in the case of receipt of a fragmented packet. (See Section - 7, "Handling Fragments".) 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. - - * If the Next Layer Protocol value is ICMP, then there is a - 16-bit selector for the ICMP message type and code. The - message type is a single 8-bit value, which defines the type - of an ICMP message, or ANY. The ICMP code is a single 8-bit - value that defines a specific subtype for an ICMP message. - For IKE, the message type is placed in the most significant 8 - bits of the 16-bit selector and the code is placed in the - least significant 8 bits. This 16-bit selector can contain a - single type and a range of codes, a single type and ANY code, - and ANY type and ANY code. Given a policy entry with a range - of Types (T-start to T-end) and a range of Codes (C-start to - C-end), and an ICMP packet with Type t and Code c, an - implementation MUST test for a match using - - (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + - C-end - - Note that the ICMP message type and code may not be available - in the case of receipt of a fragmented packet. (See Section - 7, "Handling Fragments".) - - - Name: This is not a selector like the others above. It is not - acquired from a packet. A name may be used as a symbolic - identifier for an IPsec Local or Remote address. Named SPD - entries are used in two ways: - - 1. A named SPD entry is used by a responder (not an initiator) - in support of access control when an IP address would not be - appropriate for the Remote IP address selector, e.g., for - "road warriors". The name used to match this field is - communicated during the IKE negotiation in the ID payload. - In this context, the initiator's Source IP address (inner IP - header in tunnel mode) is bound to the Remote IP address in - the SAD entry created by the IKE negotiation. This address - overrides the Remote IP address value in the SPD, when the - SPD entry is selected in this fashion. All IPsec - implementations MUST support this use of names. - - 2. A named SPD entry may be used by an initiator to identify a - user for whom an IPsec SA will be created (or for whom - traffic may be bypassed). The initiator's IP source address - (from inner IP header in tunnel mode) is used to replace the - following if and when they are created: - - - -Kent & Seo Standards Track [Page 28] - -RFC 4301 Security Architecture for IP December 2005 - - - - local address in the SPD cache entry - - local address in the outbound SAD entry - - remote address in the inbound SAD entry - - Support for this use is optional for multi-user, native host - implementations and not applicable to other implementations. - Note that this name is used only locally; it is not - communicated by the key management protocol. Also, name - forms other than those used for case 1 above (responder) are - applicable in the initiator context (see below). - - An SPD entry can contain both a name (or a list of names) and - also values for the Local or Remote IP address. - - For case 1, responder, the identifiers employed in named SPD - entries are one of the following four types: - - a. a fully qualified user name string (email), e.g., - mozart@foo.example.com - (this corresponds to ID_RFC822_ADDR in IKEv2) - - b. a fully qualified DNS name, e.g., - foo.example.com - (this corresponds to ID_FQDN in IKEv2) - - c. X.500 distinguished name, e.g., [WaKiHo97], - CN = Stephen T. Kent, O = BBN Technologies, - SP = MA, C = US - (this corresponds to ID_DER_ASN1_DN in IKEv2, after - decoding) - - d. a byte string - (this corresponds to Key_ID in IKEv2) - - For case 2, initiator, the identifiers employed in named SPD - entries are of type byte string. They are likely to be Unix - UIDs, Windows security IDs, or something similar, but could - also be a user name or account name. In all cases, this - identifier is only of local concern and is not transmitted. - - The IPsec implementation context determines how selectors are used. - For example, a native host implementation typically makes use of a - socket interface. When a new connection is established, the SPD can - be consulted and an SA bound to the socket. Thus, traffic sent via - that socket need not result in additional lookups to the SPD (SPD-O - and SPD-S) cache. In contrast, a BITS, BITW, or security gateway - implementation needs to look at each packet and perform an - SPD-O/SPD-S cache lookup based on the selectors. - - - -Kent & Seo Standards Track [Page 29] - -RFC 4301 Security Architecture for IP December 2005 - - -4.4.1.2. Structure of an SPD Entry - - This section contains a prose description of an SPD entry. Also, - Appendix C provides an example of an ASN.1 definition of an SPD - entry. - - This text describes the SPD in a fashion that is intended to map - directly into IKE payloads to ensure that the policy required by SPD - entries can be negotiated through IKE. Unfortunately, the semantics - of the version of IKEv2 published concurrently with this document - [Kau05] do not align precisely with those defined for the SPD. - Specifically, IKEv2 does not enable negotiation of a single SA that - binds multiple pairs of local and remote addresses and ports to a - single SA. Instead, when multiple local and remote addresses and - ports are negotiated for an SA, IKEv2 treats these not as pairs, but - as (unordered) sets of local and remote values that can be - arbitrarily paired. Until IKE provides a facility that conveys the - semantics that are expressed in the SPD via selector sets (as - described below), users MUST NOT include multiple selector sets in a - single SPD entry unless the access control intent aligns with the IKE - "mix and match" semantics. An implementation MAY warn users, to - alert them to this problem if users create SPD entries with multiple - selector sets, the syntax of which indicates possible conflicts with - current IKE semantics. - - The management GUI can offer the user other forms of data entry and - display, e.g., the option of using address prefixes as well as - ranges, and symbolic names for protocols, ports, etc. (Do not confuse - the use of symbolic names in a management interface with the SPD - selector "Name".) Note that Remote/Local apply only to IP addresses - and ports, not to ICMP message type/code or Mobility Header type. - Also, if the reserved, symbolic selector value OPAQUE or ANY is - employed for a given selector type, only that value may appear in the - list for that selector, and it must appear only once in the list for - that selector. Note that ANY and OPAQUE are local syntax conventions - -- IKEv2 negotiates these values via the ranges indicated below: - - ANY: start = 0 end = <max> - OPAQUE: start = <max> end = 0 - - An SPD is an ordered list of entries each of which contains the - following fields. - - o Name -- a list of IDs. This quasi-selector is optional. - The forms that MUST be supported are described above in - Section 4.4.1.1 under "Name". - - - - - -Kent & Seo Standards Track [Page 30] - -RFC 4301 Security Architecture for IP December 2005 - - - o PFP flags -- one per traffic selector. A given flag, e.g., - for Next Layer Protocol, applies to the relevant selector - across all "selector sets" (see below) contained in an SPD - entry. When creating an SA, each flag specifies for the - corresponding traffic selector whether to instantiate the - selector from the corresponding field in the packet that - triggered the creation of the SA or from the value(s) in - the corresponding SPD entry (see Section 4.4.1, "How to - Derive the Values for an SAD Entry"). Whether a single - flag is used for, e.g., source port, ICMP type/code, and - MH type, or a separate flag is used for each, is a local - matter. There are PFP flags for: - - Local Address - - Remote Address - - Next Layer Protocol - - Local Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Remote Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - o One to N selector sets that correspond to the "condition" - for applying a particular IPsec action. Each selector set - contains: - - Local Address - - Remote Address - - Next Layer Protocol - - Local Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Remote Port, or ICMP message type/code or Mobility - Header type (depending on the next layer protocol) - - Note: The "next protocol" selector is an individual value - (unlike the local and remote IP addresses) in a selector - set entry. This is consistent with how IKEv2 negotiates - the Traffic Selector (TS) values for an SA. It also makes - sense because one may need to associate different port - fields with different protocols. It is possible to - associate multiple protocols (and ports) with a single SA - by specifying multiple selector sets for that SA. - - o Processing info -- which action is required -- PROTECT, - BYPASS, or DISCARD. There is just one action that goes - with all the selector sets, not a separate action for each - set. If the required processing is PROTECT, the entry - contains the following information. - - IPsec mode -- tunnel or transport - - - - - -Kent & Seo Standards Track [Page 31] - -RFC 4301 Security Architecture for IP December 2005 - - - - (if tunnel mode) local tunnel address -- For a - non-mobile host, if there is just one interface, this - is straightforward; if there are multiple - interfaces, this must be statically configured. For a - mobile host, the specification of the local address - is handled externally to IPsec. - - (if tunnel mode) remote tunnel address -- There is no - standard way to determine this. See 4.5.3, "Locating - a Security Gateway". - - Extended Sequence Number -- Is this SA using extended - sequence numbers? - - stateful fragment checking -- Is this SA using - stateful fragment checking? (See Section 7 for more - details.) - - Bypass DF bit (T/F) -- applicable to tunnel mode SAs - - Bypass DSCP (T/F) or map to unprotected DSCP values - (array) if needed to restrict bypass of DSCP values -- - applicable to tunnel mode SAs - - IPsec protocol -- AH or ESP - - algorithms -- which ones to use for AH, which ones to - use for ESP, which ones to use for combined mode, - ordered by decreasing priority - - It is a local matter as to what information is kept with regard to - handling extant SAs when the SPD is changed. - -4.4.1.3. More Regarding Fields Associated with Next Layer Protocols - - Additional selectors are often associated with fields in the Next - Layer Protocol header. A particular Next Layer Protocol can have - zero, one, or two selectors. There may be situations where there - aren't both local and remote selectors for the fields that are - dependent on the Next Layer Protocol. The IPv6 Mobility Header has - only a Mobility Header message type. AH and ESP have no further - selector fields. A system may be willing to send an ICMP message - type and code that it does not want to receive. In the descriptions - below, "port" is used to mean a field that is dependent on the Next - Layer Protocol. - - A. If a Next Layer Protocol has no "port" selectors, then - the Local and Remote "port" selectors are set to OPAQUE in - the relevant SPD entry, e.g., - - Local's - next layer protocol = AH - "port" selector = OPAQUE - - - - - -Kent & Seo Standards Track [Page 32] - -RFC 4301 Security Architecture for IP December 2005 - - - Remote's - next layer protocol = AH - "port" selector = OPAQUE - - B. Even if a Next Layer Protocol has only one selector, e.g., - Mobility Header type, then the Local and Remote "port" - selectors are used to indicate whether a system is - willing to send and/or receive traffic with the specified - "port" values. For example, if Mobility Headers of a - specified type are allowed to be sent and received via an - SA, then the relevant SPD entry would be set as follows: - - Local's - next layer protocol = Mobility Header - "port" selector = Mobility Header message type - - Remote's - next layer protocol = Mobility Header - "port" selector = Mobility Header message type - - If Mobility Headers of a specified type are allowed to be - sent but NOT received via an SA, then the relevant SPD - entry would be set as follows: - - Local's - next layer protocol = Mobility Header - "port" selector = Mobility Header message type - - Remote's - next layer protocol = Mobility Header - "port" selector = OPAQUE - - If Mobility Headers of a specified type are allowed to be - received but NOT sent via an SA, then the relevant SPD - entry would be set as follows: - - Local's - next layer protocol = Mobility Header - "port" selector = OPAQUE - - Remote's - next layer protocol = Mobility Header - "port" selector = Mobility Header message type - - C. If a system is willing to send traffic with a particular - "port" value but NOT receive traffic with that kind of - port value, the system's traffic selectors are set as - follows in the relevant SPD entry: - - - -Kent & Seo Standards Track [Page 33] - -RFC 4301 Security Architecture for IP December 2005 - - - Local's - next layer protocol = ICMP - "port" selector = <specific ICMP type & code> - - Remote's - next layer protocol = ICMP - "port" selector = OPAQUE - - D. To indicate that a system is willing to receive traffic - with a particular "port" value but NOT send that kind of - traffic, the system's traffic selectors are set as follows - in the relevant SPD entry: - - Local's - next layer protocol = ICMP - "port" selector = OPAQUE - - Remote's - next layer protocol = ICMP - "port" selector = <specific ICMP type & code> - - For example, if a security gateway is willing to allow - systems behind it to send ICMP traceroutes, but is not - willing to let outside systems run ICMP traceroutes to - systems behind it, then the security gateway's traffic - selectors are set as follows in the relevant SPD entry: - - Local's - next layer protocol = 1 (ICMPv4) - "port" selector = 30 (traceroute) - - Remote's - next layer protocol = 1 (ICMPv4) - "port" selector = OPAQUE - -4.4.2. Security Association Database (SAD) - - In each IPsec implementation, there is a nominal Security Association - Database (SAD), in which each entry defines the parameters associated - with one SA. Each SA has an entry in the SAD. For outbound - processing, each SAD entry is pointed to by entries in the SPD-S part - of the SPD cache. For inbound processing, for unicast SAs, the SPI - is used either alone to look up an SA or in conjunction with the - IPsec protocol type. If an IPsec implementation supports multicast, - the SPI plus destination address, or SPI plus destination and source - addresses are used to look up the SA. (See Section 4.1 for details on - the algorithm that MUST be used for mapping inbound IPsec datagrams - to SAs.) The following parameters are associated with each entry in - - - -Kent & Seo Standards Track [Page 34] - -RFC 4301 Security Architecture for IP December 2005 - - - the SAD. They should all be present except where otherwise noted, - e.g., AH Authentication algorithm. This description does not purport - to be a MIB, only a specification of the minimal data items required - to support an SA in an IPsec implementation. - - For each of the selectors defined in Section 4.4.1.1, the entry for - an inbound SA in the SAD MUST be initially populated with the value - or values negotiated at the time the SA was created. (See the - paragraph in Section 4.4.1 under "Handling Changes to the SPD while - the System is Running" for guidance on the effect of SPD changes on - extant SAs.) For a receiver, these values are used to check that the - header fields of an inbound packet (after IPsec processing) match the - selector values negotiated for the SA. Thus, the SAD acts as a cache - for checking the selectors of inbound traffic arriving on SAs. For - the receiver, this is part of verifying that a packet arriving on an - SA is consistent with the policy for the SA. (See Section 6 for rules - for ICMP messages.) These fields can have the form of specific - values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1, - "Selectors". Note also that there are a couple of situations in - which the SAD can have entries for SAs that do not have corresponding - entries in the SPD. Since this document does not mandate that the - SAD be selectively cleared when the SPD is changed, SAD entries can - remain when the SPD entries that created them are changed or deleted. - Also, if a manually keyed SA is created, there could be an SAD entry - for this SA that does not correspond to any SPD entry. - - Note: The SAD can support multicast SAs, if manually configured. An - outbound multicast SA has the same structure as a unicast SA. The - source address is that of the sender, and the destination address is - the multicast group address. An inbound, multicast SA must be - configured with the source addresses of each peer authorized to - transmit to the multicast SA in question. The SPI value for a - multicast SA is provided by a multicast group controller, not by the - receiver, as for a unicast SA. Because an SAD entry may be required - to accommodate multiple, individual IP source addresses that were - part of an SPD entry (for unicast SAs), the required facility for - inbound, multicast SAs is a feature already present in an IPsec - implementation. However, because the SPD has no provisions for - accommodating multicast entries, this document does not specify an - automated way to create an SAD entry for a multicast, inbound SA. - Only manually configured SAD entries can be created to accommodate - inbound, multicast traffic. - - Implementation Guidance: This document does not specify how an SPD-S - entry refers to the corresponding SAD entry, as this is an - implementation-specific detail. However, some implementations (based - on experience from RFC 2401) are known to have problems in this - regard. In particular, simply storing the (remote tunnel header IP - - - -Kent & Seo Standards Track [Page 35] - -RFC 4301 Security Architecture for IP December 2005 - - - address, remote SPI) pair in the SPD cache is not sufficient, since - the pair does not always uniquely identify a single SAD entry. For - instance, two hosts behind the same NAT could choose the same SPI - value. The situation also may arise if a host is assigned an IP - address (e.g., via DHCP) previously used by some other host, and the - SAs associated with the old host have not yet been deleted via dead - peer detection mechanisms. This may lead to packets being sent over - the wrong SA or, if key management ensures the pair is unique, - denying the creation of otherwise valid SAs. Thus, implementors - should implement links between the SPD cache and the SAD in a way - that does not engender such problems. - -4.4.2.1. Data Items in the SAD - - The following data items MUST be in the SAD: - - o Security Parameter Index (SPI): a 32-bit value selected by the - receiving end of an SA to uniquely identify the SA. In an SAD - entry for an outbound SA, the SPI is used to construct the - packet's AH or ESP header. In an SAD entry for an inbound SA, the - SPI is used to map traffic to the appropriate SA (see text on - unicast/multicast in Section 4.1). - - o Sequence Number Counter: a 64-bit counter used to generate the - Sequence Number field in AH or ESP headers. 64-bit sequence - numbers are the default, but 32-bit sequence numbers are also - supported if negotiated. - - o Sequence Counter Overflow: a flag indicating whether overflow of - the sequence number counter should generate an auditable event and - prevent transmission of additional packets on the SA, or whether - rollover is permitted. The audit log entry for this event SHOULD - include the SPI value, current date/time, Local Address, Remote - Address, and the selectors from the relevant SAD entry. - - o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) - used to determine whether an inbound AH or ESP packet is a replay. - - Note: If anti-replay has been disabled by the receiver for an SA, - e.g., in the case of a manually keyed SA, then the Anti-Replay - Window is ignored for the SA in question. 64-bit sequence numbers - are the default, but this counter size accommodates 32-bit - sequence numbers as well. - - o AH Authentication algorithm, key, etc. This is required only if - AH is supported. - - - - - -Kent & Seo Standards Track [Page 36] - -RFC 4301 Security Architecture for IP December 2005 - - - o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode - algorithm is used, these fields will not be applicable. - - o ESP integrity algorithm, keys, etc. If the integrity service is - not selected, these fields will not be applicable. If a combined - mode algorithm is used, these fields will not be applicable. - - o ESP combined mode algorithms, key(s), etc. This data is used when - a combined mode (encryption and integrity) algorithm is used with - ESP. If a combined mode algorithm is not used, these fields are - not applicable. - - o Lifetime of this SA: a time interval after which an SA must be - replaced with a new SA (and new SPI) or terminated, plus an - indication of which of these actions should occur. This may be - expressed as a time or byte count, or a simultaneous use of both - with the first lifetime to expire taking precedence. A compliant - implementation MUST support both types of lifetimes, and MUST - support a simultaneous use of both. If time is employed, and if - IKE employs X.509 certificates for SA establishment, the SA - lifetime must be constrained by the validity intervals of the - certificates, and the NextIssueDate of the Certificate Revocation - Lists (CRLs) used in the IKE exchange for the SA. Both initiator - and responder are responsible for constraining the SA lifetime in - this fashion. Note: The details of how to handle the refreshing - of keys when SAs expire is a local matter. However, one - reasonable approach is: - - (a) If byte count is used, then the implementation SHOULD count the - number of bytes to which the IPsec cryptographic algorithm is - applied. For ESP, this is the encryption algorithm (including - Null encryption) and for AH, this is the authentication - algorithm. This includes pad bytes, etc. Note that - implementations MUST be able to handle having the counters at - the ends of an SA get out of synch, e.g., because of packet - loss or because the implementations at each end of the SA - aren't doing things the same way. - - (b) There SHOULD be two kinds of lifetime -- a soft lifetime that - warns the implementation to initiate action such as setting up - a replacement SA, and a hard lifetime when the current SA ends - and is destroyed. - - (c) If the entire packet does not get delivered during the SA's - lifetime, the packet SHOULD be discarded. - - o IPsec protocol mode: tunnel or transport. Indicates which mode of - AH or ESP is applied to traffic on this SA. - - - -Kent & Seo Standards Track [Page 37] - -RFC 4301 Security Architecture for IP December 2005 - - - o Stateful fragment checking flag. Indicates whether or not - stateful fragment checking applies to this SA. - - o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both - inner and outer headers are IPv4. - - o DSCP values -- the set of DSCP values allowed for packets carried - over this SA. If no values are specified, no DSCP-specific - filtering is applied. If one or more values are specified, these - are used to select one SA among several that match the traffic - selectors for an outbound packet. Note that these values are NOT - checked against inbound traffic arriving on the SA. - - o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if - needed to restrict bypass of DSCP values -- applicable to tunnel - mode SAs. This feature maps DSCP values from an inner header to - values in an outer header, e.g., to address covert channel - signaling concerns. - - o Path MTU: any observed path MTU and aging variables. - - o Tunnel header IP source and destination address -- both addresses - must be either IPv4 or IPv6 addresses. The version implies the - type of IP header to be used. Only used when the IPsec protocol - mode is tunnel. - -4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD - - For each selector, the following tables show the relationship - between the value in the SPD, the PFP flag, the value in the - triggering packet, and the resulting value in the SAD. Note that - the administrative interface for IPsec can use various syntactic - options to make it easier for the administrator to enter rules. - For example, although a list of ranges is what IKEv2 sends, it - might be clearer and less error prone for the user to enter a - single IP address or IP address prefix. - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 38] - -RFC 4301 Security Architecture for IP December 2005 - - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - loc addr list of ranges 0 IP addr "S" list of ranges - ANY 0 IP addr "S" ANY - list of ranges 1 IP addr "S" "S" - ANY 1 IP addr "S" "S" - - rem addr list of ranges 0 IP addr "D" list of ranges - ANY 0 IP addr "D" ANY - list of ranges 1 IP addr "D" "D" - ANY 1 IP addr "D" "D" - - protocol list of prot's* 0 prot. "P" list of prot's* - ANY** 0 prot. "P" ANY - OPAQUE**** 0 prot. "P" OPAQUE - - list of prot's* 0 not avail. discard packet - ANY** 0 not avail. ANY - OPAQUE**** 0 not avail. OPAQUE - - list of prot's* 1 prot. "P" "P" - ANY** 1 prot. "P" "P" - OPAQUE**** 1 prot. "P" *** - - list of prot's* 1 not avail. discard packet - ANY** 1 not avail. discard packet - OPAQUE**** 1 not avail. *** - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 39] - -RFC 4301 Security Architecture for IP December 2005 - - - If the protocol is one that has two ports, then there will be - selectors for both Local and Remote ports. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - loc port list of ranges 0 src port "s" list of ranges - ANY 0 src port "s" ANY - OPAQUE 0 src port "s" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 src port "s" "s" - ANY 1 src port "s" "s" - OPAQUE 1 src port "s" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - rem port list of ranges 0 dst port "d" list of ranges - ANY 0 dst port "d" ANY - OPAQUE 0 dst port "d" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 dst port "d" "d" - ANY 1 dst port "d" "d" - OPAQUE 1 dst port "d" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - - - - - - - - - - -Kent & Seo Standards Track [Page 40] - -RFC 4301 Security Architecture for IP December 2005 - - - If the protocol is mobility header, then there will be a selector - for mh type. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - -------- ---------------- --- ------------ -------------- - mh type list of ranges 0 mh type "T" list of ranges - ANY 0 mh type "T" ANY - OPAQUE 0 mh type "T" OPAQUE - - list of ranges 0 not avail. discard packet - ANY 0 not avail. ANY - OPAQUE 0 not avail. OPAQUE - - list of ranges 1 mh type "T" "T" - ANY 1 mh type "T" "T" - OPAQUE 1 mh type "T" *** - - list of ranges 1 not avail. discard packet - ANY 1 not avail. discard packet - OPAQUE 1 not avail. *** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 41] - -RFC 4301 Security Architecture for IP December 2005 - - - If the protocol is ICMP, then there will be a 16-bit selector for - ICMP type and ICMP code. Note that the type and code are bound to - each other, i.e., the codes apply to the particular type. This - 16-bit selector can contain a single type and a range of codes, a - single type and ANY code, and ANY type and ANY code. - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - --------- ---------------- --- ------------ -------------- - ICMP type a single type & 0 type "t" & single type & - and code range of codes code "c" range of codes - a single type & 0 type "t" & single type & - ANY code code "c" ANY code - ANY type & ANY 0 type "t" & ANY type & - code code "c" ANY code - OPAQUE 0 type "t" & OPAQUE - code "c" - - a single type & 0 not avail. discard packet - range of codes - a single type & 0 not avail. discard packet - ANY code - ANY type & 0 not avail. ANY type & - ANY code ANY code - OPAQUE 0 not avail. OPAQUE - - a single type & 1 type "t" & "t" and "c" - range of codes code "c" - a single type & 1 type "t" & "t" and "c" - ANY code code "c" - ANY type & 1 type "t" & "t" and "c" - ANY code code "c" - OPAQUE 1 type "t" & *** - code "c" - - a single type & 1 not avail. discard packet - range of codes - a single type & 1 not avail. discard packet - ANY code - ANY type & 1 not avail. discard packet - ANY code - OPAQUE 1 not avail. *** - - - - - - - - -Kent & Seo Standards Track [Page 42] - -RFC 4301 Security Architecture for IP December 2005 - - - If the name selector is used: - - Value in - Triggering Resulting SAD - Selector SPD Entry PFP Packet Entry - --------- ---------------- --- ------------ -------------- - name list of user or N/A N/A N/A - system names - - * "List of protocols" is the information, not the way - that the SPD or SAD or IKEv2 have to represent this - information. - ** 0 (zero) is used by IKE to indicate ANY for - protocol. - *** Use of PFP=1 with an OPAQUE value is an error and - SHOULD be prohibited by an IPsec implementation. - **** The protocol field cannot be OPAQUE in IPv4. This - table entry applies only to IPv6. - -4.4.3. Peer Authorization Database (PAD) - - The Peer Authorization Database (PAD) provides the link between the - SPD and a security association management protocol such as IKE. It - embodies several critical functions: - - o identifies the peers or groups of peers that are authorized - to communicate with this IPsec entity - o specifies the protocol and method used to authenticate each - peer - o provides the authentication data for each peer - o constrains the types and values of IDs that can be asserted - by a peer with regard to child SA creation, to ensure that the - peer does not assert identities for lookup in the SPD that it - is not authorized to represent, when child SAs are created - o peer gateway location info, e.g., IP address(es) or DNS names, - MAY be included for peers that are known to be "behind" a - security gateway - - The PAD provides these functions for an IKE peer when the peer acts - as either the initiator or the responder. - - To perform these functions, the PAD contains an entry for each peer - or group of peers with which the IPsec entity will communicate. An - entry names an individual peer (a user, end system or security - gateway) or specifies a group of peers (using ID matching rules - defined below). The entry specifies the authentication protocol - (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre- - shared secrets) and the authentication data (e.g., the pre-shared - - - -Kent & Seo Standards Track [Page 43] - -RFC 4301 Security Architecture for IP December 2005 - - - secret or the trust anchor relative to which the peer's certificate - will be validated). For certificate-based authentication, the entry - also may provide information to assist in verifying the revocation - status of the peer, e.g., a pointer to a CRL repository or the name - of an Online Certificate Status Protocol (OCSP) server associated - with the peer or with the trust anchor associated with the peer. - - Each entry also specifies whether the IKE ID payload will be used as - a symbolic name for SPD lookup, or whether the remote IP address - provided in traffic selector payloads will be used for SPD lookups - when child SAs are created. - - Note that the PAD information MAY be used to support creation of more - than one tunnel mode SA at a time between two peers, e.g., two - tunnels to protect the same addresses/hosts, but with different - tunnel endpoints. - -4.4.3.1. PAD Entry IDs and Matching Rules - - The PAD is an ordered database, where the order is defined by an - administrator (or a user in the case of a single-user end system). - Usually, the same administrator will be responsible for both the PAD - and SPD, since the two databases must be coordinated. The ordering - requirement for the PAD arises for the same reason as for the SPD, - i.e., because use of "star name" entries allows for overlaps in the - set of IKE IDs that could match a specific entry. - - Six types of IDs are supported for entries in the PAD, consistent - with the symbolic name types and IP addresses used to identify SPD - entries. The ID for each entry acts as the index for the PAD, i.e., - it is the value used to select an entry. All of these ID types can - be used to match IKE ID payload types. The six types are: - - o DNS name (specific or partial) - o Distinguished Name (complete or sub-tree constrained) - o RFC 822 email address (complete or partially qualified) - o IPv4 address (range) - o IPv6 address (range) - o Key ID (exact match only) - - The first three name types can accommodate sub-tree matching as well - as exact matches. A DNS name may be fully qualified and thus match - exactly one name, e.g., foo.example.com. Alternatively, the name may - encompass a group of peers by being partially specified, e.g., the - string ".example.com" could be used to match any DNS name ending in - these two domain name components. - - - - - -Kent & Seo Standards Track [Page 44] - -RFC 4301 Security Architecture for IP December 2005 - - - Similarly, a Distinguished Name may specify a complete Distinguished - Name to match exactly one entry, e.g., CN = Stephen, O = BBN - Technologies, SP = MA, C = US. Alternatively, an entry may encompass - a group of peers by specifying a sub-tree, e.g., an entry of the form - "C = US, SP = MA" might be used to match all DNs that contain these - two attributes as the top two Relative Distinguished Names (RDNs). - - For an RFC 822 e-mail addresses, the same options exist. A complete - address such as foo@example.com matches one entity, but a sub-tree - name such as "@example.com" could be used to match all the entities - with names ending in those two domain names to the right of the @. - - The specific syntax used by an implementation to accommodate sub-tree - matching for distinguished names, domain names or RFC 822 e-mail - addresses is a local matter. But, at a minimum, sub-tree matching of - the sort described above MUST be supported. (Substring matching - within a DN, DNS name, or RFC 822 address MAY be supported, but is - not required.) - - For IPv4 and IPv6 addresses, the same address range syntax used for - SPD entries MUST be supported. This allows specification of an - individual address (via a trivial range), an address prefix (by - choosing a range that adheres to Classless Inter-Domain Routing - (CIDR)-style prefixes), or an arbitrary address range. - - The Key ID field is defined as an OCTET string in IKE. For this name - type, only exact-match syntax MUST be supported (since there is no - explicit structure for this ID type). Additional matching functions - MAY be supported for this ID type. - -4.4.3.2. IKE Peer Authentication Data - - Once an entry is located based on an ordered search of the PAD based - on ID field matching, it is necessary to verify the asserted - identity, i.e., to authenticate the asserted ID. For each PAD entry, - there is an indication of the type of authentication to be performed. - This document requires support for two required authentication data - types: - - - X.509 certificate - - pre-shared secret - - For authentication based on an X.509 certificate, the PAD entry - contains a trust anchor via which the end entity (EE) certificate for - the peer must be verifiable, either directly or via a certificate - path. See RFC 3280 for the definition of a trust anchor. An entry - used with certificate-based authentication MAY include additional - data to facilitate certificate revocation status, e.g., a list of - - - -Kent & Seo Standards Track [Page 45] - -RFC 4301 Security Architecture for IP December 2005 - - - appropriate OCSP responders or CRL repositories, and associated - authentication data. For authentication based on a pre-shared - secret, the PAD contains the pre-shared secret to be used by IKE. - - This document does not require that the IKE ID asserted by a peer be - syntactically related to a specific field in an end entity - certificate that is employed to authenticate the identity of that - peer. However, it often will be appropriate to impose such a - requirement, e.g., when a single entry represents a set of peers each - of whom may have a distinct SPD entry. Thus, implementations MUST - provide a means for an administrator to require a match between an - asserted IKE ID and the subject name or subject alt name in a - certificate. The former is applicable to IKE IDs expressed as - distinguished names; the latter is appropriate for DNS names, RFC 822 - e-mail addresses, and IP addresses. Since KEY ID is intended for - identifying a peer authenticated via a pre-shared secret, there is no - requirement to match this ID type to a certificate field. - - See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE - performs peer authentication using certificates or pre-shared - secrets. - - This document does not mandate support for any other authentication - methods, although such methods MAY be employed. - -4.4.3.3. Child SA Authorization Data - - Once an IKE peer is authenticated, child SAs may be created. Each - PAD entry contains data to constrain the set of IDs that can be - asserted by an IKE peer, for matching against the SPD. Each PAD - entry indicates whether the IKE ID is to be used as a symbolic name - for SPD matching, or whether an IP address asserted in a traffic - selector payload is to be used. - - If the entry indicates that the IKE ID is to be used, then the PAD - entry ID field defines the authorized set of IDs. If the entry - indicates that child SAs traffic selectors are to be used, then an - additional data element is required, in the form of IPv4 and/or IPv6 - address ranges. (A peer may be authorized for both address types, so - there MUST be provision for both a v4 and a v6 address range.) - -4.4.3.4. How the PAD Is Used - - During the initial IKE exchange, the initiator and responder each - assert their identity via the IKE ID payload and send an AUTH payload - to verify the asserted identity. One or more CERT payloads may be - transmitted to facilitate the verification of each asserted identity. - - - - -Kent & Seo Standards Track [Page 46] - -RFC 4301 Security Architecture for IP December 2005 - - - When an IKE entity receives an IKE ID payload, it uses the asserted - ID to locate an entry in the PAD, using the matching rules described - above. The PAD entry specifies the authentication method to be - employed for the identified peer. This ensures that the right method - is used for each peer and that different methods can be used for - different peers. The entry also specifies the authentication data - that will be used to verify the asserted identity. This data is - employed in conjunction with the specified method to authenticate the - peer, before any CHILD SAs are created. - - Child SAs are created based on the exchange of traffic selector - payloads, either at the end of the initial IKE exchange or in - subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now - authenticated) IKE peer is used to constrain creation of child SAs; - specifically, the PAD entry specifies how the SPD is searched using a - traffic selector proposal from a peer. There are two choices: either - the IKE ID asserted by the peer is used to find an SPD entry via its - symbolic name, or peer IP addresses asserted in traffic selector - payloads are used for SPD lookups based on the remote IP address - field portion of an SPD entry. 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. - - Note that because the PAD is checked before searching for an SPD - entry, this safeguard protects an initiator against spoofing attacks. - For example, assume that IKE A receives an outbound packet destined - for IP address X, a host served by a security gateway. RFC 2401 - [RFC2401] and this document do not specify how A determines the - address of the IKE peer serving X. However, any peer contacted by A - as the presumed representative for X must be registered in the PAD in - order to allow the IKE exchange to be authenticated. Moreover, when - the authenticated peer asserts that it represents X in its traffic - selector exchange, the PAD will be consulted to determine if the peer - in question is authorized to represent X. Thus, the PAD provides a - binding of address ranges (or name sub-spaces) to peers, to counter - such attacks. - -4.5. SA and Key Management - - All IPsec implementations MUST support both manual and automated SA - and cryptographic key management. The IPsec protocols, AH and ESP, - are largely independent of the associated SA management techniques, - although the techniques involved do affect some of the security - services offered by the protocols. For example, the optional - anti-replay service available for AH and ESP requires automated SA - management. Moreover, the granularity of key distribution employed - with IPsec determines the granularity of authentication provided. In - general, data origin authentication in AH and ESP is limited by the - - - -Kent & Seo Standards Track [Page 47] - -RFC 4301 Security Architecture for IP December 2005 - - - extent to which secrets used with the integrity algorithm (or with a - key management protocol that creates such secrets) are shared among - multiple possible sources. - - The following text describes the minimum requirements for both types - of SA management. - -4.5.1. Manual Techniques - - The simplest form of management is manual management, in which a - person manually configures each system with keying material and SA - management data relevant to secure communication with other systems. - Manual techniques are practical in small, static environments but - they do not scale well. For example, a company could create a - virtual private network (VPN) using IPsec in security gateways at - several sites. If the number of sites is small, and since all the - sites come under the purview of a single administrative domain, this - might be a feasible context for manual management techniques. In - this case, the security gateway might selectively protect traffic to - and from other sites within the organization using a manually - configured key, while not protecting traffic for other destinations. - It also might be appropriate when only selected communications need - to be secured. A similar argument might apply to use of IPsec - entirely within an organization for a small number of hosts and/or - gateways. Manual management techniques often employ statically - configured, symmetric keys, though other options also exist. - -4.5.2. Automated SA and Key Management - - Widespread deployment and use of IPsec requires an Internet-standard, - scalable, automated, SA management protocol. Such support is - required to facilitate use of the anti-replay features of AH and ESP, - and to accommodate on-demand creation of SAs, e.g., for user- and - session-oriented keying. (Note that the notion of "rekeying" an SA - actually implies creation of a new SA with a new SPI, a process that - generally implies use of an automated SA/key management protocol.) - - The default automated key management protocol selected for use with - IPsec is IKEv2 [Kau05]. This document assumes the availability of - certain functions from the key management protocol that are not - supported by IKEv1. Other automated SA management protocols MAY be - employed. - - When an automated SA/key management protocol is employed, the output - from this protocol is used to generate multiple keys for a single SA. - This also occurs because distinct keys are used for each of the two - - - - - -Kent & Seo Standards Track [Page 48] - -RFC 4301 Security Architecture for IP December 2005 - - - SAs created by IKE. If both integrity and confidentiality are - employed, then a minimum of four keys are required. Additionally, - some cryptographic algorithms may require multiple keys, e.g., 3DES. - - The Key Management System may provide a separate string of bits for - each key or it may generate one string of bits from which all keys - are extracted. If a single string of bits is provided, care needs to - be taken to ensure that the parts of the system that map the string - of bits to the required keys do so in the same fashion at both ends - of the SA. To ensure that the IPsec implementations at each end of - the SA use the same bits for the same keys, and irrespective of which - part of the system divides the string of bits into individual keys, - the encryption keys MUST be taken from the first (left-most, - high-order) bits and the integrity keys MUST be taken from the - remaining bits. The number of bits for each key is defined in the - relevant cryptographic algorithm specification RFC. In the case of - multiple encryption keys or multiple integrity keys, the - specification for the cryptographic algorithm must specify the order - in which they are to be selected from a single string of bits - provided to the cryptographic algorithm. - -4.5.3. Locating a Security Gateway - - This section discusses issues relating to how a host learns about the - existence of relevant security gateways and, once a host has - contacted these security gateways, how it knows that these are the - correct security gateways. The details of where the required - information is stored is a local matter, but the Peer Authorization - Database (PAD) described in Section 4.4 is the most likely candidate. - (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2 - below.) - - Consider a situation in which a remote host (SH1) is using the - Internet to gain access to a server or other machine (H2) and there - is a security gateway (SG2), e.g., a firewall, through which H1's - traffic must pass. An example of this situation would be a mobile - host crossing the Internet to his home organization's firewall (SG2). - This situation raises several issues: - - 1. How does SH1 know/learn about the existence of the security - gateway SG2? - - 2. How does it authenticate SG2, and once it has authenticated SG2, - how does it confirm that SG2 has been authorized to represent H2? - - 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to - contact H2? - - - - -Kent & Seo Standards Track [Page 49] - -RFC 4301 Security Architecture for IP December 2005 - - - 4. How does SH1 know/learn about any additional gateways that provide - alternate paths to H2? - - To address these problems, an IPsec-supporting host or security - gateway MUST have an administrative interface that allows the - user/administrator to configure the address of one or more security - gateways for ranges of destination addresses that require its use. - This includes the ability to configure information for locating and - authenticating one or more security gateways and verifying the - authorization of these gateways to represent the destination host. - (The authorization function is implied in the PAD.) This document - does not address the issue of how to automate the - discovery/verification of security gateways. - -4.6. SAs and Multicast - - The receiver-orientation of the SA implies that, in the case of - unicast traffic, the destination system will select the SPI value. - By having the destination select the SPI value, there is no potential - for manually configured SAs to conflict with automatically configured - (e.g., via a key management protocol) SAs or for SAs from multiple - sources to conflict with each other. For multicast traffic, there - are multiple destination systems associated with a single SA. So - some system or person will need to coordinate among all multicast - groups to select an SPI or SPIs on behalf of each multicast group and - then communicate the group's IPsec information to all of the - legitimate members of that multicast group via mechanisms not defined - here. - - Multiple senders to a multicast group SHOULD use a single Security - Association (and hence SPI) for all traffic to that group when a - symmetric key encryption or integrity algorithm is employed. In such - circumstances, the receiver knows only that the message came from a - system possessing the key for that multicast group. In such - circumstances, a receiver generally will not be able to authenticate - which system sent the multicast traffic. Specifications for other, - more general multicast approaches are deferred to the IETF Multicast - Security Working Group. - -5. IP Traffic Processing - - As mentioned in Section 4.4.1, "The Security Policy Database (SPD)", - the SPD (or associated caches) MUST be consulted during the - processing of all traffic that crosses the IPsec protection boundary, - including IPsec management traffic. If no policy is found in the SPD - that matches a packet (for either inbound or outbound traffic), the - packet MUST be discarded. To simplify processing, and to allow for - very fast SA lookups (for SG/BITS/BITW), this document introduces the - - - -Kent & Seo Standards Track [Page 50] - -RFC 4301 Security Architecture for IP December 2005 - - - notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S), - and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As - mentioned earlier, the SAD acts as a cache for checking the selectors - of inbound IPsec-protected traffic arriving on SAs.) There is - nominally one cache per SPD. For the purposes of this specification, - it is assumed that each cached entry will map to exactly one SA. - Note, however, exceptions arise when one uses multiple SAs to carry - traffic of different priorities (e.g., as indicated by distinct DSCP - values) but the same selectors. Note also, that there are a couple - of situations in which the SAD can have entries for SAs that do not - have corresponding entries in the SPD. Since this document does not - mandate that the SAD be selectively cleared when the SPD is changed, - SAD entries can remain when the SPD entries that created them are - changed or deleted. Also, if a manually keyed SA is created, there - could be an SAD entry for this SA that does not correspond to any SPD - entry. - - Since SPD entries may overlap, one cannot safely cache these entries - in general. Simple caching might result in a match against a cache - entry, whereas an ordered search of the SPD would have resulted in a - match against a different entry. But, if the SPD entries are first - decorrelated, then the resulting entries can safely be cached. Each - cached entry will indicate that matching traffic should be bypassed - or discarded, appropriately. (Note: The original SPD entry might - result in multiple SAs, e.g., because of PFP.) Unless otherwise - noted, all references below to the "SPD" or "SPD cache" or "cache" - are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache - containing entries from the decorrelated SPD. - - Note: In a host IPsec implementation based on sockets, the SPD will - be consulted whenever a new socket is created to determine what, if - any, IPsec processing will be applied to the traffic that will flow - on that socket. This provides an implicit caching mechanism, and the - portions of the preceding discussion that address caching can be - ignored in such implementations. - - Note: It is assumed that one starts with a correlated SPD because - that is how users and administrators are accustomed to managing these - sorts of access control lists or firewall filter rules. Then the - decorrelation algorithm is applied to build a list of cache-able SPD - entries. The decorrelation is invisible at the management interface. - - For inbound IPsec traffic, the SAD entry selected by the SPI serves - as the cache for the selectors to be matched against arriving IPsec - packets, after AH or ESP processing has been performed. - - - - - - -Kent & Seo Standards Track [Page 51] - -RFC 4301 Security Architecture for IP December 2005 - - -5.1. Outbound IP Traffic Processing (protected-to-unprotected) - - First consider the path for traffic entering the implementation via a - protected interface and exiting via an unprotected interface. - - Unprotected Interface - ^ - | - (nested SAs) +----------+ - -------------------|Forwarding|<-----+ - | +----------+ | - | ^ | - | | BYPASS | - V +-----+ | - +-------+ | SPD | +--------+ - ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec - | (*) | | (*) |---->|(AH/ESP)| boundary - +-------+ +-----+ +--------+ - | +-------+ / ^ - | |DISCARD| <--/ | - | +-------+ | - | | - | +-------------+ - |---------------->|SPD Selection| - +-------------+ - ^ - | +------+ - | -->| ICMP | - | / +------+ - |/ - | - | - Protected Interface - - - Figure 2. Processing Model for Outbound Traffic - (*) = The SPD caches are shown here. If there - is a cache miss, then the SPD is checked. - There is no requirement that an - implementation buffer the packet if - there is a cache miss. - - - - - - - - - - -Kent & Seo Standards Track [Page 52] - -RFC 4301 Security Architecture for IP December 2005 - - - IPsec MUST perform the following steps when processing outbound - packets: - - 1. When a packet arrives from the subscriber (protected) interface, - invoke the SPD selection function to obtain the SPD-ID needed to - choose the appropriate SPD. (If the implementation uses only one - SPD, this step is a no-op.) - - 2. Match the packet headers against the cache for the SPD specified - by the SPD-ID from step 1. Note that this cache contains entries - from SPD-O and SPD-S. - - 3a. If there is a match, then process the packet as specified by the - matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH - or ESP. If IPsec processing is applied, there is a link from the - SPD cache entry to the relevant SAD entry (specifying the mode, - cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec - processing is as previously defined, for tunnel or transport - modes and for AH or ESP, as specified in their respective RFCs - [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of - the stateful fragment checking flag (and the DF bit in the IP - header of the outbound packet) determine whether the packet can - (must) be fragmented prior to or after IPsec processing, or if it - must be discarded and an ICMP PMTU message is sent. - - 3b. If no match is found in the cache, search the SPD (SPD-S and - SPD-O parts) specified by SPD-ID. If the SPD entry calls for - BYPASS or DISCARD, create one or more new outbound SPD cache - entries and if BYPASS, create one or more new inbound SPD cache - entries. (More than one cache entry may be created since a - decorrelated SPD entry may be linked to other such entries that - were created as a side effect of the decorrelation process.) If - the SPD entry calls for PROTECT, i.e., creation of an SA, the key - management mechanism (e.g., IKEv2) is invoked to create the SA. - If SA creation succeeds, a new outbound (SPD-S) cache entry is - created, along with outbound and inbound SAD entries, otherwise - the packet is discarded. (A packet that triggers an SPD lookup - MAY be discarded by the implementation, or it MAY be processed - against the newly created cache entry, if one is created.) Since - SAs are created in pairs, an SAD entry for the corresponding - inbound SA also is created, and it contains the selector values - derived from the SPD entry (and packet, if any PFP flags were - "true") used to create the inbound SA, for use in checking - inbound traffic delivered via the SA. - - 4. The packet is passed to the outbound forwarding function - (operating outside of the IPsec implementation), to select the - interface to which the packet will be directed. This function - - - -Kent & Seo Standards Track [Page 53] - -RFC 4301 Security Architecture for IP December 2005 - - - may cause the packet to be passed back across the IPsec boundary, - for additional IPsec processing, e.g., in support of nested SAs. - If so, there MUST be an entry in SPD-I database that permits - inbound bypassing of the packet, otherwise the packet will be - discarded. If necessary, i.e., if there is more than one SPD-I, - the traffic being looped back MAY be tagged as coming from this - internal interface. This would allow the use of a different - SPD-I for "real" external traffic vs. looped traffic, if needed. - - Note: With the exception of IPv4 and IPv6 transport mode, an SG, - BITS, or BITW implementation MAY fragment packets before applying - IPsec. (This applies only to IPv4. For IPv6 packets, only the - originator is allowed to fragment them.) The device SHOULD have a - configuration setting to disable this. The resulting fragments are - evaluated against the SPD in the normal manner. Thus, fragments not - containing port numbers (or ICMP message type and code, or Mobility - Header type) will only match rules having port (or ICMP message type - and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for - more details.) - - Note: With regard to determining and enforcing the PMTU of an SA, the - IPsec system MUST follow the steps described in Section 8.2. - -5.1.1. Handling an Outbound Packet That Must Be Discarded - - If an IPsec system receives an outbound packet that it finds it must - discard, it SHOULD be capable of generating and sending an ICMP - message to indicate to the sender of the outbound packet that the - packet was discarded. The type and code of the ICMP message will - depend on the reason for discarding the packet, as specified below. - The reason SHOULD be recorded in the audit log. The audit log entry - for this event SHOULD include the reason, current date/time, and the - selector values from the packet. - - a. The selectors of the packet matched an SPD entry requiring the - packet to be discarded. - - IPv4 Type = 3 (destination unreachable) Code = 13 - (Communication Administratively Prohibited) - - IPv6 Type = 1 (destination unreachable) Code = 1 - (Communication with destination administratively - prohibited) - - b1. The IPsec system successfully reached the remote peer but was - unable to negotiate the SA required by the SPD entry matching the - packet because, for example, the remote peer is administratively - prohibited from communicating with the initiator, the initiating - - - -Kent & Seo Standards Track [Page 54] - -RFC 4301 Security Architecture for IP December 2005 - - - peer was unable to authenticate itself to the remote peer, the - remote peer was unable to authenticate itself to the initiating - peer, or the SPD at the remote peer did not have a suitable - entry. - - IPv4 Type = 3 (destination unreachable) Code = 13 - (Communication Administratively Prohibited) - - IPv6 Type = 1 (destination unreachable) Code = 1 - (Communication with destination administratively - prohibited) - - b2. The IPsec system was unable to set up the SA required by the SPD - entry matching the packet because the IPsec peer at the other end - of the exchange could not be contacted. - - IPv4 Type = 3 (destination unreachable) Code = 1 (host - unreachable) - - IPv6 Type = 1 (destination unreachable) Code = 3 (address - unreachable) - - Note that an attacker behind a security gateway could send packets - with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it - to send ICMP messages to W.X.Y.Z. This creates an opportunity for a - denial of service (DoS) attack among hosts behind a security gateway. - To address this, a security gateway SHOULD include a management - control to allow an administrator to configure an IPsec - implementation to send or not send the ICMP messages under these - circumstances, and if this facility is selected, to rate limit the - transmission of such ICMP responses. - -5.1.2. Header Construction for Tunnel Mode - - This section describes the handling of the inner and outer IP - headers, extension headers, and options for AH and ESP tunnels, with - regard to outbound traffic processing. This includes how to - construct the encapsulating (outer) IP header, how to process fields - in the inner IP header, and what other actions should be taken for - outbound, tunnel mode traffic. The general processing described here - is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]: - - o The outer IP header Source Address and Destination Address - identify the "endpoints" of the tunnel (the encapsulator and - decapsulator). The inner IP header Source Address and Destination - Addresses identify the original sender and recipient of the - datagram (from the perspective of this tunnel), respectively. - - - - -Kent & Seo Standards Track [Page 55] - -RFC 4301 Security Architecture for IP December 2005 - - - (See footnote 3 after the table in 5.1.2.1 for more details on the - encapsulating source IP address.) - - o The inner IP header is not changed except as noted below for TTL - (or Hop Limit) and the DS/ECN Fields. The inner IP header - otherwise remains unchanged during its delivery to the tunnel exit - point. - - o No change to IP options or extension headers in the inner header - occurs during delivery of the encapsulated datagram through the - tunnel. - - Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC - 2003 [Per96]) in several ways: - - o IPsec offers certain controls to a security administrator to - manage covert channels (which would not normally be a concern for - tunneling) and to ensure that the receiver examines the right - portions of the received packet with respect to application of - access controls. An IPsec implementation MAY be configurable with - regard to how it processes the outer DS field for tunnel mode for - transmitted packets. For outbound traffic, one configuration - setting for the outer DS field will operate as described in the - following sections on IPv4 and IPv6 header processing for IPsec - tunnels. Another will allow the outer DS field to be mapped to a - fixed value, which MAY be configured on a per-SA basis. (The value - might really be fixed for all traffic outbound from a device, but - per-SA granularity allows that as well.) This configuration option - allows a local administrator to decide whether the covert channel - provided by copying these bits outweighs the benefits of copying. - - o IPsec describes how to handle ECN or DS and provides the ability - to control propagation of changes in these fields between - unprotected and protected domains. In general, propagation from a - protected to an unprotected domain is a covert channel and thus - controls are provided to manage the bandwidth of this channel. - Propagation of ECN values in the other direction are controlled so - that only legitimate ECN changes (indicating occurrence of - congestion between the tunnel endpoints) are propagated. By - default, DS propagation from an unprotected domain to a protected - domain is not permitted. However, if the sender and receiver do - not share the same DS code space, and the receiver has no way of - learning how to map between the two spaces, then it may be - appropriate to deviate from the default. Specifically, an IPsec - implementation MAY be configurable in terms of how it processes - the outer DS field for tunnel mode for received packets. It may - be configured to either discard the outer DS value (the default) - OR to overwrite the inner DS field with the outer DS field. If - - - -Kent & Seo Standards Track [Page 56] - -RFC 4301 Security Architecture for IP December 2005 - - - offered, the discard vs. overwrite behavior MAY be configured on a - per-SA basis. This configuration option allows a local - administrator to decide whether the vulnerabilities created by - copying these bits outweigh the benefits of copying. See - [RFC2983] for further information on when each of these behaviors - may be useful, and also for the possible need for diffserv traffic - conditioning prior or subsequent to IPsec processing (including - tunnel decapsulation). - - o IPsec allows the IP version of the encapsulating header to be - different from that of the inner header. - - The tables in the following sub-sections show the handling for the - different header/option fields ("constructed" means that the value in - the outer field is constructed independently of the value in the - inner). - -5.1.2.1. IPv4: Header Construction for Tunnel Mode - - <-- How Outer Hdr Relates to Inner Hdr --> - Outer Hdr at Inner Hdr at - IPv4 Encapsulator Decapsulator - Header fields: -------------------- ------------ - version 4 (1) no change - header length constructed no change - DS Field copied from inner hdr (5) no change - ECN Field copied from inner hdr constructed (6) - total length constructed no change - ID constructed no change - flags (DF,MF) constructed, DF (4) no change - fragment offset constructed no change - TTL constructed (2) decrement (2) - protocol AH, ESP no change - checksum constructed constructed (2)(6) - src address constructed (3) no change - dest address constructed (3) no change - Options never copied no change - - Notes: - - (1) The IP version in the encapsulating header can be different - from the value in the inner header. - - (2) The TTL in the inner header is decremented by the encapsulator - prior to forwarding and by the decapsulator if it forwards the - packet. (The IPv4 checksum changes when the TTL changes.) - - - - - -Kent & Seo Standards Track [Page 57] - -RFC 4301 Security Architecture for IP December 2005 - - - Note: Decrementing the TTL value is a normal part of - forwarding a packet. Thus, a packet originating from the same - node as the encapsulator does not have its TTL decremented, - since the sending node is originating the packet rather than - forwarding it. This applies to BITS and native IPsec - implementations in hosts and routers. However, the IPsec - processing model includes an external forwarding capability. - TTL processing can be used to prevent looping of packets, - e.g., due to configuration errors, within the context of this - processing model. - - (3) Local and Remote addresses depend on the SA, which is used to - determine the Remote address, which in turn determines which - Local address (net interface) is used to forward the packet. - - Note: For multicast traffic, the destination address, or - source and destination addresses, may be required for - demuxing. In that case, it is important to ensure consistency - over the lifetime of the SA by ensuring that the source - address that appears in the encapsulating tunnel header is the - same as the one that was negotiated during the SA - establishment process. There is an exception to this general - rule, i.e., a mobile IPsec implementation will update its - source address as it moves. - - (4) Configuration determines whether to copy from the inner header - (IPv4 only), clear, or set the DF. - - (5) If the packet will immediately enter a domain for which the - DSCP value in the outer header is not appropriate, that value - MUST be mapped to an appropriate value for the domain - [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further - information. - - (6) If the ECN field in the inner header is set to ECT(0) or - ECT(1), where ECT is ECN-Capable Transport (ECT), and if the - ECN field in the outer header is set to Congestion Experienced - (CE), then set the ECN field in the inner header to CE; - otherwise, make no change to the ECN field in the inner - header. (The IPv4 checksum changes when the ECN changes.) - - Note: IPsec does not copy the options from the inner header into the - outer header, nor does IPsec construct the options in the outer - header. However, post-IPsec code MAY insert/construct options for - the outer header. - - - - - - -Kent & Seo Standards Track [Page 58] - -RFC 4301 Security Architecture for IP December 2005 - - -5.1.2.2. IPv6: Header Construction for Tunnel Mode - - <-- How Outer Hdr Relates Inner Hdr ---> - Outer Hdr at Inner Hdr at - IPv6 Encapsulator Decapsulator - Header fields: -------------------- ------------ - version 6 (1) no change - DS Field copied from inner hdr (5) no change (9) - ECN Field copied from inner hdr constructed (6) - flow label copied or configured (8) no change - payload length constructed no change - next header AH,ESP,routing hdr no change - hop limit constructed (2) decrement (2) - src address constructed (3) no change - dest address constructed (3) no change - Extension headers never copied (7) no change - - Notes: - - (1) - (6) See Section 5.1.2.1. - - (7) IPsec does not copy the extension headers from the inner - packet into outer headers, nor does IPsec construct extension - headers in the outer header. However, post-IPsec code MAY - insert/construct extension headers for the outer header. - - (8) See [RaCoCaDe04]. Copying is acceptable only for end systems, - not SGs. If an SG copied flow labels from the inner header to - the outer header, collisions might result. - - (9) An implementation MAY choose to provide a facility to pass the - DS value from the outer header to the inner header, on a per- - SA basis, for received tunnel mode packets. The motivation - for providing this feature is to accommodate situations in - which the DS code space at the receiver is different from that - of the sender and the receiver has no way of knowing how to - translate from the sender's space. There is a danger in - copying this value from the outer header to the inner header, - since it enables an attacker to modify the outer DSCP value in - a fashion that may adversely affect other traffic at the - receiver. Hence the default behavior for IPsec - implementations is NOT to permit such copying. - -5.2. Processing Inbound IP Traffic (unprotected-to-protected) - - Inbound processing is somewhat different from outbound processing, - because of the use of SPIs to map IPsec-protected traffic to SAs. - The inbound SPD cache (SPD-I) is applied only to bypassed or - - - -Kent & Seo Standards Track [Page 59] - -RFC 4301 Security Architecture for IP December 2005 - - - discarded traffic. If an arriving packet appears to be an IPsec - fragment from an unprotected interface, reassembly is performed prior - to IPsec processing. The intent for any SPD cache is that a packet - that fails to match any entry is then referred to the corresponding - SPD. Every SPD SHOULD have a nominal, final entry that catches - anything that is otherwise unmatched, and discards it. This ensures - that non-IPsec-protected traffic that arrives and does not match any - SPD-I entry will be discarded. - - Unprotected Interface - | - V - +-----+ IPsec protected - ------------------->|Demux|-------------------+ - | +-----+ | - | | | - | Not IPsec | | - | | | - | V | - | +-------+ +---------+ | - | |DISCARD|<---|SPD-I (*)| | - | +-------+ +---------+ | - | | | - | |-----+ | - | | | | - | | V | - | | +------+ | - | | | ICMP | | - | | +------+ | - | | V - +---------+ | +-----------+ - ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec - +---------+ | | (AH/ESP) | Boundary - ^ | +-----------+ - | | +---+ | - | BYPASS | +-->|IKE| | - | | | +---+ | - | V | V - | +----------+ +---------+ +----+ - |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| - nested SAs +----------+ | (***) | +----+ - | +---------+ - V - Protected Interface - - Figure 3. Processing Model for Inbound Traffic - - - - - -Kent & Seo Standards Track [Page 60] - -RFC 4301 Security Architecture for IP December 2005 - - - (*) = The caches are shown here. If there is - a cache miss, then the SPD is checked. - There is no requirement that an - implementation buffer the packet if - there is a cache miss. - (**) = This processing includes using the - packet's SPI, etc., to look up the SA - in the SAD, which forms a cache of the - SPD for inbound packets (except for - cases noted in Sections 4.4.2 and 5). - See step 3a below. - (***) = This SAD check refers to step 4 below. - - Prior to performing AH or ESP processing, any IP fragments that - arrive via the unprotected interface are reassembled (by IP). Each - inbound IP datagram to which IPsec processing will be applied is - identified by the appearance of the AH or ESP values in the IP Next - Protocol field (or of AH or ESP as a next layer protocol in the IPv6 - context). - - IPsec MUST perform the following steps: - - 1. When a packet arrives, it may be tagged with the ID of the - interface (physical or virtual) via which it arrived, if - necessary, to support multiple SPDs and associated SPD-I caches. - (The interface ID is mapped to a corresponding SPD-ID.) - - 2. The packet is examined and demuxed into one of two categories: - - If the packet appears to be IPsec protected and it is addressed - to this device, an attempt is made to map it to an active SA - via the SAD. Note that the device may have multiple IP - addresses that may be used in the SAD lookup, e.g., in the case - of protocols such as SCTP. - - Traffic not addressed to this device, or addressed to this - device and not AH or ESP, is directed to SPD-I lookup. (This - implies that IKE traffic MUST have an explicit BYPASS entry in - the SPD.) If multiple SPDs are employed, the tag assigned to - the packet in step 1 is used to select the appropriate SPD-I - (and cache) to search. SPD-I lookup determines whether the - action is DISCARD or BYPASS. - - 3a. If the packet is addressed to the IPsec device and AH or ESP is - specified as the protocol, the packet is looked up in the SAD. - For unicast traffic, use only the SPI (or SPI plus protocol). - For multicast traffic, use the SPI plus the destination or SPI - plus destination and source addresses, as specified in Section - 4.1. In either case (unicast or multicast), if there is no match, - discard the traffic. This is an auditable event. The audit log - - - -Kent & Seo Standards Track [Page 61] - -RFC 4301 Security Architecture for IP December 2005 - - - entry for this event SHOULD include the current date/time, SPI, - source and destination of the packet, IPsec protocol, and any - other selector values of the packet that are available. If the - packet is found in the SAD, process it accordingly (see step 4). - - 3b. If the packet is not addressed to the device or is addressed to - this device and is not AH or ESP, look up the packet header in - the (appropriate) SPD-I cache. If there is a match and the - packet is to be discarded or bypassed, do so. If there is no - cache match, look up the packet in the corresponding SPD-I and - create a cache entry as appropriate. (No SAs are created in - response to receipt of a packet that requires IPsec protection; - only BYPASS or DISCARD cache entries can be created this way.) If - there is no match, discard the traffic. This is an auditable - event. The audit log entry for this event SHOULD include the - current date/time, SPI if available, IPsec protocol if available, - source and destination of the packet, and any other selector - values of the packet that are available. - - 3c. Processing of ICMP messages is assumed to take place on the - unprotected side of the IPsec boundary. Unprotected ICMP - messages are examined and local policy is applied to determine - whether to accept or reject these messages and, if accepted, what - action to take as a result. For example, if an ICMP unreachable - message is received, the implementation must decide whether to - act on it, reject it, or act on it with constraints. (See Section - 6.) - - 4. Apply AH or ESP processing as specified, using the SAD entry - selected in step 3a above. Then match the packet against the - inbound selectors identified by the SAD entry to verify that the - received packet is appropriate for the SA via which it was - received. - - 5. If an IPsec system receives an inbound packet on an SA and the - packet's header fields are not consistent with the selectors for - the SA, it MUST discard the packet. This is an auditable event. - The audit log entry for this event SHOULD include the current - date/time, SPI, IPsec protocol(s), source and destination of the - packet, any other selector values of the packet that are - available, and the selector values from the relevant SAD entry. - The system SHOULD also be capable of generating and sending an - IKE notification of INVALID_SELECTORS to the sender (IPsec peer), - indicating that the received packet was discarded because of - failure to pass selector checks. - - - - - - -Kent & Seo Standards Track [Page 62] - -RFC 4301 Security Architecture for IP December 2005 - - - To minimize the impact of a DoS attack, or a mis-configured peer, the - IPsec system SHOULD include a management control to allow an - administrator to configure the IPsec implementation to send or not - send this IKE notification, and if this facility is selected, to rate - limit the transmission of such notifications. - - After traffic is bypassed or processed through IPsec, it is handed to - the inbound forwarding function for disposition. This function may - cause the packet to be sent (outbound) across the IPsec boundary for - additional inbound IPsec processing, e.g., in support of nested SAs. - If so, then as with ALL outbound traffic that is to be bypassed, the - packet MUST be matched against an SPD-O entry. Ultimately, the - packet should be forwarded to the destination host or process for - disposition. - -6. ICMP Processing - - This section describes IPsec handling of ICMP traffic. There are two - categories of ICMP traffic: error messages (e.g., type = destination - unreachable) and non-error messages (e.g., type = echo). This - section applies exclusively to error messages. Disposition of - non-error, ICMP messages (that are not addressed to the IPsec - implementation itself) MUST be explicitly accounted for using SPD - entries. - - The discussion in this section applies to ICMPv6 as well as to - ICMPv4. Also, a mechanism SHOULD be provided to allow an - administrator to cause ICMP error messages (selected, all, or none) - to be logged as an aid to problem diagnosis. - -6.1. Processing ICMP Error Messages Directed to an IPsec Implementation - -6.1.1. ICMP Error Messages Received on the Unprotected Side of the - Boundary - - Figure 3 in Section 5.2 shows a distinct ICMP processing module on - the unprotected side of the IPsec boundary, for processing ICMP - messages (error or otherwise) that are addressed to the IPsec device - and that are not protected via AH or ESP. An ICMP message of this - sort is unauthenticated, and its processing may result in denial or - degradation of service. This suggests that, in general, it would be - desirable to ignore such messages. However, many ICMP messages will - be received by hosts or security gateways from unauthenticated - sources, e.g., routers in the public Internet. Ignoring these ICMP - messages can degrade service, e.g., because of a failure to process - PMTU message and redirection messages. Thus, there is also a - motivation for accepting and acting upon unauthenticated ICMP - messages. - - - -Kent & Seo Standards Track [Page 63] - -RFC 4301 Security Architecture for IP December 2005 - - - To accommodate both ends of this spectrum, a compliant IPsec - implementation MUST permit a local administrator to configure an - IPsec implementation to accept or reject unauthenticated ICMP - traffic. This control MUST be at the granularity of ICMP type and - MAY be at the granularity of ICMP type and code. Additionally, an - implementation SHOULD incorporate mechanisms and parameters for - dealing with such traffic. For example, there could be the ability - to establish a minimum PMTU for traffic (on a per destination basis), - to prevent receipt of an unauthenticated ICMP from setting the PMTU - to a trivial size. - - If an ICMP PMTU message passes the checks above and the system is - configured to accept it, then there are two possibilities. If the - implementation applies fragmentation on the ciphertext side of the - boundary, then the accepted PMTU information is passed to the - forwarding module (outside of the IPsec implementation), which uses - it to manage outbound packet fragmentation. If the implementation is - configured to effect plaintext side fragmentation, then the PMTU - information is passed to the plaintext side and processed as - described in Section 8.2. - -6.1.2. ICMP Error Messages Received on the Protected Side of the - Boundary - - These ICMP messages are not authenticated, but they do come from - sources on the protected side of the IPsec boundary. Thus, these - messages generally are viewed as more "trustworthy" than their - counterparts arriving from sources on the unprotected side of the - boundary. The major security concern here is that a compromised host - or router might emit erroneous ICMP error messages that could degrade - service for other devices "behind" the security gateway, or that - could even result in violations of confidentiality. For example, if - a bogus ICMP redirect were consumed by a security gateway, it could - cause the forwarding table on the protected side of the boundary to - be modified so as to deliver traffic to an inappropriate destination - "behind" the gateway. Thus, implementers MUST provide controls to - allow local administrators to constrain the processing of ICMP error - messages received on the protected side of the boundary, and directed - to the IPsec implementation. These controls are of the same type as - those employed on the unprotected side, described above in Section - 6.1.1. - -6.2. Processing Protected, Transit ICMP Error Messages - - When an ICMP error message is transmitted via an SA to a device - "behind" an IPsec implementation, both the payload and the header of - the ICMP message require checking from an access control perspective. - If one of these messages is forwarded to a host behind a security - - - -Kent & Seo Standards Track [Page 64] - -RFC 4301 Security Architecture for IP December 2005 - - - gateway, the receiving host IP implementation will make decisions - based on the payload, i.e., the header of the packet that purportedly - triggered the error response. Thus, an IPsec implementation MUST be - configurable to check that this payload header information is - consistent with the SA via which it arrives. (This means that the - payload header, with source and destination address and port fields - reversed, matches the traffic selectors for the SA.) If this sort of - check is not performed, then, for example, anyone with whom the - receiving IPsec system (A) has an active SA could send an ICMP - Destination Unreachable message that refers to any host/net with - which A is currently communicating, and thus effect a highly - efficient DoS attack regarding communication with other peers of A. - Normal IPsec receiver processing of traffic is not sufficient to - protect against such attacks. However, not all contexts may require - such checks, so it is also necessary to allow a local administrator - to configure an implementation to NOT perform such checks. - - To accommodate both policies, the following convention is adopted. - If an administrator wants to allow ICMP error messages to be carried - by an SA without inspection of the payload, then configure an SPD - entry that explicitly allows for carriage of such traffic. If an - administrator wants IPsec to check the payload of ICMP error messages - for consistency, then do not create any SPD entries that accommodate - carriage of such traffic based on the ICMP packet header. This - convention motivates the following processing description. - - IPsec senders and receivers MUST support the following processing for - ICMP error messages that are sent and received via SAs. - - If an SA exists that accommodates an outbound ICMP error message, - then the message is mapped to the SA and only the IP and ICMP headers - are checked upon receipt, just as would be the case for other - traffic. If no SA exists that matches the traffic selectors - associated with an ICMP error message, then the SPD is searched to - determine if such an SA can be created. If so, the SA is created and - the ICMP error message is transmitted via that SA. Upon receipt, - this message is subject to the usual traffic selector checks at the - receiver. This processing is exactly what would happen for traffic - in general, and thus does not represent any special processing for - ICMP error messages. - - If no SA exists that would carry the outbound ICMP message in - question, and if no SPD entry would allow carriage of this outbound - ICMP error message, then an IPsec implementation MUST map the message - to the SA that would carry the return traffic associated with the - packet that triggered the ICMP error message. This requires an IPsec - implementation to detect outbound ICMP error messages that map to no - extant SA or SPD entry, and treat them specially with regard to SA - - - -Kent & Seo Standards Track [Page 65] - -RFC 4301 Security Architecture for IP December 2005 - - - creation and lookup. The implementation extracts the header for the - packet that triggered the error (from the ICMP message payload), - reverses the source and destination IP address fields, extracts the - protocol field, and reverses the port fields (if accessible). It - then uses this extracted information to locate an appropriate, active - outbound SA, and transmits the error message via this SA. If no such - SA exists, no SA will be created, and this is an auditable event. - - If an IPsec implementation receives an inbound ICMP error message on - an SA, and the IP and ICMP headers of the message do not match the - traffic selectors for the SA, the receiver MUST process the received - message in a special fashion. Specifically, the receiver must - extract the header of the triggering packet from the ICMP payload, - and reverse fields as described above to determine if the packet is - consistent with the selectors for the SA via which the ICMP error - message was received. If the packet fails this check, the IPsec - implementation MUST NOT forwarded the ICMP message to the - destination. This is an auditable event. - -7. Handling Fragments (on the protected side of the IPsec boundary) - - Earlier sections of this document describe mechanisms for (a) - fragmenting an outbound packet after IPsec processing has been - applied and reassembling it at the receiver before IPsec processing - and (b) handling inbound fragments received from the unprotected side - of the IPsec boundary. This section describes how an implementation - should handle the processing of outbound plaintext fragments on the - protected side of the IPsec boundary. (See Appendix D, "Fragment - Handling Rationale".) In particular, it addresses: - - o mapping an outbound non-initial fragment to the right SA - (or finding the right SPD entry) - o verifying that a received non-initial fragment is - authorized for the SA via which it was received - o mapping outbound and inbound non-initial fragments to the - right SPD-O/SPD-I entry or the relevant cache entry, for - BYPASS/DISCARD traffic - - Note: In Section 4.1, transport mode SAs have been defined to not - carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two - special values, ANY and OPAQUE, were defined for selectors and that - ANY includes OPAQUE. The term "non-trivial" is used to mean that the - selector has a value other than OPAQUE or ANY. - - Note: The term "non-initial fragment" is used here to indicate a - fragment that does not contain all the selector values that may be - needed for access control. As observed in Section 4.4.1, depending - on the Next Layer Protocol, in addition to Ports, the ICMP message - - - -Kent & Seo Standards Track [Page 66] - -RFC 4301 Security Architecture for IP December 2005 - - - type/code or Mobility Header type could be missing from non-initial - fragments. Also, for IPv6, even the first fragment might NOT contain - the Next Layer Protocol or Ports (or ICMP message type/code, or - Mobility Header type) depending on the kind and number of extension - headers present. If a non-initial fragment contains the Port (or - ICMP type and code or Mobility Header type) but not the Next Layer - Protocol, then unless there is an SPD entry for the relevant - Local/Remote addresses with ANY for Next Layer Protocol and Port (or - ICMP type and code or Mobility Header type), the fragment would not - contain all the selector information needed for access control. - - To address the above issues, three approaches have been defined: - - o Tunnel mode SAs that carry initial and non-initial fragments - (See Section 7.1.) - o Separate tunnel mode SAs for non-initial fragments (See - Section 7.2.) - o Stateful fragment checking (See Section 7.3.) - -7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments - - All implementations MUST support tunnel mode SAs that are configured - to pass traffic without regard to port field (or ICMP type/code or - Mobility Header type) values. If the SA will carry traffic for - specified protocols, the selector set for the SA MUST specify the - port fields (or ICMP type/code or Mobility Header type) as ANY. An - SA defined in this fashion will carry all traffic including initial - and non-initial fragments for the indicated Local/Remote addresses - and specified Next Layer protocol(s). If the SA will carry traffic - without regard to a specific protocol value (i.e., ANY is specified - as the (Next Layer) protocol selector value), then the port field - values are undefined and MUST be set to ANY as well. (As noted in - 4.4.1, ANY includes OPAQUE as well as all specific values.) - -7.2. Separate Tunnel Mode SAs for Non-Initial Fragments - - An implementation MAY support tunnel mode SAs that will carry only - non-initial fragments, separate from non-fragmented packets and - initial fragments. The OPAQUE value will be used to specify port (or - ICMP type/code or Mobility Header type) field selectors for an SA to - carry such fragments. Receivers MUST perform a minimum offset check - on IPv4 (non-initial) fragments to protect against overlapping - fragment attacks when SAs of this type are employed. Because such - checks cannot be performed on IPv6 non-initial fragments, users and - administrators are advised that carriage of such fragments may be - dangerous, and implementers may choose to NOT support such SAs for - IPv6 traffic. Also, an SA of this sort will carry all non-initial - fragments that match a specified Local/Remote address pair and - - - -Kent & Seo Standards Track [Page 67] - -RFC 4301 Security Architecture for IP December 2005 - - - protocol value, i.e., the fragments carried on this SA belong to - packets that if not fragmented, might have gone on separate SAs of - differing security. Therefore, users and administrators are advised - to protect such traffic using ESP (with integrity) and the - "strongest" integrity and encryption algorithms in use between both - peers. (Determination of the "strongest" algorithms requires - imposing an ordering of the available algorithms, a local - determination at the discretion of the initiator of the SA.) - - Specific port (or ICMP type/code or Mobility Header type) selector - values will be used to define SAs to carry initial fragments and - non-fragmented packets. This approach can be used if a user or - administrator wants to create one or more tunnel mode SAs between the - same Local/Remote addresses that discriminate based on port (or ICMP - type/code or Mobility Header type) fields. These SAs MUST have - non-trivial protocol selector values, otherwise approach #1 above - MUST be used. - - Note: In general, for the approach described in this section, one - needs only a single SA between two implementations to carry all - non-initial fragments. However, if one chooses to have multiple SAs - between the two implementations for QoS differentiation, then one - might also want multiple SAs to carry fragments-without-ports, one - for each supported QoS class. Since support for QoS via distinct SAs - is a local matter, not mandated by this document, the choice to have - multiple SAs to carry non-initial fragments should also be local. - -7.3. Stateful Fragment Checking - - An implementation MAY support some form of stateful fragment checking - for a tunnel mode SA with non-trivial port (or ICMP type/code or MH - type) field values (not ANY or OPAQUE). 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. This standard - does not specify how peers will deal with such fragments, e.g., via - reassembly or other means, at either sender or receiver. However, a - receiver MUST discard non-initial fragments that arrive on an SA with - non-trivial port (or ICMP type/code or MH type) selector values - unless this feature has been negotiated. Also, the receiver MUST - discard non-initial fragments that do not comply with the security - policy applied to the overall packet. Discarding such packets is an - auditable event. Note that in network configurations where fragments - - - -Kent & Seo Standards Track [Page 68] - -RFC 4301 Security Architecture for IP December 2005 - - - of a packet might be sent or received via different security gateways - or BITW implementations, stateful strategies for tracking fragments - may fail. - -7.4. BYPASS/DISCARD Traffic - - All implementations MUST support DISCARDing of fragments using the - normal SPD packet classification mechanisms. All implementations - MUST support stateful fragment checking to accommodate BYPASS traffic - for which a non-trivial port range is specified. The concern is that - BYPASS of a cleartext, non-initial fragment arriving at an IPsec - implementation could undermine the security afforded IPsec-protected - traffic directed to the same destination. For example, consider an - IPsec implementation configured with an SPD entry that calls for - IPsec protection of traffic between a specific source/destination - address pair, and for a specific protocol and destination port, e.g., - TCP traffic on port 23 (Telnet). Assume that the implementation also - allows BYPASS of traffic from the same source/destination address - pair and protocol, but for a different destination port, e.g., port - 119 (NNTP). An attacker could send a non-initial fragment (with a - forged source address) that, if bypassed, could overlap with - IPsec-protected traffic from the same source and thus violate the - integrity of the IPsec-protected traffic. Requiring stateful - fragment checking for BYPASS entries with non-trivial port ranges - prevents attacks of this sort. As noted above, in network - configurations where fragments of a packet might be sent or received - via different security gateways or BITW implementations, stateful - strategies for tracking fragments may fail. - -8. Path MTU/DF Processing - - The application of AH or ESP to an outbound packet increases the size - of a packet and thus may cause a packet to exceed the PMTU for the SA - via which the packet will travel. An IPsec implementation also may - receive an unprotected ICMP PMTU message and, if it chooses to act - upon the message, the result will affect outbound traffic processing. - This section describes the processing required of an IPsec - implementation to deal with these two PMTU issues. - -8.1. DF Bit - - All IPsec implementations MUST support the option of copying the DF - bit from an outbound packet to the tunnel mode header that it emits, - when traffic is carried via a tunnel mode SA. This means that it - MUST be possible to configure the implementation's treatment of the - DF bit (set, clear, copy from inner header) for each SA. This - applies to SAs where both inner and outer headers are IPv4. - - - - -Kent & Seo Standards Track [Page 69] - -RFC 4301 Security Architecture for IP December 2005 - - -8.2. Path MTU (PMTU) Discovery - - This section discusses IPsec handling for unprotected Path MTU - Discovery messages. ICMP PMTU is used here to refer to an ICMP - message for: - - IPv4 (RFC 792 [Pos81b]): - - Type = 3 (Destination Unreachable) - - Code = 4 (Fragmentation needed and DF set) - - Next-Hop MTU in the low-order 16 bits of the - second word of the ICMP header (labeled "unused" - in RFC 792), with high-order 16 bits set to zero) - - IPv6 (RFC 2463 [CD98]): - - Type = 2 (Packet Too Big) - - Code = 0 (Fragmentation needed) - - Next-Hop MTU in the 32-bit MTU field of the ICMP6 - message - -8.2.1. Propagation of PMTU - - When an IPsec implementation receives an unauthenticated PMTU - message, and it is configured to process (vs. ignore) such messages, - it maps the message to the SA to which it corresponds. This mapping - is effected by extracting the header information from the payload of - the PMTU message and applying the procedure described in Section 5.2. - The PMTU determined by this message is used to update the SAD PMTU - field, taking into account the size of the AH or ESP header that will - be applied, any crypto synchronization data, and the overhead imposed - by an additional IP header, in the case of a tunnel mode SA. - - In a native host implementation, it is possible to maintain PMTU data - at the same granularity as for unprotected communication, so there is - no loss of functionality. Signaling of the PMTU information is - internal to the host. For all other IPsec implementation options, - the PMTU data must be propagated via a synthesized ICMP PMTU. In - these cases, the IPsec implementation SHOULD wait for outbound - traffic to be mapped to the SAD entry. When such traffic arrives, if - the traffic would exceed the updated PMTU value the traffic MUST be - handled as follows: - - Case 1: Original (cleartext) packet is IPv4 and has the DF - bit set. The implementation SHOULD discard the packet - and send a PMTU ICMP message. - - - - - - - -Kent & Seo Standards Track [Page 70] - -RFC 4301 Security Architecture for IP December 2005 - - - Case 2: Original (cleartext) packet is IPv4 and has the DF - bit clear. The implementation SHOULD fragment (before or - after encryption per its configuration) and then forward - the fragments. It SHOULD NOT send a PMTU ICMP message. - - Case 3: Original (cleartext) packet is IPv6. The implementation - SHOULD discard the packet and send a PMTU ICMP message. - -8.2.2. PMTU Aging - - In all IPsec implementations, the PMTU associated with an SA MUST be - "aged" and some mechanism is required to update the PMTU in a timely - manner, especially for discovering if the PMTU is smaller than - required by current network conditions. A given PMTU has to remain - in place long enough for a packet to get from the source of the SA to - the peer, and to propagate an ICMP error message if the current PMTU - is too big. - - Implementations SHOULD use the approach described in the Path MTU - Discovery document (RFC 1191 [MD90], Section 6.3), which suggests - periodically resetting the PMTU to the first-hop data-link MTU and - then letting the normal PMTU Discovery processes update the PMTU as - necessary. The period SHOULD be configurable. - -9. Auditing - - IPsec implementations are not required to support auditing. For the - most part, the granularity of auditing is a local matter. However, - several auditable events are identified in this document, and for - each of these events a minimum set of information that SHOULD be - included in an audit log is defined. Additional information also MAY - be included in the audit log for each of these events, and additional - events, not explicitly called out in this specification, also MAY - result in audit log entries. There is no requirement for the - receiver to transmit any message to the purported transmitter in - response to the detection of an auditable event, because of the - potential to induce denial of service via such action. - -10. Conformance Requirements - - All IPv4 IPsec implementations MUST comply with all requirements of - this document. All IPv6 implementations MUST comply with all - requirements of this document. - - - - - - - - -Kent & Seo Standards Track [Page 71] - -RFC 4301 Security Architecture for IP December 2005 - - -11. Security Considerations - - The focus of this document is security; hence security considerations - permeate this specification. - - IPsec imposes stringent constraints on bypass of IP header data in - both directions, across the IPsec barrier, especially when tunnel - mode SAs are employed. Some constraints are absolute, while others - are subject to local administrative controls, often on a per-SA - basis. For outbound traffic, these constraints are designed to limit - covert channel bandwidth. For inbound traffic, the constraints are - designed to prevent an adversary who has the ability to tamper with - one data stream (on the unprotected side of the IPsec barrier) from - adversely affecting other data streams (on the protected side of the - barrier). The discussion in Section 5 dealing with processing DSCP - values for tunnel mode SAs illustrates this concern. - - If an IPsec implementation is configured to pass ICMP error messages - over SAs based on the ICMP header values, without checking the header - information from the ICMP message payload, serious vulnerabilities - may arise. Consider a scenario in which several sites (A, B, and C) - are connected to one another via ESP-protected tunnels: A-B, A-C, and - B-C. Also assume that the traffic selectors for each tunnel specify - ANY for protocol and port fields and IP source/destination address - ranges that encompass the address range for the systems behind the - security gateways serving each site. This would allow a host at site - B to send an ICMP Destination Unreachable message to any host at site - A, that declares all hosts on the net at site C to be unreachable. - This is a very efficient DoS attack that could have been prevented if - the ICMP error messages were subjected to the checks that IPsec - provides, if the SPD is suitably configured, as described in Section - 6.2. - -12. IANA Considerations - - The IANA has assigned the value (3) for the asn1-modules registry and - has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD - module. See Appendix C, "ASN.1 for an SPD Entry". - -13. Differences from RFC 2401 - - This architecture document differs substantially from RFC 2401 - [RFC2401] in detail and in organization, but the fundamental notions - are unchanged. - - o The processing model has been revised to address new IPsec - scenarios, improve performance, and simplify implementation. This - includes a separation between forwarding (routing) and SPD - - - -Kent & Seo Standards Track [Page 72] - -RFC 4301 Security Architecture for IP December 2005 - - - selection, several SPD changes, and the addition of an outbound SPD - cache and an inbound SPD cache for bypassed or discarded traffic. - There is also a new database, the Peer Authorization Database - (PAD). This provides a link between an SA management protocol - (such as IKE) and the SPD. - - o There is no longer a requirement to support nested SAs or "SA - bundles". Instead this functionality can be achieved through SPD - and forwarding table configuration. An example of a configuration - has been added in Appendix E. - - o SPD entries were redefined to provide more flexibility. Each SPD - entry now consists of 1 to N sets of selectors, where each selector - set contains one protocol and a "list of ranges" can now be - specified for the Local IP address, Remote IP address, and whatever - fields (if any) are associated with the Next Layer Protocol (Local - Port, Remote Port, ICMP message type and code, and Mobility Header - type). An individual value for a selector is represented via a - trivial range and ANY is represented via a range than spans all - values for the selector. An example of an ASN.1 description is - included in Appendix C. - - o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and - ECN. The tunnel section has been updated to explain how to handle - DSCP and ECN bits. - - o For tunnel mode SAs, an SG, BITS, or BITW implementation is now - allowed to fragment packets before applying IPsec. This applies - only to IPv4. For IPv6 packets, only the originator is allowed to - fragment them. - - o When security is desired between two intermediate systems along a - path or between an intermediate system and an end system, transport - mode may now be used between security gateways and between a - security gateway and a host. - - o This document clarifies that for all traffic that crosses the IPsec - boundary, including IPsec management traffic, the SPD or associated - caches must be consulted. - - o This document defines how to handle the situation of a security - gateway with multiple subscribers requiring separate IPsec - contexts. - - o A definition of reserved SPIs has been added. - - - - - - -Kent & Seo Standards Track [Page 73] - -RFC 4301 Security Architecture for IP December 2005 - - - o Text has been added explaining why ALL IP packets must be checked - -- IPsec includes minimal firewall functionality to support access - control at the IP layer. - - o The tunnel section has been updated to clarify how to handle the IP - options field and IPv6 extension headers when constructing the - outer header. - - o SA mapping for inbound traffic has been updated to be consistent - with the changes made in AH and ESP for support of unicast and - multicast SAs. - - o Guidance has been added regarding how to handle the covert channel - created in tunnel mode by copying the DSCP value to outer header. - - o Support for AH in both IPv4 and IPv6 is no longer required. - - o PMTU handling has been updated. The appendix on - PMTU/DF/Fragmentation has been deleted. - - o Three approaches have been added for handling plaintext fragments - on the protected side of the IPsec boundary. Appendix D documents - the rationale behind them. - - o Added revised text describing how to derive selector values for SAs - (from the SPD entry or from the packet, etc.) - - o Added a new table describing the relationship between selector - values in an SPD entry, the PFP flag, and resulting selector values - in the corresponding SAD entry. - - o Added Appendix B to describe decorrelation. - - o Added text describing how to handle an outbound packet that must be - discarded. - - o Added text describing how to handle a DISCARDED inbound packet, - i.e., one that does not match the SA upon which it arrived. - - o IPv6 mobility header has been added as a possible Next Layer - Protocol. IPv6 Mobility Header message type has been added as a - selector. - - o ICMP message type and code have been added as selectors. - - o The selector "data sensitivity level" has been removed to simplify - things. - - - - -Kent & Seo Standards Track [Page 74] - -RFC 4301 Security Architecture for IP December 2005 - - - o Updated text describing handling ICMP error messages. The appendix - on "Categorization of ICMP Messages" has been deleted. - - o The text for the selector name has been updated and clarified. - - o The "Next Layer Protocol" has been further explained and a default - list of protocols to skip when looking for the Next Layer Protocol - has been added. - - o The text has been amended to say that this document assumes use of - IKEv2 or an SA management protocol with comparable features. - - o Text has been added clarifying the algorithm for mapping inbound - IPsec datagrams to SAs in the presence of multicast SAs. - - o The appendix "Sequence Space Window Code Example" has been removed. - - o With respect to IP addresses and ports, the terms "Local" and - "Remote" are used for policy rules (replacing source and - destination). "Local" refers to the entity being protected by an - IPsec implementation, i.e., the "source" address/port of outbound - packets or the "destination" address/port of inbound packets. - "Remote" refers to a peer entity or peer entities. The terms - "source" and "destination" are still used for packet header fields. - -14. Acknowledgements - - The authors would like to acknowledge the contributions of Ran - Atkinson, who played a critical role in initial IPsec activities, and - who authored the first series of IPsec standards: RFCs 1825-1827; and - Charlie Lynn, who made significant contributions to the second series - of IPsec standards (RFCs 2401, 2402, and 2406) and to the current - versions, especially with regard to IPv6 issues. The authors also - would like to thank the members of the IPsec and MSEC working groups - who have contributed to the development of this protocol - specification. - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 75] - -RFC 4301 Security Architecture for IP December 2005 - - -Appendix A: Glossary - - This section provides definitions for several key terms that are - employed in this document. Other documents provide additional - definitions and background information relevant to this technology, - e.g., [Shi00], [VK83], and [HA94]. Included in this glossary are - generic security service and security mechanism terms, plus - IPsec-specific terms. - - Access Control - A security service that prevents unauthorized use of a resource, - including the prevention of use of a resource in an unauthorized - manner. In the IPsec context, the resource to which access is - being controlled is often: - - o for a host, computing cycles or data - o for a security gateway, a network behind the gateway - or bandwidth on that network. - - Anti-replay - See "Integrity" below. - - Authentication - Used informally to refer to the combination of two nominally - distinct security services, data origin authentication and - connectionless integrity. See the definitions below for each of - these services. - - Availability - When viewed as a security service, addresses the security concerns - engendered by attacks against networks that deny or degrade - service. For example, in the IPsec context, the use of - anti-replay mechanisms in AH and ESP support availability. - - Confidentiality - The security service that protects data from unauthorized - disclosure. The primary confidentiality concern in most instances - is unauthorized disclosure of application-level data, but - disclosure of the external characteristics of communication also - can be a concern in some circumstances. Traffic flow - confidentiality is the service that addresses this latter concern - by concealing source and destination addresses, message length, or - frequency of communication. In the IPsec context, using ESP in - tunnel mode, especially at a security gateway, can provide some - level of traffic flow confidentiality. (See also "Traffic - Analysis" below.) - - - - - -Kent & Seo Standards Track [Page 76] - -RFC 4301 Security Architecture for IP December 2005 - - - Data Origin Authentication - A security service that verifies the identity of the claimed - source of data. This service is usually bundled with - connectionless integrity service. - - Encryption - A security mechanism used to transform data from an intelligible - form (plaintext) into an unintelligible form (ciphertext), to - provide confidentiality. The inverse transformation process is - designated "decryption". Often the term "encryption" is used to - generically refer to both processes. - - Integrity - A security service that ensures that modifications to data are - detectable. Integrity comes in various flavors to match - application requirements. IPsec supports two forms of integrity: - connectionless and a form of partial sequence integrity. - Connectionless integrity is a service that detects modification of - an individual IP datagram, without regard to the ordering of the - datagram in a stream of traffic. The form of partial sequence - integrity offered in IPsec is referred to as anti-replay - integrity, and it detects arrival of duplicate IP datagrams - (within a constrained window). This is in contrast to - connection-oriented integrity, which imposes more stringent - sequencing requirements on traffic, e.g., to be able to detect - lost or re-ordered messages. Although authentication and - integrity services often are cited separately, in practice they - are intimately connected and almost always offered in tandem. - - Protected vs. Unprotected - "Protected" refers to the systems or interfaces that are inside - the IPsec protection boundary, and "unprotected" refers to the - systems or interfaces that are outside the IPsec protection - boundary. IPsec provides a boundary through which traffic passes. - There is an asymmetry to this barrier, which is reflected in the - processing model. Outbound data, if not discarded or bypassed, is - protected via the application of AH or ESP and the addition of the - corresponding headers. Inbound data, if not discarded or - bypassed, is processed via the removal of AH or ESP headers. In - this document, inbound traffic enters an IPsec implementation from - the "unprotected" interface. Outbound traffic enters the - implementation via the "protected" interface, or is internally - generated by the implementation on the "protected" side of the - boundary and directed toward the "unprotected" interface. An - IPsec implementation may support more than one interface on either - or both sides of the boundary. The protected interface may be - - - - - -Kent & Seo Standards Track [Page 77] - -RFC 4301 Security Architecture for IP December 2005 - - - internal, e.g., in a host implementation of IPsec. The protected - interface may link to a socket layer interface presented by the - OS. - - Security Association (SA) - A simplex (uni-directional) logical connection, created for - security purposes. All traffic traversing an SA is provided the - same security processing. In IPsec, an SA is an Internet-layer - abstraction implemented through the use of AH or ESP. State data - associated with an SA is represented in the SA Database (SAD). - - Security Gateway - An intermediate system that acts as the communications interface - between two networks. The set of hosts (and networks) on the - external side of the security gateway is termed unprotected (they - are generally at least less protected than those "behind" the SG), - while the networks and hosts on the internal side are viewed as - protected. The internal subnets and hosts served by a security - gateway are presumed to be trusted by virtue of sharing a common, - local, security administration. In the IPsec context, a security - gateway is a point at which AH and/or ESP is implemented in order - to serve a set of internal hosts, providing security services for - these hosts when they communicate with external hosts also - employing IPsec (either directly or via another security gateway). - - Security Parameters Index (SPI) - An arbitrary 32-bit value that is used by a receiver to identify - the SA to which an incoming packet should be bound. For a unicast - SA, the SPI can be used by itself to specify an SA, or it may be - used in conjunction with the IPsec protocol type. Additional IP - address information is used to identify multicast SAs. The SPI is - carried in AH and ESP protocols to enable the receiving system to - select the SA under which a received packet will be processed. An - SPI has only local significance, as defined by the creator of the - SA (usually the receiver of the packet carrying the SPI); thus an - SPI is generally viewed as an opaque bit string. However, the - creator of an SA may choose to interpret the bits in an SPI to - facilitate local processing. - - Traffic Analysis - The analysis of network traffic flow for the purpose of deducing - information that is useful to an adversary. Examples of such - information are frequency of transmission, the identities of the - conversing parties, sizes of packets, and flow identifiers - [Sch94]. - - - - - - -Kent & Seo Standards Track [Page 78] - -RFC 4301 Security Architecture for IP December 2005 - - -Appendix B: Decorrelation - - This appendix is based on work done for caching of policies in the IP - Security Policy Working Group by Luis Sanchez, Matt Condell, and John - Zao. - - Two SPD entries are correlated if there is a non-null intersection - between the values of corresponding selectors in each entry. Caching - correlated SPD entries can lead to incorrect policy enforcement. A - solution to this problem, which still allows for caching, is to - remove the ambiguities by decorrelating the entries. That is, the - SPD entries must be rewritten so that for every pair of entries there - exists a selector for which there is a null intersection between the - values in both of the entries. Once the entries are decorrelated, - there is no longer any ordering requirement on them, since only one - entry will match any lookup. The next section describes - decorrelation in more detail and presents an algorithm that may be - used to implement decorrelation. - -B.1. Decorrelation Algorithm - - The basic decorrelation algorithm takes each entry in a correlated - SPD and divides it into a set of entries using a tree structure. - The nodes of the tree are the selectors that may overlap between the - policies. At each node, the algorithm creates a branch for each of - the values of the selector. It also creates one branch for the - complement of the union of all selector values. Policies are then - formed by traversing the tree from the root to each leaf. The - policies at the leaves are compared to the set of already - decorrelated policy rules. Each policy at a leaf is either - completely overridden by a policy in the already decorrelated set and - is discarded or is decorrelated with all the policies in the - decorrelated set and is added to it. - - The basic algorithm does not guarantee an optimal set of decorrelated - entries. That is, the entries may be broken up into smaller sets - than is necessary, though they will still provide all the necessary - policy information. Some extensions to the basic algorithm are - described later to improve this and improve the performance of the - algorithm. - - C A set of ordered, correlated entries (a correlated SPD). - Ci The ith entry in C. - U The set of decorrelated entries being built from C. - Ui The ith entry in U. - Sik The kth selection for policy Ci. - Ai The action for policy Ci. - - - - -Kent & Seo Standards Track [Page 79] - -RFC 4301 Security Architecture for IP December 2005 - - - A policy (SPD entry) P may be expressed as a sequence of selector - values and an action (BYPASS, DISCARD, or PROTECT): - - Ci = Si1 x Si2 x ... x Sik -> Ai - - 1) Put C1 in set U as U1 - - For each policy Cj (j > 1) in C - - 2) If Cj is decorrelated with every entry in U, then add it to U. - - 3) If Cj is correlated with one or more entries in U, create a tree - rooted at the policy Cj that partitions Cj into a set of decorrelated - entries. The algorithm starts with a root node where no selectors - have yet been chosen. - - A) Choose a selector in Cj, Sjn, that has not yet been chosen when - traversing the tree from the root to this node. If there are no - selectors not yet used, continue to the next unfinished branch - until all branches have been completed. When the tree is - completed, go to step D. - - T is the set of entries in U that are correlated with the entry - at this node. - - The entry at this node is the entry formed by the selector - values of each of the branches between the root and this node. - Any selector values that are not yet represented by branches - assume the corresponding selector value in Cj, since the values - in Cj represent the maximum value for each selector. - - B) Add a branch to the tree for each value of the selector Sjn that - appears in any of the entries in T. (If the value is a superset - of the value of Sjn in Cj, then use the value in Cj, since that - value represents the universal set.) Also add a branch for the - complement of the union of all the values of the selector Sjn - in T. When taking the complement, remember that the universal - set is the value of Sjn in Cj. A branch need not be created - for the null set. - - C) Repeat A and B until the tree is completed. - - D) The entry to each leaf now represents an entry that is a subset - of Cj. The entries at the leaves completely partition Cj in - such a way that each entry is either completely overridden by - an entry in U, or is decorrelated with the entries in U. - - Add all the decorrelated entries at the leaves of the tree to U. - - - -Kent & Seo Standards Track [Page 80] - -RFC 4301 Security Architecture for IP December 2005 - - - 4) Get next Cj and go to 2. - - 5) When all entries in C have been processed, then U will contain an - decorrelated version of C. - - There are several optimizations that can be made to this algorithm. - A few of them are presented here. - - It is possible to optimize, or at least improve, the amount of - branching that occurs by carefully choosing the order of the - selectors used for the next branch. For example, if a selector Sjn - can be chosen so that all the values for that selector in T are equal - to or a superset of the value of Sjn in Cj, then only a single branch - needs to be created (since the complement will be null). - - Branches of the tree do not have to proceed with the entire - decorrelation algorithm. For example, if a node represents an entry - that is decorrelated with all the entries in U, then there is no - reason to continue decorrelating that branch. Also, if a branch is - completely overridden by an entry in U, then there is no reason to - continue decorrelating the branch. - - An additional optimization is to check to see if a branch is - overridden by one of the CORRELATED entries in set C that has already - been decorrelated. That is, if the branch is part of decorrelating - Cj, then check to see if it was overridden by an entry Cm, m < j. - This is a valid check, since all the entries Cm are already expressed - in U. - - Along with checking if an entry is already decorrelated in step 2, - check if Cj is overridden by any entry in U. If it is, skip it since - it is not relevant. An entry x is overridden by another entry y if - every selector in x is equal to or a subset of the corresponding - selector in entry y. - - - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 81] - -RFC 4301 Security Architecture for IP December 2005 - - -Appendix C: ASN.1 for an SPD Entry - - This appendix is included as an additional way to describe SPD - entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has - been successfully compiled. This syntax is merely illustrative and - need not be employed in an implementation to achieve compliance. The - SPD description in Section 4.4.1 is normative. - - SPDModule - - {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) - ipsec (8) asn1-modules (3) spd-module (1) } - - DEFINITIONS IMPLICIT TAGS ::= - - BEGIN - - IMPORTS - RDNSequence FROM PKIX1Explicit88 - { iso(1) identified-organization(3) - dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) } ; - - -- An SPD is a list of policies in decreasing order of preference - SPD ::= SEQUENCE OF SPDEntry - - SPDEntry ::= CHOICE { - iPsecEntry IPsecEntry, -- PROTECT traffic - bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS - - IPsecEntry ::= SEQUENCE { -- Each entry consists of - name NameSets OPTIONAL, - pFPs PacketFlags, -- Populate from packet flags - -- Applies to ALL of the corresponding - -- traffic selectors in the SelectorLists - condition SelectorLists, -- Policy "condition" - processing Processing -- Policy "action" - } - - BypassOrDiscardEntry ::= SEQUENCE { - bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD - condition InOutBound } - - InOutBound ::= CHOICE { - outbound [0] SelectorLists, - inbound [1] SelectorLists, - bothways [2] BothWays } - - - - -Kent & Seo Standards Track [Page 82] - -RFC 4301 Security Architecture for IP December 2005 - - - BothWays ::= SEQUENCE { - inbound SelectorLists, - outbound SelectorLists } - - NameSets ::= SEQUENCE { - passed SET OF Names-R, -- Matched to IKE ID by - -- responder - local SET OF Names-I } -- Used internally by IKE - -- initiator - - Names-R ::= CHOICE { -- IKEv2 IDs - dName RDNSequence, -- ID_DER_ASN1_DN - fqdn FQDN, -- ID_FQDN - rfc822 [0] RFC822Name, -- ID_RFC822_ADDR - keyID OCTET STRING } -- KEY_ID - - Names-I ::= OCTET STRING -- Used internally by IKE - -- initiator - - FQDN ::= IA5String - - RFC822Name ::= IA5String - - PacketFlags ::= BIT STRING { - -- if set, take selector value from packet - -- establishing SA - -- else use value in SPD entry - localAddr (0), - remoteAddr (1), - protocol (2), - localPort (3), - remotePort (4) } - - SelectorLists ::= SET OF SelectorList - - SelectorList ::= SEQUENCE { - localAddr AddrList, - remoteAddr AddrList, - protocol ProtocolChoice } - - Processing ::= SEQUENCE { - extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit - seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit - fragCheck BOOLEAN, -- TRUE stateful fragment checking, - -- FALSE no stateful fragment checking - lifetime SALifetime, - spi ManualSPI, - algorithms ProcessingAlgs, - - - -Kent & Seo Standards Track [Page 83] - -RFC 4301 Security Architecture for IP December 2005 - - - tunnel TunnelOptions OPTIONAL } -- if absent, use - -- transport mode - - SALifetime ::= SEQUENCE { - seconds [0] INTEGER OPTIONAL, - bytes [1] INTEGER OPTIONAL } - - ManualSPI ::= SEQUENCE { - spi INTEGER, - keys KeyIDs } - - KeyIDs ::= SEQUENCE OF OCTET STRING - - ProcessingAlgs ::= CHOICE { - ah [0] IntegrityAlgs, -- AH - esp [1] ESPAlgs} -- ESP - - ESPAlgs ::= CHOICE { - integrity [0] IntegrityAlgs, -- integrity only - confidentiality [1] ConfidentialityAlgs, -- confidentiality - -- only - both [2] IntegrityConfidentialityAlgs, - combined [3] CombinedModeAlgs } - - IntegrityConfidentialityAlgs ::= SEQUENCE { - integrity IntegrityAlgs, - confidentiality ConfidentialityAlgs } - - -- Integrity Algorithms, ordered by decreasing preference - IntegrityAlgs ::= SEQUENCE OF IntegrityAlg - - -- Confidentiality Algorithms, ordered by decreasing preference - ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg - - -- Integrity Algorithms - IntegrityAlg ::= SEQUENCE { - algorithm IntegrityAlgType, - parameters ANY -- DEFINED BY algorithm -- OPTIONAL } - - IntegrityAlgType ::= INTEGER { - none (0), - auth-HMAC-MD5-96 (1), - auth-HMAC-SHA1-96 (2), - auth-DES-MAC (3), - auth-KPDK-MD5 (4), - auth-AES-XCBC-96 (5) - -- tbd (6..65535) - } - - - -Kent & Seo Standards Track [Page 84] - -RFC 4301 Security Architecture for IP December 2005 - - - -- Confidentiality Algorithms - ConfidentialityAlg ::= SEQUENCE { - algorithm ConfidentialityAlgType, - parameters ANY -- DEFINED BY algorithm -- OPTIONAL } - - ConfidentialityAlgType ::= INTEGER { - encr-DES-IV64 (1), - encr-DES (2), - encr-3DES (3), - encr-RC5 (4), - encr-IDEA (5), - encr-CAST (6), - encr-BLOWFISH (7), - encr-3IDEA (8), - encr-DES-IV32 (9), - encr-RC4 (10), - encr-NULL (11), - encr-AES-CBC (12), - encr-AES-CTR (13) - -- tbd (14..65535) - } - - CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg - - CombinedModeAlg ::= SEQUENCE { - algorithm CombinedModeType, - parameters ANY -- DEFINED BY algorithm} -- defined outside - -- of this document for AES modes. - - CombinedModeType ::= INTEGER { - comb-AES-CCM (1), - comb-AES-GCM (2) - -- tbd (3..65535) - } - - TunnelOptions ::= SEQUENCE { - dscp DSCP, - ecn BOOLEAN, -- TRUE Copy CE to inner header - df DF, - addresses TunnelAddresses } - - TunnelAddresses ::= CHOICE { - ipv4 IPv4Pair, - ipv6 [0] IPv6Pair } - - IPv4Pair ::= SEQUENCE { - local OCTET STRING (SIZE(4)), - remote OCTET STRING (SIZE(4)) } - - - -Kent & Seo Standards Track [Page 85] - -RFC 4301 Security Architecture for IP December 2005 - - - IPv6Pair ::= SEQUENCE { - local OCTET STRING (SIZE(16)), - remote OCTET STRING (SIZE(16)) } - - DSCP ::= SEQUENCE { - copy BOOLEAN, -- TRUE copy from inner header - -- FALSE do not copy - mapping OCTET STRING OPTIONAL} -- points to table - -- if no copy - - DF ::= INTEGER { - clear (0), - set (1), - copy (2) } - - ProtocolChoice::= CHOICE { - anyProt AnyProtocol, -- for ANY protocol - noNext [0] NoNextLayerProtocol, -- has no next layer - -- items - oneNext [1] OneNextLayerProtocol, -- has one next layer - -- item - twoNext [2] TwoNextLayerProtocol, -- has two next layer - -- items - fragment FragmentNoNext } -- has no next layer - -- info - - AnyProtocol ::= SEQUENCE { - id INTEGER (0), -- ANY protocol - nextLayer AnyNextLayers } - - AnyNextLayers ::= SEQUENCE { -- with either - first AnyNextLayer, -- ANY next layer selector - second AnyNextLayer } -- ANY next layer selector - - NoNextLayerProtocol ::= INTEGER (2..254) - - FragmentNoNext ::= INTEGER (44) -- Fragment identifier - - OneNextLayerProtocol ::= SEQUENCE { - id INTEGER (1..254), -- ICMP, MH, ICMPv6 - nextLayer NextLayerChoice } -- ICMP Type*256+Code - -- MH Type*256 - - TwoNextLayerProtocol ::= SEQUENCE { - id INTEGER (2..254), -- Protocol - local NextLayerChoice, -- Local and - remote NextLayerChoice } -- Remote ports - - - - -Kent & Seo Standards Track [Page 86] - -RFC 4301 Security Architecture for IP December 2005 - - - NextLayerChoice ::= CHOICE { - any AnyNextLayer, - opaque [0] OpaqueNextLayer, - range [1] NextLayerRange } - - -- Representation of ANY in next layer field - AnyNextLayer ::= SEQUENCE { - start INTEGER (0), - end INTEGER (65535) } - - -- Representation of OPAQUE in next layer field. - -- Matches IKE convention - OpaqueNextLayer ::= SEQUENCE { - start INTEGER (65535), - end INTEGER (0) } - - -- Range for a next layer field - NextLayerRange ::= SEQUENCE { - start INTEGER (0..65535), - end INTEGER (0..65535) } - - -- List of IP addresses - AddrList ::= SEQUENCE { - v4List IPv4List OPTIONAL, - v6List [0] IPv6List OPTIONAL } - - -- IPv4 address representations - IPv4List ::= SEQUENCE OF IPv4Range - - IPv4Range ::= SEQUENCE { -- close, but not quite right ... - ipv4Start OCTET STRING (SIZE (4)), - ipv4End OCTET STRING (SIZE (4)) } - - -- IPv6 address representations - IPv6List ::= SEQUENCE OF IPv6Range - - IPv6Range ::= SEQUENCE { -- close, but not quite right ... - ipv6Start OCTET STRING (SIZE (16)), - ipv6End OCTET STRING (SIZE (16)) } - - END - - - - - - - - - - -Kent & Seo Standards Track [Page 87] - -RFC 4301 Security Architecture for IP December 2005 - - -Appendix D: Fragment Handling Rationale - - There are three issues that must be resolved regarding processing of - (plaintext) fragments in IPsec: - - - mapping a non-initial, outbound fragment to the right SA - (or finding the right SPD entry) - - verifying that a received, non-initial fragment is authorized - for the SA via which it is received - - mapping outbound and inbound non-initial fragments to the - right SPD/cache entry, for BYPASS/DISCARD traffic - - The first and third issues arise because we need a deterministic - algorithm for mapping traffic to SAs (and SPD/cache entries). All - three issues are important because we want to make sure that - non-initial fragments that cross the IPsec boundary do not cause the - access control policies in place at the receiver (or transmitter) to - be violated. - -D.1. Transport Mode and Fragments - - First, we note that transport mode SAs have been defined to not carry - fragments. This is a carryover from RFC 2401, where transport mode - SAs always terminated at endpoints. This is a fundamental - requirement because, in the worst case, an IPv4 fragment to which - IPsec was applied might then be fragmented (as a ciphertext packet), - en route to the destination. IP fragment reassembly procedures at - the IPsec receiver would not be able to distinguish between pre-IPsec - fragments and fragments created after IPsec processing. - - For IPv6, only the sender is allowed to fragment a packet. As for - IPv4, an IPsec implementation is allowed to fragment tunnel mode - packets after IPsec processing, because it is the sender relative to - the (outer) tunnel header. However, unlike IPv4, it would be - feasible to carry a plaintext fragment on a transport mode SA, - because the fragment header in IPv6 would appear after the AH or ESP - header, and thus would not cause confusion at the receiver with - respect to reassembly. Specifically, the receiver would not attempt - reassembly for the fragment until after IPsec processing. To keep - things simple, this specification prohibits carriage of fragments on - transport mode SAs for IPv6 traffic. - - When only end systems used transport mode SAs, the prohibition on - carriage of fragments was not a problem, since we assumed that the - end system could be configured to not offer a fragment to IPsec. For - a native host implementation, this seems reasonable, and, as someone - already noted, RFC 2401 warned that a BITS implementation might have - to reassemble fragments before performing an SA lookup. (It would - - - -Kent & Seo Standards Track [Page 88] - -RFC 4301 Security Architecture for IP December 2005 - - - then apply AH or ESP and could re-fragment the packet after IPsec - processing.) Because a BITS implementation is assumed to be able to - have access to all traffic emanating from its host, even if the host - has multiple interfaces, this was deemed a reasonable mandate. - - In this specification, it is acceptable to use transport mode in - cases where the IPsec implementation is not the ultimate destination, - e.g., between two SGs. In principle, this creates a new opportunity - for outbound, plaintext fragments to be mapped to a transport mode SA - for IPsec processing. However, in these new contexts in which a - transport mode SA is now approved for use, it seems likely that we - can continue to prohibit transmission of fragments, as seen by IPsec, - i.e., packets that have an "outer header" with a non-zero fragment - offset field. For example, in an IP overlay network, packets being - sent over transport mode SAs are IP-in-IP tunneled and thus have the - necessary inner header to accommodate fragmentation prior to IPsec - processing. When carried via a transport mode SA, IPsec would not - examine the inner IP header for such traffic, and thus would not - consider the packet to be a fragment. - -D.2. Tunnel Mode and Fragments - - For tunnel mode SAs, it has always been the case that outbound - fragments might arrive for processing at an IPsec implementation. - The need to accommodate fragmented outbound packets can pose a - problem because a non-initial fragment generally will not contain the - port fields associated with a next layer protocol such as TCP, UDP, - or SCTP. Thus, depending on the SPD configuration for a given IPsec - implementation, plaintext fragments might or might not pose a - problem. - - For example, if the SPD requires that all traffic between two address - ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries - apply to this address range), then it should be easy to carry - non-initial fragments on the SA defined for this address range, since - the SPD entry implies an intent to carry ALL traffic between the - address ranges. But, if there are multiple SPD entries that could - match a fragment, and if these entries reference different subsets of - port fields (vs. ANY), then it is not possible to map an outbound - non-initial fragment to the right entry, unambiguously. (If we choose - to allow carriage of fragments on transport mode SAs for IPv6, the - problems arises in that context as well.) - - This problem largely, though not exclusively, motivated the - definition of OPAQUE as a selector value for port fields in RFC 2401. - The other motivation for OPAQUE is the observation that port fields - might not be accessible due to the prior application of IPsec. For - example, if a host applied IPsec to its traffic and that traffic - - - -Kent & Seo Standards Track [Page 89] - -RFC 4301 Security Architecture for IP December 2005 - - - arrived at an SG, these fields would be encrypted. The algorithm - specified for locating the "next layer protocol" described in RFC - 2401 also motivated use of OPAQUE to accommodate an encrypted next - layer protocol field in such circumstances. Nonetheless, the primary - use of the OPAQUE value was to match traffic selector fields in - packets that did not contain port fields (non-initial fragments), or - packets in which the port fields were already encrypted (as a result - of nested application of IPsec). RFC 2401 was ambiguous in - discussing the use of OPAQUE vs. ANY, suggesting in some places that - ANY might be an alternative to OPAQUE. - - We gain additional access control capability by defining both ANY and - OPAQUE values. OPAQUE can be defined to match only fields that are - not accessible. We could define ANY as the complement of OPAQUE, - i.e., it would match all values but only for accessible port fields. - We have therefore simplified the procedure employed to locate the - next layer protocol in this document, so that we treat ESP and AH as - next layer protocols. As a result, the notion of an encrypted next - layer protocol field has vanished, and there is also no need to worry - about encrypted port fields either. And accordingly, OPAQUE will be - applicable only to non-initial fragments. - - Since we have adopted the definitions above for ANY and OPAQUE, we - need to clarify how these values work when the specified protocol - does not have port fields, and when ANY is used for the protocol - selector. Accordingly, if a specific protocol value is used as a - selector, and if that protocol has no port fields, then the port - field selectors are to be ignored and ANY MUST be specified as the - value for the port fields. (In this context, ICMP TYPE and CODE - values are lumped together as a single port field (for IKEv2 - negotiation), as is the IPv6 Mobility Header TYPE value.) If the - protocol selector is ANY, then this should be treated as equivalent - to specifying a protocol for which no port fields are defined, and - thus the port selectors should be ignored, and MUST be set to ANY. - -D.3. The Problem of Non-Initial Fragments - - For an SG implementation, it is obvious that fragments might arrive - from end systems behind the SG. A BITW implementation also may - encounter fragments from a host or gateway behind it. (As noted - earlier, native host implementations and BITS implementations - probably can avoid the problems described below.) In the worst case, - fragments from a packet might arrive at distinct BITW or SG - instantiations and thus preclude reassembly as a solution option. - Hence, in RFC 2401 we adopted a general requirement that fragments - must be accommodated in tunnel mode for all implementations. However, - - - - - -Kent & Seo Standards Track [Page 90] - -RFC 4301 Security Architecture for IP December 2005 - - - RFC 2401 did not provide a perfect solution. The use of OPAQUE as a - selector value for port fields (a SHOULD in RFC 2401) allowed an SA - to carry non-initial fragments. - - Using the features defined in RFC 2401, if one defined an SA between - two IPsec (SG or BITW) implementations using the OPAQUE value for - both port fields, then all non-initial fragments matching the - source/destination (S/D) address and protocol values for the SA would - be mapped to that SA. Initial fragments would NOT map to this SA, if - we adopt a strict definition of OPAQUE. However, RFC 2401 did not - provide detailed guidance on this and thus it may not have been - apparent that use of this feature would essentially create a - "non-initial fragment only" SA. - - In the course of discussing the "fragment-only" SA approach, it was - noted that some subtle problems, problems not considered in RFC 2401, - would have to be avoided. For example, an SA of this sort must be - configured to offer the "highest quality" security services for any - traffic between the indicated S/D addresses (for the specified - protocol). This is necessary to ensure that any traffic captured by - the fragment-only SA is not offered degraded security relative to - what it would have been offered if the packet were not fragmented. A - possible problem here is that we may not be able to identify the - "highest quality" security services defined for use between two IPsec - implementation, since the choice of security protocols, options, and - algorithms is a lattice, not a totally ordered set. (We might safely - say that BYPASS < AH < ESP w/integrity, but it gets complicated if we - have multiple ESP encryption or integrity algorithm options.) So, one - has to impose a total ordering on these security parameters to make - this work, but this can be done locally. - - However, this conservative strategy has a possible performance - downside. If most traffic traversing an IPsec implementation for a - given S/D address pair (and specified protocol) is bypassed, then a - fragment-only SA for that address pair might cause a dramatic - increase in the volume of traffic afforded crypto processing. If the - crypto implementation cannot support high traffic rates, this could - cause problems. (An IPsec implementation that is capable of line rate - or near line rate crypto performance would not be adversely affected - by this SA configuration approach. Nonetheless, the performance - impact is a potential concern, specific to implementation - capabilities.) - - Another concern is that non-initial fragments sent over a dedicated - SA might be used to effect overlapping reassembly attacks, when - combined with an apparently acceptable initial fragment. (This sort - of attack assumes creation of bogus fragments and is not a side - effect of normal fragmentation.) This concern is easily addressed in - - - -Kent & Seo Standards Track [Page 91] - -RFC 4301 Security Architecture for IP December 2005 - - - IPv4, by checking the fragment offset value to ensure that no - non-initial fragments have a small enough offset to overlap port - fields that should be contained in the initial fragment. Recall that - the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60 - bytes, so any ports should be present in the initial fragment. If we - require all non-initial fragments to have an offset of, say, 128 or - greater, just to be on the safe side, this should prevent successful - attacks of this sort. If the intent is only to protect against this - sort of reassembly attack, this check need be implemented only by a - receiver. - - IPv6 also has a fragment offset, carried in the fragmentation - extension header. However, IPv6 extension headers are variable in - length and there is no analogous max header length value that we can - use to check non-initial fragments, to reject ones that might be used - for an attack of the sort noted above. A receiver would need to - maintain state analogous to reassembly state, to provide equivalent - protection. So, only for IPv4 is it feasible to impose a fragment - offset check that would reject attacks designed to circumvent port - field checks by IPsec (or firewalls) when passing non-initial - fragments. - - Another possible concern is that in some topologies and SPD - configurations this approach might result in an access control - surprise. The notion is that if we create an SA to carry ALL - (non-initial) fragments, then that SA would carry some traffic that - might otherwise arrive as plaintext via a separate path, e.g., a path - monitored by a proxy firewall. But, this concern arises only if the - other path allows initial fragments to traverse it without requiring - reassembly, presumably a bad idea for a proxy firewall. Nonetheless, - this does represent a potential problem in some topologies and under - certain assumptions with respect to SPD and (other) firewall rule - sets, and administrators need to be warned of this possibility. - - A less serious concern is that non-initial fragments sent over a - non-initial fragment-only SA might represent a DoS opportunity, in - that they could be sent when no valid, initial fragment will ever - arrive. This might be used to attack hosts behind an SG or BITW - device. However, the incremental risk posed by this sort of attack, - which can be mounted only by hosts behind an SG or BITW device, seems - small. - - If we interpret the ANY selector value as encompassing OPAQUE, then a - single SA with ANY values for both port fields would be able to - accommodate all traffic matching the S/D address and protocol traffic - selectors, an alternative to using the OPAQUE value. But, using ANY - - - - - -Kent & Seo Standards Track [Page 92] - -RFC 4301 Security Architecture for IP December 2005 - - - here precludes multiple, distinct SAs between the same IPsec - implementations for the same address pairs and protocol. So, it is - not an exactly equivalent alternative. - - Fundamentally, fragment handling problems arise only when more than - one SA is defined with the same S/D address and protocol selector - values, but with different port field selector values. - -D.4. BYPASS/DISCARD Traffic - - We also have to address the non-initial fragment processing issue for - BYPASS/DISCARD entries, independent of SA processing. This is - largely a local matter for two reasons: - - 1) We have no means for coordinating SPD entries for such - traffic between IPsec implementations since IKE is not - invoked. - 2) Many of these entries refer to traffic that is NOT - directed to or received from a location that is using - IPsec. So there is no peer IPsec implementation with - which to coordinate via any means. - - However, this document should provide guidance here, consistent with - our goal of offering a well-defined, access control function for all - traffic, relative to the IPsec boundary. To that end, this document - says that implementations MUST support fragment reassembly for - BYPASS/DISCARD traffic when port fields are specified. An - implementation also MUST permit a user or administrator to accept - such traffic or reject such traffic using the SPD conventions - described in Section 4.4.1. The concern is that BYPASS of a - cleartext, non-initial fragment arriving at an IPsec implementation - could undermine the security afforded IPsec-protected traffic - directed to the same destination. For example, consider an IPsec - implementation configured with an SPD entry that calls for - IPsec-protection of traffic between a specific source/destination - address pair, and for a specific protocol and destination port, e.g., - TCP traffic on port 23 (Telnet). Assume that the implementation also - allows BYPASS of traffic from the same source/destination address - pair and protocol, but for a different destination port, e.g., port - 119 (NNTP). An attacker could send a non-initial fragment (with a - forged source address) that, if bypassed, could overlap with - IPsec-protected traffic from the same source and thus violate the - integrity of the IPsec-protected traffic. Requiring stateful - fragment checking for BYPASS entries with non-trivial port ranges - prevents attacks of this sort. - - - - - - -Kent & Seo Standards Track [Page 93] - -RFC 4301 Security Architecture for IP December 2005 - - -D.5. Just say no to ports? - - It has been suggested that we could avoid the problems described - above by not allowing port field selectors to be used in tunnel mode. - But the discussion above shows this to be an unnecessarily stringent - approach, i.e., since no problems arise for the native OS and BITS - implementations. Moreover, some WG members have described scenarios - where use of tunnel mode SAs with (non-trivial) port field selectors - is appropriate. So the challenge is defining a strategy that can - deal with this problem in BITW and SG contexts. Also note that - BYPASS/DISCARD entries in the SPD that make use of ports pose the - same problems, irrespective of tunnel vs. transport mode notions. - - Some folks have suggested that a firewall behind an SG or BITW should - be left to enforce port-level access controls and the effects of - fragmentation. However, this seems to be an incongruous suggestion - in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned - about firewalls that always discard fragments. If many firewalls - don't pass fragments in general, why should we expect them to deal - with fragments in this case? So, this analysis rejects the suggestion - of disallowing use of port field selectors with tunnel mode SAs. - -D.6. Other Suggested Solutions - - One suggestion is to reassemble fragments at the sending IPsec - implementation, and thus avoid the problem entirely. This approach - is invisible to a receiver and thus could be adopted as a purely - local implementation option. - - A more sophisticated version of this suggestion calls for - establishing and maintaining minimal state from each initial fragment - encountered, to allow non-initial fragments to be matched to the - right SAs or SPD/cache entries. This implies an extension to the - current processing model (and the old one). The IPsec implementation - would intercept all fragments; capture Source/Destination IP - addresses, protocol, packet ID, and port fields from initial - fragments; and then use this data to map non-initial fragments to SAs - that require port fields. If this approach is employed, the receiver - needs to employ an equivalent scheme, as it too must verify that - received fragments are consistent with SA selector values. A - non-initial fragment that arrives prior to an initial fragment could - be cached or discarded, awaiting arrival of the corresponding initial - fragment. - - A downside of both approaches noted above is that they will not - always work. When a BITW device or SG is configured in a topology - that might allow some fragments for a packet to be processed at - different SGs or BITW devices, then there is no guarantee that all - - - -Kent & Seo Standards Track [Page 94] - -RFC 4301 Security Architecture for IP December 2005 - - - fragments will ever arrive at the same IPsec device. This approach - also raises possible processing problems. If the sender caches - non-initial fragments until the corresponding initial fragment - arrives, buffering problems might arise, especially at high speeds. - If the non-initial fragments are discarded rather than cached, there - is no guarantee that traffic will ever pass, e.g., retransmission - will result in different packet IDs that cannot be matched with prior - transmissions. In any case, housekeeping procedures will be needed - to decide when to delete the fragment state data, adding some - complexity to the system. Nonetheless, this is a viable solution in - some topologies, and these are likely to be common topologies. - - The Working Group rejected an earlier version of the convention of - creating an SA to carry only non-initial fragments, something that - was supported implicitly under the RFC 2401 model via use of OPAQUE - port fields, but never clearly articulated in RFC 2401. The - (rejected) text called for each non-initial fragment to be treated as - protocol 44 (the IPv6 fragment header protocol ID) by the sender and - receiver. This approach has the potential to make IPv4 and IPv6 - fragment handling more uniform, but it does not fundamentally change - the problem, nor does it address the issue of fragment handling for - BYPASS/DISCARD traffic. Given the fragment overlap attack problem - that IPv6 poses, it does not seem that it is worth the effort to - adopt this strategy. - -D.7. Consistency - - Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform - fragmentation prior to IPsec processing. If this fragmentation is - performed after SA lookup at the sender, there is no "mapping to the - right SA" problem. But, the receiver still needs to be able to - verify that the non-initial fragments are consistent with the SA via - which they are received. Since the initial fragment might be lost en - route, the receiver encounters all of the potential problems noted - above. Thus, if we are to be consistent in our decisions, we need to - say how a receiver will deal with the non-initial fragments that - arrive. - -D.8. Conclusions - - There is no simple, uniform way to handle fragments in all contexts. - Different approaches work better in different contexts. Thus, this - document offers 3 choices -- one MUST and two MAYs. At some point in - the future, if the community gains experience with the two MAYs, they - may become SHOULDs or MUSTs or other approaches may be proposed. - - - - - - -Kent & Seo Standards Track [Page 95] - -RFC 4301 Security Architecture for IP December 2005 - - -Appendix E: Example of Supporting Nested SAs via SPD and Forwarding - Table Entries - - This appendix provides an example of how to configure the SPD and - forwarding tables to support a nested pair of SAs, consistent with - the new processing model. For simplicity, this example assumes just - one SPD-I. - - The goal in this example is to support a transport mode SA from A to - C, carried over a tunnel mode SA from A to B. For example, A might - be a laptop connected to the public Internet, B might be a firewall - that protects a corporate network, and C might be a server on the - corporate network that demands end-to-end authentication of A's - traffic. - - +---+ +---+ +---+ - | A |=====| B | | C | - | |------------| | - | |=====| | | | - +---+ +---+ +---+ - - A's SPD contains entries of the form: - - Next Layer - Rule Local Remote Protocol Action - ---- ----- ------ ---------- ----------------------- - 1 C A ESP BYPASS - 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf) - 3 A C ANY PROTECT(ESP,transport,integr-only) - 4 A B ICMP,IKE BYPASS - - A's unprotected-side forwarding table is set so that outbound packets - destined for C are looped back to the protected side. A's - protected-side forwarding table is set so that inbound ESP packets - are looped back to the unprotected side. A's forwarding tables - contain entries of the form: - - Unprotected-side forwarding table - - Rule Local Remote Protocol Action - ---- ----- ------ -------- --------------------------- - 1 A C ANY loop back to protected side - 2 A B ANY forward to B - - - - - - - - -Kent & Seo Standards Track [Page 96] - -RFC 4301 Security Architecture for IP December 2005 - - - Protected-side forwarding table - - Rule Local Remote Protocol Action - ---- ----- ------ -------- ----------------------------- - 1 A C ESP loop back to unprotected side - - An outbound TCP packet from A to C would match SPD rule 3 and have - transport mode ESP applied to it. The unprotected-side forwarding - table would then loop back the packet. The packet is compared - against SPD-I (see Figure 2), matches SPD rule 1, and so it is - BYPASSed. The packet is treated as an outbound packet and compared - against the SPD for a third time. This time it matches SPD rule 2, - so ESP is applied in tunnel mode. This time the forwarding table - doesn't loop back the packet, because the outer destination address - is B, so the packet goes out onto the wire. - - An inbound TCP packet from C to A is wrapped in two ESP headers; the - outer header (ESP in tunnel mode) shows B as the source, whereas the - inner header (ESP transport mode) shows C as the source. Upon - arrival at A, the packet would be mapped to an SA based on the SPI, - have the outer header removed, and be decrypted and - integrity-checked. Then it would be matched against the SAD - selectors for this SA, which would specify C as the source and A as - the destination, derived from SPD rule 2. The protected-side - forwarding function would then send it back to the unprotected side - based on the addresses and the next layer protocol (ESP), indicative - of nesting. It is compared against SPD-O (see Figure 3) and found to - match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA - based on the SPI, integrity-checked, and compared against the SAD - selectors derived from SPD rule 3. The forwarding function then - passes it up to the next layer, because it isn't an ESP packet. - - - - - - - - - - - - - - - - - - - - -Kent & Seo Standards Track [Page 97] - -RFC 4301 Security Architecture for IP December 2005 - - -References - -Normative References - - [BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, - Z., and W. Weiss, "An Architecture for Differentiated - Service", RFC 2475, December 1998. - - [Bra97] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Level", BCP 14, RFC 2119, March 1997. - - [CD98] Conta, A. and S. Deering, "Internet Control Message - Protocol (ICMPv6) for the Internet Protocol Version 6 - (IPv6) Specification", RFC 2463, December 1998. - - [DH98] Deering, S., and R. Hinden, "Internet Protocol, - Version 6 (IPv6) Specification", RFC 2460, December - 1998. - - [Eas05] 3rd Eastlake, D., "Cryptographic Algorithm - Implementation Requirements For Encapsulating Security - Payload (ESP) and Authentication Header (AH)", RFC - 4305, December 2005. - - [HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2) - Protocol", RFC 4306, December 2005. - - [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)", - RFC 4303, December 2005. - - [Ken05b] Kent, S., "IP Authentication Header", RFC 4302, - December 2005. - - [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC - 1191, November 1990. - - [Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility - Support in IPv6", RFC 3775, June 2004. - - [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [Pos81b] Postel, J., "Internet Control Message Protocol", RFC - 792, September 1981. - - - - -Kent & Seo Standards Track [Page 98] - -RFC 4301 Security Architecture for IP December 2005 - - - [Sch05] Schiller, J., "Cryptographic Algorithms for use in the - Internet Key Exchange Version 2 (IKEv2)", RFC 4307, - December 2005. - - [WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight - Directory Access Protocol (v3): UTF-8 String - Representation of Distinguished Names", RFC 2253, - December 1997. - -Informative References - - [CoSa04] Condell, M., and L. Sanchez, "On the Deterministic - Enforcement of Un-ordered Security Policies", BBN - Technical Memo 1346, March 2004. - - [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. - Traina, "Generic Routing Encapsulation (GRE)", RFC - 2784, March 2000. - - [Gro02] Grossman, D., "New Terminology and Clarifications for - Diffserv", RFC 3260, April 2002. - [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast - for IP", Work in Progress, November 3, 2002. - - [HA94] Haller, N. and R. Atkinson, "On Internet - Authentication", RFC 1704, October 1994. - - [NiBlBaBL98] 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. - - [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - - [RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The - Addition of Explicit Congestion Notification (ECN) to - IP", RFC 3168, September 2001. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for - the Internet Protocol", RFC 2401, November 1998. - - [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC - 2983, October 2000. - - [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, - "The Group Domain of Interpretation", RFC 3547, July - 2003. - - - -Kent & Seo Standards Track [Page 99] - -RFC 4301 Security Architecture for IP December 2005 - - - [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group - Security Architecture", RFC 3740, March 2004. - - [RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S. - Deering, "IPv6 Flow Label Specification", RFC 3697, - March 2004. - - [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John - Wiley & Sons, New York, NY, 1994. - - [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828, - May 2000. - - [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, - "IP Payload Compression Protocol (IPComp)", RFC 3173, - September 2001. - - [ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec - Transport Mode for Dynamic Routing", RFC 3884, - September 2004. - - [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in - High-level Networks", ACM Computing Surveys, Vol. 15, - No. 2, June 1983. - -Authors' Addresses - - Stephen Kent - BBN Technologies - 10 Moulton Street - Cambridge, MA 02138 - USA - - Phone: +1 (617) 873-3988 - EMail: kent@bbn.com - - - Karen Seo - BBN Technologies - 10 Moulton Street - Cambridge, MA 02138 - USA - - Phone: +1 (617) 873-3152 - EMail: kseo@bbn.com - - - - - - -Kent & Seo Standards Track [Page 100] - -RFC 4301 Security Architecture for IP December 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Kent & Seo Standards Track [Page 101] - diff --git a/doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt b/doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt deleted file mode 100644 index fad6cea0e..000000000 --- a/doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt +++ /dev/null @@ -1,5547 +0,0 @@ - - - - - - -Network Working Group C. Kaufman, Ed. -Request for Comments: 4306 Microsoft -Obsoletes: 2407, 2408, 2409 December 2005 -Category: Standards Track - - - Internet Key Exchange (IKEv2) Protocol - -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 Internet Society (2005). - -Abstract - - This document describes version 2 of the Internet Key Exchange (IKE) - protocol. IKE is a component of IPsec used for performing mutual - authentication and establishing and maintaining security associations - (SAs). - - This version of the IKE specification combines the contents of what - were previously separate documents, including Internet Security - Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC - 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network - Address Translation (NAT) Traversal, Legacy authentication, and - remote address acquisition. - - Version 2 of IKE does not interoperate with version 1, but it has - enough of the header format in common that both versions can - unambiguously run over the same UDP port. - - - - - - - - - - - - - - -Kaufman Standards Track [Page 1] - -RFC 4306 IKEv2 December 2005 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Usage Scenarios ............................................5 - 1.2. The Initial Exchanges ......................................7 - 1.3. The CREATE_CHILD_SA Exchange ...............................9 - 1.4. The INFORMATIONAL Exchange ................................11 - 1.5. Informational Messages outside of an IKE_SA ...............12 - 2. IKE Protocol Details and Variations ............................12 - 2.1. Use of Retransmission Timers ..............................13 - 2.2. Use of Sequence Numbers for Message ID ....................14 - 2.3. Window Size for Overlapping Requests ......................14 - 2.4. State Synchronization and Connection Timeouts .............15 - 2.5. Version Numbers and Forward Compatibility .................17 - 2.6. Cookies ...................................................18 - 2.7. Cryptographic Algorithm Negotiation .......................21 - 2.8. Rekeying ..................................................22 - 2.9. Traffic Selector Negotiation ..............................24 - 2.10. Nonces ...................................................26 - 2.11. Address and Port Agility .................................26 - 2.12. Reuse of Diffie-Hellman Exponentials .....................27 - 2.13. Generating Keying Material ...............................27 - 2.14. Generating Keying Material for the IKE_SA ................28 - 2.15. Authentication of the IKE_SA .............................29 - 2.16. Extensible Authentication Protocol Methods ...............31 - 2.17. Generating Keying Material for CHILD_SAs .................33 - 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34 - 2.19. Requesting an Internal Address on a Remote Network .......34 - 2.20. Requesting the Peer's Version ............................35 - 2.21. Error Handling ...........................................36 - 2.22. IPComp ...................................................37 - 2.23. NAT Traversal ............................................38 - 2.24. Explicit Congestion Notification (ECN) ...................40 - 3. Header and Payload Formats .....................................41 - 3.1. The IKE Header ............................................41 - 3.2. Generic Payload Header ....................................44 - 3.3. Security Association Payload ..............................46 - 3.4. Key Exchange Payload ......................................56 - 3.5. Identification Payloads ...................................56 - 3.6. Certificate Payload .......................................59 - 3.7. Certificate Request Payload ...............................61 - 3.8. Authentication Payload ....................................63 - 3.9. Nonce Payload .............................................64 - 3.10. Notify Payload ...........................................64 - 3.11. Delete Payload ...........................................72 - 3.12. Vendor ID Payload ........................................73 - 3.13. Traffic Selector Payload .................................74 - 3.14. Encrypted Payload ........................................77 - - - -Kaufman Standards Track [Page 2] - -RFC 4306 IKEv2 December 2005 - - - 3.15. Configuration Payload ....................................79 - 3.16. Extensible Authentication Protocol (EAP) Payload .........84 - 4. Conformance Requirements .......................................85 - 5. Security Considerations ........................................88 - 6. IANA Considerations ............................................90 - 7. Acknowledgements ...............................................91 - 8. References .....................................................91 - 8.1. Normative References ......................................91 - 8.2. Informative References ....................................92 - Appendix A: Summary of Changes from IKEv1 .........................96 - Appendix B: Diffie-Hellman Groups .................................97 - B.1. Group 1 - 768 Bit MODP ....................................97 - B.2. Group 2 - 1024 Bit MODP ...................................97 - -1. Introduction - - 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 of IKE. Version 1 of IKE was - defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. 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 [RFC4301]. - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and - "MAY" that appear in this document are to be interpreted as described - in [Bra97]. - - The term "Expert Review" is to be interpreted as defined in - [RFC2434]. - - 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) [RFC4303] and/or Authentication - Header (AH) [RFC4302] 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 - - - -Kaufman Standards Track [Page 3] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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. - - - - - - -Kaufman Standards Track [Page 4] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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 [RFC4301]. 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 [RFC1958], - - - -Kaufman Standards Track [Page 5] - -RFC 4306 IKEv2 December 2005 - - - [RFC2775], and a method of limiting the inherent problems with - complexity in networks noted by [RFC3439]. 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). - -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. In support of the latter case, IKEv2 includes a mechanism - 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. - - - -Kaufman Standards Track [Page 6] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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 - - - -Kaufman Standards Track [Page 7] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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. - - - -Kaufman Standards Track [Page 8] - -RFC 4306 IKEv2 December 2005 - - - 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. - -1.3. The CREATE_CHILD_SA Exchange - - This exchange consists of a single request/response pair, and 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". - - Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this - section the term "initiator" refers to the endpoint initiating this - exchange. - - - - -Kaufman Standards Track [Page 9] - -RFC 4306 IKEv2 December 2005 - - - A CHILD_SA is created by sending a CREATE_CHILD_SA request. 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). - - In the CHILD_SA created as part of the initial exchange, a second KE - payload and nonce MUST NOT be sent. The nonces from the initial - exchange are used in computing the keys for the CHILD_SA. - - The CREATE_CHILD_SA request contains: - - 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 in the TSi and TSr payloads. If this - CREATE_CHILD_SA exchange is rekeying an existing SA other than the - IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA - being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an - existing SA, the N payload MUST be omitted. If the SA offers include - different Diffie-Hellman groups, KEi MUST be an element of the group - the initiator expects the responder to accept. If it guesses wrong, - the CREATE_CHILD_SA exchange will fail, and it will have to retry - with a different KEi. - - 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 response contains: - - <-- 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. If the responder chooses a - cryptographic suite with a different group, it MUST reject the - request. The initiator SHOULD repeat the request, but now with a KEi - payload from the group the responder selected. - - - -Kaufman Standards Track [Page 10] - -RFC 4306 IKEv2 December 2005 - - - The traffic selectors for traffic to be sent on that SA are specified - in the TS payloads, which may be a subset of what the initiator of - the CHILD_SA proposed. Traffic selectors are omitted if this - CREATE_CHILD_SA request is being used to change the key of the - IKE_SA. - -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. - - 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. 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. 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 - - - - -Kaufman Standards Track [Page 11] - -RFC 4306 IKEv2 December 2005 - - - 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. - - A node SHOULD regard half-closed connections as anomalous and audit - their existence should 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. - - 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. - -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 - - - - -Kaufman Standards Track [Page 12] - -RFC 4306 IKEv2 December 2005 - - - 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 [KPS03]. 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. IKEv2 implementations SHOULD 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. Implementations and configuration should 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. - -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). - - - - -Kaufman Standards Track [Page 13] - -RFC 4306 IKEv2 December 2005 - - - 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. The IKE_SA initial setup messages will - always be numbered 0 and 1. 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. - - 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 - - - - -Kaufman Standards Track [Page 14] - -RFC 4306 IKEv2 December 2005 - - - it has a request outstanding in order to avoid a deadlock in this - situation. An IKE endpoint SHOULD be prepared to 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 SHOULD be - capable of processing incoming requests out of order to maximize - performance in the event of network failures or packet reordering. - -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 - 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. 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 - - - -Kaufman Standards Track [Page 15] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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. - - - - -Kaufman Standards Track [Page 16] - -RFC 4306 IKEv2 December 2005 - - - 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. - 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. - -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 zero. It is likely that - some implementations will want to support both 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, - 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 - - - - - -Kaufman Standards Track [Page 17] - -RFC 4306 IKEv2 December 2005 - - - 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. 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 a version 2.0 implementation and their content MUST be - ignored by a version 2.0 implementation ("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 version 2.0 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. - - 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 - SHOULD reject as invalid a message with those payloads in any other - order. - -2.6. Cookies - - The term "cookies" originates with Karn and Simpson [RFC2522] in - Photuris, an early proposal for key management with IPsec, and it has - persisted. The Internet Security Association and Key Management - Protocol (ISAKMP) [MSST98] 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. Each endpoint - - - - -Kaufman Standards Track [Page 18] - -RFC 4306 IKEv2 December 2005 - - - chooses one of the two SPIs and SHOULD 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. 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 - 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} - - - - -Kaufman Standards Track [Page 19] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) - - where <secret> is a randomly generated secret known only to the - responder and periodically changed and | indicates concatenation. - <VersionIDofSecret> should be changed whenever <secret> 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 <secret> 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 <secret> is chosen while there are connections in - the process of being initialized, an IKE_SA_INIT might be returned - with other than the current <VersionIDofSecret>. 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 <secret> around for a - short time and accept cookies computed from either one. The - responder SHOULD NOT accept cookies indefinitely after <secret> is - changed, since that would defeat part of the denial of service - protection. The responder SHOULD change the value of <secret> - frequently, especially if under attack. - - - - - - - - -Kaufman Standards Track [Page 20] - -RFC 4306 IKEv2 December 2005 - - -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 - 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. - - - - -Kaufman Standards Track [Page 21] - -RFC 4306 IKEv2 December 2005 - - -2.8. Rekeying - - 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. - 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. - - 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 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. It SHOULD do so if there has been no traffic - since the last time the SA was rekeyed. - - - -Kaufman Standards Track [Page 22] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 [RFC2474], [RFC2475], and section 4.1 of [RFC2983]). - 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. - - 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 SHOULD continue to - send messages on the old SA until one of those events occurs. When - establishing a new SA, the responder MAY defer sending messages on a - - - -Kaufman Standards Track [Page 23] - -RFC 4306 IKEv2 December 2005 - - - new SA until either it receives one or a timeout has occurred. If an - initiator receives a message on an SA for which it has not received a - response 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. - -2.9. Traffic Selector Negotiation - - When an IP packet is received by an RFC4301-compliant IPsec subsystem - and matches a "protect" selector in its Security Policy Database - (SPD), the subsystem MUST protect 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. - - 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 - - - -Kaufman Standards Track [Page 24] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 - - - - -Kaufman Standards Track [Page 25] - -RFC 4306 IKEv2 December 2005 - - - 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. Such misconfigurations SHOULD be recorded in error logs. - -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.) 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. - - - - - -Kaufman Standards Track [Page 26] - -RFC 4306 IKEv2 December 2005 - - -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 - the IKE_SA and the CHILD_SAs. - - - - -Kaufman Standards Track [Page 27] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 - - - -Kaufman Standards Track [Page 28] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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 - - - -Kaufman Standards Track [Page 29] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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.) The pre- - shared key SHOULD 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"), <msg octets>) - - 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 - - - -Kaufman Standards Track [Page 30] - -RFC 4306 IKEv2 December 2005 - - - 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. If the negotiated prf takes a - fixed-size key, the shared secret MUST be of that fixed size. - -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 - 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: - - - - - - - - - - - - - - -Kaufman Standards Track [Page 31] - -RFC 4306 IKEv2 December 2005 - - - 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 } - - 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. - - The initiator of an IKE_SA using EAP SHOULD 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. - - - - - -Kaufman Standards Track [Page 32] - -RFC 4306 IKEv2 December 2005 - - - Following such an extended exchange, the EAP AUTH payloads MUST be - included in the two messages following the one containing the EAP - Success message. - -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), - 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: - - All keys for SAs carrying data from the initiator to the responder - are taken before SAs going in the reverse direction. - - If multiple IPsec protocols are negotiated, keying material is - taken in the order in which the protocol headers will appear in - the encapsulated packet. - - 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. - - - - -Kaufman Standards Track [Page 33] - -RFC 4306 IKEv2 December 2005 - - -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). New initiator and responder SPIs are supplied in - the SPI fields. 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. - - 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} - - - -Kaufman Standards Track [Page 34] - -RFC 4306 IKEv2 December 2005 - - - 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(0.0.0.0) - INTERNAL_NETMASK(0.0.0.0) - INTERNAL_DNS(0.0.0.0) - 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.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. - - - -Kaufman Standards Track [Page 35] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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 - - - -Kaufman Standards Track [Page 36] - -RFC 4306 IKEv2 December 2005 - - - tricked into sending. 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. The recipient MUST NOT change - the state of any SA's as a result but SHOULD 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 - "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. - - - - - - -Kaufman Standards Track [Page 37] - -RFC 4306 IKEv2 December 2005 - - -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. - - - - - - -Kaufman Standards Track [Page 38] - -RFC 4306 IKEv2 December 2005 - - - 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, so an IPsec endpoint that discovers a NAT between it and - its correspondent MUST send all subsequent traffic to and from port - 4500, which NATs should not treat specially (as they might with port - 500). - - The specific requirements for supporting NAT traversal [RFC3715] are - listed below. Support for NAT traversal is optional. In this - section only, requirements listed as MUST apply only to - implementations supporting NAT traversal. - - IKE MUST listen on port 4500 as well as port 500. IKE MUST - respond to the IP address and port from which packets arrived. - - 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). - - 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. - - - - - - -Kaufman Standards Track [Page 39] - -RFC 4306 IKEv2 December 2005 - - - 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 [Hutt05]. - - 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. 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. - - The original source and destination IP address required for the - transport mode TCP and UDP packet checksum fixup (see [Hutt05]) - 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. - - 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 [RFC2401], 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 - - - -Kaufman Standards Track [Page 40] - -RFC 4306 IKEv2 December 2005 - - - [RFC3168]). 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 [RFC3168] and MUST - implement the tunnel encapsulation and decapsulation processing - specified in [RFC4301] 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 - 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. - - - - - - - - -Kaufman Standards Track [Page 41] - -RFC 4306 IKEv2 December 2005 - - - 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) and MUST NOT be zero in any other message. - - 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 Standards Track [Page 42] - -RFC 4306 IKEv2 December 2005 - - - 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 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. - - - - - - - -Kaufman Standards Track [Page 43] - -RFC 4306 IKEv2 December 2005 - - - 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 sections 2.1 and 2.2. - - o Length (4 octets) - Length of total message (header + payloads) - in octets. - -3.2. Generic Payload Header - - Each IKE payload defined in sections 3.3 through 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). - - Payload Type Values - - Next Payload Type Notation Value - - No Next Payload 0 - - RESERVED 1-32 - Security Association SA 33 - Key Exchange KE 34 - Identification - Initiator IDi 35 - - - -Kaufman Standards Track [Page 44] - -RFC 4306 IKEv2 December 2005 - - - 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 used so that there is no - overlap with the code assignments for IKEv1. Payload type values - 49-127 are reserved to IANA for future assignment in IKEv2 (see - section 6). Payload type values 128-255 are for private use among - mutually consenting parties. - - 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 Standards Track [Page 45] - -RFC 4306 IKEv2 December 2005 - - -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 - 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 - - - -Kaufman Standards Track [Page 46] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Proposals> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: Security Association Payload - - - -Kaufman Standards Track [Page 47] - -RFC 4306 IKEv2 December 2005 - - - 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) ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Transforms> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - 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 4 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 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. - - - - - - -Kaufman Standards Track [Page 48] - -RFC 4306 IKEv2 December 2005 - - - 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. - -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 - - - - -Kaufman Standards Track [Page 49] - -RFC 4306 IKEv2 December 2005 - - - value (3) corresponds to a Payload Type of Transform in IKEv1, - and the first 4 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. - - Transform Type Values - - Transform 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) - - - -Kaufman Standards Track [Page 50] - -RFC 4306 IKEv2 December 2005 - - - ENCR_DES_IV32 9 - RESERVED 10 - ENCR_NULL 11 (RFC2410) - ENCR_AES_CBC 12 (RFC3602) - ENCR_AES_CTR 13 (RFC3664) - - values 14-1023 are reserved to IANA. Values 1024-65535 are - for private use among mutually consenting parties. - - 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) - - values 5-1023 are reserved to IANA. Values 1024-65535 are for - private use among mutually consenting parties. - - 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 - AUTH_KPDK_MD5 4 (RFC1826) - AUTH_AES_XCBC_96 5 (RFC3566) - - values 6-1023 are reserved to IANA. Values 1024-65535 are for - private use among mutually consenting parties. - - 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 - - - -Kaufman Standards Track [Page 51] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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 - - - -Kaufman Standards Track [Page 52] - -RFC 4306 IKEv2 December 2005 - - - management interface via 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. - -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. - - - - -Kaufman Standards Track [Page 53] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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. 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. - - 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. Values 18-16383 - are reserved to IANA. Values 16384-32767 are for private use among - mutually consenting parties. - - - 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 Standards Track [Page 54] - -RFC 4306 IKEv2 December 2005 - - -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. - - 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". - - - - - - - - - - -Kaufman Standards Track [Page 55] - -RFC 4306 IKEv2 December 2005 - - -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. - - 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. - - 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). - - - - - - -Kaufman Standards Track [Page 56] - -RFC 4306 IKEv2 December 2005 - - - 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. - - The following table lists the assigned values for the Identification - Type field, followed by a description of the Identification Data - which follows: - - 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.). - - - - - -Kaufman Standards Track [Page 57] - -RFC 4306 IKEv2 December 2005 - - - 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 - - Reserved for 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. - IPv6-capable implementations MUST additionally be configurable to - accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable - to send only ID_IPV6_ADDR. - - - - - - - - -Kaufman Standards Track [Page 58] - -RFC 4306 IKEv2 December 2005 - - -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. - - 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 - - - -Kaufman Standards Track [Page 59] - -RFC 4306 IKEv2 December 2005 - - - 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: - - X.509 Certificate - Signature (4) contains a DER encoded X.509 - certificate whose public key is used to validate the sender's AUTH - payload. - - Certificate Revocation List (7) contains a DER encoded X.509 - certificate revocation list. - - Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and - [PKCS1]). - - 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 [KPS03]. - - 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) } ; - - - - - - -Kaufman Standards Track [Page 60] - -RFC 4306 IKEv2 December 2005 - - - 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. - -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. - - - - - - -Kaufman Standards Track [Page 61] - -RFC 4306 IKEv2 December 2005 - - - 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 [RFC3280]) from each Trust Anchor - certificate. The twenty-octet hashes are concatenated and included - with no other formatting. - - 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: - - - is configured to use certificate authentication, - - - is allowed to send a CERT payload, - - - has matching CA trust policy governing the current negotiation, and - - - 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. - - - -Kaufman Standards Track [Page 62] - -RFC 4306 IKEv2 December 2005 - - - 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.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]). - - 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. - - - - -Kaufman Standards Track [Page 63] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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. - - - - - - -Kaufman Standards Track [Page 64] - -RFC 4306 IKEv2 December 2005 - - - The Notify 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 ! 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. For notifications that do not - relate to an existing SA, 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). - - - - - - - - -Kaufman Standards Track [Page 65] - -RFC 4306 IKEv2 December 2005 - - -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. - 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. Unrecognized error types - in a request and status types in a request or response MUST be - ignored except that 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 - - - -Kaufman Standards Track [Page 66] - -RFC 4306 IKEv2 December 2005 - - - 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. To aid debugging, more - detailed error 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 be used by the recipient - only 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. - - - - -Kaufman Standards Track [Page 67] - -RFC 4306 IKEv2 December 2005 - - - 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 - - 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 - Error types 40 - 8191 - - Private Use - Errors 8192 - 16383 - - - -Kaufman Standards Track [Page 68] - -RFC 4306 IKEv2 December 2005 - - - 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). - - 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 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. - - - -Kaufman Standards Track [Page 69] - -RFC 4306 IKEv2 December 2005 - - - 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 - - values 5-240 are reserved to IANA. Values 241-255 are - for private use among mutually consenting parties. - - 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, 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 [Hutt05]. Alternately, it MAY reject the connection - attempt if NAT traversal is not supported. - - - - - - - - -Kaufman Standards Track [Page 70] - -RFC 4306 IKEv2 December 2005 - - - 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 - [RFC4301] 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 - - 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. 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. - - - - -Kaufman Standards Track [Page 71] - -RFC 4306 IKEv2 December 2005 - - - NON_FIRST_FRAGMENTS_ALSO 16395 - - Used for fragmentation control. See [RFC4301] for - explanation. - - RESERVED TO IANA - STATUS TYPES 16396 - 40959 - - Private Use - STATUS TYPES 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 a 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. - - - - - - -Kaufman Standards Track [Page 72] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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. - - - - - - - - - - -Kaufman Standards Track [Page 73] - -RFC 4306 IKEv2 December 2005 - - - 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: - - 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 ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ! ! - ~ <Traffic Selectors> ~ - ! ! - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 19: Traffic Selectors Payload Format - - o Number of TSs (1 octet) - Number of traffic selectors being - provided. - - - -Kaufman Standards Track [Page 74] - -RFC 4306 IKEv2 December 2005 - - - 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. - -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. - - - - - -Kaufman Standards Track [Page 75] - -RFC 4306 IKEv2 December 2005 - - - 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 [RFC4301] that wish to indicate "ANY" - ports MUST set the start port to 0 and the end port to 65535; note - that according to [RFC4301], "ANY" includes "OPAQUE". Systems - working with [RFC4301] that wish to indicate "OPAQUE" ports, but not - "ANY" ports, MUST set the start port to 65535 and the end port to 0. - - 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. - - - - - - - -Kaufman Standards Track [Page 76] - -RFC 4306 IKEv2 December 2005 - - - 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 - sections 2.14 and 2.18. - - The encryption and integrity protection algorithms are modeled after - the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303], - 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 Standards Track [Page 77] - -RFC 4306 IKEv2 December 2005 - - - 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 Standards Track [Page 78] - -RFC 4306 IKEv2 December 2005 - - - 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. - - - - -Kaufman Standards Track [Page 79] - -RFC 4306 IKEv2 December 2005 - - - 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 - 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. - - 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 Standards Track [Page 80] - -RFC 4306 IKEv2 December 2005 - - - 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 - - values 5-127 are reserved to IANA. Values 128-255 are for private - use among mutually consenting parties. - - 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. - - - - - -Kaufman Standards Track [Page 81] - -RFC 4306 IKEv2 December 2005 - - - The following attribute types have been defined: - - 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 - - * These attributes may be multi-valued on return only if multiple - values were requested. - - Types 16-16383 are reserved to IANA. Values 16384-32767 are for - private use among mutually consenting parties. - - 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. - In a request message, the address specified is a requested - address (or zero 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 sixteen-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. - - - - -Kaufman Standards Track [Page 82] - -RFC 4306 IKEv2 December 2005 - - - 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. - - 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. - - 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. - - 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 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. - - 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. - - - - - - - - - -Kaufman Standards Track [Page 83] - -RFC 4306 IKEv2 December 2005 - - - 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 sixteen-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.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). - - 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). - - - -Kaufman Standards Track [Page 84] - -RFC 4306 IKEv2 December 2005 - - - 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]. - - 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 SHOULD, 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. - - - - - - - -Kaufman Standards Track [Page 85] - -RFC 4306 IKEv2 December 2005 - - - 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: - - Ability to negotiate SAs through a NAT and tunnel the resulting - ESP SA over UDP. - - Ability to request (and respond to a request for) a temporary IP - address on the remote end of a tunnel. - - Ability to support various types of legacy authentication. - - Ability to support window sizes greater than one. - - Ability to establish multiple ESP and/or AH SAs within a single - IKE_SA. - - 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 closing the old SA and creating a new one. - - - - -Kaufman Standards Track [Page 86] - -RFC 4306 IKEv2 December 2005 - - - 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. The responder SHOULD include all of the other related - attributes if it has them. - - 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. The only attribute - it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must - use to bound the lifetime of the SA unless it successfully renews the - lease before it expires. 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: - - 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. - - Shared key authentication where the ID passes is any of ID_KEY_ID, - ID_FQDN, or ID_RFC822_ADDR. - - Authentication where the responder is authenticated using PKIX - Certificates and the initiator is authenticated using shared key - authentication. - - - - - - - - - - -Kaufman Standards Track [Page 87] - -RFC 4306 IKEv2 December 2005 - - -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 Standards Track [Page 88] - -RFC 4306 IKEv2 December 2005 - - - 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 [RFC4086]). 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 Standards Track [Page 89] - -RFC 4306 IKEv2 December 2005 - - - 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. 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 - 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 [KPS03]. - -6. IANA Considerations - - This document defines a number of new field types and values where - future assignments will be managed by the IANA. - - The following registries have been created by the IANA: - - IKEv2 Exchange Types (section 3.1) - IKEv2 Payload Types (section 3.2) - IKEv2 Transform Types (section 3.3.2) - IKEv2 Transform Attribute Types (section 3.3.2) - IKEv2 Encryption Transform IDs (section 3.3.2) - IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) - IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) - - - -Kaufman Standards Track [Page 90] - -RFC 4306 IKEv2 December 2005 - - - IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) - IKEv2 Identification Payload ID Types (section 3.5) - IKEv2 Certificate Encodings (section 3.6) - IKEv2 Authentication Method (section 3.8) - IKEv2 Notify Message Types (section 3.10.1) - IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) - IKEv2 Security Protocol Identifiers (section 3.3.1) - IKEv2 Traffic Selector Types (section 3.13.1) - IKEv2 Configuration Payload CFG Types (section 3.15) - IKEv2 Configuration Payload Attribute Types (section 3.15.1) - - Note: When creating a new Transform Type, a new registry for it must - be created. - - Changes and additions to any of those registries are by expert - review. - -7. Acknowledgements - - 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. - -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. - - [Bra97] Bradner, S., "Key Words for use in RFCs to indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - - - -Kaufman Standards Track [Page 91] - -RFC 4306 IKEv2 December 2005 - - - [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. - Levkowetz, "Extensible Authentication Protocol (EAP)", RFC - 3748, June 2004. - - [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - [Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. - Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC - 3948, January 2005. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition - of Explicit Congestion Notification (ECN) to IP", RFC - 3168, September 2001. - - [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. - - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. - -8.2. Informative References - - [DES] ANSI X3.106, "American National Standard for Information - Systems-Data Link Encryption", American National Standards - Institute, 1983. - - [DH] Diffie, W., and Hellman M., "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. - - [DSS] NIST, "Digital Signature Standard", FIPS 186, National - Institute of Standards and Technology, U.S. Department of - Commerce, May, 1994. - - [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle - in Tunneled Authentication Protocols", - http://eprint.iacr.org/2002/163, November 2002. - - - - -Kaufman Standards Track [Page 92] - -RFC 4306 IKEv2 December 2005 - - - [HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IDEA] Lai, X., "On the Design and Security of Block Ciphers," - ETH Series in Information Processing, v. 1, Konstanz: - Hartung-Gorre Verlag, 1992. - - [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP - Payload Compression Protocol (IPComp)", RFC 3173, - September 2001. - - [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS - protection for UDP-based protocols", ACM Conference on - Computer and Communications Security, October 2003. - - [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February - 1997. - - [LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory - Access Protocol (v3)", RFC 2251, December 1997. - - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, - "Internet Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, November 1998. - - [Orm96] 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. - - [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography - Standards (PKCS) #1: RSA Cryptography Specifications - Version 2.1", RFC 3447, February 2003. - - [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key - exchange Standard", WET-ICE Security Conference, MIT,2001, - http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. - - [Pip98] Piper, D., "The Internet IP Security Domain Of - Interpretation for ISAKMP", RFC 2407, November 1998. - - - - - - -Kaufman Standards Track [Page 93] - -RFC 4306 IKEv2 December 2005 - - - [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, - "Remote Authentication Dial In User Service (RADIUS)", RFC - 2865, June 2000. - - [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, - June 2005. - - [RFC1958] Carpenter, B., "Architectural Principles of the Internet", - RFC 1958, June 1996. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC2474] 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. - - [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., - and W. Weiss, "An Architecture for Differentiated - Service", RFC 2475, December 1998. - - [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management - Protocol", RFC 2522, March 1999. - - [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February - 2000. - - [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC - 2983, October 2000. - - [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural - Guidelines and Philosophy", RFC 3439, December 2002. - - [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation - (NAT) Compatibility Requirements", RFC 3715, March 2004. - - [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December - 2005. - - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - 4303, December 2005. - - [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for - Obtaining Digital Signatures and Public-Key - Cryptosystems", Communications of the ACM, v. 21, n. 2, - February 1978. - - - -Kaufman Standards Track [Page 94] - -RFC 4306 IKEv2 December 2005 - - - [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National - Institute of Standards and Technology, U.S. Department of - Commerce, May 1994. - - [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to - Authenticated Diffie-Hellman and its Use in the IKE - Protocols", in Advances in Cryptography - CRYPTO 2003 - Proceedings, LNCS 2729, Springer, 2003. Available at: - http://www.informatik.uni-trier.de/~ley/db/conf/ - crypto/crypto2003.html. - - [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange - Mechanism for Internet", from IEEE Proceedings of the 1996 - Symposium on Network and Distributed Systems Security. - - [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, June 1997. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kaufman Standards Track [Page 95] - -RFC 4306 IKEv2 December 2005 - - -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 [PK01]; - - 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, to make it easier to - make future revisions that do not break backward compatibility; - - - -Kaufman Standards Track [Page 96] - -RFC 4306 IKEv2 December 2005 - - - 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 [Orm96]. - - 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 Standards Track [Page 97] - -RFC 4306 IKEv2 December 2005 - - -Editor's Address - - Charlie Kaufman - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052 - - Phone: 1-425-707-3335 - EMail: charliek@microsoft.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kaufman Standards Track [Page 98] - -RFC 4306 IKEv2 December 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Kaufman Standards Track [Page 99] - diff --git a/doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt b/doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt deleted file mode 100644 index 5617a2551..000000000 --- a/doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -Network Working Group J. Schiller -Request for Comments: 4307 Massachusetts Institute of Technology -Category: Standards Track December 2005 - - - Cryptographic Algorithms for Use in the - Internet Key Exchange Version 2 (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 Internet Society (2005). - -Abstract - - The IPsec series of protocols makes use of various cryptographic - algorithms in order to provide security services. The Internet Key - Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate - which algorithms should be used in any given association. However, - to ensure interoperability between disparate implementations, it is - necessary to specify a set of mandatory-to-implement algorithms to - ensure that there is at least one algorithm that all implementations - will have available. This document defines the current set of - algorithms that are mandatory to implement as part of IKEv2, as well - as algorithms that should be implemented because they may be promoted - to mandatory at some future time. - -1. Introduction - - The Internet Key Exchange protocol provides for the negotiation of - cryptographic algorithms between both endpoints of a cryptographic - - association. Different implementations of IPsec and IKE may provide - different algorithms. However, the IETF desires that all - implementations should have some way to interoperate. In particular, - this requires that IKE define a set of mandatory-to-implement - algorithms because IKE itself uses such algorithms as part of its own - negotiations. This requires that some set of algorithms be specified - as "mandatory-to-implement" for IKE. - - - - - -Schiller Standards Track [Page 1] - -RFC 4307 IKEv2 Cryptographic Algorithms December 2005 - - - The nature of cryptography is that new algorithms surface - continuously and existing algorithms are continuously attacked. An - algorithm believed to be strong today may be demonstrated to be weak - tomorrow. Given this, the choice of mandatory-to-implement algorithm - should be conservative so as to minimize the likelihood of it being - compromised quickly. Thought should also be given to performance - considerations as many uses of IPsec will be in environments where - performance is a concern. - - Finally, we need to recognize that the mandatory-to-implement - algorithm(s) may need to change over time to adapt to the changing - world. For this reason, the selection of mandatory-to-implement - algorithms was removed from the main IKEv2 specification and placed - in this document. As the choice of algorithm changes, only this - document should need to be updated. - - Ideally, the mandatory-to-implement algorithm of tomorrow should - already be available in most implementations of IPsec by the time it - is made mandatory. To facilitate this, we will attempt to identify - those algorithms (that are known today) in this document. There is - no guarantee that the algorithms we believe today may be mandatory in - the future will in fact become so. All algorithms known today are - subject to cryptographic attack and may be broken in the future. - -2. Requirements Terminology - - Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and - "MAY" that appear in this document are to be interpreted as described - in [RFC2119]. - - We define some additional terms here: - - SHOULD+ This term means the same as SHOULD. However, it is likely - that an algorithm marked as SHOULD+ will be promoted at - some future time to be a MUST. - - SHOULD- This term means the same as SHOULD. However, an algorithm - marked as SHOULD- may be deprecated to a MAY in a future - version of this document. - - MUST- This term means the same as MUST. However, we expect at - some point that this algorithm will no longer be a MUST in - a future document. Although its status will be determined - at a later time, it is reasonable to expect that if a - future revision of a document alters the status of a MUST- - algorithm, it will remain at least a SHOULD or a SHOULD-. - - - - - -Schiller Standards Track [Page 2] - -RFC 4307 IKEv2 Cryptographic Algorithms December 2005 - - -3. Algorithm Selection - -3.1. IKEv2 Algorithm Selection - -3.1.1. Encrypted Payload Algorithms - - The IKEv2 Encrypted Payload requires both a confidentiality algorithm - and an integrity algorithm. For confidentiality, implementations - MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For - integrity, HMAC-SHA1 MUST be implemented. - -3.1.2. Diffie-Hellman Groups - - There are several Modular Exponential (MODP) groups that are defined - for use in IKEv2. They are defined in both the [IKEv2] base document - and in the MODP extensions document. They are identified by group - number. Any groups not listed here are considered as "MAY be - implemented". - - Group Number Bit Length Status Defined - 2 1024 MODP Group MUST- [RFC2409] - 14 2048 MODP Group SHOULD+ [RFC3526] - -3.1.3. IKEv2 Transform Type 1 Algorithms - - IKEv2 defines several possible algorithms for Transfer Type 1 - (encryption). These are defined below with their implementation - status. - - Name Number Defined In Status - RESERVED 0 - ENCR_3DES 3 [RFC2451] MUST- - ENCR_NULL 11 [RFC2410] MAY - ENCR_AES_CBC 12 [AES-CBC] SHOULD+ - ENCR_AES_CTR 13 [AES-CTR] SHOULD - -3.1.4. IKEv2 Transform Type 2 Algorithms - - Transfer Type 2 Algorithms are pseudo-random functions used to - generate random values when needed. - - Name Number Defined In Status - RESERVED 0 - PRF_HMAC_MD5 1 [RFC2104] MAY - PRF_HMAC_SHA1 2 [RFC2104] MUST - PRF_AES128_CBC 4 [AESPRF] SHOULD+ - - - - - -Schiller Standards Track [Page 3] - -RFC 4307 IKEv2 Cryptographic Algorithms December 2005 - - -3.1.5. IKEv2 Transform Type 3 Algorithms - - Transfer Type 3 Algorithms are Integrity algorithms used to protect - data against tampering. - - Name Number Defined In Status - NONE 0 - AUTH_HMAC_MD5_96 1 [RFC2403] MAY - AUTH_HMAC_SHA1_96 2 [RFC2404] MUST - AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+ - -4. Security Considerations - - The security of cryptographic-based systems depends on both the - strength of the cryptographic algorithms chosen and the strength of - the keys used with those algorithms. The security also depends on - the engineering of the protocol used by the system to ensure that - there are no non-cryptographic ways to bypass the security of the - overall system. - - This document concerns itself with the selection of cryptographic - algorithms for the use of IKEv2, specifically with the selection of - "mandatory-to-implement" algorithms. The algorithms identified in - this document as "MUST implement" or "SHOULD implement" are not known - to be broken at the current time, and cryptographic research so far - leads us to believe that they will likely remain secure into the - foreseeable future. However, this isn't necessarily forever. We - would therefore expect that new revisions of this document will be - issued from time to time that reflect the current best practice in - this area. - -5. Normative References - - [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange - (IKE)", RFC 2409, November 1998. - - [IKEv2] Kaufman, C., Ed., "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. - - [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential - (MODP) Diffie-Hellman groups for Internet Key Exchange - (IKE)", RFC 3526, May 2003. - - [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, November 1998. - - - -Schiller Standards Track [Page 4] - -RFC 4307 IKEv2 Cryptographic Algorithms December 2005 - - - [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm - and Its Use With IPsec", RFC 2410, November 1998. - - [AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC - Cipher Algorithm and Its Use with IPsec", RFC 3602, - September 2003. - - [AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES) - Counter Mode With IPsec Encapsulating Security Payload - (ESP)", RFC 3686, January 2004. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the - Internet Key Exchange Protocol (IKE)", RFC 3664, January - 2004. - - [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within - ESP and AH", RFC 2403, November 1998. - - [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 - within ESP and AH", RFC 2404, November 1998. - - [AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 - Algorithm and Its Use With IPsec", RFC 3566, September - 2003. - -Author's Address - - Jeffrey I. Schiller - Massachusetts Institute of Technology - Room W92-190 - 77 Massachusetts Avenue - Cambridge, MA 02139-4307 - USA - - Phone: +1 (617) 253-0161 - EMail: jis@mit.edu - - - - - - - - - - - -Schiller Standards Track [Page 5] - -RFC 4307 IKEv2 Cryptographic Algorithms December 2005 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2005). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Schiller Standards Track [Page 6] - diff --git a/doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf b/doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf Binary files differdeleted file mode 100644 index b8eb665e0..000000000 --- a/doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf +++ /dev/null |