diff options
| author | Martin Willi <martin@strongswan.org> | 2006-04-28 07:19:46 +0000 |
|---|---|---|
| committer | Martin Willi <martin@strongswan.org> | 2006-04-28 07:19:46 +0000 |
| commit | ff8a0c2107d52db93d9145229e8142220675a882 (patch) | |
| tree | d0b305c80014d080e7fc96ee92434bd11376b97d /doc | |
| parent | a3678ca2526c24e7335f87174a219ea52c09418e (diff) | |
| download | strongswan-ff8a0c2107d52db93d9145229e8142220675a882.tar.bz2 strongswan-ff8a0c2107d52db93d9145229e8142220675a882.tar.xz | |
- moved RFCs from ikev2 into doc dir
Diffstat (limited to 'doc')
20 files changed, 56353 insertions, 0 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 differnew file mode 100644 index 000000000..496421eb5 --- /dev/null +++ b/doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf 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 differnew file mode 100644 index 000000000..aa2cded2e --- /dev/null +++ b/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf 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 differnew file mode 100644 index 000000000..d5d3b43cc --- /dev/null +++ b/doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf diff --git a/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt b/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt new file mode 100644 index 000000000..d4c67b161 --- /dev/null +++ b/doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt @@ -0,0 +1,3248 @@ + + + +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 new file mode 100644 index 000000000..c1493c197 --- /dev/null +++ b/doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt @@ -0,0 +1,6535 @@ + + +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 new file mode 100644 index 000000000..9d1b9d74d --- /dev/null +++ b/doc/ikev2/[IKEv2bis] - draft-hoffman-ikev2bis-00.txt @@ -0,0 +1,6776 @@ + + + +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 new file mode 100644 index 000000000..863ffe3ff --- /dev/null +++ b/doc/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt @@ -0,0 +1,5657 @@ +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 differnew file mode 100644 index 000000000..a467aea78 --- /dev/null +++ b/doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf diff --git a/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt b/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt new file mode 100644 index 000000000..1fb8fe11a --- /dev/null +++ b/doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt @@ -0,0 +1,619 @@ + + + + + + +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 new file mode 100644 index 000000000..7b2f87c85 --- /dev/null +++ b/doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt @@ -0,0 +1,1795 @@ + + + + + + +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 new file mode 100644 index 000000000..c3af56268 --- /dev/null +++ b/doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt @@ -0,0 +1,4819 @@ + + + + + + +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 new file mode 100644 index 000000000..9d3e6f80e --- /dev/null +++ b/doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt @@ -0,0 +1,2299 @@ + + + + + + +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 new file mode 100644 index 000000000..9169d78be --- /dev/null +++ b/doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt @@ -0,0 +1,3083 @@ + + + + + + +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 new file mode 100644 index 000000000..54f6d5db5 --- /dev/null +++ b/doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt @@ -0,0 +1,2187 @@ + + + + + + +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 new file mode 100644 index 000000000..433908bb7 --- /dev/null +++ b/doc/ikev2/[RFC3280] - x509 Certificates.txt @@ -0,0 +1,7227 @@ + + + + + + +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 new file mode 100644 index 000000000..7b688a33f --- /dev/null +++ b/doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt @@ -0,0 +1,563 @@ + + + + + + +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 new file mode 100644 index 000000000..4a8eba975 --- /dev/null +++ b/doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt @@ -0,0 +1,5659 @@ + + + + + + +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 new file mode 100644 index 000000000..fad6cea0e --- /dev/null +++ b/doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt @@ -0,0 +1,5547 @@ + + + + + + +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 new file mode 100644 index 000000000..5617a2551 --- /dev/null +++ b/doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt @@ -0,0 +1,339 @@ + + + + + + +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 differnew file mode 100644 index 000000000..b8eb665e0 --- /dev/null +++ b/doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf |