Request for Comments: 4430 K. Kamada
Category: Standards Track Yokogawa Electric Corp.
M. Thomas
J. Vilhuber
Cisco Systems
March 2006
Kerberized Internet Negotiation of Keys (KINK)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the Kerberized Internet Negotiation of Keys
(KINK) protocol. 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.
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 ...................................38
1. Introduction
KINK is designed to provide a secure, scalable mechanism for
establishing keys between communicating entities within a centrally
managed environment in which it is important to maintain consistent
security policy. The security goals of KINK are to provide privacy,
authentication, and replay protection of key management messages and
to avoid denial of service vulnerabilities whenever possible. The
performance goals of the protocol are to have a low computational
cost, low latency, and a small footprint. It is also to avoid or
minimize the use of public key operations. In particular, the
protocol provides the capability to establish IPsec security
associations (SAs) in two messages with minimal computational effort.
These requirements are described in RFC 3129 [REQ4KINK].
Kerberos [KERBEROS] provides an efficient authentication mechanism
for clients and servers using a trusted third-party model. Kerberos
also provides a mechanism for cross-realm authentication natively. A
client obtains a ticket from an online authentication server, the Key
Distribution Center (KDC). The ticket is then used to construct a
credential for authenticating the client to the server. As a result
of this authentication operation, the server will also share a secret
key with the client. KINK uses this property as the basis of
distributing keys for IPsec.
The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity versus IKE’s
necessity of using public key cryptography [IKE]. Initial
authentication to the KDC may be performed using either symmetric
keys, or asymmetric keys using the Public Key Cryptography for
Initial Authentication in Kerberos [PKINIT]; however, subsequent
requests for tickets as well as authenticated exchanges between the
client and servers always utilize symmetric cryptography. Therefore,
public key operations (if any) are limited and are amortized over the
lifetime of the credentials acquired in the initial authentication
operation to the KDC. For example, a client may use a single public
key exchange with the KDC to efficiently establish multiple SAs with
many other servers in the realm of the KDC. Kerberos also scales
better than direct peer-to-peer keying when symmetric keys are used.
The reason is that since the keys are stored in the KDC, the number
of principal keys is O(n+m) rather than 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 is assumed that the readers are familiar with the terms and
concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC],
and IKE [IKE].
2. Protocol Overview
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.
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 as the authentication mechanism; therefore, a KINK
host needs to get a service ticket for each peer before actual key
negotiations. This is basically a pure Kerberos exchange and the
actual KDC traffic here is for illustrative purposes only. In
practice, when a principal obtains various tickets is a subject of
Kerberos and local policy consideration. As an exception, the GETTGT
message flow of KINK (described in section 3.1) is used when a User-
to-User authentication is required. In this flow, we assume that
both A and B have ticket-granting tickets (TGTs) from their KDCs.
After a service ticket is obtained, KINK uses the CREATE message flow
(section 3.2), DELETE message flow (section 3.3), and STATUS message
flow (section 3.4) to manage SAs. In these flows, we assume that A
has a service ticket for B.
3.1. GETTGT Message Flow
This flow is used to retrieve a TGT from the remote peer in User-to-
User authentication mode.
If the initiator determines that it will not be able to get a normal
(non-User-to-User) service ticket for the responder, it can try a
User-to-User authentication. In this case, it first fetches a TGT
from the responder in order to 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 Flow
The initiator MAY support the following events as triggers to go to
the User-to-User path. Note that the two errors described below will
not be authenticated, and how to act on them depends on the policy.
o The local policy says that the responder requires a User-
to-User authentication.
o A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from
the responder.
o A KDC_ERR_MUST_USE_USER2USER error is returned from the
KDC.
3.2. CREATE Message Flow
This flow creates SAs. The CREATE command takes an "optimistic"
approach, where SAs are initially created on the expectation that the
responder will choose the initial proposed payload. The optimistic
proposal is placed in the first transform payload(s) of the first
proposal. The initiator MUST check to see if the optimistic proposal
was selected by comparing all transforms and attributes, which MUST
be identical to those in the initiator’s optimistic proposal with the
exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these
attributes MAY be set to a lower value by the responder and still
expect optimistic keying, but MUST NOT be set to a higher value that
MUST generate a NO-PROPOSAL-CHOSEN error. 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 receives 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 Flow
Creating SAs has two modes: 2-way handshake and 3-way handshake.
The initiator usually begins a negotiation expecting a 2-way
handshake. When the optimistic proposal is not chosen by the
responder, the negotiation is switched to a 3-way handshake. When
and only when the initiator uses a KE payload, 3-way handshake is
expected from the beginning.
A 2-way handshake is performed in the following steps:
1) 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.
2) A then sends the CREATE message to B.
3) 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.
4) B then sends a REPLY to A without a Nonce payload and without
requesting an ACK.
5) Upon receipt of the REPLY, A creates an outbound SA (A->B).
A 3-way handshake is performed in the following steps:
1) The host A sends the CREATE message to B without creating any
SA.
2) B chooses one proposal according to its policy.
3) 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.
4) 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).
5) A now sends the ACK message.
6) Upon receipt of the ACK, B installs the final outbound SA
(B->A).
If B does not 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 that it can install the final outbound SA. The initiator MUST
always generate an ACK if the ACKREQ bit is set in the KINK header,
even if it believes that the responder was in error.
3.2.1. CREATE Key Derivation Considerations
The CREATE command’s optimistic approach allows an SA to be created
in two messages rather than three. The implication of a two-message
exchange is that B will not contribute to the key since A must set up
the inbound SA before it receives any additional keying material from
B. This may be suspect under normal circumstances; however, KINK
takes advantage of the fact that the KDC provides a reliable source
of randomness which is used in key derivation. In many cases, this
will provide an adequate session key so that B will not require an
acknowledgement. Since B is always at liberty to contribute to the
keying material, this is strictly a trade-off between the key
strength versus the number of messages, which KINK implementations
may decide 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 will include an ISAKMP
payload containing the list of the 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 Flow
The DELETE command takes a "pessimistic" approach, which does not
delete inbound SAs until it receives acknowledgement that the other
host has received the DELETE. The exception to the pessimistic
approach is if the initiator wants to immediately cease all activity
on an inbound SA. In this 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; thus, when the responder receives a DELETE
command, it MUST delete SAs of both directions, and MUST reply with
ISAKMP Delete payload(s) that indicate the inbound SA(s) for the
responder of this flow. If the responder cannot find an appropriate
SPI to be deleted, it MUST return an ISAKMP notification with
INVALID_SPI, which also serves to inform the initiator that it can
delete the inbound SA.
A race condition with the DELETE flow exists. Due to network
reordering, etc., packets in flight while the DELETE operation is
taking place may arrive after the diagrams above, which recommend
deleting the inbound SA. A KINK implementation SHOULD implement a
grace timer that 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. The behavior
described here is referred from the behavior of the TCP [RFC793]
flags FIN and RST.
3.4. STATUS Message Flow
This flow is used to send any information to a peer or to elicit any
information from a peer. An initiator may send a STATUS command to
the responder at any time, optionally with DOI-specific ISAKMP
payloads. In the case of the IPsec DOI, these are generally in the
form of ISAKMP Notification payloads. A STATUS command is also used
as a means of dead peer detection described in section 3.7.
A B KDC
------ ------ ---
1 STATUS[+ISAKMP]---------->
2 <-----------REPLY[+ISAKMP]
Figure 4: STATUS Message Flow
3.5. Reporting Errors
When the responder detects an error in a received command, it can
send a DOI-specific payload to indicate the error in a REPLY message.
There are three types of payloads that can indicate errors:
KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for
KINK errors, and KINK_ISAKMP payloads for ISAKMP errors. Details are
described in sections 4.2.3, 4.2.8, and 4.2.6, respectively.
If the initiator detects an error in a received reply, there is no
means to report it back to the responder. The initiator SHOULD log
the event and 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 upon the client and server time contained in the
KRB-ERROR message. The client SHOULD store this clock difference and
use it to adjust its clock in subsequent messages. If the error is
not protected, the client MUST NOT use the difference to adjust
subsequent messages, because doing so would allow an attacker to
construct authenticators that can be used to mount replay attacks.
3.6. Rekeying Security Associations
KINK expects the initiator of an SA to be responsible for rekeying
the SA for two reasons. The first reason is to prevent needless
duplication of SAs as the result of collisions due to an initiator
and responder both trying to renew an existing SA. The second reason
is due to the client/server nature of Kerberos exchanges, which
expects the client to get and maintain tickets. While KINK expects
that a KINK host is able to get and maintain tickets, in practice it
is often advantageous for servers to wait for clients to initiate
sessions so that they do not need to maintain a large ticket cache.
There are no special semantics for rekeying SAs in KINK. That is, in
order to rekey an existing SA, the initiator must CREATE a new SA
followed by either deleting the old SA with the DELETE flow or
letting it time out. When identical flow selectors are available on
different SAs, KINK implementations SHOULD choose the SA most
recently created. It should be noted that KINK avoids most of the
problems of [IKE] rekeying by having a reliable delete mechanism.
Normally, a KINK implementation that rekeys existing SAs will try to
rekey the SA ahead of an SA termination, which may include the hard
lifetime in time/bytecount or the overflow of the sequence number
counter. We call this time "soft lifetime". The soft lifetime MUST