Kerberized Internet Negotiation of Keys

Last updated September 03, 2020

Kerberized Internet Negotiation of Keys (KINK) is a protocol defined in RFC 4430 used to set up an IPsec security association (SA), similar to Internet Key Exchange (IKE), utilizing the Kerberos protocol to allow trusted third parties to handle authentication of peers and management of security policies in a centralized fashion.^[1]

Its motivation is given in RFC 3129 as an alternative to IKE, in which peers must each use X.509 certificates for authentication, use Diffie–Hellman key exchange (DH) for encryption, know and implement a security policy for every peer with which it will connect,^[2] with authentication of the X.509 certificates either pre-arranged or using DNS, preferably with DNSSEC.^[3] Utilizing Kerberos, KINK peers must only mutually authenticate with the appropriate Authentication Server (AS), with a key distribution center (KDC) in turn controlling distribution of keying material 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	8	16
0	type	version	length
32	domain of interpretation (DOI)
64	transaction ID (XID)
96	next payload	A	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 (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 implementations of KINK are currently available:

Racoon2 from the WIDE Project.

Related Research Articles

Kerberos is a computer-network authentication protocol that works on the basis of tickets to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. The protocol was named after the character Kerberos from Greek mythology, the ferocious three-headed guard dog of Hades. Its designers aimed it primarily at a client–server model and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks.

In computer networking, Point-to-Point Protocol (PPP) is a Data link layer communications protocol between two routers directly without any host or any other networking in between. It can provide connection authentication, transmission encryption, and compression.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts the packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

The Point-to-Point Tunneling Protocol (PPTP) is an obsolete method for implementing virtual private networks. PPTP has many well known security issues.

In computing, Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec protocol suite. IKE builds upon the Oakley protocol and ISAKMP. IKE uses X.509 certificates for authentication ‒ either pre-shared or distributed using DNS ‒ and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived. In addition, a security policy for every peer which will connect must be manually maintained.

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself. Rather, it relies on an encryption protocol that it passes within the tunnel to provide privacy.

Internet Security Association and Key Management Protocol (ISAKMP) is a protocol defined by RFC 2408 for establishing Security association (SA) and cryptographic keys in an Internet environment. ISAKMP only provides a framework for authentication and key exchange and is designed to be key exchange independent; protocols such as Internet Key Exchange (IKE) and Kerberized Internet Negotiation of Keys (KINK) provide authenticated keying material for use with ISAKMP. For example: IKE describes a protocol using part of Oakley and part of SKEME in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI

Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO), often pronounced "spenay-go", is a GSSAPI "pseudo mechanism" used by client-server software to negotiate the choice of security technology. SPNEGO is used when a client application wants to authenticate to a remote server, but neither end is sure what authentication protocols the other supports. The pseudo-mechanism uses a protocol to determine what common GSSAPI mechanisms are available, selects one and then dispatches all further security operations to it. This can help organizations deploy new security mechanisms in a phased manner.

Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols. It decouples authentication mechanisms from application protocols, in theory allowing any authentication mechanism supported by SASL to be used in any application protocol that uses SASL. Authentication mechanisms can also support proxy authorization, a facility allowing one user to assume the identity of another. They can also provide a data security layer offering data integrity and data confidentiality services. DIGEST-MD5 provides an example of mechanisms which can provide a data-security layer. Application protocols that support SASL typically also support Transport Layer Security (TLS) to complement the services offered by SASL.

Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco Systems that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links or point-to-multipoint links over an Internet Protocol network.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the internet protocol suite.

Network address translation traversal is a computer networking technique of establishing and maintaining Internet protocol connections across gateways that implement network address translation (NAT).

A security association (SA) 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 connection. The framework for establishing security associations is provided by the Internet Security Association and Key Management Protocol (ISAKMP). Protocols such as Internet Key Exchange (IKE) and Kerberized Internet Negotiation of Keys (KINK) provide authenticated keying material.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt the communications channel, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Multimedia Internet KEYing (MIKEY) is a key management protocol that is intended for use with real-time applications. It can specifically be used to set up encryption keys for multimedia sessions that are secured using SRTP, the security protocol commonly used for securing real-time communications such as VoIP.

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6). ICMPv6 is defined in RFC 4443. ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions, and has a framework for extensions to implement future changes.

Group Domain of Interpretation or GDOI is a cryptographic protocol for group key management. The GDOI protocol is specified in an IETF Standard, RFC 6407, and is based on Internet Security Association and Key Management Protocol (ISAKMP), RFC 2408, and Internet Key Exchange version 1 (IKE). Whereas IKE is run between two peers to establish a "pair-wise security association", GDOI protocol is run between a group member and a "group controller/key server" (controller) and establishes a security association among two or more group members.

The internet layer is a group of internetworking methods, protocols, and specifications in the Internet protocol suite that are used to transport network packets from the originating host across network boundaries; if necessary, to the destination host specified by an IP address. The internet layer derives its name from its function facilitating internetworking, which is the concept of connecting multiple networks with each other through gateways.

GSS-TSIG is an extension to the TSIG DNS authentication protocol for secure key exchange. It is a GSS-API algorithm which uses Kerberos for passing security tokens to provide authentication, integrity and confidentiality.

Zeroshell is a small open-source Linux distribution for servers and embedded systems which aims to provide network services. Its administration relies on a web-based graphical interface; no shell is needed to administer and configure it. Zeroshell is available as Live CD and CompactFlash images, and VMware virtual machines.

References

↑ RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 2
↑ RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 1
↑ RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE), Internet Engineering Task Force, June 2001, p. 5

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 2

[2] RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 1

[3] RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE), Internet Engineering Task Force, June 2001, p. 5