Kerberized Internet Negotiation of Keys (KINK)
Extracted elements (31)
Kerberos-based centralized key management scales as O(n+m) principal keys rather than IKE's O(n*m) pairwise keys. Public key operations (if used at all via PKINIT) are amortized over the lifetime of KDC credentials; subsequent ticket-based exchanges use only symmetric cryptography, reducing computational cost.
The CREATE command's optimistic approach allows SA establishment in two messages instead of three by pre-installing an inbound SA based on the first transform proposal. This is safe because the KDC provides a reliable source of randomness for key derivation even without a responder nonce contribution.
The initiator is responsible for rekeying (not the responder) for two reasons: to prevent SA duplication from simultaneous renewal collisions, and because Kerberos's client/server model means servers benefit from not maintaining large ticket caches while waiting for client-initiated sessions.
KINK directly reuses IKE Quick Mode (phase 2) payloads with minor changes, specifically: the HASH payload is not used, the Nonce payload Nr is optional, PFS via KE payload is SHOULD rather than MUST, and the prf for key derivation is determined by the Kerberos session key etype rather than the IKE phase 1 negotiated algorithm.
KINK is extensible via the DOI field and Quick Mode version numbers in KINK_ISAKMP. New DOIs (e.g., GDOI) can reuse KINK as a secure transport; the QM major.minor version 1.0 under one DOI is independent of version 1.0 under another DOI. KINK implementations MUST reject unsupported ISAKMP versions with KINK_BADQMVERS and SHOULD be able to revert to version 1.0.
A KINK peer MUST NOT conclude that a peer is dead based solely on unprotected routing information such as ICMP messages. A peer MUST NOT make any inferences about a lack of STATUS messages from another peer; dead peer detection is not periodic keepalives.
IKE phase 1 payloads MUST NOT be sent in KINK. All capabilities and requirements in IKE Quick Mode MUST be supported unless otherwise noted. KINK MUST NOT send multiple Quick Mode transactions within a single KINK_ISAKMP payload.
In a 3-way CREATE handshake, the responder MUST request an ACK (set ACKREQ bit) if it does not choose the first proposal, adds a nonce, or accepts a KE exchange. The initiator MUST always generate an ACK if the ACKREQ bit is set in the KINK header, even if it believes the responder was in error.
In the CREATE flow, the initiator MUST check that the optimistic proposal was selected by comparing all transforms and attributes. Lifetime attributes MAY be lowered by the responder, but MUST NOT be set to a higher value; a higher value MUST generate a NO-PROPOSAL-CHOSEN error. The initiator MUST use the shorter lifetime.
KINK peers MUST record the current epoch for which they have valid SA information and reflect it in each AP-REQ and AP-REP message. If a peer discovers that a principal's epoch has changed on a subsequent message, it MUST consider all SAs created by that principal as invalid.
The Cksum 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 Kerberos ticket. If the checksum type is not a keyed algorithm, the message MUST be rejected.
The KINK_AP_REQ payload MUST request mutual authentication. If the peer's principal name is generated from an FQDN, the principal name MUST take the form 'kink/fqdn@REALM' with the 'fqdn' part in lowercase.
The soft lifetime for rekeying MUST be randomized to avoid synchronization with similar implementations. T-rekey SHOULD be at least twice as high as T-retrans (the full retransmission cycle time).
When retransmitting, a KINK peer MUST create a new Kerberos authenticator for the AP-REQ. It MUST use the same ticket within a set of retransmissions to avoid race conditions from different KEYMATs. The retransmission timer MUST implement a truncated exponential back-off mechanism.
When the responder receives a DELETE command, it MUST delete SAs of both directions and MUST reply with ISAKMP Delete payloads indicating the inbound SA(s) for the responder. If the responder cannot find the SPI, it MUST return an ISAKMP notification with INVALID_SPI.
Key derivation uses the IKE formula: KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b]). SKEYID_d is the Kerberos session key from the AP-REQ ticket; prf is the pseudo-random function corresponding to the session key's etype. Nr_b is optional and treated as zero-length when absent.
KINK defines six message types: CREATE (1), DELETE (2), REPLY (3), GETTGT (4), ACK (5), and STATUS (6). Values 7–127 are reserved to IANA; 128–255 are for private use. All KINK exchanges follow a command/response pattern with an optional ACK.
KINK uses two Kerberos key usage numbers: 39 for KINK_ENCRYPT payload encryption and 40 for the Cksum field checksum. These ensure distinct keys are derived for encryption versus integrity protection.
IANA created a new registry for KINK parameters containing three sub-registries: KINK Message Types (section 4), KINK Next Payload Types (section 4.2), and KINK Error Codes (section 4.2.8). Additions from the RESERVED TO IANA range require Standards Action or Expert Review with a published RFC.
KINK does not mandate PFS via KE payloads due to computational cost, making it a policy trade-off. Without KE, compromise of a Kerberos principal key can expose session keys. The existence of other Kerberized services that do not provide PFS further weakens the overall system security posture.
KINK explicitly relies on the KDC to provide adequate entropy for session key generation. Kerberos is susceptible to dictionary attacks on user passwords; service principals should use randomly generated keys (e.g., -randomkey option). The KDC is a central point of attack as with any AAA server.
Principal names are KINK service identities, but SA-protected traffic is identified by DOI-specific selectors (IP addresses, ports). If two hosts share the same IP address, it may be impossible to determine which principal's key protects the traffic. Implementations must carefully bind principal names to SA selectors.
Sending unauthenticated errors must be handled carefully to avoid acting as an amplifier in denial-of-service attacks. Implementations SHOULD take precautions when acting on unauthenticated KINK errors or Kerberos error messages. Clock skew error responses SHOULD be cryptographically protected when a service key is available.
CREATE SA establishment has two modes. In 2-way handshake (optimistic), the initiator pre-creates an inbound SA; if the responder accepts, both outbound SAs are installed without an ACK. In 3-way handshake (non-optimistic or KE present), the initiator sends CREATE without creating SAs; responder selects proposal and sets ACKREQ; initiator creates SAs and sends ACK; responder installs outbound SA upon ACK.
Dead peer detection state: a peer records the epoch of each principal with valid SAs. On receipt of any KINK message, if the principal's epoch differs from the recorded value, the peer MUST invalidate all SAs for that principal. STATUS messages are used to elicit a cryptographically secured response carrying the current epoch.
The generic KINK payload header is: Next Payload (1 octet), RESERVED (1 octet), Payload Length (2 octets), followed by a variable-length value. Payload types include 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).
The KINK_AP_REQ and KINK_AP_REP payloads each carry an EPOCH field (4 octets, least-significant 32 bits of POSIX time) representing the absolute time at which the creator has valid SA information, followed by the raw Kerberos AP-REQ or AP-REP.
The KINK_ENCRYPT payload encapsulates encrypted KINK payloads and includes InnerNextPload (1 octet), RESERVED2 (3 octets), and the ciphertext. It MUST be the final payload in the outer chain and MUST be encrypted before the final KINK checksum is applied; encrypted content starts at InnerNextPload, covering PayloadLength minus 4 octets.
The KINK_ERROR payload carries a 4-octet ErrorCode in network byte order. Defined codes include KINK_OK (0), KINK_PROTOERR (1), KINK_INVDOI (2), KINK_INVMAJ (3), KINK_INTERR (5), KINK_BADQMVERS (6), and KINK_U2UDENIED (7).
The KINK_ISAKMP payload carries IKE Quick Mode (phase 2) payloads and includes InnerNextPload (1 octet), QMMaj (4 bits, MUST be 1), QMMin (4 bits, MUST be 0), RESERVED (2 octets), followed by the Quick Mode payloads. Each KINK_ISAKMP payload MUST contain a single Quick Mode transaction.
The KINK message header contains: Type (1 octet), MjVer (4 bits, MUST be 1), RESRVED (4 bits), Length (2 octets), DOI (4 octets), XID (4 octets), NextPayload (1 octet), ACKREQ flag (1 bit), RESERVED2 (7 bits), CksumLen (2 octets), followed by payloads and a variable-length Cksum field.