Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7815

Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation

Pages: 41
Informational
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC7815 - Page 1
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 Implementation

Abstract

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.
Top   ToC   RFC7815 - Page 2
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.
Top   ToC   RFC7815 - Page 3

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
Top   ToC   RFC7815 - Page 4

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].
Top   ToC   RFC7815 - Page 5

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
Top   ToC   RFC7815 - Page 6
   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.
Top   ToC   RFC7815 - Page 7
   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.
Top   ToC   RFC7815 - Page 8
   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.
Top   ToC   RFC7815 - Page 9
   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.
Top   ToC   RFC7815 - Page 10
   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').
Top   ToC   RFC7815 - Page 11
   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).
Top   ToC   RFC7815 - Page 12

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.
Top   ToC   RFC7815 - Page 13
   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
Top   ToC   RFC7815 - Page 14
   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.
Top   ToC   RFC7815 - Page 15

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>.
Top   ToC   RFC7815 - Page 16
   [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)

Next Section