KINK, Kerberized Internet Negotiation of Keys

Description Glossary RFCs Publications Obsolete RFCs


Protocol suite: TCP/IP.
Protocol type:Application layer protocol.
Multicast addresses:
Ports:910 (UDP).
MIME subtype:
Working groups: kink, Kerberized Internet Negotiation of Keys.
Links: IANA: KINK parameters.

RFC 4430:

KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations.

MAC header IP header UDP header KINK header Data :::

KINK header:

0001020304050607 0809101112131415 1617181920212223 2425262728293031
Type Version 0 Length
Transaction ID
Next payload A 0 Checksum length
Payloads :::
Checksum :::

Type. 8 bits.
Message type.

private use.

Version. 4 bits.
KINK protocol version.

Length. 16 bits.
Size of the message in bytes.

DOI, Domain of Interpretation. 32 bits.
All DOIs must be registered with the IANA in the ISAKMP Domain of Interpretation section of the isakmp registry. 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.

Transaction ID. 32 bits.
Also known as an XID. A KINK transaction is bound together by a transaction ID, which is created by the command initiator and replicated in subsequent messages in the transaction. A transaction is defined as a command, a reply, and an optional acknowledgement. Transaction IDs are used by the initiator to discriminate between multiple outstanding requests to a responder. It is not used for replay protection because that functionality is provided by Kerberos. The value is chosen by the initiator and MUST be unique with all outstanding transactions. XIDs MAY be constructed by using a monotonic counter or random number generator.

Next payload. 8 bits.
Indicates the type of the first payload after the message header.

Next payloadDescription
0KINK_DONE. Final payload in the message.
private use.

A, ACK request. 1 bit.
Set to one if the responder requires an explicit acknowledgement that a REPLY was received. An initiator MUST NOT set this flag, nor should a responder except for a REPLY to a CREATE when the optimistic proposal is chosen.

Checksum length. 16 bits.
Size in bytess of the cryptographic checksum of the message. If cleared to zero, the message is unauthenticated.

Payloads. Variable length.

Checksum. Variable length.
Kerberos keyed checksum over the entire message excluding the Cksum field itself. When any padding bytes are required between the last payload and this field, they 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 a key is not available, this field is not present, and the Checksum length field is cleared to zero. The content of this field is the output of the Kerberos 5 get_mic function. The get_mic function used 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, the field is zeroed out and the Checksum length field is filled with the total packet length without the checksum. Then, the packet is passed to the get_mic function and its output is appended to the packet. Any KINK padding after this field is not allowed, except the Kerberos internal one, which may be included in the output of the get_mic function. Finally, the field is filled with the checksum length and the Checksum length field is filled with the total packet length including the checksum. To verify the checksum, a length-without-checksum is calculated from the value of the Checksum length field, subtracting the Checksum length. The Checksum length field is filled with the length- without-checksum value and the Checksum length field is zeroed out. Then, the packet without checksum (offset from 0 to length-without-checksum minus 1 of the received packet) and the checksum (offset from length-without-checksum to the last) are passed to the verify_mic function. If verification fails, the message MUST be dropped.



[RFC 3129] Requirements for Kerberized Internet Negotiation of Keys.

[RFC 4430] Kerberized Internet Negotiation of Keys (KINK).


Obsolete RFCs:

Description Glossary RFCs Publications Obsolete RFCs