RFC 7815
Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
Pages: 41
Informational
Informational
Part 1 of 2 – Pages 1 to 16
Internet Engineering Task Force (IETF) T. Kivinen Request for Comments: 7815 INSIDE Secure Category: Informational March 2016 ISSN: 2070-1721 Minimal Internet Key Exchange Version 2 (IKEv2) Initiator ImplementationAbstract
This document describes a minimal initiator version of the Internet Key Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other. This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7815.
Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Initial Exchange . . . . . . . . . . . . . . . . . . . . 5 2.2. Other Exchanges . . . . . . . . . . . . . . . . . . . . . 12 2.3. Generating Keying Material . . . . . . . . . . . . . . . 12 3. Conformance Requirements . . . . . . . . . . . . . . . . . . 13 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Header and Payload Formats . . . . . . . . . . . . . 17 A.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 17 A.2. Generic Payload Header . . . . . . . . . . . . . . . . . 19 A.3. Security Association Payload . . . . . . . . . . . . . . 21 A.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 23 A.3.2. Transform Substructure . . . . . . . . . . . . . . . 24 A.3.3. Valid Transform Types by Protocol . . . . . . . . . . 26 A.3.4. Transform Attributes . . . . . . . . . . . . . . . . 26 A.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 27 A.5. Identification Payloads . . . . . . . . . . . . . . . . . 27 A.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 29 A.7. Certificate Request Payload . . . . . . . . . . . . . . . 30 A.8. Authentication Payload . . . . . . . . . . . . . . . . . 31 A.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 31 A.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 32 A.10.1. Notify Message Types . . . . . . . . . . . . . . . . 33 A.11. Traffic Selector Payload . . . . . . . . . . . . . . . . 34 A.11.1. Traffic Selector . . . . . . . . . . . . . . . . . . 36 A.12. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Useful Optional Features . . . . . . . . . . . . . . 39 B.1. IKE SA Delete Notification . . . . . . . . . . . . . . . 39 B.2. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 40 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources. This document describes a minimal IKEv2 implementation designed for use on such constrained nodes that is interoperable with "Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC7296]. A minimal IKEv2 implementation only supports the initiator end of the protocol. It only supports the initial IKE_SA_INIT and IKE_AUTH exchanges and does not initiate any other exchanges. It also replies with an empty (or error) message to all incoming requests. This means that most of the optional features of IKEv2 are left out: NAT traversal, IKE SA rekey, Child SA rekey, multiple Child SAs, deleting Child / IKE SAs, Configuration payloads, Extensible Authentication Protocol (EAP) authentication, COOKIEs, etc. Some optimizations can be done because of the limited set of supported features, and this text should not be considered for generic IKEv2 implementations (for example, Message IDs can be done as specified because minimal implementation is only sending out an IKE_SA_INIT and IKE_AUTH request and not any other request). This document is intended to be standalone, meaning everything needed to implement IKEv2 is copied here except the description of the cryptographic algorithms. The IKEv2 specification has lots of background information and rationale that has been omitted from this document. Numerous additional numeric values from IANA registries have been omitted from this document; only those which are of interest for a minimal implementation are listed. The main body of this document describes how to use the shared secret authentication in IKEv2, as it is easiest to implement. In some cases, that is not enough, and Appendix B.2 describes how to use raw public keys instead of shared secret authentication. For more information, check the full IKEv2 specification in [RFC7296] and [IKEV2IANA]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term "Constrained Node" is defined in "Terminology for Constrained-Node Networks" [RFC7228].
1.1. Use Cases
One use case for this kind of minimal implementation is in small devices doing machine-to-machine communication. In such environments, the node initiating connections can be very small, and the other end of the communication channel is some kind of larger device. An example of the small initiating node could be a remote garage door opener device, i.e., a device having buttons that open and close a garage door and that connects to the home area network server over a wireless link. Another example of such a device is some kind of sensor device, for example, a room temperature sensor, which sends periodic temperature data to some centralized node. Those devices usually sleep for a long time and only wake up periodically or because of user interaction. The data transfer is always initiated from that sleeping node when they wake up; after they send packets, there might be ACKs or other packets coming back before they go back to sleep. If some data needs to be transferred from a server node to the small device, it can be implemented by polling, i.e., the small node periodically polls for the server to see if it, for example, has some configuration changes or similar. While the device is sleeping, it will not maintain the IKEv2 SA. That is, it will always create the IKEv2 SA again when it wakes up. This means there is no need to do liveness checks for the server, as after the device wakes up again, the minimal implementation will start from the beginning again.2. Exchanges
2.1. Initial Exchange
All IKEv2 communications consist of pairs of messages: a request and a response. The pair is called an "exchange" and is sometimes called a "request/response pair". Every request requires a response. For every pair of IKEv2 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. IKEv2 is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. A retransmission from the initiator MUST be bitwise
identical to the original request. Retransmission times MUST increase exponentially. IKEv2 is run over UDP port 500. All IKEv2 implementations MUST be able to send, receive, and process IKEv2 messages that are up to 1280 octets long. An implementation MUST accept incoming requests even if the source port is not 500 and MUST respond to the address and port from which the request was received. The minimal implementation of IKEv2 only uses the first two exchanges, called IKE_SA_INIT and IKE_AUTH. These are used to create the IKE SA and the first Child SA. In addition to those messages, a minimal IKEv2 implementation needs to understand the CREATE_CHILD_SA request enough to generate a CREATE_CHILD_SA response containing the NO_ADDITIONAL_SAS error notify. It needs to understand the INFORMATIONAL request enough to generate an empty INFORMATIONAL response to it. There is no requirement to be able to respond to any other requests. All messages following the IKE_SA_INIT exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the IKE_SA_INIT exchange. Every IKEv2 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. Minimal implementations only need to support the role of initiator, so it typically only sends an IKE_SA_INIT request that, when answered, is followed by an IKE_AUTH. As those messages have fixed Message IDs (0 and 1), it does not need to keep track of its own Message IDs for outgoing requests after that. Minimal implementations can also optimize Message ID handling of the incoming requests, as they do not need to protect incoming requests against replays. This is possible because minimal implementations will only return error or empty notification replies to incoming requests. This means that any of those incoming requests do not have any effect on the minimal implementation, thus processing them again does not cause any harm. Because of this, a minimal implementation can always answer a request coming in, with the same Message ID than what the request had, and then forget the request/response pair immediately. This means there is no need to keep track of Message IDs of the incoming requests.
In the following descriptions, the payloads contained in the message are indicated by the names listed below. Notation Payload ----------------------------------------- AUTH Authentication CERTREQ Certificate Request D Delete HDR IKE header (not a payload) IDi Identification - Initiator IDr Identification - Responder KE Key Exchange Ni, Nr Nonce N Notify SA Security Association SK Encrypted and Authenticated TSi Traffic Selector - Initiator TSr Traffic Selector - Responder The initial exchanges are as follows: Initiator Responder ------------------------------------------------------------------- HDR(SPIi=xxx, SPIr=0, IKE_SA_INIT, Flags: Initiator, Message ID=0), SAi1, KEi, Ni --> <-- HDR(SPIi=xxx, SPIr=yyy, IKE_SA_INIT, Flags: Response, Message ID=0), SAr1, KEr, Nr, [CERTREQ] HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts. Each endpoint chooses one of the two SPIs and MUST choose them so as to be unique identifiers of an IKE SA. An SPI value of zero is special: it indicates that the remote SPI value is not yet known by the sender. Incoming IKEv2 packets are mapped to an IKE SA using only the packet's SPI, not using (for example) the source IP address of the packet. The SAi1 payload states the cryptographic algorithms the initiator supports for the IKE SA. The KEi and KEr payloads contain Diffie- Hellman values, and Ni and Nr are the nonces. The SAr1 contains the chosen cryptographic suite from the initiator's offered choices. A minimal implementation using shared secrets will ignore the CERTREQ payload.
Minimal implementation will most likely support exactly one set of
cryptographic algorithms, meaning the SAi1 payload will be static.
It needs to check that the SAr1 received matches the proposal it
sent.
At this point in the negotiation, each party can generate SKEYSEED,
from which all keys are derived for that IKE SA.
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 )
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)
...
(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.
The SK_d is used for deriving new keys for the Child SAs. The SK_ai
and SK_ar are used as a key to the integrity protection algorithm for
authenticating the component messages of subsequent exchanges. The
SK_ei and SK_er are used for encrypting (and of course decrypting)
all subsequent exchanges. The SK_pi and SK_pr are used when
generating an AUTH payload. The lengths of SK_d, SK_pi, and SK_pr
MUST be the preferred key length of the Pseudorandom Function (PRF)
agreed upon.
A separate SK_e and SK_a is computed for each direction. 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. The notation SK { ... } indicates that these
payloads are encrypted and integrity protected using that direction's
SK_e and SK_a.
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, AUTH, SAr2, 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. The
responder asserts its identity with the IDr payload, authenticates
its identity, and protects the integrity of the second message with
the AUTH payload.
As minimal implementation usually has only one host where it
connects, that means it has only one shared secret. This means it
does not need to care about the IDr payload that much. If the other
end sends an AUTH payload that the initiator can verify using the
shared secret it has, then it knows the other end is the peer it was
configured to talk to.
In the IKE_AUTH request, the initiator sends the SA offer(s) in the
SAi2 payload and the proposed Traffic Selectors (TSs) for the Child
SA in the TSi and TSr payloads. The responder replies with the
accepted offer in an SAr2 payload and with the selected Traffic
Selectors. The selected Traffic Selectors may be a subset of what
the initiator proposed.
In the minimal implementation, both SA payloads and TS payloads are
going to be mostly static. The SA payload will have the SPI value
used in the Encapsulating Security Payload (ESP), but the algorithms
are most likely going to be the one and only supported set. The TS
payloads on the initiator end will most likely say from any to any,
i.e., full wildcard ranges, or from the local IP to the remote IP.
In the wildcard case, the responder quite often narrows the range
down to the one IP address pair. Using a single IP address pair as
the Traffic Selectors when sending the IKE_AUTH request will simplify
processing as the responder will either accept the IP address pair or
return an error. If wildcard ranges are used, there is a possibility
that the responder will narrow the Traffic Selector range to range
that is not acceptable by the initiator.
The IKE_AUTH (and IKE_SA_INIT) response may contain multiple status
notification payloads that can be ignored by minimal implementations.
There can also be Vendor ID, Certificate, Certificate Request, or Configuration payloads, but any payload unknown to minimal implementations can simply be skipped over (response messages cannot have critical unsupported payloads). The exchange above includes N(INITIAL_CONTACT) notification in the request as that is quite commonly sent by a minimal implementation. It indicates to the other end that the initiator does not have any other IKE SAs between it and the responder, and if there is any left from previous runs, those can be deleted by the responder. As minimal implementations delete IKE SAs without sending IKE SA delete requests, this will help the responder to clean up leftover state. When using shared secret authentication, the peers are authenticated by having each calculating a Message Authentication Code (MAC) over a block of data: For the initiator: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <InitiatorSignedOctets>) For the responder: AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <ResponderSignedOctets>) The string "Key Pad for IKEv2" is 17 ASCII characters without null termination. The implementation can precalculate the inner prf and only store the output of it. This is possible because a minimal IKEv2 implementation usually only supports one PRF. In the following calculations, IDi' and IDr' are the entire ID payloads excluding the fixed header, and the Ni and Nr are only the values, not the payloads containing it. Note that neither the nonce Ni/Nr nor the value prf(SK_pr, IDr')/prf(SK_pi, IDi') are transmitted. The initiator signs the first message (IKE_SA_INIT request), starting with the first octet of the first SPI in the header and ending with the last octet of the last payload in that first message. Appended to this (for purposes of computing the signature) are the responder's nonce Nr and the value prf(SK_pi, IDi'). For the responder, the octets to be signed start with the first octet of the first SPI in the header of the second message (IKE_SA_INIT response) and end with the last octet of the last payload in that second message. Appended to this are the initiator's nonce Ni and the value prf(SK_pr, IDr').
The initiator's signed octets can be described as: InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage1 = RealIKEHDR | RestOfMessage1 NonceRPayload = PayloadHeader | NonceRData InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload RestOfInitIDPayload = IDType | RESERVED | InitIDData MACedIDForI = prf(SK_pi, RestOfInitIDPayload) The responder's signed octets can be described as: ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR RealIKEHDR = SPIi | SPIr | . . . | Length RealMessage2 = RealIKEHDR | RestOfMessage2 NonceIPayload = PayloadHeader | NonceIData ResponderIDPayload = PayloadHeader | RestOfRespIDPayload RestOfRespIDPayload = IDType | RESERVED | RespIDData MACedIDForR = prf(SK_pr, RestOfRespIDPayload) Note that all of the payloads inside the RestOfMessageX are included under the signature, including any payload types not listed in this document. The initiator might also get an unauthenticated response back that has a notification payload with an error code inside. As that error code will be unauthenticated and may be faked, there is no need to do anything for those. A minimal implementation can simply ignore those errors and retransmit its request until it times out, and if that happens, then the IKE SA (and Child SA) creation failed. The responder might also reply with an IKE_AUTH response packet that does not contain the payloads needed to set up a Child SA (SAr2, TSi, and TSr) but instead contain AUTH payload and an error. Minimal implementation that does not support the CREATE_CHILD_SA exchange cannot recover from this scenario. It can delete the IKE SA and start over from the beginning (which might fail again if this is a configuration error, or it might succeed if this was temporal failure).
2.2. Other Exchanges
Minimal implementations MUST be able to reply to INFORMATIONAL requests by sending back an empty INFORMATIONAL response: Minimal implementation Other end ------------------------------------------------------------------- <-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, Flags: none, Message ID=m), SK {...} HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL, Flags: Initiator | Response, Message ID=m), SK {} --> Minimal implementations MUST be able to reply to incoming CREATE_CHILD_SA requests. A typical implementation will reject the CREATE_CHILD_SA exchanges by sending a NO_ADDITIONAL_SAS error notify back: Minimal implementation Other end ------------------------------------------------------------------- <-- HDR(SPIi=xxx, SPIy=yyy, CREATE_CHILD_SA, Flags: none, Message ID=m), SK {...} HDR(SPIi=xxx, SPIr=yyy, CREATE_CHILD_SA, Flags: Initiator | Response, Message ID=m), SK {N(NO_ADDITIONAL_SAS)} --> Note that INFORMATIONAL and CREATE_CHILD_SA requests might contain unsupported critical payloads, in which case a compliant implementation MUST ignore the request and send a response message back that has the UNSUPPORTED_CRITICAL_PAYLOAD notification. That notification payload data contains a 1-octet payload type of the unsupported critical payload.2.3. Generating Keying Material
The keying material for the Child SA created by the IKE_AUTH exchange is generated as follows: KEYMAT = prf+(SK_d, Ni | Nr) Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
A single CHILD_SA negotiation may result in multiple Security
Associations. ESP and Authentication Header (AH) SAs exist in pairs
(one in each direction), so two SAs are created in a single Child SA
negotiation for them. The keying material for each Child SA MUST be
taken from the expanded KEYMAT using the following rules:
o All keys for SAs carrying data from the initiator to the responder
are taken before SAs going from the responder to the initiator.
o If an IPsec protocol requires multiple keys, the order in which
they are taken from the SA's keying material needs to be described
in the protocol's specification. For ESP and AH, [IPSECARCH]
defines the order, namely: the encryption key (if any) MUST be
taken from the first bits, and the integrity key (if any) MUST be
taken from the remaining bits.
Each cryptographic algorithm takes a fixed number of bits of keying
material specified as part of the algorithm or negotiated in SA
payloads.
3. Conformance Requirements
For an implementation to be called conforming to the RFC 7296
specification, it MUST be possible to configure it to accept the
following:
o Public Key Infrastructure using X.509 (PKIX) Certificates
containing and signed by RSA keys of size 1024 or 2048 bits, where
the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
o Authentication where the responder is authenticated using PKIX
Certificates, and the initiator is authenticated using shared key
authentication.
This document only supports the second bullet; it does not support
PKIX Certificates at all. As full RFC 7296 responders must also
support that shared key authentication, this allows a minimal
implementation to be able to interoperate with all implementations
that are compliant with RFC 7296.
PKIX Certificates are left out from the minimal implementation as
those would add quite a lot of complexity to the implementation. The
actual code changes needed in the IKEv2 protocol are small, but the
certificate validation code would be more complex than the whole
minimal IKEv2 implementation itself. If public-key-based authentication is needed for scalability reasons, then raw public keys would probably be the best compromise (see Appendix B.2).4. Implementation Status
This document describes a minimal implementation written by the author of this document. The minimal implementation supported the base IKE_SA_INIT and IKE_AUTH exchanges and successfully interoperated with a full IKEv2 server. This minimal implementation was presented in the Interconnecting Smart Objects with Internet Workshop in Prague in March 2011 [Kiv11]. This implementation was written as proof of concept in perl. There was another proof-of-concept implementation written in python, which also interoperated with a full IKEv2 server. Both implementations were written just for demonstration purposes and included fixed configuration built into the code, and both also implemented ESP, ICMP, and IP layers to the level that was needed to send and receive one ICMP echo packet. Both implementations were about 1000 lines of code excluding cryptographic libraries but including ESP, ICMP, and IP layers.5. Security Considerations
As this implements the same protocol as RFC 7296, this means all security considerations from it also apply to this document.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.6.2. Informative References
[EAI] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, DOI 10.17487/RFC6532, February 2012, <http://www.rfc-editor.org/info/rfc6532>. [IDNA] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [IKEV2IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <http://www.iana.org/assignments/ikev2-parameters>. [IPSEARCH] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [Kiv11] Kivinen, T., "Interconnecting Smart Objects with Internet Workshop 2011-03025; IKEv2 and Smart Objects", March 2011, <https://www.iab.org/wp-content/IAB-uploads/2011/04/ Kivinen.pdf>. [MODES] National Institute of Standards and Technology, U.S. Department of Commerce, "Recommendation for Block Cipher Modes of Operation", SP 800-38A, 2001. [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <http://www.rfc-editor.org/info/rfc7619>. [RFC7670] Kivinen, T., Wouters, P., and H. Tschofenig, "Generic Raw Public-Key Support for IKEv2", RFC 7670, DOI 10.17487/RFC7670, January 2016, <http://www.rfc-editor.org/info/rfc7670>.
(next page on part 2)