aboutsummaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
authorMartin Willi <martin@strongswan.org>2006-04-28 07:19:46 +0000
committerMartin Willi <martin@strongswan.org>2006-04-28 07:19:46 +0000
commitff8a0c2107d52db93d9145229e8142220675a882 (patch)
treed0b305c80014d080e7fc96ee92434bd11376b97d /doc
parenta3678ca2526c24e7335f87174a219ea52c09418e (diff)
downloadstrongswan-ff8a0c2107d52db93d9145229e8142220675a882.tar.bz2
strongswan-ff8a0c2107d52db93d9145229e8142220675a882.tar.xz
- moved RFCs from ikev2 into doc dir
Diffstat (limited to 'doc')
-rw-r--r--doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdfbin0 -> 808558 bytes
-rw-r--r--doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdfbin0 -> 172284 bytes
-rw-r--r--doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdfbin0 -> 104081 bytes
-rw-r--r--doc/ikev2/[IKEv2Clarifications] - IKEv2 Clarifications and Implementation Guidelines.txt3248
-rw-r--r--doc/ikev2/[IKEv2Draft] - Internet Key Exchange (IKEv2) Protocol Draft v17.txt6535
-rw-r--r--doc/ikev2/[IKEv2bis] - draft-hoffman-ikev2bis-00.txt6776
-rw-r--r--doc/ikev2/[IPsecArch] - Security Architecture for the Internet Protocol.txt5657
-rw-r--r--doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdfbin0 -> 169659 bytes
-rw-r--r--doc/ikev2/[RFC2104] - HMAC - Keyed-Hashing for Message Authentication.txt619
-rw-r--r--doc/ikev2/[RFC2407] - The Internet IP Security Domain of Interpretation for ISAKMP.txt1795
-rw-r--r--doc/ikev2/[RFC2408] - Internet Security Association and Key Management Protocol (ISAKMP).txt4819
-rw-r--r--doc/ikev2/[RFC2409] - The Internet Key Exchange (IKE).txt2299
-rw-r--r--doc/ikev2/[RFC2412] - The OAKLEY Key Determination Protocol.txt3083
-rw-r--r--doc/ikev2/[RFC2437] - PKCS #1 RSA Cryptography Specifications Version 2.0.txt2187
-rw-r--r--doc/ikev2/[RFC3280] - x509 Certificates.txt7227
-rw-r--r--doc/ikev2/[RFC3526] - More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE).txt563
-rw-r--r--doc/ikev2/[RFC4301] - Security Architecture for the Internet Protocol.txt5659
-rw-r--r--doc/ikev2/[RFC4306] - Internet Key Exchange (IKEv2) Protocol.txt5547
-rw-r--r--doc/ikev2/[RFC4307] - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2).txt339
-rw-r--r--doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdfbin0 -> 653279 bytes
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
new file mode 100644
index 000000000..496421eb5
--- /dev/null
+++ b/doc/ikev2/[DoxygenManual] - Doxygen Manual v1.4.5.pdf
Binary files differ
diff --git a/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf b/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf
new file mode 100644
index 000000000..aa2cded2e
--- /dev/null
+++ b/doc/ikev2/[Horman04] - Understanding And Programming With Netlink Sockets.pdf
Binary files differ
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
new file mode 100644
index 000000000..d5d3b43cc
--- /dev/null
+++ b/doc/ikev2/[IKEAnalysis] - Key Exchange in IPSec - Analysis of IKE.pdf
Binary files differ
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
new file mode 100644
index 000000000..a467aea78
--- /dev/null
+++ b/doc/ikev2/[QuantitativeAnalyses] - IKEv1 and IKEv2 - A Quantitative Analyses.pdf
Binary files differ
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
new file mode 100644
index 000000000..b8eb665e0
--- /dev/null
+++ b/doc/ikev2/[Thomas03] - IPSec Architektur und Protokolle, Internet Key Exchange (IKE).pdf
Binary files differ