< draft-ietf-kink-kink-01.txt   draft-ietf-kink-kink-02.txt >
INTERNET-DRAFT KINK M. Thomas INTERNET-DRAFT KINK M. Thomas
Editor Editor
M. Froh M. Froh
Cybersafe Cybersafe
M. Hur M. Hur
D. McGrew D. McGrew
J. Vilhuber J. Vilhuber
Cisco Cisco
S Medvinsky S Medvinsky
Motorola Motorola
July 19, 2001 October 20, 2001
Kerberized Internet Negotiation of Keys (KINK) Kerberized Internet Negotiation of Keys (KINK)
draft-ietf-kink-kink-01.txt draft-ietf-kink-kink-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 42 skipping to change at page 1, line 43
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
The KINK Working Group will create a standards track protocol to KINK defines a low-latency, computationally inexpensive, easily
facilitate centralized key exchange in an application independent managed, and cryptographically sound protocol to set up and maintain
fashion. Participating systems will use the Kerberos architecture as [IPSEC] security associations using [KERBEROS] authentication. KINK
defined in RFC 1510 for key management and the KINK protocol between reuses many [ISAKMP] Quick Mode payloads to create, delete and
applications. The goal of KINK is to produce a low-latency, maintain IPsec security associations which should lead to substantial
computationally inexpensive, easily managed, and cryptographically reuse of existing [IKE] implementations.
sound protocol that is flexible enough to be able to be extended for
many applications.
The initial focus of the protocol will be keying IPsec security
associations as defined in RFC 2401. Future version of the KINK
protocol may define new objects and Domains of Interpretation to
extend KINK to be suitable for keying other kinds of applications.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119. document are to be interpreted as described in RFC-2119.
Action Items:
o Which Diffie Hellman group for PFS?
o Word the KINK_ENCRYPT IV use description better
o Better discussion of error scenarios; more specific error codes?
o Should we register the KINK payloads with IANA as ISAKMP types?
This would avoid potential name space collisions.
o Still need to talk about when to use U-U vs. normal mode (aka
Discovery).
o Need a port from IANA
Changes from -00
o Numerous editorial changes
o Change CREATE SA to reflect ACK reliability guidelines. Mention
grace timer for ACK.
o Make final ACK optional in DELETE flow. This seems like it was a
mistake. Clarify the grace timer.
o Add STATUS verb to reflect the ability of Quick mode to send
mid-SA notifications.
o Reorganize the KINK header to not have a short paylaod and
reserve all of the flags.
o Clarify the method of applying the keyed hash over the message.
Also remove redundant checksum type in checksum field (it's
defined to be the etype of the ticket).
o Clarify the padding rules.
o Clarify in GETTGT/TGTREP that you supply a realm to GETTGT and
TGTREP returns the principal name of to do the UU with.
o List all of the appropriate Kerberos Errors that can be
returned. Mention which ones must be handled.
o Add IKE major/minor version in ISAKMP payload header.
o Clarify how to produce the KINK encrypt header.
o Add an INTERNAL ERROR error code.
o Modify the various headers/payloads of section 6 and 8 to more
accurately reflect that we are using IKE Quick Mode directly;
remove text describing ISAKMP headers, refer to 240x.
o Add section for PFS support.
o Change key derivation section to reflect the use of quick mode
method.
o Reflect ACK handling in Transport Considerations
o Add Security Considerations.
1. Introduction 1. Introduction
KINK is designed to provide a secure, scalable mechanism for estab- KINK is designed to provide a secure, scalable mechanism for estab-
lishing keys between communicating entities within a centrally lishing keys between communicating entities within a centrally
managed environment in which it is important to maintain consistent managed environment in which it is important to maintain consistent
security policy. The security goals of KINK are to provide privacy, security policy. The security goals of KINK are to provide privacy,
authentication, and replay protection of key management messages, and authentication, and replay protection of key management messages, and
to avoid denial of service vulnerabilities whenever possible. The to avoid denial of service vulnerabilities whenever possible. The
performance goals of the protocol are to incur a low computational performance goals of the protocol are to incur a low computational
cost, to have a low latency, to have a small footprint, and to avoid cost, to have low latency, to have a small footprint, and to avoid or
or minimize the use of public key operations. In particular, the minimize the use of public key operations. In particular, the proto-
protocol should provide the capability to establish SAs in two mes- col provides the capability to establish security associations in two
sages with minimal computational effort. messages with minimal computational effort.
Kerberos [KERB] and [RFC1510] provides an efficient mechanism for Kerberos [KERB] and [KERBEROS] provides an efficient mechanism for
trusted third party authentication for clients and servers. (Kerberos trusted third party authentication for clients and servers. (Ker-
also provides an efficient mechanism for inter-realm authentication beros also provides an mechanisms for inter-realm authentication
[PKCROSS].) Clients obtain tickets (a ticket is a symmetric key cer- natively and with [PKCROSS].) Clients obtain tickets from an online
tificate) from an online authentication server (the Key Distribution authentication server (the Key Distribution Center or KDC). Tickets
Center or KDC). Tickets are used to construct credentials for authen- are then used to construct credentials for authenticating the client
ticating the client to the server. As a result of this authentica- to the server. As a result of this authentication operation, the
tion, the client and the server share a secret (a key, generated by client and the server will also share a secret. KINK uses this pro-
the KDC, that is encrypted within the ticket). perty as the basis of distributing keys for IPsec.
The central key management provided by Kerberos is efficient, because The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity. Initial authenti- it limits computational cost and limits complexity versus IKE's
cation to the KDC may be performed using either symmetric or asym- necessity of using public key cryptography. Initial authentication
metric keys [PKINIT]; however, subsequent requests for tickets util- to the KDC may be performed using either symmetric keys or asymmetric
ize symmetric cryptography, which is much more efficient than public keys using [PKINIT]; however, subsequent requests for tickets, as
key cryptography. Therefore, public key operations are limited and well as authenticated exchanges between client and server always
are amortized over the lifetime of the Kerberos tickets. For exam- utilize symmetric cryptography. Therefore, public key operations (if
ple, a server may use a single public key exchange with the KDC to any) are limited and are amortized over the lifetime of the initial
efficiently establish multiple security associations with other authentication operation to the Kerberos KDC. For example, a client
servers. Since Kerberos principal keys (used for initial asymmetric may use a single public key exchange with the KDC to efficiently
authentication) are stored in the KDC, the number of principal keys establish multiple security associations with many other servers in
is order of magnitude O(n) rather than O(n^2), as would be required the extended realm of the KDC. Kerberos also scales better than
for a pre-shared key type of solution. 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) rather than O(n*m), where "n" is the number of clients
and "m" is the number of servers.
This document specifies the Kerberized Internet Negotiation of Keys This document specifies the Kerberized Internet Negotiation of Keys
Protocol and its use to establish and maintain IPsec Security Associ- Protocol and the domain of interpretation (DOI) for establishing and
ations [RFC2401]. KINK could be used to maintain Security Associa- maintaining IPsec Security Associations [IPSEC]. No other domains of
tions defined in other Domains of Interpretation, though such use is interpretation are defined in this document.
outside of the scope of this document. It should be noted that KINK
is a complement to and not a replacement for the Internet Key
Exchange [IKE], as KINK requires the use of an online authentication
server and cannot provide identity protection nor perfect forward
secrecy (as described in [RFC2412]). There are many situations in
which centralized key management is desirable.
While Kerberos specifies a standard protocol between the client and
the KDC to get tickets, the actual ticket exchange between client and
server is application specific. KINK is intended to be an alterna-
tive to requiring each application having its own method of tran-
sporting and validating service tickets using a protocol which is
efficient and tailored to the specific needs of Kerberos and the
applications for which it provides keying and parameter negotiation.
KINK defines the "on the wire" protocol for establishing keys based
on Kerberos authentication. This is a general protocol that may be
used to securely establish keys for any purpose. This protocol is
ideally suited for environment in which efficiency, scalability, and
central management are important. This document defines the KINK pro-
tocol and also defines a domain of interpretation to establish and
maintain IPsec security associations. Any other domains of interpre-
tation must be defined separately. The protocol takes full advantage
of the features of RFC 2401 but in the context of a centralized key-
ing authority.
2. Terminology 2. Terminology
Ticket Ticket
A Kerberos term for a record that helps a client authenticate A Kerberos term for a record that helps a client authenticate
itself to a server; it contains the client's identity, a session itself to a server; it contains the client's identity, a session
key, a lifetime, and other information, all sealed using the key, a lifetime, and other information, all sealed using the
server's secret key. The combination of a ticket and an authentica- server's secret key. The combination of a ticket and an authentica-
tor (which proves freshness and knowledge of the key within the tor (which proves freshness and knowledge of the key within the
ticket) creates an authentication credential. ticket) creates an authentication credential.
KDC KDC
Key Distribution Center, a network service that supplies tickets Key Distribution Center, a network service that supplies tickets
and temporary session keys; or an instance of that service or the and temporary session keys; or an instance of that service or the
skipping to change at page 5, line 13 skipping to change at page 3, line 29
Ticket-Granting Ticket (TGT) requests. The initial ticket portion Ticket-Granting Ticket (TGT) requests. The initial ticket portion
is referred to as the Authentication Server (or service). The is referred to as the Authentication Server (or service). The
Ticket-Granting Ticket portion is referred to as the Ticket- Ticket-Granting Ticket portion is referred to as the Ticket-
Granting Server (or service). Granting Server (or service).
Realm Realm
A Kerberos administrative domain. A single KDC may be responsible A Kerberos administrative domain. A single KDC may be responsible
for one or more realms. A fully qualified principal name includes for one or more realms. A fully qualified principal name includes
a realm name along with a principal name unique within that realm. a realm name along with a principal name unique within that realm.
3. Protocol Overview TGT
A ticket granting ticket is a normal Kerberos ticket which the KDC
issues for the Kerberos service. The main purpose of a TGT is to
capture the results of initial authentication for subsequent ticket
granting requests, thus providing a single sign-on service.
This document specifies a protocol (KINK) that allows two peers to User-User
directly establish symmetric keys, where one peer has already Kerberos normally divides the world into clients and servers where
obtained an authentication credential for the other peer from a the server maintains a table of keys (keytab) which is used to
trusted third party known as the Kerberos KDC (Key Distribution encrypt/decrypt service tickets. In situations where a principal
Center). An authentication credential for a server obtained from the may not have a keytab (ex. a human/client principal rather than a
KDC is known as the Kerberos service ticket. service principal), Kerberos provides the means of issuing what is
known as a User-User ticket. To produce the User-User ticket, the
KDC requires the ticket granting tickets from both client princi-
pals. Kerberos does not specify a means obtaining a client's
ticket granting ticket, and is thus application specific.
The use of Kerberos tickets minimizes the amount of state that is Principal
required for this key management protocol. It is possible for only Kerberos named entities are known as principals, and are roughly
one of the peers to save Kerberos tickets, while the other peer can equivalent to X.509 distinguished names. Principals are either
remain completely stateless. KINK uses this property to allow mes- client or service principals. A principal is an entity that
sage exchanges to be stateless. That is, a secure session is not engages in a security relationship. A Kerberos principal name is
required to exchange KINK messages as each message contains all of roughly equivalent to an X.509 distinguished name (it associates
the information required to authenticate the message. This is in the principal with an adminsitrative domain). Principals may be
contrast to IKE [IKE] which requires a phase 1 security association client or servers. A server principal is generally distinguished
to be created and maintained in order to create subsequent security by a flag in a KDC principal database and by a keytab maintained by
associations. the server.
Kerberos tickets utilize only symmetric key cryptography with rela- DER
tively small overhead required to process them (as compared to public ASN.1 Distinguished Encoding Rules; Kerberos version 5 uses this
key-based protocols). However, an authentication mechanism that is encoding format of ASN.1.
utilized between a KDC client and the KDC can be either symmetric key
based (as specified by the base Kerberos protocol [RFC1510]) or pub-
lic key based (as specified by PKINIT [PKINIT]).
KINK hosts are peers in the IPsec sense of the meaning that a KINK Quick-Mode
host can initiate or respond to KINK commands. Messages come in three IKE defines two phases: an authentication phase (phase 1, or Main
varieties: commands, replies, and acknowledgments. In most cir- Mode) and a security association maintenance phase (phase 2, or
cumstances, a KINK security association can be installed in two mes- Quick Mode). KINK reuses IKE Quick Mode.
sages: a command and a reply. The method here is to use an "optimis-
tic" algorithm where negotiation proposals are prioritized and the
top choice is installed in the security association database. If for
some reason the respondent does not choose the first proposal, the
respondent may choose another but at the cost of a ACK message so
that it can be guaranteed of delivery.
Since the KDC does not possess a symmetric key PKINIT principals KINK AP-REQ/AP-REP
defines an unauthenticated request for getting a peer's ticket grant- Kerberos defines an standardized message format and transport for
ing ticket. This allows KINK peers to request a User to User service contacting a KDC to perform initial authentication, and for grant-
ticket. Upon receipt of the User to User service ticket, all messages ing subsequent service tickets. When a client needs to authenticate
exchanges are identical. Discovery issues are discussed in section to a server, Kerberos provides a standardized message format, but
XXX. leaves the transport as application specific. The messages which
perform this function are AP-REQ between the client and the server,
and AP-REP between the server and client if mutual authentication
is needed.
KINK is intended as a generic key management protocol based on Ker- 3. Protocol Overview
beros tickets. It can be used to provide key management for any
security layer above level 2 in the Internet protocol stack, includ- KINK is a command/response protocol which can create, delete and
ing application-layer security. This document includes an IPSec DOI maintain IPsec security associations. Each command or response con-
(Domain of Interpretation) that enables KINK to be used directly as tains a common header along with a set of type-length-value payloads
an IPSec key management protocol. Other DOI specifications may be which are constrained according to the type of command or response.
used to apply KINK to other security protocols. KINK itself is a stateless protocol in that each command or response
does not require storage of hard state for KINK itself. This is in
contrast to IKE's use of Main Mode to first establish an ISAKMP secu-
rity association followed by subsequent Quick Mode exchanges.
KINK uses Kerberos mechanisms to provide mutual authentication,
replay protection. For security association establishment. KINK pro-
vides privacy of the payloads which follow the Kerberos authentica-
tor. KINK's design 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 the means of
using Kerberos User-User mechanisms when there isn't 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 authenti-
cation.
KINK directly reuses [ISAKMP] Quick Mode payloads, with some minor
changes and omissions. In most cases, KINK exchanges are a single
command and its response. The lone exception is the CREATE command
which allows a final acknowledgment message when the respondent needs
a full three-way handshake. This is only needed when the optimistic
keying route is not taken, though it is expected that that will not
be the norm. KINK also provides rekeying and dead peer detection as
basic features.
4. Message Flows 4. Message Flows
KINK message flows all follow the same pattern between the two peers: KINK message flows all follow the same pattern between the two peers:
a command, a response and an optional acknowledgement. The actual a command, a response and a possible acknowledgment with CREATE's.
Kerberos KDC traffic here is for illustrative purposes only. In prac- The actual Kerberos KDC traffic here is for illustrative purposes
tice, when a principal obtains various tickets is a subject of Ker- only. In practice, when a principal obtains various tickets is a sub-
beros and local policy consideration. In these flows, we assume that ject of Kerberos and local policy consideration. In these flows, we
A and B both have TGT's from their KDC. assume that A and B both have TGT's from their KDC.
4.1. Standard KINK Message Flow 4.1. Standard KINK Message Flow
A B KDC A B KDC
------ ------ --- ------ ------ ---
1 COMMAND-------------------> 1 COMMAND------------------->
2 <------------------REPLY 2 <------------------REPLY
3 [ ACK---------------------> ] 3 [ ACK---------------------> ]
Figure 1: KINK Message Flow Figure 1: KINK Message Flow
4.2. GETTGT Message Flow 4.2. GETTGT Message Flow
If the initiator determines that it will not be able to directly get If the initiator determines that it will not be able to get a normal
a service ticket for the respondent (ie, B is a PKINIT principal), it service ticket for the respondent (eg, B is a client principal), it
must fetch the TGT from the respondent first in order to get a User- MUST first fetch the TGT from the respondent in order to get a User-
User service ticket: User service ticket:
A B KDC A B KDC
------ ------ --- ------ ------ ---
1 GETTGT+KRB_TGT_REQ-------> 1 GETTGT+KRB_TGT_REQ------->
2 <-------REPLY+KRB_TGT_REP 2 <-------REPLY+KRB_TGT_REP
3 TGS-REQ+TGT(B)-------------------------------------> 3 TGS-REQ+TGT(B)------------------------------------->
4 <--------------------------------------------TGS-REP 4 <--------------------------------------------TGS-REP
Figure 2: GETTGT Message Flow Figure 2: GETTGT Message Flow
4.3. CREATE Security Association 4.3. CREATE Security Association
This flow instantiates a security association. The CREATE command This flow instantiates a security association. The CREATE command
takes an "optimistic" approach where security associations are takes an "optimistic" approach where security associations are
initially created on the expectation that the respondent will chose initially created on the expectation that the respondent will chose
the initial proposed payload. the initial proposed payload. The optimistic payload is defined as
the first transform of the first proposal of the first conjugate.
The initiator MUST checks to see if the optimistic payload was
selected by comparing all transforms and attributes which MUST be
identical from the initiator's optimistic proposal with the lone
exception of LIFE_KILOBYTES and LIFE_SECONDS. Both of these
attributes MAY be set to a lower value by the respondent and still
expect optimistic keying, but MUST NOT be set to a higher value which
MUST generate an error.
CREATE'ing a security association on an existing SPI is an error in
KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI.
A B KDC A B KDC
------ ------ --- ------ ------ ---
A creates initial inbound SA (B->A) A creates initial inbound SA (B->A)
1 CREATE+ISAKMP------------> 1 CREATE+ISAKMP------------>
B creates inbound SA to A (A->B). If B chooses A's first B creates inbound SA to A (A->B). If B chooses A's optimistic
proposal, proposal, it creates the outbound SA as well (B->A).
it creates the outbound SA as well (B->A).
2 <------------REPLY+ISAKMP 2 <------------REPLY+ISAKMP
A creates outbound SA and modifies inbound SA if it first A creates outbound SA and modifies inbound SA if it first
proposal proposal wasn't acceptable.
wasn't acceptible.
3 [ ACK--------------------> ] 3 [ ACK--------------------> ]
[ B creates the outbound SA to A (B-A). ] [ B creates the outbound SA to A (B-A). ]
Figure 3: CREATE Message Flow Figure 3: CREATE Message Flow
The security associations are instantiated as follows: In step one The security associations are instantiated as follows: In step one
host A creates an inbound security association in its database from host A creates an inbound security association in its security asso-
B->A using the first proposal in the ISAKMP SA proposal. It is then ciation database from B->A using the optimistic proposal in the
ready to receive any messages from B. A then sends the CREATE message ISAKMP SA proposal. It is then ready to receive any messages from B.
to B. If B agrees to A's initial proposal and does not desire to con- A then sends the CREATE message to B. If B agrees to A's optimistic
tribute entropy to the session key, B instantiates a security associ- proposal, B instantiates a security association in its database from
ation in its database from A->B. B then instantiates the security A->B. B then instantiates the security association from B->A. It then
association from B->A. It then sends a REPLY to A without a NONCE sends a REPLY to A without a NONCE payload and without requesting an
payload and without requesting an ACK. If B does not choose the first ACK. If B does not choose the first proposal, it sends the actual
proposal, it sends the actual choice in the REPLY, a NONCE and choice in the REPLY, a NONCE payload and requests that the REPLY be
requests that the REPLY be acknowledged. Upon receipt of the REPLY, A acknowledged. Upon receipt of the REPLY, A modifies the inbound secu-
modifies the inbound security association as necessary, instantiates rity association as necessary, instantiates the security association
the security association from A->B, If B requested an ACK, A now from A->B, If B requested an ACK, A now sends the ACK message. Upon
sends the ACK message. Upon receipt of the ACK, B installs the final receipt of the ACK, B installs the final security association from
security association from B->A. B->A.
If B adds a nonce, or does not choose the first proposal, it SHOULD Note: if B adds a nonce, or does not choose the first proposal, it
request an ACK so that it can install the final outbound security MUST request an ACK so that it can install the final outbound secu-
association. Since ACK's are not reliable [see section on Transport rity association. The initiator MUST always generate an ACK if the
Considerations], the requestor SHOULD implement a grace timer to ACKREQ bit is set in the KINK header, even if it believes that the
install the outbound security association. respondent was in error.
4.3.1. CREATE Key Derivation Considerations 4.3.1. CREATE Key Derivation Considerations
The CREATE command's optimistic approach allows a security associa- The CREATE command's optimistic approach allows a security associa-
tion to be created in two messages rather than three. The implication tion 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 of a two message exchange is that B will not contribute to the key
since A must set up the inbound security association before it since A must set up the inbound security association before it
receives any additional keying material from B. Under normal cir- receives any additional keying material from B. Under normal cir-
cumstances this may be suspect, however KINK takes advantage of the cumstances this may be suspect, however KINK takes advantage of the
fact that the KDC provides a reliable source of randomness which is fact that the KDC provides a reliable source of randomness which is
skipping to change at page 9, line 19 skipping to change at page 7, line 41
deleted. For the IPSEC DOI, those payloads will include an ISAKMP deleted. For the IPSEC DOI, those payloads will include an ISAKMP
payload contains the SPI to be deleted in each direction. payload contains the SPI to be deleted in each direction.
A B KDC A B KDC
------ ------ --- ------ ------ ---
A deletes outbound SA to B A deletes outbound SA to B
1 DELETE+ISAKMP------------> 1 DELETE+ISAKMP------------>
B deletes outbound SA to A B deletes inbound and outbound SA to A
2 <-------------REPLY+ISAKMP 2 <-------------REPLY+ISAKMP
A deletes inbound SA to B A deletes inbound SA to B
[3 ACK--------------------> ]
[ B deletes inbound SA to A]
Figure 4: DELETE Message Flow Figure 4: DELETE Message Flow
The DELETE command takes a "pessimistic approach" which does not The DELETE command takes a "pessimistic approach" which does not
delete incoming security associations until it receives acknowledg- delete incoming security associations until it receives acknowledg-
ment that the other host has received the DELETE. The exception to ment that the other host has received the DELETE. The exception to
the pessimistic approach is if the initiator wants to immediately the pessimistic approach is if the initiator wants to immediately
cease all activity on an incoming SA. In this case, it MAY delete the cease all activity on an incoming SA. In this case, it MAY delete the
incoming SA as well in step one. The respondent MUST NOT delete its incoming SA as well in step one. If the receiver cannot find an
incoming SA until it either receives the final ACK, or the transac- appropriate SPI to delete, it MUST return an ISAKMP INVALID_SPI
tion times out. notification which also serves to inform the initiator that it can
delete the incoming SA. For simplicity, KINK does not allow half open
security associations; thus upon receiving a DELETE, the responder
MUST delete its security associations, and MUST reply with ISAKMP
delete notification messages if the SPI is found.
A final race condition with DELETE exists. Packets in flight while A race condition with DELETE exists. Packets in flight while the
the DELETE operation is taking place may, due to network reording, DELETE operation is taking place may, due to network reordering, etc,
etc, arrive after the diagrams above recommend deleting the incoming arrive after the diagrams above recommend deleting the incoming secu-
security association. A KINK implementation MUST implement a grace rity association. A KINK implementation SHOULD implement a grace
timer which SHOULD be set to a period of at least two times the aver- timer which SHOULD be set to a period of at least two times the aver-
age round trip time, or to a configurable value. A KINK implementa- age round trip time, or to a configurable value. A KINK implementa-
tion MAY chose to set the grace period to zero at appropriate times tion MAY chose to set the grace period to zero at appropriate times
to ungracefully delete a security association. The behavior described to ungracefully delete a security association. The behavior described
here loosely mimics the behavior of the TCP [RFC793] flags FIN and here loosely mimics the behavior of the TCP [RFC793] flags FIN and
RST. RST.
4.4.1. Rekeying Security Associations 4.4.1. Rekeying Security Associations
KINK requires the initiator of a security association to be responsi- KINK requires the initiator of a security association to be responsi-
ble for rekeying a security association. The reason is twofold: the ble for rekeying a security association. The reason is twofold: the
first is to prevent needless duplication of security associations as first is to prevent needless duplication of security associations as
the result of collisions due to an initiator and respondent both try- the result of collisions due to an initiator and respondent both try-
ing to renew an existing security association. The second reason is ing to renew an existing security association. The second reason is
due to the client/server nature of Kerberos exchanges which expects due to the client/server nature of Kerberos exchanges which expects
the client to get and maintain tickets. While KINK requires that a the client to get and maintain tickets. While KINK requires that a
KINK host be able to get and maintain tickets, in practice it is KINK host be able to get and maintain tickets, in practice it is
advantageous for servers to wait for clients to initiate sessions so often advantageous for servers to wait for clients to initiate ses-
that they do not need to maintain a large ticket cache. sions so that they do not need to maintain a large ticket cache.
There are no special semantics for rekeying security associations in There are no special semantics for rekeying security associations in
KINK. That is, in order to rekey an existing security association, KINK. That is, in order to rekey an existing security association,
the initiator must CREATE a new security association followed by the initiator must CREATE a new security association followed by
either DELETE'ing the old security association or letting it just either DELETE'ing the old security association or letting it time
time out. When identical flow selectors are available on different out. When identical flow selectors are available on different secu-
security associations, KINK implementations SHOULD chose the security rity associations, KINK implementations SHOULD choose the security
association most recently created. association 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 which rekeys existing security associ-
ations will try to rekey the security association ahead of a hard SA
expiration. We call this time the rekey time Trekey. In order to
avoid synchronization with similar implementations, KINK initiators
MUST randomly pick a rekeying time between Trekey and the SA expira-
tion time minus the amount of time it would take to go through a full
retransmission time cycle, Tretrans. Trk SHOULD be set at least twice
as high as Tretrans.
4.4.2. Dead Peer Detection
In order to determine that a KINK peer has lost its security database
information, KINK peers MUST record the current epoch for which they
have valid SADB information and reflect that epoch in each AP-REQ and
AP-REP message. When a KINK peer creates state for a given security
association, it MUST also record the principal's epoch as well. If it
discovers on a subsequent message that the principal's epoch has
changed, it MUST consider all security associations created by that
principal as invalid, and take some action such as tearing those SA's
down.
It should be noted that KINK alone cannot provide a complete solution
for dead peer detection since in many situations a KINK peer would
have no reason to send subsequent KINK messages from whence it could
determine the epoch mismatch. The larger picture may require some
assistance from the IP layer itself to inform IPsec peers that they
are sending SA protected data into a black hole. Assuming this
mechanism is eventually defined, KINK peers SHOULD use this informa-
tion as a hint that something is amiss and perform a dead peer detec-
tion operation by using the STATUS message to elicit a response which
contains the peer's current epoch. Since the STATUS message is
integrity protected, it in combination with network layer messaging
should provide a secure means of recovery from dead peers.
4.5. STATUS Message Flow 4.5. STATUS Message Flow
At any point, a sender may send status, normally in the form of DOI At any point, a sender may send status, normally in the form of DOI
specific payloads to its peer. In the case of the IPsec DOI, these specific payloads to its peer. In the case of the IPsec DOI, these
are generally in the form of ISAKMP Notification Payloads. are generally in the form of ISAKMP Notification Payloads.
A B KDC A B KDC
------ ------ --- ------ ------ ---
1 STATUS+ISAKMP------------> 1 STATUS+ISAKMP------------>
2 <-------------REPLY+ISAKMP 2 <-------------REPLY+ISAKMP
Figure 4: STATUS Message Flow Figure 5: STATUS Message Flow
5. KINK Message Format 5. KINK Message Format
All values in KINK are formatted in the network byte order: Most All values in KINK are formatted in network byte order: Most
Significant Byte first. Significant Byte first.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer | MnVer | Length | | Type | MjVer | MnVer | Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) | | Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Transaction ID (XID) | | Transaction ID (XID) |
+---------------+---------------+-+-----------------------------+ +---------------+---------------+-+-----------------------------+
| CksumLen | NextPayload |A| Reserved | | CksumLen | NextPayload |A| Reserved |
+---------------+---------------+-+-----------------------------+ +---------------+---------------+-+-----------------------------+
| | | |
~ Cksum ~ ~ Cksum ~
| | | |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| | | |
~ A series of payloads ~ ~ A series of payloads ~
| | | |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
Figure 5: Format of a KINK message Figure 6: Format of a KINK message
Fields: Fields:
o Type (1 octet) - The type of message of this packet o Type (1 octet) - The type of message of this packet
Type Value Type Value
----- ----- ----- -----
RESERVED 0 RESERVED 0
CREATE 1 CREATE 1
DELETE 2 DELETE 2
REPLY 3 REPLY 3
GETTGT 4 GETTGT 4
ACK 5 ACK 5
STATUS 6 STATUS 6
o MjVer (4 bits) - Major protocol version number. This MUST be set o MjVer (4 bits) - Major protocol version number. This MUST be set
to 1. to 1.
o MnVer (4 bits) - Minor protocol version number. This MUST be set o MnVer (4 bits) - Minor protocol version number. This MUST be set
to 0. to 0.
o Length (16 bits) - Length of the message in octets. Note that it o Length (2 octets) - Length of the message in octets. Note that it
is legal within KINK to omit the last bytes of padding in the last is legal within KINK to omit the last bytes of padding in the last
payload in the overall length. payload in the overall length.
o DOI (4 octets) - The domain of interpretation. All DOI's must be o DOI (4 octets) - The domain of interpretation. All DOI's must be
registered with the IANA in the "Assigned Numbers" RFC [STD-2]. registered with the IANA in the "Assigned Numbers" RFC [STD-2].
The IANA Assigned Number for the Internet IP Security DOI (IPSEC The IANA Assigned Number for the Internet IP Security DOI (IPSEC
DOI) is one (1). This field defines the context of all other sub- DOI) is one (1). This field defines the context of all other sub-
payloads in this payloads. If other sub-payloads have a DOI field payloads in this payloads. If other sub-payloads have a DOI field
(example: Security Association Payload), then the DOI in that (example: Security Association Payload), then the DOI in that
sub-payload MUST be checked against the DOI in this header, and sub-payload MUST be checked against the DOI in this header, and
the values MUST be the same. the values MUST be the same.
o XID (4 octets) - The transaction ID. A KINK transaction is bound o XID (4 octets) - The transaction ID. A KINK transaction is bound
together by a transaction ID which is created by the command ini- together by a transaction ID which is created by the command ini-
tiator and replicated in subsequent messages in the transaction. A tiator and replicated in subsequent messages in the transaction. A
transaction is defined as a command, a reply, and an optional ack- transaction is defined as a command, a reply, and an optional ack-
nowledgment. Transaction ID's are used by the initiator to nowledgment. Transaction ID's are used by the initiator to
discriminate between multiple outstanding requests to a respon- discriminate between multiple outstanding requests to a respon-
dent. It is not used for replay protection because that func- dent. It is not used for replay protection because that func-
tionality is provided by Kerberos. tionality is provided by Kerberos. The value of XID is chosen by
the initiator and MUST be unique with all outstanding transac-
tions. XID's MAY be constructed by using a monotonic counter, or
random number generator.
o CksumLen (2 octets) -- CksumLen is the length in octets of the o CksumLen (2 octets) -- CksumLen is the length in octets of the
keyed hash of the message. A CksumLen of zero implies that the keyed hash of the message. A CksumLen of zero implies that the
message is unauthenticated. Note that as with payload padding, the message is unauthenticated. Note that as with payload padding, the
length here denotes the actual number of octets of the checksum length here denotes the actual number of octets of the checksum
structure not including any padding required. structure not including any padding required.
o NextPayload (1 octet) -- Indicates the type of the first payload o NextPayload (1 octet) -- Indicates the type of the first payload
after the message header after the message header
o A (1 bit) -- ACK Request. Set to one if the responder desires an o A (1 bit) -- ACK Request. Set to one if the responder requires an
explicit acknowledgement that a REPLY was received. An initiator explicit acknowledgment that a REPLY was received. An initiator
MUST NOT set this flag. MUST NOT set this flag, nor should any other command other than
CREATE request an ACK and then only when the optimistic SA is not
chosen.
o Reserved (15 bits) -- Reserved and must be zero o Reserved (15 bits) -- Reserved and must be zero
o Cksum (variable) - Keyed checksum over the entire message. This o Cksum (variable) - Keyed checksum over the entire message. This
field MUST always be present whenever a key is available via an 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 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 the ticket. When a key is not available, this field is not
present, and the CksumLen field is set to zero. The hash algorithm present, and the CksumLen field is set to zero. The hash algorithm
used is the same as specified in the etype for the Kerberos ses- used is the same as specified in the etype for the Kerberos ses-
sion key in the Kerberos ticket. If the etype does not specify a sion key in the Kerberos ticket. If the etype does not specify a
hash algorithm, SHA1 with a 20 byte checksum MUST be used. The hash algorithm, SHA1 with a 20 byte checksum MUST be used. The
format of the Cksum field is as follows: format of the Cksum field is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| checksum (variable) | padding (variable) | | checksum (variable) ~ padding (variable) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 6: KINK Checksum Figure 7: KINK Checksum
To compute the checksum, the checksum field is zeroed out and the
appropriate algorithm is run over the entire message (as given by
the Length field in the KINK header), and placed in the Checksum
field. To verify the checksum, the checksum is saved, and the
checksum field is zeroed out. The checksum algorithm is run over
the message, and the result is compared with the saved version. If
they do not match, the message MUST be dropped.
The KINK header is followed immediately by a series of The KINK header is followed immediately by a series of
Type/Length/Value fields, defined in the next section. Type/Length/Value fields, defined in the next section.
5.1. KINK Payloads 5.1. KINK Payloads
Immediately following the header, there is a list of Immediately following the header, there is a list of
Type/Length/Value (TLV) payloads. There can be any number of payloads Type/Length/Value (TLV) payloads. There can be any number of payloads
following the header. Each payload MUST begin with a payload header. following the header. Each payload MUST begin with a payload header.
Each payload header is built on the generic payload header. Any data Each payload header is built on the generic payload header. Any data
immediately follows the generic header. Payloads are all implicitly immediately follows the generic header. Payloads are all implicitly
padded to longword boundaries, though the payload length field MUST padded to 4 octet boundaries, though the payload length field MUST
accurately reflect the actual number of octets in the payload. accurately reflect the actual number of octets in the payload.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| value (variable) | | value (variable) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 7: Format of a KINK payload Figure 8: Format of a KINK payload
Fields: Fields:
o NextPayload (2 octets) - The type of the next payload o NextPayload (2 octets) - The type of the next payload
NextPayload Number NextPayload Number
---- ------ ---- ------
KINK_DONE 0 KINK_DONE 0 (same as ISAKMP_NEXT_NONE)
KINK_AP_REQ 1 KINK_AP_REQ 14
KINK_AP_REP 2 KINK_AP_REP 15
KINK_KRB_ERROR 3 KINK_KRB_ERROR 16
KINK_TGT_REQ 4 KINK_TGT_REQ 17
KINK_TGT_REP 5 KINK_TGT_REP 18
KINK_ISAKMP 6 KINK_ISAKMP 19
KINK_ENCRYPT 7 KINK_ENCRYPT 20
KINK_ERROR 8 KINK_ERROR 21
NextPayload type KINK_DONE denotes that the current payload is the NextPayload type KINK_DONE denotes that the current payload is the
final payload in the message. final payload in the message.
Note: the payload types are taken from the ISAKMP registry for
payload types. As such, payloads 0-13 are used for ISAKMP, and
22-127 are reserved to IANA.
o RESERVED (1 octet) - Unused, MUST be set to 0. o RESERVED (1 octet) - Unused, MUST be set to 0.
o Length (2 octets) - The length of this payload, including the Type o Length (2 octets) - The length of this payload, including the Type
and Length fields. and Length fields.
o Value (variable) - This field is depends on the Type. o Value (variable) - This value of this field depends on the Type.
5.1.1. KINK Padding Rules 5.1.1. KINK Padding Rules
KINK has the following rules regarding alignment and padding: KINK has the following rules regarding alignment and padding:
o All length fields MUST reflect the actual number of octets in the o All length fields MUST reflect the actual number of octets in the
structure; ie they do not account for padding bytes structure; ie they do not account for padding bytes
o Between KINK payloads, checksums, headers or any other other vari- o Between KINK payloads, checksums, headers or any other other vari-
able length data, the adjacent fields MUST be longword aligned. able length data, the adjacent fields MUST be aligned on 4 octet
boundaries.
o Variable length fields MUST always start immediately after the o Variable length fields MUST always start immediately after the
last octet of the previous field. Ie, they are not padded to a last octet of the previous field. Ie, they are not padded to a 4
longword boundary. octet boundary.
5.1.2. 5.1.1 KINK_AP_REQ Payload 5.1.2. 5.1.1 KINK_AP_REQ Payload
The KINK_AP_REQ payload relays a kerberos AP-REQ to the respondent. The KINK_AP_REQ payload relays a Kerberos AP-REQ to the respondent.
The AP-REQ MUST request mutual authetication. The service that the The AP-REQ MUST request mutual authentication. The service that the
KINK peer SHOULD request is "ipsec/fqdn@REALM" where "ipsec" is the KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is the
KINK IPsec service, "fqdn" is the fully qualified domain name of the KINK IPsec service, "fqdn" is the fully qualified domain name of the
service host, and REALM is the Kerberos realm of the service. The service host, and REALM is the Kerberos realm of the service. The
exception to this rule is when User-User service is requested in exception to this rule is when User-User service is requested in
which case the service name MUST be the service returned in the which case the service name MUST be the service returned in the
GetTGT response payload. GetTGT response payload.
The value field of this payload has the following format: The value field of this payload has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| | | |
~ KRB_AP_REQ ~ ~ KRB_AP_REQ ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 8: KINK_AP_REQ Payload Figure 9: KINK_AP_REQ Payload
Fields: Fields:
o EPOCH - the absolute time at which the creator of the AP-REQ has
valid security database (SADB) information. Typically this is when
the KINK keying daemon started if it does not retain SADB informa-
tion across different restarts. The format of this fields is net-
work order encoding of the standard posix four octet time stamp.
o KRB_AP_REQ - The value field of this payload contains a raw Ker- o KRB_AP_REQ - The value field of this payload contains a raw Ker-
beros KRB_AP_REQ. beros KRB_AP_REQ.
5.1.3. KINK_AP_REP Payload 5.1.3. KINK_AP_REP Payload
The KINK_AP_REP payload relays a kerberos AP-REP to the initiator. The KINK_AP_REP payload relays a kerberos AP-REP to the initiator.
The AP-REP MUST be checked for freshness as described in [1510]. The AP-REP MUST be checked for freshness as described in [KERBEROS].
The value field of this payload has the following format: The value field of this payload has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| EPOCH |
+---------------------------------------------------------------+
| | | |
~ KRB_AP_REP ~ ~ KRB_AP_REP ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 9: KINK_AP_REP Payload Figure 10: KINK_AP_REP Payload
Fields: Fields:
o EPOCH - the absolute time at which the creator of the AP-REP has
valid security database (SADB) information. Typically this is when
the KINK keying daemon started if it does not retain SADB informa-
tion across different restarts. The format of this fields is net-
work order encoding of the standard posix four octet time stamp.
o KRB_AP_REP - The value field of this payload contains a raw Ker- o KRB_AP_REP - The value field of this payload contains a raw Ker-
beros KRB_AP_REP. beros KRB_AP_REP.
5.1.4. KINK_KRB_ERROR Payload 5.1.4. KINK_KRB_ERROR Payload
The KINK_KRB_ERROR payload relays kerberos type errors back to the The KINK_KRB_ERROR payload relays Kerberos type errors back to the
initiator. The receiver MUST be prepared to receive any valid [1510] initiator. The receiver MUST be prepared to receive any valid
error type, but the sender SHOULD only send the following errors: [KERBEROS] error type, but the sender SHOULD send only the following
errors:
KRB5KRB_AP_ERR_BAD_INTEGRITY KRB5KRB_AP_ERR_BAD_INTEGRITY
KRB5KRB_AP_ERR_TKT_EXPIRED KRB5KRB_AP_ERR_TKT_EXPIRED
KRB5KRB_AP_ERR_TKT_NYV
KRB5KRB_AP_ERR_REPEAT
KRB5KRB_AP_ERR_NOT_US
KRB5KRB_AP_ERR_BADMATCH
KRB5KRB_AP_ERR_SKEW KRB5KRB_AP_ERR_SKEW
KRB5KRB_AP_ERR_BADADDR
KRB5KRB_AP_ERR_BADVERSION
KRB5KRB_AP_ERR_MSG_TYPE
KRB5KRB_AP_ERR_MODIFIED
KRB5KRB_AP_ERR_BADORDER
KRB5KRB_AP_ERR_ILL_CR_TKT
KRB5KRB_AP_ERR_BADKEYVER
KRB5KRB_AP_ERR_NOKEY KRB5KRB_AP_ERR_NOKEY
KRB5KRB_AP_ERR_MUT_FAIL KRB5KRB_AP_ERR_BADKEYVER
KRB5KRB_AP_ERR_BADDIRECTION
KRB5KRB_AP_ERR_METHOD
KRB5KRB_AP_ERR_BADSEQ
KRB5KRB_AP_ERR_INAPP_CKSUM
KRB5KRB_AP_WRONG_PRINC
KRB5KRB_AP_ERR_TKT_INVALID
A compliant KINK implementation MUST take appropriate action for:
KRB5KRB_AP_ERR_BAD_INTEGRITY KINK implementations MUST make use of keyed Kerberos errors when the
KRB5KRB_AP_ERR_TKT_EXPIRED appropriate service key is available as specified in [KRBREVS]. In
KRB5KRB_AP_ERR_REPEAT particular, clock skew errors MUST be integrity protected. For
KRB5KRB_AP_ERR_SKEW unauthenticated Kerberos errors, the receiver MAY choose to act on
KRB5KRB_AP_ERR_MUT_FAIL them, but SHOULD take precautions against make-work kinds of attacks.
Note that KINK does not make use of the text or e_data field of the Note that KINK does not make use of the text or e_data field of the
Kerberos error message, though a compliant KINK implementation MUST Kerberos error message, though a compliant KINK implementation MUST
be prepared to receive them. be prepared to receive them and MAY log them.
The value field of this payload has the following format: The value field of this payload has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
~ KRB_ERROR ~ ~ KRB_ERROR ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 10: KINK_KRB_ERROR Payload
Figure 11: KINK_KRB_ERROR Payload
Fields: Fields:
o KRB_ERROR - The value field of this payload contains a raw o KRB_ERROR - The value field of this payload contains a raw
Kerberos KRB_ERROR. Kerberos KRB_ERROR.
5.1.5. KINK_TGT_REQ Payload 5.1.5. KINK_TGT_REQ Payload
The KINK_TGT_REQ payload provides a means to get a TGT from the peer The KINK_TGT_REQ payload provides a means to get a TGT from the peer
in order to obtain a User to User service ticket from the KDC in order to obtain a User to User service ticket from the KDC
skipping to change at page 17, line 30 skipping to change at page 17, line 24
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| RealmNameLen | RealmName (variable) ~ | RealmNameLen | RealmName (variable) ~
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
~ RealmName(variable) ~ ~ RealmName(variable) ~
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 11: KINK_TGT_REQ Payload Figure 12: KINK_TGT_REQ Payload
Fields: Fields:
o RealmNameLen - The length of the realm name that follows o RealmNameLen - The length of the realm name that follows
o RealmName - The realm name that the responder should return a TGT o RealmName - The realm name that the responder should return a TGT
for. for.
o RESERVED - reserved and must be zero o RESERVED - reserved and must be zero
skipping to change at page 18, line 28 skipping to change at page 18, line 28
~ PrincName(variable) +---------------+ ~ PrincName(variable) +---------------+
| ~ padding | | ~ padding |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
| TGTlength | TGT (variable) | | TGTlength | TGT (variable) |
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
| ~ | ~
~ TGT (variable) +---------------+ ~ TGT (variable) +---------------+
| ~ padding | | ~ padding |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 12: KINK_TGT_REQ Payload Figure 13: KINK_TGT_REQ Payload
Fields: Fields:
o PrincNameLen - The length of the principal name that immediately o PrincNameLen - The length of the principal name that immediately
follows follows
o PrincName - The client principal that the initiator should request o PrincName - The client principal that the initiator should request
a User to User service ticket for. a User to User service ticket for.
o TGTlength - The length of TGT that immediately follows o TGTlength - The length of TGT that immediately follows
skipping to change at page 19, line 14 skipping to change at page 19, line 14
5.1.7. KINK_ISAKMP Payload 5.1.7. KINK_ISAKMP Payload
The value field of this payload has the following format: The value field of this payload has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+-------+-------+---------------+---------------+ +---------------+-------+-------+---------------+---------------+
| InnerNextPload| IkeMj | IkeMn | RESERVED | | InnerNextPload| QMMaj | QMMin | RESERVED |
+---------------+-------+-------+---------------+---------------+ +---------------+-------+-------+---------------+---------------+
| IKE Phase II Payloads (variable) | | Quick Mode Payloads (variable) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 13: KINK_ISAKMP Payload Figure 14: KINK_ISAKMP Payload
Fields: Fields:
o InnerNextPload - First payload type of the inner series of ISAKMP o InnerNextPload - First payload type of the inner series of ISAKMP
payloads. payloads.
o IkeMj - The ISAKMP major version of the inner payloads. o QMMaj - The major version of the inner payloads. MUST be set to 1.
o IkeMn - The IKE minor version of the inner payloads o QMMin - The minor version of the inner payloads. MUST be set to 0.
o RESERVED - reserved and must be zero o RESERVED - reserved and must be zero
The purpose of the ISAKMP version is to allow backward compati- The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase
bilty with IKE and ISAKMP if there subsequent revisions. At the two) payloads to take the appropriate action dependent on the KINK
present time, the ISAKMP major and minor versions are set to one command. There may be any number of KINK_ISAKMP payloads within a
and one (1.1) respectively. While strictly speaking the ISAKMP single KINK message. While IKE is somewhat fuzzy about whether
version is not the same as the IKE version, that is how it is com- multiple different SA's may be created within a single IKE mes-
monly construed, and KINK explicitly makes that linkage. A com- sage, KINK explicitly requires that a new ISAKMP header be used
plient KINK implementation MUST support receipt of ISAKMP version for each discrete SA operation. In other words, a KINK sender MUST
1.1 payloads. It MAY support subsequent versions (both sending and NOT send multiple quick mode transactions within a single
receiving), and SHOULD provide a means to resort back to ISAKMP KINK_ISAKMP payload.
version 1.1 if the KINK peer is unable to process future versions.
A complient KINK implementation MUST NOT mix ISAKMP versions in The purpose of the Quick Mode version is to allow backward compa-
any given transaction. tibility with IKE and ISAKMP if there are subsequent revisions. At
the present time, the Quick Mode major and minor versions are set
to one and zero (1.0) respectively. These versions do not
correspond to the ISAKMP version in the ISAKMP header. A compliant
KINK implementation MUST support receipt of 1.0 payloads. It MAY
support subsequent versions (both sending and receiving), and
SHOULD provide a means to resort back to Quick Mode version 1.0 if
the KINK peer is unable to process future versions. A compliant
KINK implementation MUST NOT mix Quick Mode versions in any given
transaction.
5.1.8. KINK_ENCRYPT Payload 5.1.8. KINK_ENCRYPT Payload
The KINK_ENCRYPT payload encapsulates other payloads and is encrypted The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
using the encyption algorithm specified by the etype of the session using the encryption algorithm specified by the etype of the session
key. This payload MUST be the final payload in the message. KINK key. This payload MUST be the final payload in the message. KINK
encrypt payloads MUST be encrypted before the final KINK checksum is encrypt payloads MUST be encrypted before the final KINK checksum is
applied. applied.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| InnerNextPload| RESERVED | | InnerNextPload| RESERVED |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Payload (variable) | | Payload (variable) |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 14: KINK_ENCRYPT Payload Figure 15: KINK_ENCRYPT Payload
Fields: Fields:
o InnerNextPload (variable) - First payload type of the inner series o InnerNextPload (variable) - First payload type of the inner series
of encrypted KINK payloads. of encrypted KINK payloads.
o RESERVED - reserved and must be zero o RESERVED - reserved and must be zero
Note: the coverage of the encrypted data begins at InnerNextPload Note: the coverage of the encrypted data begins at InnerNextPload
so that first payload's type is kept confidential. Thus, the so that first payload's type is kept confidential. Thus, the
number of encrypted octets is PayloadLength - 4. number of encrypted octets is PayloadLength - 4.
[XXX/mat: I'm trying to say use krb5_c_encrypt() The format of the encryption payload uses the normal [KERBEROS]
without IV set to NULL. I may be on crack here, so somebody
say something if this is wrong.]
The format of the encryption payload uses the normal [RFC1510]
semantics of prepending a crypto-specific initialization vector semantics of prepending a crypto-specific initialization vector
and padding the entire message out to the crypto-specfic number of and padding the entire message out to the crypto-specific number
bytes. For example, with DES-CBC, the initialization vector will of bytes. For example, with DES-CBC, the initialization vector
be 8 octets long, and the entire message will be padded to an 8 will be 8 octets long, and the entire message will be padded to an
octet boundary. Note that KINK Encrypt payload MUST NOT include a 8 octet boundary. Note that KINK Encrypt payload MUST NOT include
checksum since this is redundant with the message integrity check- a checksum since this is redundant with the message integrity
sum in the KINK header. checksum in the KINK header.
5.1.9. KINK_ERROR Payload 5.1.9. KINK_ERROR Payload
The KINK_ERROR payload type provides a protocol level mechanism of The KINK_ERROR payload type provides a protocol level mechanism of
returning an error condition. This payload should not be used for returning an error condition. This payload should not be used for
either Kerberos generated errors, or DOI specific errors which have either Kerberos generated errors, or DOI specific errors which have
their own payloads defined. The error code is a an network order their own payloads defined. The error code is in network order.
integer.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length | | Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| ErrorCode | | ErrorCode |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
Figure 15: KINK_ERROR Payload Figure 16: KINK_ERROR Payload
ErrorCode Number ErrorCode Number Purpose
--------- ------ --------- ------ -------------------
KINK_OK 0 KINK_OK 0 - No error detected
KINK_PROTOERR 1 KINK_PROTOERR 1 - The message was malformed
KINK_INVDOI 2 KINK_INVDOI 2 - Invalid DOI
KINK_INVMAJ 3 KINK_INVMAJ 3 - Invalid Major Version
KINK_INVMIN 4 KINK_INVMIN 4 - Invalid Minor Version
KINK_INTERR 5 KINK_INTERR 5 - An unrecoverable internal error was
detected
RESERVED 6 - 8191 RESERVED 6 - 8191
Private Use 8192 - 16383 Private Use 8192 - 16383
o KINK_OK - No error detected 6. KINK Quick Mode Payload Profile
o KINK_PROTOERR - The message was malformed
o KINK_INVDOI - Invalid DOI
o KINK_INVMAJ - Invalid Major Version
o KINK_INVMIN - Invalid Minor Version
o KINK_INTERR - An unrecoverable internal error was detected
6. KINK Messages
KINK messages are either commands, replies, or acknowledgments. A
command is sent by an initiator to the respondent. A reply is sent
by the respondent to the initator. If the respondent desires confir-
mation of the reply, it sets the ACKREQ bit in the message header.
The initiator will then respond with an ACK messages. All commands,
responses and acknowledgements are bound together by the XID field of
the message header. The XID is normally a monotonically incrementing
field, and is used by the initiator to differentiate between out-
standing requests to a responder. The XID field does not provide
replay protection as that functionality is provided by Kerberos
mechanisms. In addition, commands and responses MUST use a
cryptographic hash over the entire message if the two peers share a
symmetric key via a ticket exchange.
6.1. CREATE
This message initiates an establishment of new Security
Association(s). The CREATE message must contain an AP-REQ payload and
any DOI specific payloads. The valid ISAKMP-CREATE payloads are
described in section 7.
CREATE contains the following payloads:
KINK Header
KINK_AP_REQ Payload
[KINK_ENCRYPT]
[ISAKMP-CREATE-PAYLOADS]
6.2. DELETE
This message indicates that the sending peer has deleted or will
shortly delete Security Association(s) with the other peer. The
valid ISAKMP-DELETE payloads are described in section 7.
DELETE contains the following payloads:
KINK Header (with DOI)
KINK_AP_REQ Payload
[KINK_ENCRYPT]
[ISAKMP-DELETE-PAYLOADS]
6.3. REPLY
The REPLY message is a generic reply which must contain either a
KINK_AP_REP or a KRB-ERROR payload. REPLY's may contain additional
DOI specific payloads such as ISAKMP payloads defined in this docu-
ment. The valid ISAKMP-REPLY payloads are described in section 7.
REPLY
KINK Header
KINK_AP_REP | KINK_KRB_ERROR Payload
[KINK_ENCRYPT]
[ KINK_ERROR ]
[ISAKMP-REPLY-PAYLOADS]
All REPLY messages must contain either a KINK_AP_REP or
KINK_KRB_ERROR. It may optionally contain a KINK_ERROR. The checksum
in the KRB-ERROR message is not used, since the KINK header already
contains a checksum field.
The server MUST return a KRB_AP_ERR_SKEW if the server clock and the
client clock are off by more than the policy-determined clock skew
limit (usually 5 minutes). The optional client's time in the KRB-
ERROR MUST be filled out, and the client MUST 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.
6.4. ACK
This is an acknowledgment returned to the originator of a REPLY mes-
sage. This message MUST NOT contain any payloads beside a lone AP-REQ
header. If the initiator detects an error in the AP-REP or any other
KINK or Kerberos error, it SHOULD take remedial action by reinitiat-
ing the initial command with the appropriate error to instruct the
KINK receiver how to correct its original problem.
ACK
KINK Header
[KINK_AP_REQ]
6.5. STATUS
This is an acknowledgment returned to the originator of a REPLY mes-
sage. This message MUST NOT contain any DOI specific payloads. ACK
MAY contain both KINK_ERROR's and KRB_ERROR's. In particular, if a
command initiator found an error in the AP_REP, it MUST send an ACK
with the proper Kerberos error regardless of the state of the ACKREQ
flag of the respondent. The respondent SHOULD be prepared to receive
an unexpected ACK from the initiator. The valid ISAKMP-STATUS pay-
loads are described in section 7.
STATUS
KINK Header
[KINK_AP_REQ]
[KINK_ENCRYPT]
[ KINK_ERROR ]
[ISAKMP-STATUS-PAYLOADS]
7. IPSEC DOI-specific ISAKMP Payloads
KINK directly uses IKE/ISAKMP payloads to negotiate security associa- KINK directly uses ISAKMP payloads to negotiate security associa-
tions. In particular, KINK uses IKE phase II payload types (aka Quick tions. In particular, KINK uses IKE phase II payload types (aka Quick
Mode). In general, there should be very few changes necessary to for Mode). In general, there should be very few changes necessary to an
an IKE implemenation to establish the security associations, and IKE implementation to establish the security associations, and unless
unless there is a note to the contrary in the memo, all capabilities there is a note to the contrary in the memo, all capabilities and
and requirements in [IKE] MUST be supported. IKE Phase I payloads requirements in [IKE] MUST be supported. IKE Phase I payloads MUST
MUST NOT be sent. NOT be sent.
Unlike IKE, KINK defines specific commands for creation, deletion, Unlike IKE, KINK defines specific commands for creation, deletion,
and status of security associations, mainly to facilitate predictable and status of security associations, mainly to facilitate predictable
SA creation/deletion (see section 4.3 and 4.4). As such, KINK places SA creation/deletion (see section 4.3 and 4.4). As such, KINK places
certain restrictions on what payloads may be sent with which com- certain restrictions on what payloads may be sent with which com-
mands, and some additional restrictions and semantics of some of the mands, and some additional restrictions and semantics of some of the
payloads. Implementors should refer to [IKE] and [ISAKMP] for the payloads. Implementors should refer to [IKE] and [ISAKMP] for the
actual format and semantics. If a particular IKE phase II payload is actual format and semantics. If a particular IKE phase II payload is
not mentioned here, it means that there are no differences in its not mentioned here, it means that there are no differences in its
use. use.
7.1. IKE Phase II (Quick Mode) Differences 6.1. General Quick Mode Differences
The following sections detail the differences to standard IKE phase
II payloads which must be incorporated for a complient KINK impleme-
nation.
7.1.1. Security Association Payload Differences
o The Security Association Payload header for IP is defined in o The Security Association Payload header for IP is defined in
[IPDOI] section 4.6.1. For this memo, the Domain of Interpreta- [IPDOI] section 4.6.1. For this memo, the Domain of Interpreta-
tion MUST be set to 1 (IPSec) and the Situation bitmap MUST be tion MUST be set to 1 (IPSec) and the Situation bitmap MUST be
set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted set to 1 (SIT_IDENTITY_ONLY). All other fields are omitted
(because SIT_IDENTITY_ONLY is set). (because SIT_IDENTITY_ONLY is set).
o KINK also expands the semantics of IKE in that the first propo- o KINK also expands the semantics of IKE in it defines an optmis-
sal MUST be the proposal which the sender of a CREATE command is tic proposal for CREATE commands to allow SA creation to com-
prepared to receive incoming IPsec datagrams. plete in two messages.
o IKE quick mode (phase 2) uses the hash algorithm used in main o IKE Quick Mode (phase 2) uses the hash algorithm used in main
mode (phase 1) to generate the keying material. KINK MUST use mode (phase 1) to generate the keying material. KINK MUST use
the hashing algorithm specified in the session ticket's etype. the hashing algorithm specified in the session ticket's etype.
o PFS uses the Diffie Hellman group used in the phase 1 exchange. o KINK does not use the HASH payload at all.
KINK uses XXX.
7.1.2. Security Association Attributes Supported o KINK allows the NONCE payload Nr to be optional to facilitate
optimistic keying.
6.2. Security Association Payloads
KINK supports the following security association attributes from KINK supports the following security association attributes from
[IPDOI]: [IPDOI]:
class value type class value type
------------------------------------------------- -------------------------------------------------
SA Life Type 1 B SA Life Type 1 B
SA Life Duration 2 V SA Life Duration 2 V
Encapsulation Mode 4 B Encapsulation Mode 4 B
Authentication Algorithm 5 B Authentication Algorithm 5 B
Key Length 6 B Key Length 6 B
Key Rounds 7 B Key Rounds 7 B
Refer to [IPDOI] for the actual definitions for these attributes. Refer to [IPDOI] for the actual definitions for these attributes.
7.1.3. Identification Payload Differences 6.3. Proposal and Transform Payloads
KINK directly uses the Proposal and Transform payloads with no
differences. KINK, however, places additional relevance to the first
proposal and first transform of each conjugate for optimistic keying.
6.4. Identification Payloads
The Identification payload carries information that is used to iden- The Identification payload carries information that is used to iden-
tify the traffic that is to be protected using the keys exchanges in tify the traffic that is to be protected using the keys exchanges in
this memo. (NB: The payload name is misleading, and should really be this memo. KINK restricts the ID types to the following values:
called the selector payload). KINK only restricts the selector types
to the following:
ID Type Value ID Type Value
------- ----- ------- -----
ID_IPV4_ADDR 1 ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4 ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5 ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6 ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7 ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8 ID_IPV6_ADDR_RANGE 8
7.1.4. Nonce Payloads 6.5. Nonce Payloads
The Nonce payload contains random data that MUST be used in key The Nonce payload contains random data that MUST be used in key
generation by the initiating KINK peer, and MAY be used by the generation by the initiating KINK peer, and MAY be used by the
responding KINK peer. In IKE, the nonce payload also provides proof responding KINK peer.
of freshness of the exchange, but this functionality is already
provided by Kerberos' use of timestamps for liveliness. A receiving
KINK peer MUST NOT use the nonce payload as the primary freshness
indicator, though it MAY use it as an additional check.
7.1.5. Notify Payloads 6.6. Notify Payloads
Notification information can be error messages specifying why an SA Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process. managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the For example, a secure front end or security gateway may use the
Notify message to synchronize SA communication. The table below Notify message to synchronize SA communication. The table below
lists the Notification messages and their corresponding values that lists the Notification messages and their corresponding values that
are supported in KINK. are supported in KINK.
NOTIFY MESSAGES - ERROR TYPES NOTIFY MESSAGES - ERROR TYPES
Errors Value Errors Value
INVALID-PAYLOAD-TYPE 1 INVALID-PAYLOAD-TYPE 1
SITUATION-NOT-SUPPORTED 3 [?] SITUATION-NOT-SUPPORTED 3
INVALID-MAJOR-VERSION 5 INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6 INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7 INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8 INVALID-FLAGS 8
INVALID-MESSAGE-ID 9 INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10 INVALID-PROTOCOL-ID 10
INVALID-SPI 11 INVALID-SPI 11
INVALID-TRANSFORM-ID 12 INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13 ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14 NO-PROPOSAL-CHOSEN 14
skipping to change at page 26, line 49 skipping to change at page 24, line 49
NOTIFY MESSAGES - STATUS TYPES NOTIFY MESSAGES - STATUS TYPES
Status Value Status Value
CONNECTED 16384 CONNECTED 16384
RESERVED (Future Use) 16385 - 24575 RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767 DOI-specific codes 24576 - 32767
Private Use 32768 - 40959 Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535 RESERVED (Future Use) 40960 - 65535
7.1.6. PFS Support 6.7. Delete Payloads
KINK directly uses ISAKMP delete payloads with no changes.
6.8. KE Payloads
IKE requires that perfect forward secrecy be supported through the IKE requires that perfect forward secrecy be supported through the
use of the KE payload. However, Kerberos in general does not provide use of the KE payload. However, Kerberos in general does not provide
PFS so it is somewhat questionable whether a system which is heavily PFS so it is somewhat questionable whether a system which is heavily
relying on Kerberos benefits from PFS. KINK retains the ability to relying on Kerberos benefits from PFS. KINK retains the ability to
use PFS, but relaxes the requirement from must implement to SHOULD use PFS, but relaxes the requirement from must implement to SHOULD
implement. implement.
7.2. IPsec DOI Message Formats 7. IPsec DOI Message Formats
7.2.1. CREATE KINK messages are either commands, replies, or acknowledgments. A
command is sent by an initiator to the respondent. A reply is sent
by the respondent to the initiator. If the respondent desires confir-
mation of the reply, it sets the ACKREQ bit in the message header.
The ACKREQ bit MUST NOT be set by the respondent except in the lone
case of a CREATE message for which one of the security associations
did not use the optimistic payload. In that case, the ACKREQ bit MUST
be set. All commands, responses and acknowledgments are bound
together by the XID field of the message header. The XID is normally
a monotonically incrementing field, and is used by the initiator to
differentiate between outstanding requests to a responder. The XID
field does not provide replay protection as that functionality is
provided by Kerberos mechanisms. In addition, commands and responses
MUST use a cryptographic hash over the entire message if the two
peers share a symmetric key via a ticket exchange.
7.1. REPLY Message Considerations
The REPLY message is a generic reply which MUST contain either a
KINK_AP_REP, a KRB-ERROR, or KINK_ERROR payload. REPLY's MAY contain
additional DOI specific payloads such as ISAKMP payloads which are
defined in the following sections. The checksum in the KRB-ERROR
message is not used, since the KINK header already contains a check-
sum field.
The server MUST return a KRB_AP_ERR_SKEW if the server clock and the
client clock are off by more than the policy-determined clock skew
limit (usually 5 minutes). The optional client's time in the KRB-
ERROR MUST be filled out, and the client MUST 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.
7.2. ACK Message Considerations
ACK's are sent only when the ACKREQ bit is set in a REPLY message.
ACK's MUST NOT contain any payloads beside a lone AP-REQ header. If
the initiator detects an error in the AP-REP or any other KINK or
Kerberos error, it SHOULD take remedial action by reinitiating the
initial command with the appropriate error to instruct the KINK
receiver how to correct its original problem.
7.3. CREATE
This message initiates an establishment of new Security This message initiates an establishment of new Security
Association(s). The CREATE message must contain an AP-REQ payload and Association(s). The CREATE message must contain an AP-REQ payload and
any DOI specific payloads. any DOI specific payloads.
CREATE contains the following payloads: CREATE KINK Header
KINK Header KINK_AP_REQ
KINK_AP_REQ payload
[KINK_ENCRYPT] [KINK_ENCRYPT]
KINK_ISAKMP payload KINK_ISAKMP payload
SA Payload[s] SA Payload[s]
Proposal Payloads Proposal Payloads
Transform Payloads Transform Payloads
Nonce Payload (Ni) Nonce Payload (Ni)
[KE] [KE]
[IDci, IDcr] [IDci, IDcr]
[Notification Payloads] [Notification Payloads]
Note: KINK, like IKE allows the creation of many security
associations in one create command. If any of the optimistic creation
mode proposals is not chosen by the respondent, it MUST request an
ACK.
Replies are of the following forms: Replies are of the following forms:
REPLY REPLY KINK Header
KINK Header KINK_AP_REP
KINK_AP_REP payload
[KINK_ENCRYPT] [KINK_ENCRYPT]
KINK_ISAKMP payload KINK_ISAKMP
SA Payload[s] SA Payload[s]
Proposal Payload Proposal Payload
Transform Payload Transform Payload
[ Nonce Payload (Nr)] [ Nonce Payload (Nr)]
[IDci, IDcr] [IDci, IDcr]
[Notification Payloads] [Notification Payloads]
Note that there MUST be at least a single proposal payload and a Note that there MUST be at least a single proposal payload and a
single transform payload in REPLY messages. Also: unlike IKE, the single transform payload in REPLY messages. Also: unlike IKE, the
Nonce Payload Nr is not required, and its absense means that the Nonce Payload Nr is not required, and its absence means that the
optimistic mode SA's installed by the initiator are valid. If any of optimistic mode SA's installed by the initiator are valid. If any of
the first proposals are not chosen by the recipient, it MUST include the first proposals are not chosen by the recipient, it MUST include
the nonce payload as well to indicate that the initiator's outgoing the nonce payload as well to indicate that the initiator's outgoing
SA's must be modified. SA's must be modified.
KINK, like IKE allows the creation of many security associations in
one create command. If any of the optimistic creation mode proposals
is not chosen by the respondent, it MUST request an ACK.
If an IPspec DOI specific error is encountered, the respondent must If an IPspec DOI specific error is encountered, the respondent must
reply with a Notify payload describing the error: reply with a Notify payload describing the error:
REPLY REPLY KINK Header
KINK Header KINK_AP_REP
KINK_AP_REP payload
[KINK_ENCRYPT] [KINK_ENCRYPT]
[ KINK_ERROR payload ] [KINK_ERROR]
KINK_ISAKMP payload KINK_ISAKMP
[Notification Payloads] [Notification Payloads]
Finally, if the respondent finds an Kerberos or KINK type of error it If the respondent finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
Finally, if the respondent finds a Kerberos or KINK type of error it
which it cannot create a AP-REP for, MUST reply with a lone which it cannot create a AP-REP for, MUST reply with a lone
KINK_KRB_ERROR or KINK_ERROR payload: KINK_KRB_ERROR or KINK_ERROR payload:
REPLY REPLY KINK Header
KINK Header [KINK_KRB_ERROR]
KINK_KRB_ERROR|KINK_ERROR payload [KINK_ERROR]
7.2.2. DELETE 7.4. DELETE
This message indicates that the sending peer has deleted or will This message indicates that the sending peer has deleted or will
shortly delete Security Association(s) with the other peer. shortly delete Security Association(s) with the other peer.
DELETE contains the following payloads: DELETE KINK Header
KINK Header KINK_AP_REQ
KINK_AP_REQ payload
[KINK_ENCRYPT] [KINK_ENCRYPT]
[ KINK_ERROR payload ] [ KINK_ERROR payload ]
KINK_ISAKMP payload KINK_ISAKMP payload
Delete Payload[s] Delete Payload[s]
[Notification Payloads] [Notification Payloads]
There are three forms of replies for a DELETE. The normal form is: There are three forms of replies for a DELETE. The normal form is:
REPLY REPLY KINK Header
KINK Header KINK_AP_REP
KINK_AP_REP payload
[KINK_ENCRYPT] [KINK_ENCRYPT]
[ KINK_ERROR payload ] [ KINK_ERROR payload ]
KINK_ISAKMP payload KINK_ISAKMP payload
Delete Payload[s] Delete Payload[s]
[Notification Payloads] [Notification Payloads]
If an IPspec DOI specific error is encountered, the respondent must If an IPsec DOI specific error is encountered, the respondent must
reply with a Notify payload describing the error: reply with a Notify payload describing the error:
REPLY REPLY KINK Header
KINK Header
KINK_AP_REP payload KINK_AP_REP payload
[ KINK_ENCRYPT payload ] [ KINK_ENCRYPT payload ]
[ KINK_ERROR payload ] [ KINK_ERROR payload ]
KINK_ISAKMP payload KINK_ISAKMP payload
[Notification Payloads] [Notification Payloads]
If the respondent finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
If the respondent finds a KINK or Kerberos type of error it MUST If the respondent finds a KINK or Kerberos type of error it MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY REPLY KINK Header
KINK Header [KRB_ERROR]
KRB_ERROR | KINK_KRB_ERROR payload [KINK_KRB_ERROR]
7.2.3. STATUS 7.5. STATUS
This message indicates that the sending peer has deleted or will The STATUS command is used in two ways:
shortly delete Security Association(s) with the other peer.
STATUS contains the following payloads: 1) As a means to relay an ISAKMP Notification message
KINK Header
KINK_AP_REQ payload
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
KINK_ISAKMP payload
[Notification Payloads]
There are three forms of replies for a STATUS. The normal form is: 2) As a means of probing a peer whether its epoch has changed for
dead peer detection.
REPLY STATUS contains the following payloads:
KINK Header KINK Header
KINK_AP_REP payload KINK_AP_REQ payload
[KINK_ENCRYPT] [ [KINK_ENCRYPT]
[ KINK_ERROR payload ] [ KINK_ERROR payload ]
KINK_ISAKMP payload [Notification Payloads] KINK_ISAKMP payload
[Notification Payloads] ]
If an IPspec DOI specific error is encountered, the respondent must There are two forms of replies for a STATUS. The normal form is:
reply with a Notify payload describing the error:
REPLY REPLY KINK Header
KINK Header KINK_AP_REP
KINK_AP_REP payload [ [KINK_ENCRYPT]
[ KINK_ENCRYPT payload ] [KINK_ERROR]
[ KINK_ERROR payload ] KINK_ISAKMP
KINK_ISAKMP payload [Notification Payloads] [Notification Payloads] ]
If the respondent finds a Kerberos error for which it can produce a
valid authenticator, the REPLY takes the following form:
REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR
If the respondent finds a KINK or Kerberos type of error it MUST If the respondent finds a KINK or Kerberos type of error it MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload: reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:
REPLY REPLY
KINK Header KINK Header
KRB_ERROR | KINK_KRB_ERROR payload [KRB_ERROR]
[KINK_KRB_ERROR]
8. Key Derivation 8. Key Derivation
KINK uses the same key derivation mechanisms that [IKE] uses in sec- KINK uses the same key derivation mechanisms that [IKE] uses in sec-
tion 5.5, which is: tion 5.5, which is:
KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b]) KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b])
The following differences apply: The following differences apply:
o SKEYID_d is the session key in the Kerberos service ticket from o SKEYID_d is the session key in the Kerberos service ticket from
the AP-REQ. the AP-REQ.
o Nr_b is optional o Nr_b is optional
By optional, it is meant that the equivalent of a zero length By optional, it is meant that the equivalent of a zero length
nonce was supplied. nonce was supplied.
9. Transport Considerations 9. Transport Considerations
KINK uses UDP on port XXX to transport its messages. There is one KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages.
timer T which SHOULD take into consideration round trip considera- There is one timer T which SHOULD take into consideration round trip
tions and MUST implement a truncated exponential backoff mechanism. considerations and MUST implement a truncated exponential backoff
The state machines is simple: any message which expects a response mechanism. The state machine is simple: any message which expects a
must retransmit the request using timer T. Since Kerberos requires response MUST retransmit the request using timer T. Since Kerberos
that messages be retransmitted with new times for replay protection, requires that messages be retransmitted with new times for replay
the message must be recreated each time including the checksum of the protection, the message MUST be recreated each time including the
message. checksum of the message. Both commands and replies with the ACKREQ
bit set are kept on retransmit timers. When a KINK initiator receives
Note that in KINK delivery of a final ACK is not reliable. A KINK a REPLY with the ACKREQ bit set, it MUST retain the ability to regen-
implementation that asks for a final ACK MUST be prepared for the ACK erate the ACK message for the transaction for a minimum of its a full
not being delivered. Two mechanisms are possible to work around the retransmission timeout cycle or until it notices that packets have
need for a final ACK: arrived on the newly constructed SA, whichever comes first.
1) A timer of the average round trip time between the two KINK
peers times some comfort margin can be started. If the ACK is
not received within that time period, the requestor can assume
that either its response was lost by the initiator, or that the
ACK was lost. In the first case, the initiator will usually
retransmit the initial request within the timeout period. In the
second case, the final cleanup should be performed as if the
initiator sent the ACK.
2) If reliability is required, the respondent could initiate a When a KINK peer retransmits a message, it MUST create a new Kerberos
security association in the opposite direction with the same authenticator for the AP-REQ so that the peer can differentiate
characteristics. This has the downside of instantiating two between replays and dropped packets. This results in a potential race
security associations simultaneously and is not recommended. condition when a retransmission occurs before an in-flight reply is
received/processed. To counter this race condition, the retransmit-
ting party SHOULD keep a list of valid authenticators which are out-
standing for any particular transaction.
10. Security Considerations 10. Security Considerations
KINK cobbles together and reuses many parts of both Kerberos and IKE, KINK cobbles together and reuses many parts of both Kerberos and IKE,
the latter which in turn is cobbled together from many other memos. the latter which in turn is cobbled together from many other memos.
As such, KINK inherits many of the weaknesses and considerations of As such, KINK inherits many of the weaknesses and considerations of
each of its components. However, KINK only uses IKE Phase II payload each of its components. However, KINK uses only IKE Phase II payloads
to create and delete security association, the security considera- to create and delete security associations, the security considera-
tions which pertain to IKE Phase I can be safely ignored. tions which pertain to IKE Phase I may be safely ignored.
KINK's use of Kerberos presents a couple of considerations. First, KINK's use of Kerberos presents a couple of considerations. First,
KINK explicitly expects that the KDC will provide adequate entropy KINK explicitly expects that the KDC will provide adequate entropy
when it generates session keys. Second, Kerberos normally being a when it generates session keys. Second, Kerberos is used as a user
user authentication vehicle allows for potentially weak user and key- authentication protocol with the possibility of dictionary attacks on
tab keys which in turn can be the weak link in subsequently generated user passwords. This memo does not describe a particular method to
IPsec security associations. This memo does not describe a particular avoid these pitfalls, but recommends that suitable randomly generated
method to avoid these pitfalls, but recommends that suitable randomly keys be used for the service principals such as using the -randomkey
generated keys be used for the service principals and client princi- option with MIT's "kadmin addprinc" command as well as for clients
pals such as using the -randomkey option with MIT's "kadmin addprinc" when that is practical.
command.
Kerberos itself does not provide for perfect forward secrecy which Kerberos itself does not provide for perfect forward secrecy which
makes KINK's reliance on the IKE ability to do PFS somewhat suspect makes KINK's reliance on the IKE ability to do PFS somewhat suspect
from an overall system's standpoint. In isolation KINK itself should from an overall system's standpoint. In isolation KINK itself should
be secure from offline analysis from compromised principal be secure from offline analysis from compromised principal
passphrases if PFS is used, but the existence of other Kerberized passphrases if PFS is used, but the existence of other Kerberized
service which do not provide PFS makes this a less than optimal service which do not provide PFS makes this a less than optimal
situation on the whole. situation on the whole.
11. IANA Considerations 10.1. Security Policy Database Considerations
KINK requires that a new well known port UDP be created. Since KINK
uses standard message types from [IKE], KINK does not require any new
registries. Any new DOI's, ISAKMP types, etc for future versions of
KINK MUST use the registries defined for [IKE].
12. Protocol Considerations
12.1. Security Policy Database Considerations
KINK leaves the population of the IPsec security policy database out KINK leaves the population of the IPsec security policy database out
of scope. There are, however, considerations which should be pointed of scope. There are, however, considerations which should be pointed
out. Firstly, even though when and when not to initiate a user to out. First, even though when and when not to initiate a user to user
user flow is left to the discretion of the KINK implemention, a Ker- flow is left to the discretion of the KINK implementation, a Kerberos
beros client which initially authenticated using a symmetric key client which initially authenticated using a symmetric key SHOULD NOT
SHOULD NOT use a user-user flow if the respondent is also in the same use a user-user flow if the respondent is also in the same realm.
realm. Likewise, a KINK initiator which authenticated in a public
key realm SHOULD use a user-user flow if the respondent is in the
same realm.
KINK does not define the cross realm behavior. At a minimum a the Likewise, a KINK initiator which authenticated in a public key realm
security policy database for a KINK implementation SHOULD contain a SHOULD use a user-user flow if the respondent is in the same realm.
logical record of the KDC to contact, principal name for the respon-
dent, and whether the KINK implementation should use a direct AP- At a minimum the security policy database for a KINK implementation
REQ/AP-REP flow, or a User-User flow to CREATE/DELETE the security SHOULD contain a logical record of the KDC to contact, principal name
association. for the respondent, and whether the KINK implementation should use a
direct AP-REQ/AP-REP flow, or a User-User flow to CREATE/DELETE the
security association.
That said, there is considerable room for improvement on how a KINK That said, there is considerable room for improvement on how a KINK
initiator could auto-discover how a respondent in a different realm initiator could auto-discover how a respondent in a different realm
initially authenticated. This is left as an implementation detail as initially authenticated. This is left as an implementation detail as
well as the subject of possible future standardization efforts which well as the subject of possible future standardization efforts which
are outside of the scope of the KINK working group. are outside of the scope of the KINK working group.
13. Related Work 11. IANA Considerations
KINK requires that a new well known system port for UDP be created.
Since KINK uses standard message types from [IKE], KINK does not
require any new registries. Any new DOI's, ISAKMP types, etc for
future versions of KINK MUST use the registries defined for [IKE].
12. Related Work
The IPsec working group has defined a number of protocols that pro- The IPsec working group has defined a number of protocols that pro-
vide the ability to create and maintain cryptographically secure vide the ability to create and maintain cryptographically secure
security associations at layer three (ie, the IP layer). This effort security associations at layer three (ie, the IP layer). This effort
has produced two distinct protocols: has produced two distinct protocols:
o a mechanism for encrypting and authenticating IP datagram o a mechanism for encrypting and authenticating IP datagram
payloads which assumes a shared secret between the sender and payloads which assumes a shared secret between the sender and
receiver receiver
skipping to change at page 33, line 5 skipping to change at page 32, line 5
the peer to peer nature of IKE requires the use of Diffie Hellman the peer to peer nature of IKE requires the use of Diffie Hellman
(DH) to establish a shared secret. DH, unfortunately, is computation- (DH) to establish a shared secret. DH, unfortunately, is computation-
ally quite expensive and prone to denial of service attacks. IKE also ally quite expensive and prone to denial of service attacks. IKE also
relies on X.509 certificates to realize scalable authentication of relies on X.509 certificates to realize scalable authentication of
peers. Digital signatures are also computationally expensive and cer- peers. Digital signatures are also computationally expensive and cer-
tificate based trust models are difficult to deploy in practice. tificate based trust models are difficult to deploy in practice.
While IKE does allow for pre-shared symmetric keys, key distribution While IKE does allow for pre-shared symmetric keys, key distribution
is required between all peers -- an O(n2) problem -- which is prob- is required between all peers -- an O(n2) problem -- which is prob-
lematic for large deployments. lematic for large deployments.
14. References 13. References
[RFC1510] [KERBEROS]
J. Kohl, C. Neuman. The Kerberos Network Authentication Service J. Kohl, C. Neuman. The Kerberos Network Authentication Service
(V5). Request for Comments 1510. (V5). Request for Comments 1510.
[KERB]B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service [KERB]B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service
for Computer Networks, IEEE Communications, 32(9):33-38. Sep- for Computer Networks, IEEE Communications, 32(9):33-38. Sep-
tember 1994. tember 1994.
[PKINIT] [PKINIT]
B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray, B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky, J. Wray,
J. Trostle. Public Key Cryptography for Initial Authentication J. Trostle. Public Key Cryptography for Initial Authentication
in Kerberos. draft-ietf-cat-kerberos-pk-init-11.txt in Kerberos. draft-ietf-cat-kerberos-pk-init-11.txt
[PKCROSS] [PKCROSS]
M.Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky, M.Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky,
B. Sommerfeld. Public Key Cryptography for Cross-Realm Authen- B. Sommerfeld. Public Key Cryptography for Cross-Realm Authen-
tication in Kerberos. draft-ietf-cat-kerberos-pk-cross-06.txt tication in Kerberos. draft-ietf-cat-kerberos-pk-cross-06.txt
[RFC2401] [IPSEC]
S. Kent, R. Atkinson. Security Architecture for the Internet S. Kent, R. Atkinson. Security Architecture for the Internet
Protocol. Request for Comments 2401. Protocol. Request for Comments 2401.
[IKE]D. Harkins, D. Carrel. The Internet Key Exchange (IKE). [IKE]D. Harkins, D. Carrel. The Internet Key Exchange (IKE).
Request for Comments 2409. Request for Comments 2409.
[ISAKMP] [ISAKMP]
Maughhan, D., Schertler, M., Schneider, M., and J. Turner, Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol "Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[IPDOI] [IPDOI]
Piper, D., "The Internet IP Security Domain Of Interpretation Piper, D., "The Internet IP Security Domain Of Interpretation
for ISAKMP", RFC 2407, November 1998. for ISAKMP", RFC 2407, November 1998.
15. Mailing List [RFC2412]
Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
November 1998.
[RFC793]
Postel, J., "Transmission Control Protocol", RFC 793, Sep-01-
1981
14. Mailing List
Please send comments to the KINK mailing list (ietf-kink@vpnc.org). Please send comments to the KINK mailing list (ietf-kink@vpnc.org).
You can subscribe by sending mail to ietf-kink-request@vpnc.org with You can subscribe by sending mail to ietf-kink-request@vpnc.org with
a line in the body of the mail with the word SUBSCRIBE in it. a line in the body of the mail with the word SUBSCRIBE in it.
16. Author's Addresses 15. Author's Addresses
Mike Froh Mike Froh
CyberSafe Corporation CyberSafe Corporation
180 Elgin Street 180 Elgin Street
Ottawa, Ontario K2P 2K3 Ottawa, Ontario K2P 2K3
Phone: +1 613 234 7300 Phone: +1 613 234 7300
E-mail: mike.froh@cybersafe.com E-mail: mike.froh@cybersafe.com
Matthew Hur
David McGrew David McGrew
Mike Thomas Michael Thomas
Jan Vilhuber Jan Vilhuber
Matthew Hur
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
E-mail: {mcgrew,mat,mhur,vilhuber}@cisco.com E-mail: {mcgrew,mat,mhur,vilhuber}@cisco.com
Sasha Medvinsky Sasha Medvinsky
Motorola Motorola
6450 Sequence Drive 6450 Sequence Drive
San Diego, CA 92121 San Diego, CA 92121
+1 858 404 2367 +1 858 404 2367
E-mail: smedvinsky@gi.com E-mail: smedvinsky@gi.com
17. Acknowledgements 16. Acknowledgments
Many have contributed to the KINK effort, including our working group Many have contributed to the KINK effort, including our working group
chairs Derek Atkins and Jonathan Trostle. The original inspiration chairs Derek Atkins and Jonathan Trostle. The original inspiration
came from Cablelab's Packetcable effort which defined a simplifed came from Cablelab's Packetcable effort which defined a simplifed
version of Kerberized IPsec. The inspiration for wholly reusing IKE version of Kerberized IPsec. The inspiration for wholly reusing IKE
Phase II is the result of the Tero Kivinen's initial draft suggesting Phase II is the result of the Tero Kivinen's initial draft suggesting
the obvious. the obvious.
 End of changes. 138 change blocks. 
610 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/