RFC 4430
Kerberized Internet Negotiation of Keys (KINK)
RFC 4430: Kerberized Internet Negotiation of Keys (KINK) ✨
part 1 of 9, more on the way bestie 🎀
- Network Working Group 💖 This is the group that put this spec together.
- Authors: S. Sakane and K. Kamada from Yokogawa Electric Corp., plus M. Thomas and J. Vilhuber from Cisco Systems 👑
- Category: Standards Track, so this is a real protocol spec 🔥
- Date: March 2006 🌸
- Obsoletes / Updates: the header doesn't list any, so this doc doesn't claim to replace or update another RFC 🦋
Status of This Memo 🌈
okay so this doc is a standards track spec for the internet community, and it's basically asking everyone to talk about it and send suggestions 🫶 For where this protocol stands in the official standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1). And yes, distribution is totally unlimited, so share away 💅
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract ✨
okay so KINK is the Kerberized Internet Negotiation of Keys 💖 It's a protocol that's low-latency, cheap on computation, easy to manage, and cryptographically solid, and it's used to set up and maintain security associations with Kerberos doing the authentication 🔐 The lowkey genius part is that KINK reuses the Quick Mode payloads from the Internet Key Exchange (IKE). That means existing IKE implementations can be reused a LOT 🤯
Table of Contents 🦋
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Protocol Overview ...............................................4
3. Message Flows ...................................................4
3.1. GETTGT Message Flow ........................................5
3.2. CREATE Message Flow ........................................6
3.2.1. CREATE Key Derivation Considerations ................7
3.3. DELETE Message Flow ........................................8
3.4. STATUS Message Flow ........................................9
3.5. Reporting Errors ...........................................9
3.6. Rekeying Security Associations ............................10
3.7. Dead Peer Detection .......................................10
3.7.1. Coping with Dead User-to-User Peers ................12
4. KINK Message Format ............................................13
4.1. KINK Alignment Rules ......................................15
4.2. KINK Payloads .............................................16
4.2.1. KINK_AP_REQ Payload ................................17
4.2.2. KINK_AP_REP Payload ................................18
4.2.3. KINK_KRB_ERROR Payload .............................19
4.2.4. KINK_TGT_REQ Payload ...............................20
4.2.5. KINK_TGT_REP Payload ...............................21
4.2.6. KINK_ISAKMP Payload ................................21
4.2.7. KINK_ENCRYPT Payload ...............................22
4.2.8. KINK_ERROR Payload .................................23
5. Differences from IKE Quick Mode ................................25
5.1. Security Association Payloads .............................26
5.2. Proposal and Transform Payloads ...........................26
5.3. Identification Payloads ...................................26
5.4. Nonce Payloads ............................................26
5.5. Notify Payloads ...........................................27
5.6. Delete Payloads ...........................................28
5.7. KE Payloads ...............................................28
6. Message Construction and Constraints for IPsec DOI .............28
6.1. REPLY Message .............................................28
6.2. ACK Message ...............................................28
6.3. CREATE Message ............................................29
6.4. DELETE Message ............................................30
6.5. STATUS Message ............................................31
6.6. GETTGT Message ............................................32
7. ISAKMP Key Derivation ..........................................32
8. Key Usage Numbers for Kerberos Key Derivation ..................33
9. Transport Considerations .......................................33
10. Security Considerations .......................................34
11. IANA Considerations ...........................................35
12. Forward Compatibility Considerations ..........................35
12.1. New Versions of Quick Mode ...............................36
12.2. New DOI ..................................................36
13. Related Work ..................................................36
14. Acknowledgements ..............................................37
15. References ....................................................37
15.1. Normative References .....................................37
15.2. Informative References ...................................381. Introduction 💖
okay so KINK is built to give you a secure, scalable way to set up keys between communicating entities in a centrally managed environment, where keeping security policy consistent really matters ✨ Its security goals are privacy, authentication, and replay protection for key management messages, plus avoiding denial of service vulnerabilities whenever possible 🛡️ On the performance side, the goals are low computational cost, low latency, and a small footprint. It also tries to avoid or minimize public key operations 🔑 The bit that's honestly iconic is that the protocol can set up IPsec security associations (SAs) in just two messages with minimal computation 🔥 These requirements are described in RFC 3129 [REQ4KINK].
Kerberos [KERBEROS] gives you an efficient authentication mechanism for clients and servers using a trusted third-party model 🎀 It also does cross-realm authentication natively, which is so clean. A client gets a ticket from an online authentication server, the Key Distribution Center (KDC). That ticket then gets used to build a credential for authenticating the client to the server 🧚 As a result of this authentication, the server also ends up sharing a secret key with the client. KINK uses this property as the basis for distributing keys for IPsec 🦋
Kerberos' central key management is efficient because it keeps computational cost and complexity down, compared to IKE, which needs public key cryptography [IKE] 💅 Initial authentication to the KDC can use either symmetric keys or asymmetric keys through the Public Key Cryptography for Initial Authentication in Kerberos [PKINIT]. Subsequent ticket requests, and the authenticated exchanges between the client and servers, always use symmetric cryptography though 🌸 So any public key operations (if there are any) are limited, and they get amortized over the lifetime of the credentials from the initial authentication to the KDC. For example, a client can do a single public key exchange with the KDC and then efficiently set up multiple SAs with many other servers in the KDC's realm 🙌 Kerberos also scales better than direct peer-to-peer keying when symmetric keys are used. The reason is that the keys live in the KDC, so the number of principal keys is O(n+m) instead of O(n*m), where "n" is the number of clients and "m" is the number of servers 💜
1.1. Conventions Used in This Document 📝
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] 🎀
It's assumed that readers already know the terms and concepts from Kerberos Version 5 [KERBEROS], IPsec [IPSEC], and IKE [IKE] 🧠
2. Protocol Overview 🌈
okay so KINK is a command/response protocol that can create, delete, and maintain IPsec SAs ✨ Each command or response has a common header plus a set of type-length-value payloads. The type of a command or response decides which payloads can be sent in the messages of that exchange 💖 KINK itself is stateless, meaning each command or response doesn't need to store hard state for KINK. This is the big contrast with IKE, which uses Main Mode to set up an Internet Security Association and Key Management Protocol (ISAKMP) SA first, and then does Quick Mode exchanges after that 🦋
KINK uses Kerberos mechanisms to get mutual authentication and replay protection 🔐 When setting up SAs, KINK gives confidentiality to the payloads that follow the Kerberos AP-REQ payload. The design also mitigates denial of service attacks by requiring authenticated exchanges before any public key operations or any state installation happens. That's a main character move 👑 KINK also gives you a way to use Kerberos User-to-User mechanisms when there isn't a key shared between the server and the KDC. This typically happens (though it's not limited to this) with IPsec peers that use PKINIT for initial authentication 🧚
KINK directly reuses the Quick Mode payloads defined in section 5.5 of [IKE], with a few minor changes and omissions 🌸 In most cases a KINK exchange is just one command and its response. An optional third message is required when creating SAs, but only if the responder rejects the first proposal from the initiator or wants to contribute keying materials 🫶 KINK also handles rekeying and dead peer detection, so it's fully covered 💅
3. Message Flows 🍓
All KINK message flows follow the same pattern between the two peers: a command, a response, and an optional acknowledgement in a CREATE flow ✨ A command is a GETTGT, CREATE, DELETE, or STATUS message. A response is a REPLY message, and an acknowledgement is an ACK message 💖
KINK uses Kerberos for authentication, so a KINK host needs to get a service ticket for each peer before the actual key negotiation starts 🎀 This is basically a pure Kerberos exchange, and the actual KDC traffic shown here is for illustrative purposes only 🧚 In practice, when a principal obtains its various tickets is a matter for Kerberos and local policy to decide 🦋 The one exception is the GETTGT message flow of KINK (described in section 3.1), which is used when User-to-User authentication is required. In that flow, we assume that both A and B already have ticket-granting tickets (TGTs) from their KDCs 👑
After a service ticket is obtained, KINK uses the CREATE message flow (section 3.2), the DELETE message flow (section 3.3), and the STATUS message flow (section 3.4) to manage SAs 🌈 In these flows, we assume that A already has a service ticket for B 💜
3.1. GETTGT Message Flow 🎀
okay bestie, this flow is how you grab a TGT from the remote peer when you're in User-to-User authentication mode 🦋
so like, if the initiator figures out it's not gonna be able to get a normal (non-User-to-User) service ticket for the responder, it can try User-to-User auth instead 💅 in that case it first goes and fetches a TGT from the responder so it can get a User-to-User service ticket:
A B KDC
------ ------ ---
1 GETTGT+KINK_TGT_REQ------>
2 <-------REPLY+KINK_TGT_REP
3 TGS-REQ+TGT(B)------------------------------------>
4 <-------------------------------------------TGS-REP
Figure 1: GETTGT Message Flowthe initiator MAY support these events as triggers to head down the User-to-User path 🌸 heads up though, the two errors below are NOT authenticated, so how you act on them is up to your policy 🙈
- The local policy says that the responder requires a User-to-User authentication.
- A
KRB_AP_ERR_USER_TO_USER_REQUIREDerror is returned from the responder. - A
KDC_ERR_MUST_USE_USER2USERerror is returned from the KDC.
3.2. CREATE Message Flow ✨
this one is giving optimistic energy 🔥 the CREATE command takes an "optimistic" approach, where SAs get created on the expectation that the responder will just pick the initial proposed payload. the optimistic proposal lives in the first transform payload(s) of the first proposal.
the initiator MUST check whether the optimistic proposal was selected by comparing all transforms and attributes. they have to be identical to the ones in the initiator's optimistic proposal, except for LIFE_KILOBYTES and LIFE_SECONDS. each of those attributes MAY be set to a lower value by the responder and still expect optimistic keying, but it MUST NOT set one to a higher value, because that MUST generate a NO-PROPOSAL-CHOSEN error 😭 and the initiator MUST use the shorter lifetime 💜
when a CREATE command contains an existing Security Parameter Index (SPI), the responder MUST reject it and SHOULD return an ISAKMP notification with INVALID-SPI 🙅♀️
when a key exchange (KE) payload is sent from the initiator but the responder does not support it, the responder MUST reject it with an ISAKMP notification of INVALID-PAYLOAD-TYPE containing a KE payload type as its notification data. when the initiator gets this error, it MAY retry without a KE payload (as another transaction) if its policy allows that 🌈
A B KDC
------ ------ ---
A creates an optimistic inbound SA (B->A) unless using a KE.
1 CREATE+ISAKMP------------>
B creates an inbound SA (A->B).
B creates an outbound SA (B->A) if optimistic and not using a KE.
2 <-------------REPLY+ISAKMP
A creates an outbound SA (A->B).
A replaces an inbound SA (B->A) if non-optimistic.
A creates an inbound SA (B->A) if using a KE.
3 [ ACK---------------------> ]
[ B creates an outbound SA (B->A). ]
Figure 2: CREATE Message Flowcreating SAs has two modes: 2-way handshake and 3-way handshake 🎀 the initiator usually starts out expecting a 2-way handshake. if the responder doesn't pick the optimistic proposal, the negotiation switches to a 3-way handshake. and when and ONLY when the initiator uses a KE payload, the 3-way handshake is expected from the very beginning 👑
here's the 2-way handshake, step by step:
- The host A creates an inbound SA (B->A) in its SA database using the optimistic proposal in the ISAKMP SA proposal. It is then ready to receive any messages from B.
- A then sends the CREATE message to B.
- If B agrees to A's optimistic proposal, B creates an inbound SA (A->B) and an outbound SA (B->A) in its database. If B does not choose the first proposal or wants to add a Nonce payload, switch to step 3 of the 3-way handshake described below.
- B then sends a REPLY to A without a Nonce payload and without requesting an ACK.
- Upon receipt of the REPLY, A creates an outbound SA (A->B).
and here's the 3-way handshake 💅
- The host A sends the CREATE message to B without creating any SA.
- B chooses one proposal according to its policy.
- B creates an inbound SA (A->B) and sends the actual choice in the REPLY. It SHOULD send the optional Nonce payload (as it does not increase message count and generally increases entropy sources) and MUST request that the REPLY be acknowledged 🫶
- Upon receipt of the REPLY, A creates the inbound SA (B->A) (or modifies it as necessary, if switched from 2-way), and the outbound SA (A->B).
- A now sends the ACK message.
- Upon receipt of the ACK, B installs the final outbound SA (B->A).
if B doesn't choose the first proposal, adds a nonce, or accepts the KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit) so it can install the final outbound SA. and the initiator MUST always generate an ACK if the ACKREQ bit is set in the KINK header, even if it thinks the responder messed up 🙈
3.2.1. CREATE Key Derivation Considerations 🧚
the CREATE command's optimistic approach lets an SA get created in two messages instead of three ✨ the catch is that B won't contribute to the key, since A has to set up the inbound SA before it gets any extra keying material from B. ngl that may seem sus under normal circumstances 😳 but KINK takes advantage of the fact that the KDC provides a reliable source of randomness, which gets used in key derivation. in lots of cases, that gives you an adequate session key, so B won't need an acknowledgement. since B is always free to contribute to the keying material, this is really just a trade-off between key strength and number of messages, and KINK implementations may decide that as a matter of policy 🦋
3.3. DELETE Message Flow 💀
the DELETE command deletes existing SAs. the domain of interpretation (DOI)-specific payloads describe the actual SA to be deleted. for the IPsec DOI, those payloads include an ISAKMP payload with the list of SPIs to be deleted 🍓
A B KDC
------ ------ ---
A deletes outbound SA to B.
1 DELETE+ISAKMP------------>
B deletes inbound and outbound SA to A.
2 <-------------REPLY+ISAKMP
A deletes inbound SA to B.
Figure 3: DELETE Message Flowthe DELETE command takes a "pessimistic" approach, so it doesn't delete inbound SAs until it hears back that the other host got the DELETE 🥺 the exception is if the initiator wants to immediately cease all activity on an inbound SA. in that case it MAY delete the inbound SA as well in step 1, above 🌸
the ISAKMP payload contains ISAKMP Delete payload(s) that indicate the inbound SA(s) for the initiator of this flow. KINK does NOT allow half-open SAs, so when the responder gets a DELETE command, it MUST delete SAs of both directions, and it MUST reply with ISAKMP Delete payload(s) that indicate the inbound SA(s) for the responder of this flow. if the responder can't find an appropriate SPI to delete, it MUST return an ISAKMP notification with INVALID_SPI, which also tells the initiator that it can delete the inbound SA 🙌
okay so there's a race condition with the DELETE flow 🏃♀️ because of network reordering and stuff, packets that are still in flight while the DELETE is happening might show up after the diagrams above, which suggest deleting the inbound SA. a KINK implementation SHOULD implement a grace timer, which SHOULD be set to a period of at least two times the average round-trip time, or to a configurable value. a KINK implementation MAY choose to set the grace period to zero at appropriate times to delete an SA ungracefully 💅 this behavior is borrowed from how TCP [RFC793] handles the FIN and RST flags, fr fr 🎀
3.4. STATUS Message Flow 🫧
this flow is used to send any info to a peer or to get info out of a peer 🍭 an initiator can send a STATUS command to the responder at any time, optionally with DOI-specific ISAKMP payloads. for the IPsec DOI, these are usually ISAKMP Notification payloads. a STATUS command is also used as a means of dead peer detection, which is described in section 3.7 🧚
A B KDC
------ ------ ---
1 STATUS[+ISAKMP]---------->
2 <-----------REPLY[+ISAKMP]
Figure 4: STATUS Message Flow3.5. Reporting Errors 🚨
when the responder spots an error in a received command, it can send a DOI-specific payload to show the error in a REPLY message 💖 there are three types of payloads that can carry errors: KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for KINK errors, and KINK_ISAKMP payloads for ISAKMP errors. the details are in sections 4.2.3, 4.2.8, and 4.2.6, respectively 📖
if the initiator finds an error in a received reply, there's no way to report it back to the responder 😩 the initiator SHOULD log the event, and it MAY take a remedial action by reinitiating the initial command 🔁
if the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. the optional client's time in the KRB-ERROR SHOULD be filled out. if the server protects the error by adding the Cksum field and returning the correct client's time, the client SHOULD compute the difference (in seconds) between the two clocks, based on the client and server time in the KRB-ERROR message. the client SHOULD store this clock difference and use it to adjust its clock in subsequent messages ⏰
🚨 bestie, this part is SO serious. if the error is NOT protected, the client MUST NOT use the difference to adjust subsequent messages, because doing so would let an attacker construct authenticators that can be used to mount replay attacks. do not skip this 💀🔥
3.6. Rekeying Security Associations ✨
Okay so KINK says the initiator of an SA is the one in charge of rekeying it 💅 There are two reasons. First, it stops needless duplicate SAs from showing up when the initiator and responder both try to renew the same SA at the same time (collisions are chaos 😭). Second, Kerberos is client/server, and in Kerberos the client is the one who gets and maintains tickets. KINK expects a KINK host to be able to get and keep tickets, but honestly, servers usually like to wait for clients to start sessions so they don't have to hoard a huge ticket cache 🧚
There are no special rekeying semantics in KINK 🎀 To rekey an existing SA, the initiator has to CREATE a new SA, and then either DELETE the old one using the DELETE flow or just let it time out. When identical flow selectors show up on different SAs, KINK implementations SHOULD choose the SA that was created most recently. Also, KINK dodges most of the headaches that come with [IKE] rekeying because it has a reliable delete mechanism. Main character energy 👑
Normally, a KINK implementation that rekeys existing SAs tries to do it ahead of the SA ending. That ending could be the hard lifetime (in time or bytecount) or the sequence number counter overflowing. This early point is called the "soft lifetime" 🦋 The soft lifetime MUST be randomized so that similar implementations don't all rekey at the exact same moment (synchronization is giving chaos). For the time-based lifetime, one reasonable approach is to pick a random time between T-rekey and T-retrans and subtract it from the hard lifetime. Here, T-rekey is the reasonable maximum rekeying margin, and T-retrans is how long a full retransmission cycle takes 🌸 T-rekey SHOULD be at least twice as high as T-retrans. Iconic planning, honestly 💖
3.7. Dead Peer Detection 💀
Okay this one's important. To figure out that a KINK peer has lost its security database information, KINK peers MUST record the current epoch for which they have valid SA information for a peer, and they MUST reflect that epoch in each AP-REQ and AP-REP message 🍓 When a KINK peer creates state for a given SA, it MUST also record the principal's epoch. If it later finds out in a subsequent message that the principal's epoch has changed, it MUST consider all SAs created by that principal invalid, and then take some action, like tearing those SAs down 😭
Peers SHOULD use routing feedback (in the form of ICMP messages) as a trigger to check whether the peer is still alive 🔥 But a KINK peer MUST NOT conclude that the peer is dead just from unprotected routing information (aka said ICMP messages). Not on my watch 🙅♀️
If there's any suspicion that a peer might be dead (based on any information the KINK peer has, including a lack of IPsec traffic, etc.), the KINK STATUS message SHOULD be used to coax an acknowledgement out of the peer 🫶 Since nothing is negotiated about dead peer detection in KINK, each peer gets to decide its own metric for "suspicion," and also which timeouts to use before declaring a peer dead for not responding to the STATUS message. That's desirable, and it does not break interoperability ✨
The STATUS message has a twofold effect 🦋 First, it gets a cryptographically secured (and replay-protected) response from the peer, which tells us whether the peer is reachable/alive. Second, it carries the peer's epoch number, so we can tell whether the peer has rebooted and lost all its state. This is crucial to KINK. In IKE, if a peer reboots, all the cryptographic context is gone, and no cryptographically secure communication is possible without renegotiating keys. In KINK, because of Kerberos tickets, we can keep communicating securely with a peer even after it rebooted, since the shared cryptographic key is carried in the Kerberos ticket 🎀 So active cryptographic communication does not tell you that the peer hasn't rebooted and lost all its state, and that's exactly why the epoch is needed 🙈
Let's say Peer A sends a STATUS and Peer B sends back the REPLY (see section 3.4). Peer B MAY assume that the sender is alive, and the epoch in the STATUS message will show whether Peer A has lost state. Peer B MUST acknowledge the STATUS message with a REPLY message, as described in section 3.4 🌈
The REPLY message tells Peer A that the peer is alive, and the epoch in the REPLY shows whether Peer B has lost its state or not 💜 If Peer A doesn't get a REPLY from Peer B within a suitable timeout, Peer A MAY send another STATUS message. It's up to Peer A to decide how aggressively to declare Peer B dead. That level of aggressiveness can depend on lots of things, like rapid failover versus the number of messages sent by nodes with huge numbers of SAs 🍓
Note that Peer B MUST NOT make any inferences about a lack of STATUS messages from Peer A 🙅♀️ Peer B MAY use a STATUS message from Peer A as an indication of A's aliveness, but Peer B MUST NOT expect another STATUS message at any time (i.e., dead peer detection is not periodic keepalives). Bestie, DPD is not a heartbeat 💀
Here are the strategies for sending STATUS messages 🧚 Peer A may decide to send a STATUS message only after a prolonged period where no traffic was sent in either direction over the IPsec SAs with the peer. Once traffic shows up, Peer A may want to know whether that traffic is going into a black hole, so it sends a STATUS message. Alternatively, Peer A may use an idle timer to detect a lack of traffic with the peer, and send STATUS messages during the quiet phase to make sure the peer is still alive before traffic needs to finally be sent 🌸
3.7.1. Coping with Dead User-to-User Peers 🫠
Here's the tricky part. When an initiator uses a User-to-User ticket and a responder has lost its previous TGT, the usual dead peer detection (DPD) mechanism does not work, because the responder can't decrypt the ticket with its new TGT 😭 So in this case, the following actions happen:
- When the responder receives a KINK command with a User-to-User ticket that can't be decrypted with its TGT, it returns a REPLY with a
KINK_TGT_REPpayload containing the TGT. - When the initiator receives a
KINK_TGT_REP, it retrieves a new service ticket with the TGT and retries the command.
This doesn't actually define a way to detect a dead User-to-User peer 🙃 It's about recovering from the situation where the responder doesn't have the right TGT to decrypt a service ticket sent by the initiator. After recovery, they can exchange their epochs, and the usual DPD mechanism will detect a dead peer if it really has been dead ✨
The initiator MUST NOT think the peer is dead just because it got a KINK_TGT_REP, for two reasons. One is that the message is not authenticated. The other is that losing a TGT doesn't necessarily mean losing the SA database information 🎀 The initiator SHOULD NOT forget the previous service ticket until the new one has been successfully obtained, which keeps the cost down if a forged KINK_TGT_REP shows up 🛡️ Protecting your tickets is literally self-care 💅
4. KINK Message Format ✨
okay so bestie, first things first: every value in KINK is in network byte order (most significant byte first) 🫶 and the RESERVED fields MUST be set to zero (0) when a packet is sent 🧚. The receiver MUST ignore these fields 💅.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer |RESRVED| Length |
+---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+
| Transaction ID (XID) |
+---------------+-+-------------+-------------------------------+
| NextPayload |A| RESERVED2 | CksumLen |
+---------------+-+-------------+-------------------------------+
| |
~ A series of payloads ~
| |
+-------------------------------+-------------------------------+
| |
~ Cksum (variable) ~
| |
+-------------------------------+-------------------------------+Figure 5: Format of a KINK Message 🎀
Here's the breakdown, fr fr:
- Type (1 octet) -- The type of this message. Here's the vibe check 💖:
Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6
RESERVED TO IANA 7 - 127
Private Use 128 - 255- MjVer (4 bits) -- The major protocol version number. It is literally just 1, so it MUST be set to 1 🌸.
- RESRVED (4 bits) -- Reserved. It MUST be zero when sent and MUST be ignored when received 🦋.
- Length (2 octets) -- The length of the message in octets. Extra stuff after the message isn't forbidden in KINK, lowkey, but the Length field MUST represent the actual length of the message 📏.
- DOI (4 octets) -- The domain of interpretation. All DOIs must be registered with the IANA in the ISAKMP Domain of Interpretation section of the isakmp-registry [ISAKMP-REG]. The IANA Assigned Number for the Internet IP Security DOI [IPDOI] is one (1). This field defines the context of all sub-payloads in this message. If sub-payloads have a DOI field (e.g., Security Association Payload), then the DOI in that sub-payload MUST be checked against the DOI in this header, and the values MUST be the same 🔥.
- XID (4 octets) -- The transaction ID. A KINK transaction is bound together by a transaction ID, which the command initiator creates and copies into every message after it in the transaction. A transaction is a command, a reply, and an optional acknowledgement. The initiator uses transaction IDs to tell apart multiple outstanding requests to a responder 🧚. XID is NOT used for replay protection, because Kerberos handles that job 🙈. The initiator chooses the value of XID, and it MUST be unique across all outstanding transactions. XIDs MAY be built with a monotonic counter or a random number generator 🎲.
- NextPayload (1 octet) -- Tells you the type of the first payload after the message header 👑.
- A, or ACKREQ (1 bit) -- ACK Request. It's set to one if the responder needs an explicit acknowledgement that a REPLY was received. An initiator MUST NOT set this flag, and a responder should not either, except for a REPLY to a CREATE when the optimistic proposal is chosen 💅.
- RESERVED2 (7 bits) -- Reserved. It MUST be zero on send and MUST be ignored by a receiver 🌈.
- CksumLen (2 octets) -- The length in octets of the cryptographic checksum of the message. A CksumLen of zero means the message is unauthenticated 🍓.
- Cksum (variable) -- This is the Kerberos keyed checksum over the entire message, except for the Cksum field itself. Any padding bytes between the last payload and the Cksum field MUST be included in the calculation 🧮. This field MUST always be present whenever a key is available via an AP-REQ or AP-REP payload. The key used MUST be the session key in the ticket. When no key is available, this field is not present and the CksumLen field is set to zero 🫠. The content of this field is the output of the Kerberos 5 get_mic function [KCRYPTO]. The get_mic function is specified by a checksum type, which is a "required checksum mechanism" of the etype for the Kerberos session key in the Kerberos ticket. If the checksum type is not a keyed algorithm, the message MUST be rejected 🚫.
To compute the checksum, you zero out the CksumLen field and fill the Length field with the total packet length without the checksum. Then you pass the packet to the get_mic function and append its output to the packet. KINK padding after the Cksum field isn't allowed, except for the Kerberos internal padding, which may be included in the output of the get_mic function 🧁. Finally, you fill in the CksumLen field with the checksum length and the Length field with the total packet length, checksum included ✨.
To verify the checksum, you work out a length-without-checksum from the Length field by subtracting CksumLen. Set the Length field to that length-without-checksum value and zero out the CksumLen field. Then pass the packet without checksum (offset 0 through length-without-checksum minus 1 of the received packet) and the checksum (offset length-without-checksum through the last octet) to the verify_mic function. If verification fails, the message MUST be dropped 💀.
The KINK header is followed immediately by a series of Type/Length/Value fields, defined in section 4.2 🎀.
4.1. KINK Alignment Rules
KINK has some rules about alignment and padding, and they're kinda strict 🙈:
- All length fields MUST reflect the actual number of octets in the structure. In other words, they do not count padding bytes that KINK alignment requires 📐.
- KINK headers, payloads, and the Cksum field MUST be aligned on 4-octet boundaries 🧱.
- Variable length fields (except the Cksum field) MUST always start immediately after the last octet of the previous field. They are NOT aligned to 4-octet boundaries, so don't go looking for padding there 🦋.
4.2. KINK Payloads
Right after the header comes a list of Type/Length/Value (TLV) payloads 🧚. There can be any number of payloads after the header. Each payload MUST begin with a payload header, and every payload header is built on the generic payload header. Any data immediately follows the generic header. Payloads are all implicitly aligned to 4-octet boundaries, though the payload length field MUST accurately reflect the actual number of octets in the payload 💜.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| value (variable) |
+---------------+---------------+---------------+---------------+Figure 6: Format of a KINK Payload 🌸
Fields:
- Next Payload (1 octet) -- The type of the next payload. Check out the lineup 👀:
NextPayload Value
---- -----
KINK_DONE 0
KINK_AP_REQ 1
KINK_AP_REP 2
KINK_KRB_ERROR 3
KINK_TGT_REQ 4
KINK_TGT_REP 5
KINK_ISAKMP 6
KINK_ENCRYPT 7
KINK_ERROR 8
RESERVED TO IANA 9 - 127
Private Use 128 - 255A Next Payload type of KINK_DONE means the current payload is the final payload in the message 🏁.
- RESERVED (1 octet) -- Reserved. It MUST be set to zero by a sender and MUST be ignored by a receiver 🫶.
- Payload Length (2 octets) -- The length of this payload, including the type and length fields 📏.
- Value (variable) -- What goes here depends on the type of the payload ✨.
4.2.1. KINK_AP_REQ Payload 🎀
okay bestie, this payload is how the initiator delivers a Kerberos AP-REQ to the responder 💌 and the AP-REQ MUST request mutual authentication ✨ no skipping that!!
this doc doesn't say how to generate the principal name 🤷♀️ you could keep complete principal names in local policy, turn Fully Qualified Domain Names (FQDNs) into principal names, convert IP addresses into principal names with secure name services, etc. but see the first paragraph of the Security Considerations section 💀
if the peer's principal name for the KINK service comes from an FQDN, the principal name the initiator starts from will be kink/fqdn@REALM 🦋 where kink is a literal string for the KINK IPsec service, fqdn is the fully qualified domain name of the service host, and REALM is the Kerberos realm of the service. principal names are case sensitive, and the fqdn part MUST be lowercase as described in [KERBEROS] 🫶
the value field of this payload looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REQ ~
| |
+---------------------------------------------------------------+
Figure 7: KINK_AP_REQ PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- EPOCH -- the absolute time at which the creator of the AP-REQ has valid SA information. typically this is when the KINK keying daemon started, if it doesn't keep SA information across restarts ⏰ the value here is the least significant 4 octets of so-called POSIX time, which is the elapsed seconds (but not counting leap seconds) from
1970-01-01T00:00:00 UTC. for example,2038-01-19T03:14:07 UTCis represented as0x7fffffff🧚 - AP-REQ -- the value field of this payload contains a raw Kerberos AP-REQ 💜
4.2.2. KINK_AP_REP Payload 🌈
the KINK_AP_REP payload relays a Kerberos AP-REP back to the initiator 📬 and the AP-REP MUST be checked for freshness as described in [KERBEROS] 🕵️♀️
the value field of this payload looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| |
~ AP-REP ~
| |
+---------------------------------------------------------------+
Figure 8: KINK_AP_REP PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- EPOCH -- the absolute time at which the creator of the AP-REP has valid SA information. typically this is when the KINK keying daemon started, if it doesn't keep SA information across restarts ⏰ the value here is the least significant 4 octets of so-called POSIX time, which is the elapsed seconds (but not counting leap seconds) from
1970-01-01T00:00:00 UTC. for example,2038-01-19T03:14:07 UTCis represented as0x7fffffff🧚 - AP-REP -- the value field of this payload contains a raw Kerberos AP-REP 💜
4.2.3. KINK_KRB_ERROR Payload 💀
the KINK_KRB_ERROR payload relays Kerberos errors back to the initiator 🚨 the initiator MUST be prepared to receive any valid Kerberos error type [KERBEROS] 😭
KINK implementations SHOULD make use of a KINK Cksum field when returning KINK_KRB_ERROR and the right service key is available 🔐 especially with clock skew errors, protecting the error at the server gives a better user experience because clocks don't have to be synchronized. however, lots of Kerberos implementations don't make it easy to grab the session key to protect error packets 🙄 for unauthenticated Kerberos errors, the initiator MAY choose to act on them, but SHOULD take precautions against make-work kinds of attacks 🛡️
note that KINK doesn't use the text or e_data field of the Kerberos error message 🙈 still, a compliant KINK implementation MUST be prepared to receive them and MAY log them 📝
the value field of this payload looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ KRB-ERROR ~
| |
+---------------------------------------------------------------+
Figure 9: KINK_KRB_ERROR PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- KRB-ERROR -- the value field of this payload contains a raw Kerberos KRB-ERROR 💜
4.2.4. KINK_TGT_REQ Payload 🎟️
the KINK_TGT_REQ payload gives you a way to get a TGT from the peer, so you can grab a User-to-User service ticket from the KDC 👑
the value field of this payload looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ PrincName (variable) ~
| |
+---------------------------------------------------------------+
Figure 10: KINK_TGT_REQ PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- PrincName -- the name of the principal the initiator wants to talk to 🗣️ it's assumed the initiator knows the responder's principal name (realm name included) the same way as in the non-User-to-User case. the TGT returned MUST NOT be an inter-realm TGT, and its cname and crealm MUST match the requested principal name, so the initiator can rendezvous with the responder at the responder's realm 🦋
PrincName values are octet string representations of a principal and realm name, formatted just like the octet string used in the "NAME" component of the Generic Security Service Application Program Interface (GSS-API) [RFC2743] exported name token for the Kerberos V5 GSS-API mechanism [RFC1964]. see RFC 1964, section 2.1.3 ✨
if the responder isn't the requested principal and can't get a TGT for that name, it MAY return a KRB_AP_ERR_NOT_US 🙅♀️ if administrative policy prohibits returning a TGT, it MAY return a KINK_U2UDENIED 🚫
4.2.5. KINK_TGT_REP Payload 🍓
the value field of this payload contains the TGT that was requested in a previous KINK_TGT_REQ payload of a GETTGT command 🎁
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| |
~ TGT (variable) ~
| |
+---------------------------------------------------------------+
Figure 11: KINK_TGT_REP PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- TGT -- the Distinguished Encoding Rules (DER)-encoded TGT of the responder 💅
4.2.6. KINK_ISAKMP Payload 🌸
the value field of this payload looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+-------+-------+---------------+---------------+
| InnerNextPload| QMMaj | QMMin | RESERVED |
+---------------+-------+-------+---------------+---------------+
| Quick Mode Payloads (variable) |
+---------------+---------------+---------------+---------------+
Figure 12: KINK_ISAKMP PayloadFields:
- Next Payload, RESERVED, Payload Length -- defined at the beginning of this section 🌸
- InnerNextPload -- first payload type of the inner series of ISAKMP payloads 🧩
- QMMaj -- the major version of the inner payloads. MUST be set to 1 🔢
- QMMin -- the minor version of the inner payloads. MUST be set to 0 🔢
the KINK_ISAKMP payload wraps up the IKE Quick Mode (phase 2) payloads so they can take the right action depending on the KINK command 🎀 there can be any number of KINK_ISAKMP payloads inside a single KINK message. [IKE] is kinda fuzzy about whether multiple different SAs can be created in a single IKE message, but KINK explicitly requires that a new ISAKMP header be used for each discrete SA operation. in other words, a KINK implementation MUST NOT send multiple Quick Mode transactions within a single KINK_ISAKMP payload 🙅♀️
the Quick Mode version is there so you can stay backward compatible with IKE and ISAKMP if there are later revisions 🔮 right now, the Quick Mode major and minor versions are set to one and zero (1.0). these don't line up with the ISAKMP version in the ISAKMP header 🙃 a compliant KINK implementation MUST support receiving 1.0 payloads. it MAY support later versions (both sending and receiving), and SHOULD provide a way to fall back to Quick Mode version 1.0 if the KINK peer can't process future versions 🔁 and a compliant KINK implementation MUST NOT mix Quick Mode versions in any given transaction 🚫💖
4.2.7. KINK_ENCRYPT Payload 🔐
okay so the KINK_ENCRYPT payload is basically a little secret box 🎁 that wraps up other KINK payloads and locks them with the session key and whatever algorithm its etype names. this payload MUST be the very last one in the outer payload chain of the message, bestie. and the box MUST be sealed (encrypted) before the final KINK checksum goes on top 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED2 |
+---------------+---------------+---------------+---------------+
| Payload (variable) |
+---------------+---------------+---------------+---------------+ Figure 13: KINK_ENCRYPT PayloadFields:
Next Payload,RESERVED,Payload Length-- Defined in the beginning of this section. This payload is the last one in a message, and accordingly, theNext Payloadfield must beKINK_DONE(0). 🏁InnerNextPload-- First payload type of the inner series of encrypted KINK payloads. 👀RESERVED2-- Reserved and MUST be zero when sent, MUST be ignored when received. 🫧
the encryption covers everything starting at InnerNextPload, so the type of the very first payload stays confidential 🤫 that means the number of encrypted octets is PayloadLength - 4. lowkey genius.
the format follows the normal Kerberos semantics. the content is the output of an encrypt function defined in the Encryption Algorithm Profile section of [KCRYPTO] 🔑 the encrypt function itself, the specific-key, and the initial state are all defined along with the etype. the encrypt function may have padding built in, and there may be some garbage data at the end of the decrypted plaintext 🗑️ a KINK implementation MUST be prepared to ignore that padding after the last sub-payload inside the KINK_ENCRYPT payload. no drama, just ignore it ✨
also, each encrypt function has its own integrity protection mechanism. it's redundant with the checksum in the KINK header, but it's unavoidable because you can't always strip the integrity part out of the encrypt function 🙃 double-checked, bestie.
4.2.8. KINK_ERROR Payload 🚨
the KINK_ERROR payload is the protocol-level way of saying "ope, something's wrong" 💀 this payload should not be used for Kerberos-generated errors or DOI-specific errors that already have their own payloads defined. the error code is in network order.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| ErrorCode |
+---------------+---------------+---------------+---------------+ Figure 14: KINK_ERROR PayloadFields:
Next Payload,RESERVED,Payload Length-- Defined in the beginning of this section.ErrorCode-- One of the following values in the network byte order:
ErrorCode Value Purpose
--------- ----- -------------------
KINK_OK 0 No error detected
KINK_PROTOERR 1 The message was malformed
KINK_INVDOI 2 Invalid DOI
KINK_INVMAJ 3 Invalid Major Version
RESERVED 4
KINK_INTERR 5 An unrecoverable internal error
KINK_BADQMVERS 6 Unsupported Quick Mode Version
KINK_U2UDENIED 7 Returning a TGT is prohibited
RESERVED TO IANA 8 - 8191
Private Use 8192 - 16383
RESERVED 16384 -the responder MUST NOT return KINK_OK 🙅♀️ when the initiator receives a KINK_ERROR payload, it MAY act as if that specific payload were not there. if the initiator supports multiple Quick Mode versions or DOIs, and KINK_BADQMVERS or KINK_INVDOI shows up and the Cksum checks out, it MAY retry with another version or DOI 🔁 a responder SHOULD return a KINK error with KINK_INVMAJ when it gets a KINK version number in the header it doesn't support. and when KINK_U2UDENIED lands, the initiator MAY retry with the non-User-to-User mode (if it hasn't tried that yet) 🥺
in general, the responder MAY choose to return these errors in reply to unauthenticated commands, but SHOULD take care to avoid getting caught up in denial of service attacks 🛡️ same energy the other way: the initiator MAY choose to act on unauthenticated errors, but SHOULD take care to avoid denial of service attacks too. stay safe out there, bestie 🫶
5. Differences from IKE Quick Mode 🎀
okay so KINK uses ISAKMP payloads directly to negotiate SAs 🤝 specifically, it uses the IKE phase 2 payload types (aka Quick Mode). honestly there should be very few changes needed to an IKE implementation to set up the SAs, and unless the memo says otherwise, all capabilities and requirements in [IKE] MUST be supported ✨ IKE phase 1 payloads MUST NOT be sent. no phase 1 vibes allowed 🚫
unlike IKE, KINK defines specific commands for creating, deleting, and checking the status of SAs, mainly so SA creation and deletion stay predictable (see sections 3.2 and 3.3) 📋 because of that, KINK puts certain restrictions on which payloads can go with which commands, plus some extra restrictions and semantics for some of the payloads. implementors should refer to [IKE] and [ISAKMP] for the actual format and semantics. if a particular IKE phase 2 payload isn't mentioned here, that means there are no differences in how it's used 💖
- The Security Association Payload header for IP is defined in section 4.6.1 of [IPDOI]. For this memo, the Domain of Interpretation MUST be set to 1 (IPsec) and the Situation bitmap MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted (because SIT_IDENTITY_ONLY is set). 🧾
- KINK also expands the semantics of IKE by defining an optimistic proposal for CREATE commands, so SA creation can wrap up in two messages ⚡
- IKE Quick Mode (phase 2) uses the hash algorithm from main mode (phase 1) to generate the keying material. For this purpose, KINK MUST use a pseudo-random function determined by the etype of the session key 🎲
- KINK does not use the HASH payload at all. bye, HASH 👋
- KINK allows the Nonce payload Nr to be optional to make optimistic keying easier 🌸
5.1. Security Association Payloads 🧁
KINK supports the following SA attributes from [IPDOI]:
class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 BRefer to [IPDOI] for the actual definitions of these attributes 📖
5.2. Proposal and Transform Payloads 🍓
KINK uses the Proposal and Transform payloads directly with no differences 🙌 the twist is that KINK gives extra relevance to the first proposal and the first transform of each conjugate for optimistic keying. first is the new best 🥇
5.3. Identification Payloads 🪪
The Identification payload carries information used to identify the traffic that the SA being established will protect 🛡️ KINK restricts the ID types (defined in section 4.6.2.1 of [IPDOI]) to the following values:
ID Type Value
------- -----
ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 85.4. Nonce Payloads 🎲
The Nonce payload contains random data that MUST be used in key generation. It MUST be sent by the initiating KINK peer, and MAY be sent by the responding KINK peer ✨ see section 7 for the discussion of how it's used in key generation.
5.5. Notify Payloads 📣
Notify payloads transmit informational data, like error conditions and state transitions, to a peer 💬 for example, they can carry error messages explaining why an SA couldn't be established. they can also carry status data that a process managing an SA database wants to share with a peer process.
Types in the range 0 - 16383 are intended for reporting errors [ISAKMP]. An implementation receiving a type in this range that it does not recognize in a response MUST assume that the corresponding request has failed entirely 💀 unrecognized error types in a request, and status types in a request or response, MUST be ignored, and they SHOULD be logged. Notify payloads with status types MAY be added to any message and MUST be ignored if not recognized. they're meant to indicate capabilities, and as part of SA negotiation they're used to negotiate non-cryptographic parameters 🧠
the table below lists the Notification messages and their values. PAYLOAD-MALFORMED stands for some error types defined by [ISAKMP]. so INVALID-PROTOCOL-ID, for example, isn't used in this document. INVALID-MAJOR-VERSION and INVALID-MINOR-VERSION aren't used either, because KINK_BADQMVERS is what tells the initiator that the IKE version isn't supported 🙈
NOTIFY MESSAGES - ERROR TYPES Value
----------------------------- -----
INVALID-PAYLOAD-TYPE 1
Sent if the ISAKMP payload type is not recognized. It is also
sent when the KE payload is not supported by the responder.
Notification Data MUST contains the one-octet payload type.
INVALID-SPI 11
Sent if the responder has an SPI indicated by the initiator in
case of CREATE flow, or if the responder does not have an SPI
indicated by the initiator in case of DELETE flow.
NO-PROPOSAL-CHOSEN 14
Sent if none of the proposals in the SA payload was
acceptable.
PAYLOAD-MALFORMED 16
Sent if the KINK_ISAKMP payload received was invalid because
some type, length, or value was out of range. It is also sent
when the request was rejected for reason that was not matched
with other error types.5.6. Delete Payloads 🗑️
KINK uses ISAKMP Delete payloads directly with no changes. easy peasy 💅
5.7. KE Payloads 🔥
IKE requires that perfect forward secrecy (PFS) be supported through the use of the KE payload. KINK keeps the ability to use PFS, but relaxes the requirement from must implement to SHOULD implement. the reasons are described in the Security Considerations section 🥹 we'll get there, bestie 💜
6. Message Construction and Constraints for IPsec DOI ✨
okay so every command, response, and acknowledgement is linked together by the XID field in the message header 🎀 The XID is usually a monotonically incrementing field, and the initiator uses it to keep track of its outstanding requests to a responder 💅 The XID does NOT give you replay protection, because that job belongs to the Kerberos mechanisms 🙈 Also, commands and responses MUST use a cryptographic checksum over the entire message if the two peers share a key through a ticket exchange 🔐
In every case in this section, if a message contains a KINK_AP_REQ or KINK_AP_REP payload, other KINK payloads MAY be wrapped inside a KINK_ENCRYPT payload 🧚
6.1. REPLY Message 💌
the REPLY message is the generic reply bestie 💖 It MUST contain either a KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload. REPLY messages MAY also carry extra DOI-specific payloads, like the ISAKMP payloads defined in the following sections ✨
6.2. ACK Message 🦋
ACKs only get sent when the ACKREQ bit is set in a REPLY message. An ACK message MUST contain an AP-REQ payload and no other payload 🫶
6.3. CREATE Message 🌸
this message kicks off the setup of new security association(s) 🚀 The CREATE message must contain an AP-REQ payload and any DOI-specific payloads. Here's the shape:
CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]Replies look like this:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP payloads
SA Payload
Proposal Payloads
Transform Payload
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]Okay, this part is important 👀 There MUST be at least a single proposal payload and a single transform payload in REPLY messages. You only get multiple proposal payloads when an SA bundle is negotiated. Also, unlike IKE, the Nonce payload Nr is NOT required. If it does exist, an acknowledgement must be requested to show that the initiator's outgoing SAs need to be modified. If any of the first proposals are not chosen by the recipient, it SHOULD include the Nonce payload 💅
KINK, just like IKE, lets you create lots of SAs in one create command 🍓 If any of the optimistic proposals are not chosen by the responder, it MUST request an ACK 💜
If an IPsec DOI-specific error shows up, the responder must reply with a Notify payload describing the error 😭
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]If the responder finds a Kerberos error that it can still make a valid authenticator for, the REPLY looks like this:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERRORLast one, and it's a big one 🔥 If the responder finds a Kerberos or KINK type of error and CAN'T create an AP-REP, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]6.4. DELETE Message 🗑️
this message says the sending peer has deleted, or is about to delete, Security Association(s) with the other peer 👋
DELETE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]There are three forms of replies for a DELETE 🎀 The normal one looks like this:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
Delete Payloads
[Notification Payloads]If an IPsec DOI-specific error shows up, the responder must reply with a Notify payload describing the error:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payloads
[Notification Payloads]If the responder finds a Kerberos error it can make a valid authenticator for, the REPLY takes this form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERRORIf the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]6.5. STATUS Message 🧠
the STATUS command has two jobs ✨
- It relays an ISAKMP Notification message.
- It probes whether a peer's epoch has changed, which is how dead peer detection works.
STATUS carries these payloads:
KINK Header
KINK_AP_REQ
[[KINK_ENCRYPT]
KINK_ISAKMP payload
[Notification Payloads]]There are three forms of replies for a STATUS 💫 The normal one is:
REPLY KINK Header
KINK_AP_REP
[[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP payload
[Notification Payloads]]If the responder finds a Kerberos error it can make a valid authenticator for, the REPLY takes this form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERRORIf the responder finds a KINK or Kerberos type of error, it MUST reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]6.6. GETTGT Message 🎟️
a GETTGT command is ONLY used to carry a Kerberos TGT. It has nothing to do with SA management, so it contains only a KINK_TGT_REQ payload and no DOI-specific payload 🙅♀️
There are two forms of replies for a GETTGT 💜 In the normal form, where the responder is allowed to return its TGT, the REPLY contains a KINK_TGT_REP payload. If the responder is NOT allowed to return its TGT, it MUST reply with a KINK_ERROR payload.
7. ISAKMP Key Derivation 🔑
KINK uses the same key derivation mechanisms as section 5.5 of [IKE] 🧁 The formula is:
KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])There are a few differences, though 👀
- prf is the pseudo-random function that matches the session key's etype. They're defined in [KCRYPTO].
- SKEYID_d is the session key in the Kerberos service ticket from the AP-REQ. Subkeys are NOT used in KINK, and they MUST be ignored if received 🙈
- Both Ni_b and Nr_b are the parts of the Nonce payloads (Ni and Nr, respectively) described in section 3.2 of [IKE]. Nr_b is optional, which means it's treated as if a zero length value was supplied when the responder's nonce (Nr) doesn't exist. When Nr exists, Nr_b MUST be included in the calculation 💅
g(qm)^xy refers to the keying material generated when KE payloads are supplied using Diffie-Hellman key agreement. This is explained in section 5.5 of [IKE] 🌈
The rest of the key derivation (for example, how to expand KEYMAT) follows IKE. How each service uses the derived keying materials is up to that service (for example, section 4.5.2 of [IPSEC]) ✨
8. Key Usage Numbers for Kerberos Key Derivation 🧩
Kerberos encrypt/decrypt functions and get_mic/verify_mic functions require "key usage numbers". They're used to generate specific keys for cryptographic operations, so different keys get used for different purposes and objects. KINK uses two usage numbers, listed below 💖
Purpose Usage number
------- ------------
KINK_ENCRYPT payload (for encryption) 39
Cksum field (for checksum) 409. Transport Considerations 🚚
KINK uses UDP on port 910 to carry its messages 📦 There is one timer T, and it SHOULD take round-trip considerations into account. It MUST implement a truncated exponential back-off mechanism 🌸 The state machine is simple: any message that expects a response MUST retransmit the request using timer T. Kerberos requires messages to be retransmitted with new times for replay protection, so the message MUST be re-created every time, including the checksum of the message 🔁 Both commands and replies with the ACKREQ bit set are kept on retransmit timers. When a KINK initiator receives a REPLY with the ACKREQ bit set, it MUST retain the ability to regenerate the ACK message for the transaction for at least its full retransmission timeout cycle, or until it notices that packets have arrived on the newly constructed SA, whichever comes first 💫
When a KINK peer retransmits a message, it MUST create a new Kerberos authenticator for the AP-REQ, so the peer can tell replays apart from dropped packets. This creates a potential race condition when a retransmission happens before an in-flight reply is received and processed 😬 To counter that race, the retransmitting party SHOULD keep a list of valid authenticators that are outstanding for any given transaction 🫶
When a KINK peer retransmits a command, it MUST use the same ticket within the retransmissions. This avoids race conditions from using different keys, which would lead to different KEYMATs between an initiator and a responder 🙃 For this reason, (1) an initiator MUST obtain a ticket whose lifetime is greater than the initiator's maximum transaction time, including timeouts, or (2) it MUST continue to use the same ticket within a set of retransmissions. If it receives an error (most likely KRB_AP_ERR_TKT_EXPIRED) from the responder, it starts a new transaction with a new ticket 🎀
10. Security Considerations 🔐
okay bestie, this section is SERIOUS but also kind of iconic 💀. The principal names are the identities of the KINK services, but the traffic that SAs protect is identified by DOI-specific selectors (IP addresses, port numbers, and so on) 🦋. That mismatch can lead to a breakaway of SA-protected data from authentication. Like, if two different hosts claim the same IP address, it may be impossible to predict which principal's key is protecting the data 😭. So an implementation must take care with the binding between principal names and the SA selectors. Main character energy means not letting those two drift apart 💅.
Sending errors without cryptographic protection has to be handled very carefully ✨. There's a trade-off between wanting to be helpful when diagnosing a problem and not wanting to be a dupe in a denial of service attack 🙈.
KINK cobbles together and reuses many parts of both Kerberos and IKE, and IKE is itself cobbled together from many other memos 🧩. So KINK inherits many of the weaknesses and considerations of each of its components. However, KINK uses only IKE phase 2 payloads to create and delete SAs, so the security considerations that pertain to IKE phase 1 may be safely ignored 🌸. Being able to skip IKE's authentication phase does mean KINK inherits all of the security considerations of Kerberos authentication as outlined in [KERBEROS] 😳. For one, a KDC, like an Authentication, Authorization, and Accounting (AAA) server, is a point of attack, and all that implies 💀. Much has been written about the shortcomings and mitigations of Kerberos, and they should be evaluated for any deployment 📚.
KINK's use of Kerberos brings a couple of considerations 🎀. First, KINK explicitly expects that the KDC will provide adequate entropy when it generates session keys. Second, Kerberos is used as a user authentication protocol, which opens up the possibility of dictionary attacks on user passwords 👀. This memo does not describe a particular method to avoid these pitfalls. It does recommend that suitable randomly generated keys should be used for the service principals, such as using the -randomkey option with MIT's kadmin addprinc command, and for clients when that is practical 🔑.
Kerberos does not currently provide perfect forward secrecy in general 😤. KINK with the KE payload can provide PFS for a service key derived from a Kerberos key, but the KE is not mandatory because of its computational cost. This is a trade-off, and operators can choose PFS over the cost, or the cost over PFS 🍓. KINK itself should be secure from offline analysis from compromised principal passphrases if PFS is used. From an overall system's standpoint, though, the existence of other Kerberized services that do not provide PFS makes this a less than optimal situation 🥺.
11. IANA Considerations 🌈
The IANA has assigned a well-known port number for KINK 🎉.
The IANA has also created a new registry for KINK parameters and registered the following identifiers:
KINK Message Types (section 4)
KINK Next Payload Types (section 4.2)
KINK Error Codes (section 4.2.8)Changes and additions to this registry follow the policies below, and their meanings are described in [BCP26] 📋.
- Using the numbers in the "Private Use" range is Private Use.
- Assignment from the "RESERVED TO IANA" range needs Standards Action, or non-standards-track RFCs with Expert Review. (Though the full specification may be a public and permanent document of a standards body other than IETF, an RFC referring to it is needed.)
- Any other change requires Standards Action.
12. Forward Compatibility Considerations 🦄
KINK can accommodate future versions of Quick Mode through the version field in the ISAKMP payload, as well as through new domains of interpretation ✨. In this memo, the only supported Quick Mode version is 1.0, which corresponds to [IKE]. Likewise, the only DOI supported is the IPsec domain of interpretation [IPDOI]. New Quick Mode versions and DOIs MUST be described in subsequent memos 📝.
KINK implementations MUST reject ISAKMP versions that are greater than the highest currently supported version, using a KINK_BADQMVERS error type 🚫. A KINK implementation that receives a KINK_BADQMVERS message SHOULD be capable of reverting back to version 1.0 🔙.
12.1. New Versions of Quick Mode 🪄
The IPsec working group is defining the next-generation IKE protocol [IKEv2] 🌟. It does not use Quick Mode, but it is similar to the one in IKEv1. The differences between the two are summarized in Appendix A of [IKEv2]. Each of them must be considered in order to use IKEv2 with KINK 🧠.
12.2. New DOI 🌷
The KINK message header contains a field called "Domain of Interpretation (DOI)", which allows other domains of interpretation to use KINK as a secure transport mechanism for keying 🔑.
As one example of a new DOI, the MSEC working group defined the Group Domain of Interpretation [GDOI] 👯. It defines a few new messages that look like ISAKMP messages but are not defined in ISAKMP.
To carry GDOI messages in KINK, the DOI field in the KINK header would indicate that GDOI is being used instead of IPSEC-DOI. The KINK_ISAKMP payload would then contain the payloads defined in the GDOI document, rather than the payloads used by [IKE] Quick Mode. The version number in the KINK_ISAKMP header is tied to the DOI in the KINK header, so a maj.min version 1.0 under DOI GDOI is different from a maj.min version 1.0 under DOI IPSEC-DOI 🫣.
13. Related Work 🧁
The IPsec working group has defined a number of protocols that create and maintain cryptographically secure SAs at layer three (the IP layer) 🌐. This effort has produced two distinct protocols:
- a mechanism for encrypting and authenticating IP datagram payloads that assumes a shared secret between the sender and receiver
- a mechanism for IPsec peers to perform mutual authentication and exchange keying material
The IPsec working group has defined a peer-to-peer authentication and keying mechanism, IKE (RFC 2409) 🤝. One drawback of a peer-to-peer protocol is that each peer must know and implement a site's security policy, which in practice can be quite complex 😩. The peer-to-peer nature of IKE also requires Diffie-Hellman (DH) to establish a shared secret. DH is computationally quite expensive and prone to denial of service attacks, unfortunately 💔. IKE also relies on X.509 certificates to achieve scalable authentication of peers. Digital signatures are computationally expensive too, and certificate-based trust models are difficult to deploy in practice 🙃. While IKE does allow for a pre-shared key, key distribution is required between all peers, which is an O(n^2) problem and becomes problematic for large deployments 📈.
14. Acknowledgements 💜
Many have contributed to the KINK effort 🫶, including our working group chairs Derek Atkins and Jonathan Trostle. The original inspiration came from CableLab's PacketCable effort, which defined a simplified version of Kerberized IPsec. That work involved Sasha Medvinsky, Mike Froh, Matt Hur, and David McGrew. The inspiration for wholly reusing IKE phase 2 is the result of Tero Kivinen's document suggesting grafting Kerberos authentication onto Quick Mode 🙌.
15. References 📚
15.1. Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IPDOI] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key
Management Protocol (ISAKMP)", RFC 2408, November 1998.
[ISAKMP-REG] IANA, "Internet Security Association and Key Management
Protocol (ISAKMP) Identifiers",
<http://www.iana.org/assignments/isakmp-registry>.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications
for Kerberos 5", RFC 3961, February 2005.
[KERBEROS] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.15.2. Informative References
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[PKINIT] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos", Work in Progress,
February 2006.
[REQ4KINK] Thomas, M., "Requirements for Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.Authors' Addresses 🖋️
Shoichi Sakane
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
EMail: Shouichi.Sakane@jp.yokogawa.com
Ken'ichi Kamada
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
EMail: Ken-ichi.Kamada@jp.yokogawa.com
Michael Thomas
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
EMail: mat@cisco.com
Jan Vilhuber
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
EMail: vilhuber@cisco.comFull Copyright Statement ⚖️
The copyright text is kept exactly as written, because legal text has to stay complete:
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property ✨
okay so this part is the legal stuff, but it's still important bestie 💅 The IETF is basically saying it doesn't take a side on whether any patents or other rights are valid, or how far they reach, and it can't promise that anyone has checked for them. It's giving "we're not the ones to ask." 🙈 If you want the rules for rights in RFC documents, look in BCP 78 and BCP 79. Those are the official places 🌸
Any IPR disclosures sent to the IETF Secretariat, and any licence assurances that are offered, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the result of an attempt to get a general licence or permission for implementers or users of this spec to use proprietary rights. 🦋
The IETF also wants to hear from anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement ✨
Huge thank-you to the people who keep the RFC Editor function running 🫶 Its funding comes from the IETF Administrative Support Activity (IASA). Without them, the RFC process would be a total mess 😭 Literally the unsung heroes of the internet, periodt 👑
📦 where this page comes from
- ietf: rfc4430 2006-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms