RFC 7815
Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation
RFC 7815: Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation ✨
- RFC number: 7815
- Author: T. Kivinen, INSIDE Secure 🎀
- Category: Informational 🧚
- Date: March 2016 📅
- ISSN: 2070-1721
- Obsoletes / updates: the title block doesn't list anything this RFC obsoletes or updates. The Abstract does say it doesn't update or modify RFC 7296, so bestie, RFC 7296 is still the boss 👑
Abstract
okay so this doc is a minimal version of IKEv2 (Internet Key Exchange version 2) made for tiny constrained devices 🔋. IKEv2 is the part of IPsec that handles mutual authentication and sets up and keeps alive Security Associations (SAs) 🔐. The full protocol has a bunch of optional extras that tiny devices don't need, so this doc spells out what the minimal version must have and some optimizations you can do 💅. It works with a full IKEv2 implementation that uses shared secret authentication, and IKEv2 doesn't require certificate authentication, so no stress 🫶. A minimal initiator can only talk to a full IKEv2 responder though. Two minimal initiators literally 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. ✨ basically, RFC 7296 wins any fight 🏆
Status of This Memo
this one is not an Internet Standards Track spec. It's published just for info, so think of it as a helpful guide and not a law 📖
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. 🌸 the IETF community got together, reviewed it, and the IESG gave it the green light. It still doesn't automatically become a Standard, though, so check Section 2 of RFC 5741 if you're curious 🙈
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. 🦋 that link is where you go for updates, errata, and feedback
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. 📜 the legal stuff is a lot, but the gist is: read the Trust's provisions, and if you pull code out of this doc, it needs the Simplified BSD License text in it, with no warranty
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. 🫠 so some older material might be locked down, meaning no editing it outside the IETF process, except for formatting it as an RFC or translating it into other languages
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 . . . . . . . . . . . . . . . . . . . . . . . . 411. Introduction ✨
okay so the Internet Protocol Suite is showing up on tiny devices that have very little power, memory, and processing 🔋. This doc describes a minimal IKEv2 implementation for those constrained nodes, and it still plays nicely 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. 💅 so it starts the first two exchanges and that's it, and anything else coming in gets an empty or error reply
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. 🙈 the list of stuff that gets cut is honestly long: NAT traversal, rekeying both IKE and Child SAs, multiple Child SAs, deleting SAs, Configuration payloads, EAP, and COOKIEs
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). 🧚 the shortcuts here are only for minimal builds, so don't copy them into a full IKEv2 implementation. Message IDs are a good example, since the minimal one only ever sends an IKE_SA_INIT and an IKE_AUTH 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. 🎀 this doc is meant to be self-contained, so you don't need to go hunting for the IKEv2 spec to build it. The only thing it leaves out is the crypto algorithm descriptions, and the background and reasoning from the full spec got cut too
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. 🔢 tons of extra IANA registry numbers got dropped. Only the ones a minimal build actually cares about are here
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. 🔑 the main body sticks to shared secrets because they're the easiest to build. If that's not enough for you, Appendix B.2 covers raw public keys
For more information, check the full IKEv2 specification in [RFC7296] and [IKEV2IANA]. 📚 for the full story, go read [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]. 🧠 these are the official key words and they mean what [RFC2119] says. "Constrained Node" is defined in [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. 🤖 the tiny device starts the connection and the big device sits on the other end
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. 🚪 think of a remote garage door opener with buttons, talking to the home network server over wireless
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. 🌡️ or a room temperature sensor that keeps sending readings to a central 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. 😴 these devices mostly nap, wake up on a schedule or when someone pokes them, and always start the data transfer themselves. ACKs or other packets might come 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. 🔄 if the server needs to send something down, the small device just checks in regularly and asks if there's anything new, like config changes
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. 💤 the device doesn't keep its IKEv2 SA alive while it sleeps. It just builds a fresh one every time it wakes up, so it never needs liveness checks, since it starts over from the beginning anyway 🌈
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. 💬 IKEv2 talks in pairs, a request and then a response, and every request needs one back
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. 🔁 the initiator handles resends when a timeout hits. The responder only ever resends its response when the request shows up again
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 built to be reliable. The initiator keeps resending its request until it gets the matching response or decides the IKE SA has failed. Every resend has to be bitwise identical to the original, and the wait between retries grows 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. 🌐 IKEv2 runs on UDP port 500. Every implementation has to handle messages up to 1280 octets, and it has to accept requests even when the source port isn't 500, replying to the exact address and port the request came from 💖
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. ✨ the minimal build only runs IKE_SA_INIT and IKE_AUTH. Those two create the IKE SA and the first Child SA. On top of that, it has to understand enough of CREATE_CHILD_SA to send back a CREATE_CHILD_SA response with the NO_ADDITIONAL_SAS error notify, and enough of INFORMATIONAL to send back an empty INFORMATIONAL response. Nothing else is required to get a response 🫶
Okay so everything after the IKE_SA_INIT exchange is locked down with the crypto algorithms and keys that got negotiated in that first step 🔐✨
Every IKEv2 message has a Message ID in its fixed header 🎀. It's how requests get matched up with their responses, and how retransmissions get spotted 🔁
A minimal initiator only really needs to be the initiator 🦋 It sends an IKE_SA_INIT request, and once that gets answered it follows up with an IKE_AUTH. Those two messages have fixed Message IDs (0 and 1), so it doesn't have to keep count of its own outgoing Message IDs after that 🧮
Minimal implementations can also take a shortcut with incoming requests, because they don't need to protect against replays 💅 They only ever send back error or empty notification replies. That means processing an incoming request again doesn't do any harm, since those requests don't change anything on the minimal side. So a minimal implementation can answer each incoming request with the same Message ID the request had, then forget that request/response pair right away. No tracking incoming Message IDs needed, bestie 🙌
Here's the notation we'll be using for the payloads in these messages 📝
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 - ResponderAnd here's how the initial exchanges go 👀
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]The HDR is the header that carries the SPIs, version numbers, and a bunch of flags 🧾 Each side picks one of the two SPIs, and it MUST choose them so they're unique identifiers of an IKE SA ✨ A zero SPI is kind of special. It means the sender doesn't know the remote SPI yet 🫶
Incoming IKEv2 packets get mapped to an IKE SA using only the SPI from the packet. Not the source IP address or anything like that 🗺️
Now the payloads: SAi1 lists the crypto algorithms the initiator is up for, KEi and KEr carry the Diffie-Hellman values, Ni and Nr are the nonces, and SAr1 is the responder's pick from the initiator's offers 💜 A minimal implementation using shared secrets just ignores the CERTREQ payload 🙈
A minimal implementation will most likely support exactly one set of crypto algorithms, so its SAi1 payload is basically static 🧊 It still needs to check that the SAr1 it receives matches the proposal it sent. Important, no cap 🔍
At this point in the negotiation, each party can generate SKEYSEED, and every key for that IKE SA gets derived from it 🔑 Here's the math, periodt:
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)
...So the keys SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr get taken in that order from the bits that prf+ spits out 🎰 The g^ir is the shared secret from the ephemeral Diffie-Hellman exchange 💫 It's written as a string of octets in big endian order, padded with zeros if needed so it matches the length of the modulus. And Ni and Nr are the nonces with any headers stripped off 🧼
Here's who does what with the keys 👑 SK_d is used for deriving new keys for the Child SAs. SK_ai and SK_ar are the integrity protection keys for authenticating the component messages of later exchanges. SK_ei and SK_er handle encryption (and, of course, decryption) for all the later exchanges. SK_pi and SK_pr get used when generating an AUTH payload. And the lengths of SK_d, SK_pi, and SK_pr MUST be the preferred key length of the agreed Pseudorandom Function (PRF) 📏
There's a separate SK_e and SK_a for each direction 🧭 The keys protecting messages from the original initiator are SK_ai and SK_ei, and the keys protecting messages going the other way are SK_ar and SK_er. The notation SK { ... } just means those payloads are encrypted and integrity protected with that direction's SK_e and SK_a 🎀
Now the IKE_AUTH exchange 🔐
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 says who it is with the IDi payload, proves it knows the secret tied to IDi, and protects the integrity of the first message using the AUTH payload 🙋♀️ The responder does the same thing in reverse: it says who it is with IDr, authenticates itself, and protects the second message with its own AUTH payload 💖
A minimal implementation usually has only one host it connects to, which means only one shared secret 🎯 So it doesn't have to care that much about the IDr payload. If the other end sends an AUTH payload the initiator can verify with the shared secret it already has, then it knows that other end is the peer it was configured to talk to. Iconic behaviour, honestly 😭
In the IKE_AUTH request, the initiator sends its SA offers in the SAi2 payload and its proposed Traffic Selectors (TSs) for the Child SA in the TSi and TSr payloads 📦 The responder answers with the accepted offer in an SAr2 payload and the selected Traffic Selectors. Those selected ones can be a subset of what the initiator proposed ✂️
In the minimal implementation, the SA and TS payloads are both going to be mostly static 🌸 The SA payload carries the SPI used in the Encapsulating Security Payload (ESP), but the algorithms will most likely be the one and only supported set. The TS payloads on the initiator end will most likely say from any to any (full wildcard ranges), or from the local IP to the remote IP 🌍
With wildcards, the responder quite often narrows things down to a single IP address pair 📉 Using just one IP address pair as the Traffic Selectors in the IKE_AUTH request makes life simpler, because the responder will either accept that pair or return an error. Easy peasy 🍓 But if wildcard ranges are used, there's a chance the responder narrows the Traffic Selector range to something the initiator doesn't find acceptable 😬
The IKE_AUTH (and IKE_SA_INIT) response might contain several status notification payloads, which minimal implementations can ignore 🫧 There can also be Vendor ID, Certificate, Certificate Request, or Configuration payloads. Any payload a minimal implementation doesn't recognise can just get skipped over, since response messages can't have critical unsupported payloads 🧚
The exchange above includes an N(INITIAL_CONTACT) notification in the request, because minimal implementations commonly send it. It tells the other end that the initiator doesn't have any other IKE SAs between itself and the responder. If there are any left over from previous runs, the responder can delete them. Minimal implementations delete their IKE SAs without sending IKE SA delete requests, so this notification helps the responder clean up leftover state 🧹
When shared secret authentication is used, each peer proves who it is by calculating a Message Authentication Code (MAC) over a block of data 🔏 Here's how it looks:
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 🔤 An implementation can precalculate the inner prf and store only its output. That works because a minimal IKEv2 implementation usually only supports one PRF, so it's a neat little shortcut 💅
For the next calculations, IDi' and IDr' are the entire ID payloads minus the fixed header, and Ni and Nr are only the nonce values, not the payloads that contain them 🧩 Heads up: neither the nonce Ni/Nr nor the value prf(SK_pr, IDr')/prf(SK_pi, IDi') gets transmitted over the wire 🤫
The initiator signs the first message (the IKE_SA_INIT request). The signed octets start at the first octet of the first SPI in the header and end at the last octet of the last payload in that first message. Tacked onto the end, for the signature calculation only, are the responder's nonce Nr and the value prf(SK_pi, IDi') 📝
For the responder, the signed octets start at the first octet of the first SPI in the header of the second message (the IKE_SA_INIT response) and end at the last octet of the last payload in that second message. Appended to those are the initiator's nonce Ni and the value prf(SK_pr, IDr') ✍️
The initiator's signed octets can be described like this:
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)And the responder's signed octets look like this:
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 every payload inside the RestOfMessageX parts is included under the signature, even payload types not listed in this document 🧾
Last thing, and it's a big one 🚨 The initiator might get an unauthenticated response back that contains a notification payload with an error code inside. Since that error code isn't authenticated, it could be faked, so there's no need to do anything about it. A minimal implementation can just ignore those errors and keep retransmitting its request until it times out. If that happens, the IKE SA (and the Child SA) creation has failed 💀
The responder could also send back an IKE_AUTH response that's missing the stuff needed to set up a Child SA (SAr2, TSi, and TSr) and instead has an AUTH payload plus an error. 😭 A minimal implementation that doesn't support the CREATE_CHILD_SA exchange can't recover from this one 💀. It can delete the IKE SA and start over from the beginning. That might fail again if it's a configuration error, or it might work if it was a 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 CREATE_CHILD_SA exchanges by sending back a NO_ADDITIONAL_SAS error notify 🙅♀️:
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 that case, a compliant implementation MUST ignore the request and send back a response message that has the UNSUPPORTED_CRITICAL_PAYLOAD notification 🚫. That notification's 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 like this 🔑:
KEYMAT = prf+(SK_d, Ni | Nr)Where Ni and Nr are the nonces from the IKE_SA_INIT exchange.
One single CHILD_SA negotiation can end up with multiple Security Associations 👯♀️. ESP and Authentication Header (AH) SAs come in pairs (one in each direction), so two SAs get created in a single Child SA negotiation for them. The keying material for each Child SA MUST be taken from the expanded KEYMAT using these rules:
- All keys for SAs carrying data from the initiator to the responder are taken before SAs going from the responder to the initiator.
- 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. That number is 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 🎀:
- 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, orID_DER_ASN1_DN. - Shared key authentication where the ID passed is any of
ID_KEY_ID,ID_FQDN, orID_RFC822_ADDR. - 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 lets a minimal implementation interoperate with all implementations that are compliant with RFC 7296 💜.
PKIX Certificates are left out of the minimal implementation because they would add a lot of complexity 🧠. 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 its author 🍓. The minimal implementation supported the base IKE_SA_INIT and IKE_AUTH exchanges and successfully interoperated with a full IKEv2 server 🥹. It was presented at the Interconnecting Smart Objects with Internet Workshop in Prague in March 2011 [Kiv11]. This implementation was written as a 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. Both also implemented ESP, ICMP, and IP layers to the level needed to send and receive one ICMP echo packet 🏓. Both 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, all security considerations from it also apply to this document 🚨🔐. Serious business, bestie, do not skip this 😤.
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>.Appendix A. Header and Payload Formats ✨
This appendix describes the actual packet payload formats. It's required to make the document self-contained 📦. The descriptions are mostly copied from RFC 7296, and more information can be found there 📚.
Various payloads contain RESERVED fields. Those MUST be sent as zero and MUST be ignored on receipt 0️⃣.
All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first" or "network byte order") 🌐. Big endian era 👑.
A.1. The IKE Header ✨
Okay bestie, every IKEv2 message starts with the IKE header, which this document calls HDR 🎀. Right after it come one or more IKE payloads, and each one names the next payload type in its own Next Payload field. So you read them like a chain: the header tells you the first payload, that payload tells you the next, and you keep going until a Next Payload field of zero says "that's all, bye" 💅. If you hit an Encrypted payload, you decrypt it and parse what's inside as more payloads. An Encrypted payload MUST be the last payload in a packet, and an Encrypted payload MUST NOT contain another Encrypted payload 🔥.
Here's what the header looks like 🦋:
0 1 2 3 4 5 6 7 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 1: IKE Header Format
Now let's break down each field 💜:
Initiator's SPI(8 octets) - A value chosen by the initiator to identify a unique IKE Security Association. This value MUST NOT be zero ✨.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 🌸.Next Payload(1 octet) - Indicates the type of payload that immediately follows the header. The format and value of each payload are defined below.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 and MUST drop the messages with a higher major version number 🚫.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 zero. They MUST ignore the minor version number of received messages 🙈.Exchange Type(1 octet) - Indicates the type of exchange being used. This constrains the payloads sent in each message in an exchange 🧚.
Exchange Type Value
----------------------------------
IKE_SA_INIT 34
IKE_AUTH 35
CREATE_CHILD_SA 36
INFORMATIONAL 37Flags(1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits look like this:
+-+-+-+-+-+-+-+-+
|X|X|R|V|I|X|X|X|
+-+-+-+-+-+-+-+-+In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt 🌈.
- R (Response) - 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 IKEv2 endpoint MUST NOT generate a response to a message that is marked as being a response 💖.
- V (Version) - 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 field. Implementations of IKEv2 MUST clear this bit when sending and MUST ignore it in incoming messages 🎀.
- I (Initiator) - 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 8 octets of the SPI were generated by the recipient. This bit changes to reflect who initiated the last rekey of the IKE SA 🔁.
Message ID(4 octets, unsigned integer) - 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 🛡️.Length(4 octets, unsigned integer) - Length of the total message (header + payloads) in octets 📏.
A.2. Generic Payload Header 💅
Every IKE payload starts with a generic payload header, shown in Figure 2 🌷. The figures for each payload below will include this generic payload header, but to keep things short, the description of each field gets skipped there.
0 1 2 3 4 5 6 7 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 2: Generic Payload Header
Here's what each generic payload header field means 🍓:
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 zero. This field provides a "chaining" capability whereby additional payloads can be added to a message by appending each one 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 zero); conversely, the Next Payload field of the last contained payload is set to zero). The payload type values needed for minimal implementations are listed here 🔗.
Next Payload Type Notation Value
--------------------------------------------------
No Next Payload 0
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
Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45
Encrypted and Authenticated SK 46- 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 1 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 🚨.
Payload Length(2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header 📦.
A.3. Security Association Payload ✨
okay so the Security Association payload (we call it SA in this doc 💖) is what you use to negotiate the attributes of a Security Association 🔥
An SA payload is made of one or more proposals. Each proposal includes one protocol 🦋. Each protocol holds one or more transforms, and each transform specifies a cryptographic algorithm. A transform can have zero or more attributes 🎀. Attributes are only needed when the Transform ID doesn't fully pin down the algorithm. Right now the only attribute is the Key Length attribute for variable-length ciphers, which means there's exactly zero or one attribute (ngl that's a tiny menu 💀)
The responder MUST choose a single suite, and that suite can be any subset of the SA proposal, following the rules below 👑
Each proposal contains one protocol. If a proposal is accepted, the SA response MUST contain the same protocol. Each IPsec protocol proposal has one or more transforms, and each transform has a Transform Type. The accepted cryptographic suite MUST contain exactly one transform of each type that was in the proposal. For example, if an ESP proposal has ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, then the accepted suite MUST contain one of the ENCR_ transforms and one of the AUTH_ transforms. So six combinations are acceptable 🧮
Minimal implementations can make a very simple SA proposal. Just include one proposal, which contains exactly one transform for each Transform Type. It's important to only include one Diffie-Hellman group in the proposal, so there's no need to do INVALID_KE_PAYLOAD processing in responses 🌸
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're nested, so 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 📏
Each Proposal/Protocol structure is followed by one or more transform structures, and the number of different transforms is generally determined by the Protocol. AH generally has two transforms: Extended Sequence Numbers (ESNs) and an integrity check algorithm. ESP generally has three: ESN, an encryption algorithm, and an integrity check algorithm. IKEv2 generally has four: a Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, and an encryption algorithm. For each Protocol, the set of permissible transforms gets Transform ID numbers, which show up 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 🔥
A given transform MAY have one or more Attributes. Attributes are necessary when the transform can be used in more than one way, like when an encryption algorithm has a variable key size. The transform specifies the algorithm, and the attribute specifies the key size. To propose alternate values for an attribute (like multiple key sizes for the AES encryption algorithm), an implementation MUST include multiple transforms with the same Transform Type, each with a single Attribute so good, right? 🎀
1 2 3
0 1 2 3 4 5 6 7 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 3: Security Association Payload
Proposals(variable) - One or more proposal substructures.
A.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 Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Proposal Substructure
0 (last) or 2 (more)(1 octet) - Specifies whether this is the last Proposal Substructure in the SA.Proposal Length(2 octets, unsigned integer) - Length of this proposal, including all transforms and attributes that follow.Proposal Num(1 octet) - When a proposal is made, the first proposal in an SA payload MUST be 1, and subsequent proposals MUST be one more than the previous proposal. When a proposal is accepted, the proposal number in the SA payload MUST match the number on the proposal sent that was accepted 🔢Protocol ID(1 octet) - Specifies the IPsec protocol identifier for the current negotiation.
Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3SPI 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 and 4 for ESP and AH).Num Transforms(1 octet) - Specifies the number of transforms in this proposal.SPI(variable) - The sending entity's SPI. When the SPI Size field is zero, this field is not present in the Security Association payload.Transforms(variable) - One or more transform substructures.
A.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 5: Transform Substructure
0 (last) or 3 (more)(1 octet) - Specifies whether this is the last Transform Substructure in the Proposal.Transform Length- The length (in octets) of the Transform Substructure including Header and Attributes.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.Transform ID(2 octets) - The specific instance of the Transform Type being proposed.
The relevant Transform Type values are listed below. For more information see [RFC7296]. 📚
Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom 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 ESPFor Transform Type 1 (Encryption Algorithm), the relevant Transform IDs are listed below.
Name Number
---------------------------
ENCR_AES_CBC 12
ENCR_AES-CCM_8 14For Transform Type 2 (Pseudorandom Function), the relevant Transform IDs are listed below.
Name Number
----------------------------------
PRF_HMAC_SHA1 2For Transform Type 3 (Integrity Algorithm), the relevant Transform IDs are listed below.
Name Number
---------------------------
AUTH_HMAC_SHA1_96 2
AUTH_AES_XCBC_96 5For Transform Type 4 (Diffie-Hellman group), the relevant Transform IDs are listed below.
Name Number
-------------------------
1536-bit MODP 5
2048-bit MODP 14For Transform Type 5 (Extended Sequence Numbers), the relevant Transform IDs are listed below.
Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1Note that an initiator who supports ESNs will usually include two ESN transforms, with values "0" and "1", in its proposals. A proposal containing a single ESN transform with value "1" means that using normal (non-extended) sequence numbers is not acceptable 🙈
A.3.3. Valid Transform Types by Protocol 💜
The number and type of transforms that accompany an SA payload depend 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-HA.3.4. Transform Attributes
okay so this is where the transforms get their extra settings 💅 Transform Type 1 (Encryption Algorithm) transforms might include one transform attribute: Key Length. 🔐
1 2 3
0 1 2 3 4 5 6 7 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| Attribute Type | Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Data Attributes 🎀
o Attribute Type (15 bits) - Unique identifier for each type of attribute (see below).
o Attribute Value - Value of the attribute associated with the attribute type.
Attribute Type Value
----------------------------
Key Length (in bits) 14okay the Key Length attribute is how you say how long the key is, in bits 🦋 It MUST use network byte order, so it's always the same way around for everyone 🫶
- The Key Length attribute MUST NOT be used with transforms that use a fixed-length key. 🙈 like, if the key size is already locked in, don't even bring it up
- Some transforms specify that the Key Length attribute MUST be always included. 💜 For example, ENCR_AES_CBC. ✨
A.4. Key Exchange Payload
this is the payload where you actually send your Diffie-Hellman public value so the other side can do the math too 🌈 ngl it's giving main character energy
1 2 3
0 1 2 3 4 5 6 7 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Num | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Key Exchange Payload Format 🎀
A Key Exchange payload is built by copying your Diffie-Hellman public value into the "Key Exchange Data" part of the payload 💖 For modular exponentiation groups (MODPs), the length of that public value MUST be equal to the length of the prime modulus the exponentiation was done over, so you add zero bits to the front if you need to 🍓
The Diffie-Hellman Group Num tells you which Diffie-Hellman group the Key Exchange Data was computed in. 🧚 This Diffie-Hellman Group Num MUST match a Diffie-Hellman group that was listed in a proposal in the SA payload sent in the same message. 👑
A.5. Identification Payloads
the Identification payloads (IDi and IDr in this doc) are how peers say who they are to each other 🪪 Bestie, this part is so important: when you use the ID_IPV4_ADDR or ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does NOT require that address to match the IP header address of the IKEv2 packets, or anything in the TSi/TSr payloads 😭 The IDi/IDr contents are only used to look up the policy and authentication data for the other party. 🔍
In a minimal implementation, it might be easiest to always use the KEY_ID type 💅 That lets the ID payload stay static ✨ Using an IP address has problems in environments where IP addresses are dynamically allocated. 🌸 (dynamic IPs are chaos, iykyk)
1 2 3
0 1 2 3 4 5 6 7 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 8: Identification Payload Format 🎀
o ID Type (1 octet) - Specifies the type of Identification being used.
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 table below lists the assigned meanings for the Identification Type field 🌈
ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.
ID_FQDN 2
A fully qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA], for example, "xn--tmonesimerkki-bfbb.example.net".
ID_RFC822_ADDR 3
A fully qualified RFC 822 email address string based [RFC5322].
An example of an ID_RFC822_ADDR is "jsmith@example.com". The
string MUST NOT contain any terminators. Because of [EAI],
implementations would be wise to treat this field as
UTF-8-encoded text, not as pure ASCII.
ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.
ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification. Minimal implementation might use
this type to send out a serial number or similar device-specific
unique static Identification Data for the device.A.6. Certificate Payload
this one carries certificates (or raw public keys) so the other side can check who you are 🔐✨
1 2 3
0 1 2 3 4 5 6 7 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 9: 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
----------------------------------------------------
X.509 Certificate - Signature 4
Raw Public Key 15o Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Encoding field.
the syntax of the types above is:
o "X.509 Certificate - Signature" contains a DER-encoded X.509 certificate whose public key is used to validate the sender's AUTH payload. Note that with this encoding, if a chain of certificates needs to be sent, multiple CERT payloads are used, only the first of which holds the public key used to validate the sender's AUTH payload. 🔗
o "Raw Public Key" contains a raw public key. In essence, the Certificate Payload contains the SubjectPublicKeyInfo part of the PKIX Certificate (see Section 4.1.2.7 of [RFC5280]). This is a quite simple ASN.1 object that contains mostly static parts before the actual public key values. See [RFC7670] for more information. 🧩
A.7. Certificate Request Payload
this is the payload where you ask the other side for a certificate from a CA you trust 🙋♀️
1 2 3
0 1 2 3 4 5 6 7 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 (CA) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: Certificate Request Payload Format 🎀
o Certificate Encoding (1 octet) - Contains an encoding of the type or format of certificate requested.
o Certification Authority (variable length) - Contains an encoding of an acceptable certification authority for the type of certificate requested.
The Certificate Encoding field has the same values as the certificate payload 🔁 The Certification Authority field holds 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. Each one is encoded as the SHA-1 hash of the Subject Public Key Info element (see Section 4.1.2.7 of [RFC5280]) from each Trust Anchor certificate. The 20-octet hashes are concatenated and included with no other formatting. 🧮
A.8. Authentication Payload
last one for this part: the Authentication payload is where you prove who you are 🛡️
1 2 3
0 1 2 3 4 5 6 7 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 11: Authentication Payload Format 🎀
o Auth Method (1 octet) - Specifies the method of authentication used.
Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Using an RSA private key with an RSASSA-PKCS1-v1_5 signature
scheme specified in [PKCS1]; see Section 2.15 of [RFC7296] for
details.
Shared Key Message Integrity Code 2
Computed as specified earlier using the shared key associated
with the identity in the ID payload and the negotiated PRF.o Authentication Data (variable length) - see Section 2.1.
A.9. Nonce Payload 🎀
Okay so bestie, the Nonce payload is basically the random little secret each side brings to the party 🦋 Here's how it's laid out:
1 2 3
0 1 2 3 4 5 6 7 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 12: Nonce Payload Formato Nonce Data (variable length) - this is the random data the sending entity generated, so it's literally the spicy bit 🌶️
The size of the Nonce Data MUST be between 16 and 256 octets, inclusive. And nonce values MUST NOT be reused, no exceptions 💅 Rule of the club, periodt ✨
A.10. Notify Payload 📣
Okay so the Notify payload (we call it N in this doc 🧚) is how you send informational stuff to an IKE peer, like error conditions and state transitions. You'll usually spot it in a response message, where it explains why a request got rejected 🙈 It can also show up in an INFORMATIONAL exchange to report an error that wasn't in an IKE request, or in any other message to show off sender capabilities or to change what the request means. Iconic versatility 👑
1 2 3
0 1 2 3 4 5 6 7 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 13: Notify Payload Formato Protocol ID (1 octet) - if the notification is about an existing SA whose SPI is in the SPI field, this tells you what type of SA it is. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Empty fields, zero vibes only 🫶
o SPI Size (1 octet) - the length in octets of the SPI as defined by the IPsec protocol ID, or zero if no SPI is applicable. For a notification about the IKE SA, the SPI Size MUST be zero and the SPI field must be empty. (Okay the lowercase "must" is what the original says, so I'm keeping it lowercase, no drama 🙃)
o Notify Message Type (2 octets) - specifies the type of notification message 📮
o SPI (variable length) - Security Parameter Index 🔑
o Notification Data (variable length) - status or error data sent along with the Notify Message Type. The values for this field are type specific 🌈
A.10.1. Notify Message Types 🦋
Okay so notification info can be error messages explaining why an SA couldn't be set up. It can also be status data that a process managing an SA database wants to share with its peer process 💜
Types in the range 0 - 16383 are meant for reporting errors. If an implementation gets a Notify payload with one of these types that it doesn't recognize in a response, it MUST assume the corresponding request has failed entirely. Unrecognized error types in a request, and status types in a request or response, MUST be ignored, and they should be logged. Ignore-but-log, the ultimate glow-up 🌸
Notify payloads with status types MAY be added to any message, and they MUST be ignored if not recognized. They're meant to show capabilities and, as part of SA negotiation, they're used to negotiate non-cryptographic parameters ✨
NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
Indicates that the 1-octet payload type included in the
Notification Data field is unknown.
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 (DoS) 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.
NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals are not acceptable
for the responder.
NO_ADDITIONAL_SAS 35
Specifies that the node is unwilling to accept any more Child
SAs.
NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
Asserts that this IKE SA is the only IKE SA currently active
between the authenticated identities.Okay, the big one here: INVALID_SYNTAX says the error details should go to a console or log, but the catch-all error response MUST be INVALID_SYNTAX, so nobody can poke around and learn stuff 🕵️♀️💀 (In the spec, the 'MUST' there is about sending that status for any error not covered by the others, and that's the core of it.)
A.11. Traffic Selector Payload 🗺️
Okay so Traffic Selector (TS) payloads let endpoints share some of what's in their Security Policy Database (SPD) with their peers 💅 They spell out the selection criteria for packets that'll get forwarded over the newly set up SA. Main character planning 🎀
1 2 3
0 1 2 3 4 5 6 7 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 14: Traffic Selectors Payload Formato Number of TSs (1 octet) - the number of Traffic Selectors being provided 🔢
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 📏
There's no requirement that TSi and TSr contain the same number of individual Traffic Selectors. So they get read like this: 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 🤝
Two TS payloads show up in each of the messages in the exchange that creates a Child SA pair. Each TS payload has one or more Traffic Selectors, and each Traffic Selector is made of an address range (IPv4 or IPv6), a port range, and an IP protocol ID 🌐
The first TS payload is called TSi (Traffic Selector - initiator), and the second is TSr (Traffic Selector - responder). TSi says what the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the Child SA pair is. TSr says what the destination address of the traffic forwarded to (or the source address of the traffic forwarded from) the responder of the Child SA pair is 🦋
IKEv2 lets the responder pick a subset of the traffic the initiator proposed. Iconic flexibility 💖
When the responder picks a subset, it narrows the Traffic Selectors to some subset of the initiator's proposal, as long as the set doesn't become the null set ✂️ If the type of Traffic Selector proposed is unknown, the responder ignores that Traffic Selector, so the unknown type never makes it into the narrowed set 🙅♀️
To help the responder choose the right range: if the initiator asked for the SA because of a data packet, the initiator SHOULD include as the first Traffic Selector in each TSi and TSr a very specific Traffic Selector that includes the addresses in the packet that triggered the request 🎯 If the initiator creates the Child SA pair not in response to an arriving packet, but say, on 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 can be ranges instead of specific values 🌈
As minimal implementations might only support one SA, the Traffic Selectors will usually run from the initiator's IP address to the responder's IP address (so, no port or protocol selectors and only one range) 🧚
A.11.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 15: Traffic Selectorokay bestie, let's talk about the Traffic Selector!! 🎀✨ It's the little struct that tells the other side which traffic is allowed through a Security Association, and it's giving main character energy 💅.
TS Type(1 octet) - Specifies the type of Traffic Selector. 🦋IP protocol ID(1 octet) - Value specifying an associated IP protocol ID (such as UDP, TCP, and ICMP). A value of zero means that the protocol ID is not relevant to this Traffic Selector -- the SA can carry all protocols. 🌈 so zero is basically the "all protocols welcome" sign 🫶Selector Length- Specifies the length of this Traffic Selector substructure including the header. 🌸Start Port(2 octets, unsigned integer) - Value specifying the smallest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be zero. 💜 ngl this one's a must, so it's MUST zero when ports don't apply or everything's allowedEnd Port(2 octets, unsigned integer) - Value specifying the largest port number allowed by this Traffic Selector. For protocols for which port is undefined (including protocol 0), or if all ports are allowed, this field MUST be 65535. 🔥 same vibe here, but the end port is MUST 65535 insteadStarting Address- The smallest address included in this Traffic Selector (length determined by TS Type). 🧚Ending Address- The largest address included in this Traffic Selector (length determined by TS Type). 🍓
The following table lists values for the Traffic Selector Type field and the corresponding Address Selector Data. 🌈
TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7
A range of IPv4 addresses, represented by two 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 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.so TS type 7 is IPv4 ranges and TS type 8 is IPv6 ranges, periodt 💅
A.12. Encrypted Payload
The Encrypted payload, denoted as SK{...} in this document, contains other payloads in encrypted form. 🔐✨ it's basically a locked diary for your other payloads 🙈
1 2 3
0 1 2 3 4 5 6 7 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 the encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Encrypted Payload FormatNext 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; 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. 🦋Payload Length- Includes the lengths of the header, initialization vector (IV), Encrypted IKE payloads, Padding, Pad Length, and Integrity Checksum Data. 🌸Initialization Vector- For Cipher Block Chaining (CBC) mode ciphers, the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. The reader is encouraged to consult [MODES] for advice on IV generation. In particular, using the final ciphertext block of the previous message is not considered unpredictable. For modes other than CBC, the IV format and processing is specified in the document specifying the encryption algorithm and mode. 🎀 the IV has to be fresh and unpredictable every single time, bestie 😭IKE payloadsare as specified earlier in this section. This field is encrypted with the negotiated cipher. 🧚PaddingMAY 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. 🌈Pad Lengthis 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. 💖Integrity Checksum Datais 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. 🔥 this checksum is non-negotiable, the MUST is doing a lot here 💀
Appendix B. Useful Optional Features
There are some optional features of IKEv2, which might be useful for minimal implementations in some scenarios. Such features include raw public keys authentication and sending an IKE SA delete notification. 🍓✨
B.1. IKE SA Delete Notification
In some scenarios, a minimal implementation device creates an IKE SA, sends one or few packets, perhaps gets some packets back, and then the device goes back to sleep, forgetting the IKE SA. In such scenarios, it would be nice for the minimal implementation to send the IKE SA delete notification to tell the other end that the IKE SA is going away, so it can free the resources. 😴💜
Deleting the IKE SA can be done by sending one packet with a fixed Message ID and with only one payload inside the Encrypted payload. The other end will send back an empty response:
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Initiator, Message ID=2),
SK {D} -->
<-- HDR(SPIi=xxx, SPIr=yyy, INFORMATIONAL,
Flags: Response, Message ID=2),
SK {}The Delete payload format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Num of SPIs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index(es) (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Delete Payload FormatProtocol ID(1 octet) - Must be 1 for an IKE SA. 🦋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 the message header). 🌸 for IKE the SPI lives in the header, so this one's a firm MUST zeroNum of SPIs(2 octets, unsigned integer) - The number of SPIs contained in the Delete payload. This MUST be zero for IKE. 💜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 Num of SPIs fields. This field is empty for the IKE SA delete. 🧚 empty for the IKE SA delete, so nothing to see here 🙈
B.2. Raw Public Keys ✨
okay so shared secret auth is lowkey not safe enough sometimes, bc anyone who knows the secret can impersonate the server 💀. if the secret is printed on the side of the device, anyone with physical access can just read it 🙈. so in those environments, public key auth gives you stronger authentication with minimal operational overhead 💅. certificate support is quite complex, and minimal implementations usually don't need it. raw public keys are way simpler and still scale similar to certs 🫶. the fingerprint of the raw public key can also be distributed by, like, printing it on the side of the device, so the setup feels just like using a shared secret 🎀
raw public keys can also do a "leap of faith" or baby duck style setup 🦆, where the device imprints on the first device it sees when it boots up for the first time 🥹. after that first connection, it stores the fingerprint of the server's raw public key in its own configuration and checks that it never changes (unless a "reset to factory settings" or similar command is issued) 🔥
this changes the initial IKE_AUTH payloads like this:
Initiator Responder
-------------------------------------------------------------------
HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH,
Flags: Initiator, Message ID=1),
SK {IDi, CERT, AUTH, SAi2, TSi, TSr,
N(INITIAL_CONTACT)} -->
<-- HDR(SPIi=xxx, SPIr=yyy, IKE_AUTH, Flags:
Response, Message ID=1),
SK {IDr, CERT, AUTH, SAr2, TSi, TSr}the CERT payloads contain the raw public keys used to sign the hash of the InitiatorSignedOctects/ResponderSignedOctects when generating an AUTH payload 🔐. minimal implementations should use SHA-1 as the hash function, bc that is the "SHOULD" support algorithm specified in RFC 7296, so it's the most likely one that all devices support 🧠
ngl this is the important bit: RFC 7296 already obsoleted the old Raw RSA Key method, and "Generic Raw Public-Key Support for IKEv2" [RFC7670] adds a new format so you can use any type of raw public key with IKEv2. this document only specifies how to use the new format 📌
in these setups, it might be possible that authenticating the server isn't needed at all 🤷♀️. like, if a minimal device is sending sensor info to the server, the server wants to verify that the sensor is who it claims to be using raw public keys, but the sensor doesn't really care who the server is. in cases like that, the NULL authentication method [RFC7619] would be useful, because it lets devices do one-way authentication 🦋
Acknowledgements 🙏
most of the content of this document is copied from RFC 7296 📚
Author's Address 🎀
Tero Kivinen
INSIDE Secure
Eerikinkatu 28
HELSINKI FI-00180
FINLAND
Email: kivinen@iki.fi📦 where this page comes from
- ietf: rfc7815 2016-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms