Kerberized Internet Negotiation of Keys (KINK) is a protocol defined in RFC 4430 used to set up an IPsec

IPsec

Internet Protocol Security is a protocol suite for securing Internet Protocol communications by authenticating and encrypting each IP packet of a communication session...

 security association

Security association

A Security Association is the establishment of shared security attributes between two network entities to support secure communication. An SA may include attributes such as: cryptographic algorithm and mode; traffic encryption key; and parameters for the network data to be passed over the...

 (SA), similar to Internet Key Exchange

Internet key exchange

Internet Key Exchange is the protocol used to set up a security association in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP...

 (IKE), utilizing the Kerberos protocol to allow trusted third parties to handle authentication of peers and management of security policies in a centralized fashion.

Its motivation is given in RFC 3129 as an alternative to IKE, in which peers must each use X.509

X.509

In cryptography, X.509 is an ITU-T standard for a public key infrastructure and Privilege Management Infrastructure . X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation...

 certificates for authentication, use Diffie-Hellman key exchange

Diffie-Hellman key exchange

Diffie–Hellman key exchange Synonyms of Diffie–Hellman key exchange include:*Diffie–Hellman key agreement*Diffie–Hellman key establishment*Diffie–Hellman key negotiation...

 (DH) for encryption, know and implement a security policy for every peer with which it will connect, with authentication of the X.509 certificates either pre-arranged or using DNS

Domain name system

The Domain Name System is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities...

, preferably with DNSSEC. Utilizing Kerberos, KINK peers must only mutually authenticate

Mutual authentication

Mutual authentication or two-way authentication refers to two parties authenticating each other suitably. In technology terms, it refers to a client or user authenticating themselves to a server and that server authenticating itself to the user in such a way that both parties are assured of the...

 with the appropriate Authentication Server (AS), with a Key Distribution Center (KDC) in turn controlling distribution of keying material

Key (cryptography)

In cryptography, a key is a piece of information that determines the functional output of a cryptographic algorithm or cipher. Without a key, the algorithm would produce no useful result. In encryption, a key specifies the particular transformation of plaintext into ciphertext, or vice versa...

 for encryption and therefore controlling the IPSec security policy.

Protocol description

KINK is a command/response protocol that can create, delete, and maintain IPsec SAs. Each command or response contains a common header along with a set of type-length-value payloads. The type of a command or a response constrains the payloads sent in the messages of the exchange.

KINK itself is a stateless protocol in that each command or response does not require storage of hard state for KINK. This is in contrast to IKE, which uses Main Mode to first establish an Internet Security Association and Key Management Protocol (ISAKMP) SA followed by subsequent Quick Mode exchanges.

KINK uses Kerberos mechanisms to provide mutual authentication and replay protection. For establishing SAs, KINK provides confidentiality for the payloads that follow the Kerberos AP-REQ payload. The design of KINK mitigates denial of service attacks by requiring authenticated exchanges before the use of any public key operations and the installation of any state. KINK also provides a means of using Kerberos User-to-User mechanisms when there is not a key shared between the server and the KDC. This is typically, but not limited to, the case with IPsec peers using PKINIT for initial authentication.

KINK directly reuses Quick Mode payloads defined in section 5.5 of IKE, with some minor changes and omissions. In most cases, KINK exchanges are a single command and its response. An optional third message is required when creating SAs, only if the responder rejects the first proposal from the initiator or wants to contribute the keying materials. KINK also provides rekeying and dead peer detection.

Packet format

The KINK message includes the following fields:

KINK message

Bit offset	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	type								version								length
32	domain of interpretation (DOI)
64	transaction ID (XID)
96	next payload								A C K								checksum length
128 ...	payloads ...
... ...	checksum ...

• type: CREATE, DELETE, REPLY, GETTGT, ACK, STATUS, or private use

• version: the major protocol version number

• length: length of the entire message

• domain of interpretation (DOI): a DOI as defined in the Internet Security Association and Key Management Protocol
  Internet Security Association and Key Management Protocol
  ISAKMP is a protocol defined by RFC 2408 for establishing Security Associations and cryptographic keys in an Internet environment...
  
   (ISAKMP)

• transaction ID (XID): identification the transaction, defined as a command, a reply, and an optional acknowledgement

• next payload: type of the first payload after the message header as KINK_DONE, KINK_AP_REQ, KINK_AP_REP, KINK_KRB_ERROR, KINK_TGT_REQ, KINK_TGT_REP, KINK_ISAKMP, KINK_ENCRYPT, or KINK_ERROR

• ACK or ACKREQ bit: 1 if responder requires an explicit acknowledgement that a REPLY was received otherwise 0

• checksum length: length in bytes of the cryptographic checksum of the message

• payloads: a list of Type/Length/Value (TLV) payloads

• checksum: Kerberos keyed checksum over the entire message excluding the checksum field itself

Payloads

KINK payloads are defined as:

KINK payload

Bit offset	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	next payload																payload length
32 ...	value ...

• next payload: type of the first payload

• length: length of the payload

The following payloads are defined:

• KINK_AP_REQ: a payload that relays a Kerberos AP-REQ to the responder

• KINK_AP_REP: a payload that relays a Kerberos AP-REP to the initiator

• KINK_KRB_ERROR: a payload that relays Kerberos type errors back to the initiator

• KINK_TGT_REQ: a payload that provides a means to get a TGT from the peer in order to obtain a User-to-User service ticket from the KDC

• KINK_TGT_REP: a payload that contains the TGT requested in a previous KINK_TGT_REQ payload of a GETTGT command

• KINK_ISAKMP: a payload to encapsulate the ISAKMP IKE Quick Mode (phase 2) payloads, to allow backward compatibility with IKE and ISAKMP if there are subsequent revisions

• KINK_ENCRYPT: a payload to encapsulate other KINK payloads and is encrypted using the session key and the algorithm specified by its etype

• KINK_ERROR: a payload that returns an error condition

Implementations

The following open source

Open source

The term open source describes practices in production and development that promote access to the end product's source materials. Some consider open source a philosophy, others consider it a pragmatic methodology...

 implementations of KINK are currently available:

• Racoon2 from the WIDE Project
  WIDE Project
  The WIDE Project , founded over 20 years ago , is an Internet project in Japan. It runs a major backbone of the Japanese Internet and used to run the .jp TLD....
  
  .