WDIFF

draft-ietf-kink-kink-06.txt --> draft-ietf-kink-kink-07.txt

INTERNET-DRAFT Shoichi Sakane
KINK Working Group Ken'ichi Kamada
Yokogawa Electric Corp.
M. Thomas
J. Vilhuber
December 3, 2003
Cisco Systems
Expires: November 28, 2005 May 27, 2005

Kerberized Internet Negotiation of Keys (KINK)
draft-ietf-kink-kink-06.txt
draft-ietf-kink-kink-07.txt

Status of this Memo

This document

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is an Internet-Draft aware
have been or will be disclosed, and is any of which he or she becomes
aware will be disclosed, in full conformance accordance with
all provisions of Section 10 6 of RFC2026. BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." progress".

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html

This document is a submission by the KINK Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the KINK mailing list (ietf-kink@vpnc.org). 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.

Distribution of this memo is unlimited.

This Internet-Draft expires in November 28, 2005.

Thomas, Vilhuber [Page 1]
^L
Internet-Draft KINK May 2005

Abstract

The

This document describes the Kerberized Internet Negotiation of Keys
protocol (KINK) and the domain of interpretation (DOI). KINK defines
a low-latency, computationally inexpensive, easily managed, and
cryptographically sound protocol to set up establish and maintain IPsec security
associations (SAs) using the Kerberos authentication. authentication system. KINK
reuses many
ISAKMP the payloads of Quick Mode payloads to create, delete and maintain IPsec
security associations of the Internet Key Exchange (IKE),
which should lead to substantial reuse of existing IKE
implementations.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.

It is assumed that the reader is familiar with the terms and concepts
described in the Kerberos version 5 [KERBEROS], IPsec [IPSEC] and IKE
[IKE].

Thomas, Vilhuber [Page 2]
^L
Internet-Draft KINK May 2005

Table of Contents

1. Introduction .................................................... 2 ................................................. 5
2. Terminology ..................................................... 2 .................................................. 5
3. Protocol Overview ............................................... 4

Thomas, Vilhuber [Page 1]

INTERNET DRAFT KINK December 2003 ............................................ 6
4. Message Flows ................................................... 5 ................................................ 6
4.1. Standard KINK Message Flow ..................................... 5 .............................. 6
4.2. GETTGT Message Flow ............................................ 5 ..................................... 7
4.3. CREATE Security Association .................................... 5 ............................. 7
4.3.1. CREATE Key Derivation Considerations ............. 8
4.4. DELETE Security Association .................................... 7 ............................. 9
4.4.1. Rekeying Security Associations ................... 10
4.4.2. Dead Peer Detection .............................. 11
4.5. STATUS Message Flow ............................................ 10 ..................................... 12
5. KINK Message Format ............................................. 10 .......................................... 12
5.1. KINK Payloads .................................................. 13 ........................................... 15
5.1.1. KINK Quick Mode Padding Rules ............................... 16
5.1.2. KINK_AP_REQ Payload Profile ................................. 22
General Quick Mode Differences ................................. 22
Security Association Payloads .................................. 23
Proposal and Transform Payloads ................................ 23
Identification Payloads ........................................ .............................. 16
5.1.3. KINK_AP_REP Payload .............................. 17
5.1.4. KINK_KRB_ERROR Payload ........................... 18
5.1.5. KINK_TGT_REQ Payload ............................. 19
5.1.6. KINK_TGT_REP Payload ............................. 20
5.1.7. KINK_ISAKMP Payload .............................. 21
5.1.8. KINK_ENCRYPT Payload ............................. 22
5.1.9. KINK_ERROR Payload ............................... 23
Nonce
6. KINK Quick Mode Payload Profile .............................. 23
6.1. General Quick Mode Differences .......................... 24
6.2. Security Association Payloads ................................................. ........................... 24
6.3. Proposal and Transform Payloads ......................... 25
6.4. Identification Payloads ................................. 25
6.5. Nonce Payloads .......................................... 25
6.6. Notify Payloads ................................................ 24 ......................................... 25
6.7. Delete Payloads ................................................ 25 ......................................... 26
6.8. KE Payloads .................................................... 25 ............................................. 26
7. IPsec DOI Message Formats ....................................... 26 .................................... 27
7.1. REPLY Message Considerations ................................... 26 ............................ 27
7.2. ACK Message Considerations ..................................... 26 .............................. 27
7.3. CREATE Message ................................................. 27 .......................................... 28
7.4. DELETE Message ................................................. 28 .......................................... 29
7.5. STATUS Message ................................................. 29 .......................................... 30
8. Key Derivation .................................................. 30 ............................................... 31
9. Transport Considerations ........................................ 30 ..................................... 32
10. Security Considerations ......................................... 31 ...................................... 32
10.1. Security Policy Database Considerations ........................ 31 ................ 33
11. IANA Considerations ............................................. 32 .......................................... 34
12. Forward Compatibility Considerations ............................ 32 ......................... 34
12.1. New Versions of Quick Mode ..................................... 32 ............................. 34
12.2. New DOI ........................................................ 33 ................................................ 35

Thomas, Vilhuber [Page 3]
^L
Internet-Draft KINK May 2005

13. Related Work .................................................... 33 ................................................. 35
14. Acknowledgments .............................................. 36
15. References ................................................... 36
15.1. Normative References ............................................ 34 ................................... 36
15.2. Informative References .......................................... 35
Mailing List .................................................... 35
Author's ................................. 37
Authors' Addresses .............................................. 35
Acknowledgments ................................................. 36
IPR Notice ...................................................... 36 ............................................... 37
Change History (To be removed from RFC) .......................... 38
Full Copyright .................................................. 36 Statement ......................................... 38
Intellectual Property Statement .................................. 38

Thomas, Vilhuber [Page 2]

INTERNET DRAFT 4]
^L
Internet-Draft KINK December 2003 May 2005

1. Introduction

KINK is designed to provide a secure, scalable mechanism for estab-
lishing
establishing keys between communicating entities within a centrally
managed environment in which it is important to maintain consistent
security policy. The security goals of KINK are to provide privacy,
authentication, and replay protection of key management messages, and
to avoid denial of service vulnerabilities whenever possible. The
performance goals of the protocol are to incur a low computational
cost, to have low latency, to have a small footprint, and to avoid or
minimize the use of public key operations. In particular, the proto-
col
protocol provides the capability to establish IPsec security
associations in two messages with minimal computational effort.

Kerberos [KERB] and [KERBEROS] provides an efficient mechanism for
trusted third party authentication
mechanism for clients and servers. (Ker-
beros servers using trusted third-party model.
(Kerberos also provides an mechanisms for inter-realm authentication
natively and with [PKCROSS].) Clients obtain tickets
natively.) A client obtains a ticket from an online authentication
server (the Key Distribution Center or KDC). Tickets
are The ticket is then used
to construct credentials a credential for authenticating the client to the
server. As a result of this authentication operation, the client and
the server will also share a secret. secret key. KINK uses this pro-
perty property as
the basis of distributing keys for IPsec.

The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity versus IKE's [IKE]
necessity of using public key cryptography. Initial authentication
to the KDC may be performed using either symmetric keys or asymmetric
keys using [PKINIT]; however, subsequent requests for tickets, as
well as authenticated exchanges between client and server always
utilize symmetric cryptography. Therefore, public key operations (if
any) are limited and are amortized over the lifetime of the initial
authentication operation to the Kerberos KDC. For example, a client
may use a single public key exchange with the KDC to efficiently
establish multiple security associations with many other servers in
the extended realm of the KDC. Kerberos also scales better than
direct peer to peer keying when symmetric keys are used. The reason
is that since the keys are stored in the KDC, the number of principal
keys is O(n) rather than O(n*m), where "n" is the number of clients
and "m" is the number of servers. Kerberos, like any internet proto-
col,
protocol, does have its own security considerations. You can find
them discussed in [KERBEROS] and [KERB]

This document specifies [KERB].

2. Terminology

Editor's comment: remain it for the Kerberized Internet Negotiation order of Keys
Protocol and sections referred from

Thomas, Vilhuber [Page 5]
^L
Internet-Draft KINK May 2005

the domain of interpretation (DOI) for establishing issue list.

3. Protocol Overview

KINK is a command/response protocol which can create, delete, and
maintaining IPsec Security Associations [IPSEC]. No other domains of
interpretation are defined in this document.

2. Terminology

Ticket
A Kerberos term for a record that helps a client authenticate

Thomas, Vilhuber [Page 3]

INTERNET DRAFT KINK December 2003

itself to a server; it contains the client's identity, a session
key, a lifetime, and other information, all sealed using the
server's secret key. The combination of a ticket and an authentica-
tor (which proves freshness and knowledge of the key within the
ticket) creates an authentication credential.

KDC
Key Distribution Center, a network service that supplies tickets
and temporary session keys; or an instance of that service or the
host on which it runs. The KDC services both initial ticket and
Ticket-Granting Ticket (TGT) requests. The initial ticket portion
is referred to as the Authentication Server (or service). The
Ticket-Granting Ticket portion is referred to as the Ticket-
Granting Server (or service).

Realm
A Kerberos administrative domain. A single KDC may be responsible
for one or more realms. A fully qualified principal name includes
a realm name along with a principal name unique within that realm.

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.

User-User
Kerberos normally divides the world into clients and servers where
the server maintains a table of keys (keytab) which is used to
encrypt/decrypt service tickets. In situations where a principal
may not have a keytab (ex. a human/client principal rather than a
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.

Principal
Kerberos named entities are known as principals, Principals are
either client or service principals. A principal is an entity that
engages in a security relationship. A Kerberos principal name is
roughly equivalent to an X.509 distinguished name (it associates
the principal with an adminsitrative domain). Principals may be
client or servers. A server principal is generally distinguished
by a flag in a KDC principal database and by a keytab maintained by
the server.

Thomas, Vilhuber [Page 4]

INTERNET DRAFT KINK December 2003

DER
ASN.1 Distinguished Encoding Rules; Kerberos version 5 uses this
encoding format of ASN.1.

Quick-Mode
IKE defines two phases: an authentication phase (phase 1, or Main
Mode) and a security association maintenance phase (phase 2, or
Quick Mode). KINK reuses IKE Quick Mode.

AP-REQ/AP-REP
Kerberos defines an standardized message format and transport for
contacting a KDC to perform initial authentication, and for grant-
ing subsequent service tickets. When a client needs to authenticate
to a server, Kerberos provides a standardized message format, but
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.

3. Protocol Overview

KINK is a command/response protocol which can create, delete and
maintain
maintain IPsec security associations. Each command or response con-
tains
contains a common header along with a set of type-length-value
payloads which are constrained according to the type of command or
response. KINK itself is a stateless protocol in that each command
or response does not require storage of hard state for KINK itself. KINK. This is
in contrast to IKE's use of Main Mode to first establish an ISAKMP secu-
rity
security association followed by subsequent Quick Mode exchanges.

KINK uses Kerberos mechanisms to provide mutual authentication and
replay protection. For security association establishment. establishment, KINK pro-
vides
provides privacy of the payloads which follow the Kerberos authentica-
tor.
authenticator. 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 User-to-User mechanisms when there isn't a
key shared between the server and the KDC. This is typically -- typically, but
not limited
to -- to, the case with IPsec peers using [PKINIT] for initial authenti-
cation.
authentication.

KINK directly reuses [ISAKMP] Quick Mode payloads, payloads defined in section 5.5 of
[IKE], with some minor changes and omissions. In most cases, KINK
exchanges are a single command and its response. The lone exception is
that the CREATE command
which allows may have a final acknowledgment message when third message. When the respondent needs
a full three-way handshake. This is only needed when responder
disagrees with the optimistic
keying route is not taken, though proposal, it is expected that that will not
be requests the third
message, an acknowledgement, to the norm. initiator in order to complete a
non-optimistic keying. KINK also provides rekeying and dead peer detection as
basic features.

Thomas, Vilhuber [Page 5]

INTERNET DRAFT KINK December 2003
detection.

4. Message Flows

KINK message flows all follow the same pattern between the two peers:
a command, a response response, and a possible acknowledgment with CREATE's.
The actual Kerberos KDC traffic here is for illustrative purposes
only. In practice, when a principal obtains various tickets is a sub-
ject
subject of Kerberos and local policy consideration. In these flows,
we assume that A and B both have TGT's from their KDC.

4.1. Standard KINK Message Flow

Thomas, Vilhuber [Page 6]
^L
Internet-Draft KINK May 2005

A B KDC
------ ------ ---
1 COMMAND------------------->

2 <------------------REPLY

3 [ ACK---------------------> ]

Figure 1: KINK Message Flow

4.2. GETTGT Message Flow

If the initiator determines that it will not be able to get a normal
service ticket for the respondent (eg, responder (e.g., B is a client principal), it
MUST first fetch the TGT from the respondent responder in order to get a User-
User
to-User service ticket:

A B KDC
------ ------ ---
1 GETTGT+KRB_TGT_REQ------->

2 <-------REPLY+KRB_TGT_REP

3 TGS-REQ+TGT(B)------------------------------------->

4 <--------------------------------------------TGS-REP

Figure 2: GETTGT Message Flow

Thomas, Vilhuber [Page 6]

INTERNET DRAFT KINK December 2003

4.3. CREATE Security Association

This flow instantiates a security association. The CREATE command
takes an "optimistic" approach where security associations are
initially created on the expectation that the respondent responder will chose choose
the initial proposed payload. The optimistic payload proposal is defined as
the first transform of the first proposal of the first conjugate.
The initiator MUST check to see if the optimistic payload proposal was
selected by comparing all transforms and attributes which MUST be
identical from those in the initiator's optimistic proposal with the lone
exception
exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Both Each of these
attributes MAY be set to a lower value by the respondent responder 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.

Thomas, Vilhuber [Page 7]
^L
Internet-Draft KINK May 2005

A B KDC
------ ------ ---

A creates initial inbound SA (B->A)

1 CREATE+ISAKMP------------>

B creates inbound SA to A (A->B). If B chooses A's optimistic
proposal, it creates the outbound SA as well (B->A).

2 <------------REPLY+ISAKMP

A creates outbound SA and modifies inbound SA if it first
proposal wasn't acceptable.

3 [ ACK--------------------> ]

[ B creates the outbound SA to A (B-A). ]

Figure 3: CREATE Message Flow

The security associations are instantiated as follows: In step one
host A creates an inbound security association in its security asso-
ciation
association database from B->A using the optimistic proposal in the
ISAKMP SA proposal. It is then ready to receive any messages from B.
A then sends the CREATE message to B. If B agrees to A's optimistic
proposal, B instantiates a security association in its database from
A->B. B then instantiates the security association from B->A. It
then sends a REPLY to A without a NONCE payload and without
requesting an ACK. If B does not choose the first proposal, it sends
the actual choice in the REPLY. It SHOULD send the optional NONCE
payload (as it does not increase message count and generally
increases entropy sources) and MUST request that the REPLY be
acknowledged. Upon receipt of the REPLY, A modifies the inbound
security association as necessary, instantiates the security
association from A->B, If B

Thomas, Vilhuber [Page 7]

INTERNET DRAFT KINK December 2003 requested an ACK, A now sends the ACK
message. Upon receipt of the ACK, B installs the final security
association from B->A.

Note: if B adds a nonce, or does not choose the first proposal, it
MUST request an ACK so that it can install the final outbound secu-
rity
security association. The initiator MUST always generate an ACK if
the ACKREQ bit is set in the KINK header, even if it believes that
the
respondent responder was in error.

4.3.1. CREATE Key Derivation Considerations

Thomas, Vilhuber [Page 8]
^L
Internet-Draft KINK May 2005

The CREATE command's optimistic approach allows a security associa-
tion
association to be created in two messages rather than three. The
implication of a two message two-message exchange is that B will not contribute
to the key since A must set up the inbound security association
before it receives any additional keying material from B. Under
normal cir-
cumstances circumstances this may be suspect, however KINK takes
advantage of the fact that the KDC provides a reliable source of
randomness which is used in key derivation. In many cases, this will
provide an adequate session key so that B will not require an
acknowledgment. Since B is always at liberty to contribute to the
keying material, this is strictly a tradeoff between the key strength
versus the number of messages tradeoff messages, which KINK implementations may decide
as a matter of policy.

4.4. DELETE Security Association

The DELETE command deletes an existing security association. The DOI
specific payloads describe the actual security association to be
deleted. For the IPSEC DOI, those payloads will include an ISAKMP
payload containing the SPI to be deleted in each direction.

A B KDC
------ ------ ---

A deletes outbound SA to B

1 DELETE+ISAKMP------------>

B deletes inbound and outbound SA to A

2 <-------------REPLY+ISAKMP

A deletes inbound SA to B

Figure 4: DELETE Message Flow

The DELETE command takes a "pessimistic approach" "pessimistic" approach which does not
delete incoming security associations until it receives acknowledg-
ment
acknowledgment that the other host has received the DELETE. The
exception to

Thomas, Vilhuber [Page 8]

INTERNET DRAFT KINK December 2003 the pessimistic approach is if the initiator wants to
immediately cease all activity on an incoming SA. In this case, it
MAY delete the incoming SA as well in step one. If the receiver
cannot find an appropriate SPI to delete, it MUST return an ISAKMP
INVALID_SPI 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

Thomas, Vilhuber [Page 9]
^L
Internet-Draft KINK May 2005

delete notification messages if the SPI is found, or ISAKMP
INVALID_SPI if it is not.

A race condition with DELETE exists. Packets in flight while the
DELETE operation is taking place may, due to network reordering, etc,
arrive after the diagrams above recommend deleting the incoming secu-
rity
security association. A KINK implementation SHOULD implement a grace
timer which SHOULD be set to a period of at least two times the aver-
age
average round trip time, or to a configurable value. A KINK implementa-
tion
implementation MAY chose choose to set the grace period to zero at
appropriate times to ungracefully delete a security association. association ungracefully. The
behavior described here loosely mimics the behavior of the TCP
[RFC793] flags FIN and RST.

4.4.1. Rekeying Security Associations

KINK requires the initiator of a security association to be responsi-
ble
responsible for rekeying a security association. The reason is
twofold: the first is to prevent needless duplication of security
associations as the result of collisions due to an initiator and respondent
responder both try-
ing trying to renew an existing security association. The
second reason is due to the client/server nature of Kerberos
exchanges which expects the client to get and maintain tickets.
While KINK requires that a KINK host be is able to get and maintain
tickets, in practice it is often advantageous for servers to wait for
clients to initiate ses-
sions sessions so that they do not need to maintain a
large ticket cache.

There are no special semantics for rekeying security associations in
KINK. That is, in order to rekey an existing security association,
the initiator must CREATE a new security association followed by
either DELETE'ing the old security association or letting it time
out. When identical flow selectors are available on different secu-
rity
security associations, KINK implementations SHOULD choose the
security 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
associations 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 expiration time minus the amount of time it would take to go
through a full retransmission time cycle, Tretrans. Trekey SHOULD be

Thomas, Vilhuber [Page 10]
^L
Internet-Draft KINK May 2005

set at least twice as high as Tretrans.

Thomas, Vilhuber [Page 9]

INTERNET DRAFT KINK December 2003

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 security association information for a peer 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 mes-
sage
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.

While a KINK peer SHOULD use feedback from routing (in the form of
ICMP messages) as a trigger to check whether the peer is still alive
or not, a KINK peer MUST NOT conclude the peers is dead simply based
on unprotected routing information (said ICMP messages).

If there is suspicion that a peer may be dead (based on any informa-
tion
information available to the KINK peer, including lack of IPsec
traffic, etc), the KINK STATUS message SHOULD be used to coerce an acknowledg-
ment
acknowledgment out of the peer. Since nothing is negiotiated negotiated about
dead peer detection in KINK, each peer can decide its own metric for 'suspi-
cion'
'suspicion' and also what time-outs to use before declaring a peer
dead due to lack of response to the STATUS message. This is desireable,
desirable, and does not break interoperability.

The STATUS message has a two-fold effect: First, it elicits a crypto-
graphically
cryptographically secured (and replay-protected) response from the
peer, which tells us whether the peer is reachable/alive or not.
Further, it carries the epoch number of the peer, so we know whether
the peer has rebooted and lost all state or not. This is crucial to
the KINK protocol: In IKE, if a peer reboots, we loose lose all
cryptographic con-
text, context, and no cryptographically secure communication
is possible without renegotiating keys. In KINK, due to Kerberos
tickets, we can communicate securely with a peer, even if the peer
rebooted, as the shared cryptographic key used is carried in the
Kerberos ticket. Thus, active cryptographic communication is not an
indication that the peer has not rebooted and lost all state, and the
epoch is needed.

Assume a Peer A sending a STATUS and a peer B sending the REPLY (see
section 4.5). Peer B MAY assume that the sender is alive, and the
epoch in the STATUS message will indicate whether the peer A has lost
state or not. Peer B MUST acknowledge the STATUS message with a
REPLY message, as described in section 4.5.

Thomas, Vilhuber [Page 11]
^L
Internet-Draft KINK May 2005

The REPLY message will indicate to peer A that the peer is alive, and
the epoch in the REPLY will indicate whether peer B has lost its
state or not. If peer A does not receive a REPLY message from peer B
in a suitable timeout, peer A MAY send another STATUS message. It is
up to peer A to decide how aggressively to declare peer B dead. The
level of aggressiveness may depend on many factors such as rapid
failover fail
over versus number of messages sent by nodes with large numbers of
security associations.

Thomas, Vilhuber [Page 10]

INTERNET DRAFT KINK December 2003

Note that peer B MUST NOT make any inferences about a lack of STATUS
message from peer A. Peer B MAY use a STATUS message from peer A as
indication of A's aliveness, but peer B MUST NOT expect another
STATUS message at any time (i.e. Dead Peer detection is not periodic
keepalives).

Strategies for sending STATUS messages: Peer A may decide to send a
STATUS message only after a prolonged period where no traffic was
sent in either direction over the IPsec SA's with the peer. Once
there is traffic, peer A may want to know if the traffic going into a
black hole, and send a STATUS message. Alternatively, peer A may use
an idle timer to detect lack of traffic with the peer, and send
STATUS messages in the quiet phase to make sure the peer is still
alive for when traffic needs to finally be sent.

4.5. STATUS Message Flow

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
are generally in the form of ISAKMP Notification Payloads.

A B KDC
------ ------ ---

1 STATUS+ISAKMP------------>

2 <-------------REPLY+ISAKMP

Figure 5: STATUS Message Flow

Thomas, Vilhuber [Page 11]

INTERNET DRAFT KINK December 2003

5. KINK Message Format

All values in KINK are formatted in network byte order: Most order (Most
Significant Byte first. first). The RESERVED fields MUST be set to zero (0)
when a packet is sent. The receiver MUST ignore these fields.

Thomas, Vilhuber [Page 12]
^L
Internet-Draft KINK May 2005

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | MjVer | MnVer | Length |
+---------------+---------------+---------------+---------------+
| Domain of Interpretation (DOI) |
+-------------------------------+-------------------------------+
| Transaction ID (XID) |
+---------------+---------------+-+-----------------------------+
| CksumLen | NextPayload |A| Reserved RESERVED |
+---------------+---------------+-+-----------------------------+
| |
~ Cksum ~
| |
+-------------------------------+-------------------------------+
| |
~ A series of payloads ~
| |
+-------------------------------+-------------------------------+

Figure 6: Format of a KINK message

Fields:

o Type (1 octet) - The type of message of this packet

Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6

o MjVer (4 bits) - Major protocol version number. This MUST be set
to 1.

o MnVer (4 bits) - Minor protocol version number. This MUST be set
to 0.

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
payload in the overall length.

o DOI (4 octets) - The domain of interpretation. All DOI's must be
registered with the IANA in the "Assigned Numbers" RFC [STD-2].

Thomas, Vilhuber [Page 12]

INTERNET DRAFT 13]
^L
Internet-Draft KINK December 2003 May 2005

Defined values are specified by the ISAKMP Domain of
Interpretation section in the IANA isakmp-registry [ISAKMP-REG].
The IANA Assigned Number for the Internet IP Security DOI (IPSEC
DOI) [IPDOI]
is one (1). This field defines the context of all other sub-
payloads sub-payloads in
this payloads. message. If other sub-payloads have a DOI field (example: Security
Association Payload), then the DOI in that sub-payload MUST be
checked against the DOI in this header, and the values MUST be the
same.

o XID (4 octets) - The transaction ID. A KINK transaction is bound
together by a transaction ID which is created by the command ini-
tiator
initiator and replicated in subsequent messages in the
transaction. A transaction is defined as a command, a reply, and
an optional ack-
nowledgment. acknowledgment. Transaction ID's are used by the
initiator to discriminate between multiple outstanding requests to
a respon-
dent. responder. It is not used for replay protection because that func-
tionality
functionality is provided by Kerberos. The value of XID is chosen
by the initiator and MUST be unique with all outstanding transac-
tions.
transactions. 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
keyed hash of the message. A CksumLen of zero implies that the
message is unauthenticated. Note that as with payload padding,
the length here denotes the actual number of octets of the
checksum structure not including any padding required.

o NextPayload (1 octet) -- Indicates the type of the first payload
after the message header header.

o A (1 bit) -- ACK Request. Set to one if the responder requires an
explicit acknowledgment that a REPLY was received. An initiator
MUST NOT set this flag, nor should any other command other than
CREATE request an ACK and then only when the optimistic SA proposal
is not chosen.

o Reserved RESERVED (15 bits) -- Reserved and must MUST be zero on send, MUST be
ignored by a receiver.

o Cksum (variable) - Keyed checksum over the entire message. This
field MUST always be present whenever a key is available via an
AP-REQ or AP-REP payload. The key used MUST be the session key in
the ticket. When a key is not available, this field is not
present, and the CksumLen field is set to zero. The hash
algorithm used is the same as specified in the etype for the
Kerberos ses-
sion session key in the Kerberos ticket. If the etype does
not specify a hash algorithm, the message MUST be rejected.

Thomas, Vilhuber [Page 14]
^L
Internet-Draft KINK May 2005

The format of the Cksum field is as follows:

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
+---------------+---------------+---------------+---------------+
| checksum (variable) ~ padding (variable) |
+---------------+---------------+---------------+---------------+

Figure 7: KINK Checksum

Thomas, Vilhuber [Page 13]

INTERNET DRAFT KINK December 2003

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
Type/Length/Value fields, defined in the next section.

5.1. KINK Payloads

Immediately following the header, there is a list of
Type/Length/Value (TLV) payloads. There can be any number of
payloads following the header. Each payload MUST begin with a
payload header. Each payload header is built on the generic payload
header. Any data immediately follows the generic header. Payloads
are all implicitly padded to 4 octet 4-octet boundaries, though the payload
length field MUST accurately reflect the actual number of octets in
the payload.

Figure 8: Format of a KINK payload

Fields:

o NextPayload (2 (1 octets) - The type of the next payload

NextPayload Number

Thomas, Vilhuber [Page 15]
^L
Internet-Draft KINK May 2005

---- ------
KINK_DONE 0 (same as ISAKMP_NEXT_NONE)
KINK_AP_REQ KINK_ISAKMP_PAYLOAD_BASE+0
KINK_AP_REP KINK_ISAKMP_PAYLOAD_BASE+1
KINK_KRB_ERROR KINK_ISAKMP_PAYLOAD_BASE+2
KINK_TGT_REQ KINK_ISAKMP_PAYLOAD_BASE+3
KINK_TGT_REP KINK_ISAKMP_PAYLOAD_BASE+4
KINK_ISAKMP KINK_ISAKMP_PAYLOAD_BASE+5
KINK_ENCRYPT KINK_ISAKMP_PAYLOAD_BASE+6
KINK_ERROR KINK_ISAKMP_PAYLOAD_BASE+7

NextPayload type KINK_DONE denotes that the current payload is the
final payload in the message.

Thomas, Vilhuber [Page 14]

INTERNET DRAFT KINK December 2003 in the message.

Note: the payload types are taken from the ISAKMP registry for
payload types. See the IANA consideration section for the value
of KINK_ISAKMP_PAYLOAD_BASE.

o RESERVED (1 octet) - Unused, Reserved and MUST be set to 0. zero on send, MUST be
ignored by a receiver.

o Length (2 octets) - The length of this payload, including the Type
and Length fields.

o Value (variable) - This value of this field depends on the Type.

5.1.1. KINK Padding Rules

KINK has the following rules regarding alignment and padding:

o All length fields MUST reflect the actual number of octets in the
structure; ie i.e., they do not account for padding bytes bytes.

o Between KINK payloads, checksums, headers headers, or any other other vari-
able variable
length data, the adjacent fields MUST be aligned on 4 octet 4-octet
boundaries.

o Variable length fields MUST always start immediately after the
last octet of the previous field. Ie, I.e., they are not padded to a 4
octet
4-octet boundary.

Thomas, Vilhuber [Page 15]

INTERNET DRAFT KINK December 2003

5.1.2. KINK_AP_REQ Payload

The KINK_AP_REQ payload relays a Kerberos AP-REQ to the respondent. responder.
The AP-REQ MUST request mutual authentication. The service that the

Thomas, Vilhuber [Page 16]
^L
Internet-Draft KINK May 2005

KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is 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
exception to this rule is when User-User User-to-User service is requested in
which case the service name MUST be the service returned in the
GetTGT
GETTGT response payload.

The value field of this payload has the following format:

Figure 9: KINK_AP_REQ Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o EPOCH - the absolute time at which the creator of the AP-REQ has
valid security association information. Typically Typically, this is when
the KINK keying daemon started if it does not retain security associa-
tion
association information across different restarts. The format of
this
fields field is network order encoding of the standard posix four POSIX four-
octet time stamp.

o KRB_AP_REQ - The value field of this payload contains a raw Ker-
beros
Kerberos KRB_AP_REQ.

Thomas, Vilhuber [Page 16]

INTERNET DRAFT KINK December 2003

5.1.3. KINK_AP_REP Payload

The KINK_AP_REP payload relays a kerberos Kerberos AP-REP to the initiator.
The AP-REP MUST be checked for freshness as described in [KERBEROS].

The value field of this payload has the following format:

Thomas, Vilhuber [Page 17]
^L
Internet-Draft KINK May 2005

Figure 10: KINK_AP_REP Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o EPOCH - the absolute time at which the creator of the AP-REP has
valid security association information. Typically Typically, this is when
the KINK keying daemon started if it does not retain security associa-
tion
association information across different restarts. The format of
this
fields field is network order encoding of the standard posix four POSIX four-
octet time stamp.

o KRB_AP_REP - The value field of this payload contains a raw Ker-
beros
Kerberos KRB_AP_REP.

Thomas, Vilhuber [Page 17]

INTERNET DRAFT KINK December 2003

5.1.4. KINK_KRB_ERROR Payload

The KINK_KRB_ERROR payload relays Kerberos type errors back to the
initiator. The receiver MUST be prepared to receive any valid
[KERBEROS] error type, but the sender SHOULD send only the following
errors:

KRB5KRB_AP_ERR_BAD_INTEGRITY
KRB5KRB_AP_ERR_TKT_EXPIRED
KRB5KRB_AP_ERR_SKEW
KRB5KRB_AP_ERR_NOKEY
KRB5KRB_AP_ERR_BADKEYVER

KRB_AP_ERR_BAD_INTEGRITY
KRB_AP_ERR_TKT_EXPIRED
KRB_AP_ERR_SKEW
KRB_AP_ERR_NOKEY
KRB_AP_ERR_BADKEYVER

KINK implementations MUST make use of keyed Kerberos errors a KINK Cksum field when
returning KINK_KRB_ERROR and the appropriate service key is available as specified in [KRBREVS]. In
particular, clock skew errors MUST be integrity protected. For
unauthenticated Kerberos errors, the receiver MAY choose to act on
them, but SHOULD take precautions against make-work kinds of attacks.
available.

Thomas, Vilhuber [Page 18]
^L
Internet-Draft KINK May 2005

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
be prepared to receive them and MAY log them.

The value field of this payload has the following format:

Figure 11: KINK_KRB_ERROR Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o KRB_ERROR KRB-ERROR - The value field of this payload contains a raw
Kerberos KRB_ERROR.

Thomas, Vilhuber [Page 18]

INTERNET DRAFT KINK December 2003 KRB-ERROR.

5.1.5. KINK_TGT_REQ Payload

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

The value field of this payload has the following format:

Figure 12: KINK_TGT_REQ Payload

Thomas, Vilhuber [Page 19]
^L
Internet-Draft KINK May 2005

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o RealmNameLen - The length of the realm name that follows

o RealmName - The realm name that the responder should return a TGT
for. The responder MUST return a ticket for the principal
krbtgt/REALM/@REALM
krbtgt/REALM@REALM to the initiator so that a User-User User-to-User service
ticket can be obtained by the initiator.

If the responder is unable to get a TGT for the domain, it must reply
with a KRB_ERROR KINK_KRB_ERROR payload type.

Thomas, Vilhuber [Page 19]

INTERNET DRAFT KINK December 2003

5.1.6. KINK_TGT_REP Payload

The value field of this payload contains the TGT requested in a
previous KINK_TGT_REP command.

Figure 13: KINK_TGT_REQ KINK_TGT_REP Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o PrincNameLen - The length of the principal name that immediately
follows

Thomas, Vilhuber [Page 20]
^L
Internet-Draft KINK May 2005

o PrincName - The client principal that the initiator should request
a User to User User-to-User service ticket for.

o TGTlength - The length of TGT that immediately follows

o TGT - the DER encoded TGT of the responder

Thomas, Vilhuber [Page 20]

INTERNET DRAFT KINK December 2003

5.1.7. KINK_ISAKMP Payload

The value field of this payload has the following format:

Figure 14: KINK_ISAKMP Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o InnerNextPload - First payload type of the inner series of ISAKMP
payloads.

o QMMaj - The major version of the inner payloads. MUST be set to
1.

o QMMin - The minor version of the inner payloads. MUST be set to
0.

The KINK_ISAKMP payload encapsulates the IKE Quick Mode (phase two)
payloads to take the appropriate action dependent on the KINK
command. There may be any number of KINK_ISAKMP payloads within a
single KINK message. While IKE is somewhat fuzzy about whether
multiple different SA's may be created within a single IKE mes-
sage, message,
KINK explicitly requires that a new ISAKMP header be used for each
discrete SA operation. In other words, a KINK sender MUST NOT send
multiple quick mode transactions within a single KINK_ISAKMP payload.

The purpose of the Quick Mode version is to allow backward compa-
tibility

Thomas, Vilhuber [Page 21]
^L
Internet-Draft KINK May 2005

compatibility 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.

Thomas, Vilhuber [Page 21]

INTERNET DRAFT KINK December 2003

5.1.8. KINK_ENCRYPT Payload

The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
using the encryption algorithm specified by the etype of the session
key. This payload MUST be the final payload in the message. KINK
encrypt payloads MUST be encrypted before the final KINK checksum is
applied.

Figure 15: KINK_ENCRYPT Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section section. The Next Payload field must be KINK_DONE (0).

o InnerNextPload (variable) - First payload type of the inner series
of encrypted KINK payloads.

o RESERVED2 - reserved and must be zero

Note: the coverage of the encrypted data begins at InnerNextPload so
that first payload's type is kept confidential. Thus, the number of
encrypted octets is PayloadLength - 4.

The format of the encryption payload uses the normal [KERBEROS]
semantics of prepending a crypto-specific initialization vector and
padding the entire message out to the crypto-specific number of

Thomas, Vilhuber [Page 22]
^L
Internet-Draft KINK May 2005

bytes. For example, with DES-CBC, the initialization vector will be
8 octets long, and the entire message will be padded to an
8 octet 8-octet
boundary. Note that KINK Encrypt payload MUST NOT include a checksum
since this is redundant with the message integrity checksum in the
KINK header.

Thomas, Vilhuber [Page 22]

INTERNET DRAFT KINK December 2003

5.1.9. KINK_ERROR Payload

The KINK_ERROR payload type provides a protocol level mechanism of
returning an error condition. This payload should not be used for
either Kerberos generated errors, or DOI specific errors which have
their own payloads defined. The error code is in network order.

Figure 16: KINK_ERROR Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined in the beginning
of this section

o ErrorCode - one of the following error values, network orderd: ordered:

ErrorCode Number Purpose
--------- ------ -------------------
KINK_OK 0 - No error detected
KINK_PROTOERR 1 - The message was malformed
KINK_INVDOI 2 - Invalid DOI
KINK_INVMAJ 3 - Invalid Major Version
KINK_INVMIN 4 - Invalid Minor Version
KINK_INTERR 5 - An unrecoverable internal error
KINK_BADQMVERS 6 - Unsupported Quick Mode Version
RESERVED 7 - 8191
Private Use 8192 - 16383

6. KINK Quick Mode Payload Profile

KINK directly uses ISAKMP payloads to negotiate security associa-
tions.
associations. In particular, KINK uses IKE phase II payload types

Thomas, Vilhuber [Page 23]
^L
Internet-Draft KINK May 2005

(aka Quick Mode). In general, there should be very few changes
necessary to an IKE implementation to establish the security
associations, and unless there is a note to the contrary in the memo,
all capabilities and requirements in [IKE] MUST be supported. IKE
Phase I payloads MUST NOT be sent.

Unlike IKE, KINK defines specific commands for creation, deletion,
and status of security associations, mainly to facilitate predictable
SA creation/deletion (see section 4.3 and 4.4). As such, KINK places
certain restrictions on what payloads may be sent with which

Thomas, Vilhuber [Page 23]

INTERNET DRAFT KINK December 2003
commands, and some additional restrictions and semantics of some of
the payloads. Implementors should refer to [IKE] and [ISAKMP] for
the actual format and semantics. If a particular IKE phase II
payload is not mentioned here, it means that there are no differences
in its use.

6.1. General Quick Mode Differences

o The Security Association Payload header for IP is defined in
[IPDOI] section 4.6.1. For this memo, the Domain of Interpreta-
tion
Interpretation MUST be set to 1 (IPSec) (IPsec) and the Situation bitmap
MUST be set to 1 (SIT_IDENTITY_ONLY). All other fields are
omitted (because SIT_IDENTITY_ONLY is set).

o KINK also expands the semantics of IKE in it defines an optmis-
tic
optimistic proposal for CREATE commands to allow SA creation to com-
plete
complete in two messages.

o IKE Quick Mode (phase 2) uses the hash algorithm used in main
mode (phase 1) to generate the keying material. KINK MUST use
the hashing algorithm specified in the session ticket's etype.

o KINK does not use the HASH payload at all.

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
[IPDOI]:

class value type
-------------------------------------------------
SA Life Type 1 B

Thomas, Vilhuber [Page 24]
^L
Internet-Draft KINK May 2005

SA Life Duration 2 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 B

Refer to [IPDOI] for the actual definitions for these attributes.

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.

Thomas, Vilhuber [Page 24]

INTERNET DRAFT KINK December 2003

6.4. Identification Payloads

The Identification payload carries information that is used to iden-
tify
identify the traffic that is to be protected using the keys exchanges
in this memo. KINK restricts the ID types to the following values:

ID Type Value
------- -----
ID_IPV4_ADDR 1
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8

6.5. Nonce Payloads

The Nonce payload contains random data that MUST be used in key
generation by the initiating KINK peer, and MAY be used by the
responding KINK peer. See section 8 for the discussion of its use in
key generation.

Thomas, Vilhuber [Page 25]

INTERNET DRAFT KINK December 2003

6.6. Notify Payloads

Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the

Thomas, Vilhuber [Page 25]
^L
Internet-Draft KINK May 2005

Notify message to synchronize SA communication. The table below
lists the Notification messages and their corresponding values that
are supported in KINK.

NOTIFY MESSAGES - ERROR TYPES

Errors Value
INVALID-PAYLOAD-TYPE 1
SITUATION-NOT-SUPPORTED 3
INVALID-MAJOR-VERSION 5
INVALID-MINOR-VERSION 6
INVALID-EXCHANGE-TYPE 7
INVALID-FLAGS 8
INVALID-MESSAGE-ID 9
INVALID-PROTOCOL-ID 10
INVALID-SPI 11
INVALID-TRANSFORM-ID 12
ATTRIBUTES-NOT-SUPPORTED 13
NO-PROPOSAL-CHOSEN 14
BAD-PROPOSAL-SYNTAX 15
PAYLOAD-MALFORMED 16
INVALID-KEY-INFORMATION 17
INVALID-ID-INFORMATION 18
ADDRESS-NOTIFICATION 26
NOTIFY-SA-LIFETIME 27
UNEQUAL-PAYLOAD-LENGTHS 30
RESERVED (Future Use) 31 - 8191
Private Use 8192 - 16383

NOTIFY MESSAGES - STATUS TYPES

Status Value
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535

6.7. Delete Payloads

KINK directly uses ISAKMP delete payloads with no changes.

6.8. KE Payloads

Thomas, Vilhuber [Page 26]

INTERNET DRAFT
^L
Internet-Draft KINK December 2003 May 2005

IKE requires that perfect forward secrecy be supported through the
use of the KE payload. However, Kerberos in general does not provide
PFS so it is somewhat questionable whether a system which is heavily
relying on Kerberos benefits from PFS. KINK retains the ability to
use PFS, but relaxes the requirement from must implement to SHOULD
implement.

7. IPsec DOI Message Formats

KINK messages are either commands, replies, or acknowledgments. A
command is sent by an initiator to the respondent. responder. A reply is sent by
the respondent responder to the initiator. If the respondent responder desires confir-
mation
confirmation of the reply, it sets the ACKREQ bit in the message
header. The ACKREQ bit MUST NOT be set by the respondent responder except in
the lone case of a CREATE message for which one of the security
associations did not use the optimistic payload. proposal. In that case, the
ACKREQ bit MUST be set. All commands, responses 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, KINK_KRB_ERROR, or a 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 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 SHOULD compute the
difference (in seconds) between the two clocks based upon the client
and server time contained in the KRB-ERROR message. The client
SHOULD store this clock difference and use it to adjust its clock in
subsequent messages.

7.2. ACK Message Considerations

Thomas, Vilhuber [Page 27]
^L
Internet-Draft KINK May 2005

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

Thomas, Vilhuber [Page 27]

INTERNET DRAFT KINK December 2003
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 Message

This message initiates an establishment of new Security
Association(s). The CREATE message must contain an AP-REQ payload
and any DOI specific payloads.

CREATE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
KINK_ISAKMP payload
SA Payload[s]
Proposal Payloads
Transform Payloads
Nonce Payload (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]

Replies are of the following forms:

REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_ISAKMP
SA Payload[s]
Proposal Payload
Transform Payload
[ Nonce
[Nonce Payload (Nr)]
[KE]
[IDci, IDcr]
[Notification Payloads]

Note that there MUST be at least a single proposal payload and a
single transform payload in REPLY messages. Also: unlike IKE, the
Nonce Payload Nr is not required, and its absence means that SAs in
the optimistic mode SA's proposal installed by the initiator are valid. If any
of the first proposals are not chosen by the recipient, it MUST
include the nonce payload as well to indicate that the initiator's
outgoing SA's must be modified.

Thomas, Vilhuber [Page 28]
^L
Internet-Draft KINK May 2005

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, responder, it MUST request an ACK.

Thomas, Vilhuber [Page 28]

INTERNET DRAFT KINK December 2003

If an IPspec IPsec DOI specific error is encountered, the respondent responder must
reply with a Notify payload describing the error:

REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP
[Notification Payloads]

If the respondent responder 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 responder finds a Kerberos or KINK type of error it
which it cannot create a AP-REP for, it MUST reply with a lone
KINK_KRB_ERROR or KINK_ERROR payload:

REPLY KINK Header
[KINK_KRB_ERROR]
[KINK_ERROR]

7.4. DELETE Message

This message indicates that the sending peer has deleted or will
shortly delete Security Association(s) with the other peer.

DELETE KINK Header
KINK_AP_REQ
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
KINK_ISAKMP payload
Delete Payload[s]
[Notification Payloads]

There are three forms of replies for a DELETE. The normal form is:

Thomas, Vilhuber [Page 29]
^L
Internet-Draft KINK May 2005

REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
KINK_ISAKMP payload
Delete Payload[s]
[Notification Payloads]

Thomas, Vilhuber [Page 29]

INTERNET DRAFT KINK December 2003

If an IPsec DOI specific error is encountered, the respondent responder must
reply with a Notify payload describing the error:

REPLY KINK Header
KINK_AP_REP payload
[ KINK_ENCRYPT payload ]
[ KINK_ERROR payload ]
KINK_ISAKMP payload
[Notification Payloads]

If the respondent responder 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 responder finds a KINK or Kerberos type of error error, it MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:

REPLY KINK Header
[KRB_ERROR]
[KINK_KRB_ERROR]
[KINK_ERROR]

7.5. STATUS Message

The STATUS command is used in two ways:

1) As a means to relay an ISAKMP Notification message

2) As a means of probing a peer whether its epoch has changed for
dead peer detection.

Thomas, Vilhuber [Page 30]
^L
Internet-Draft KINK May 2005

STATUS contains the following payloads:
KINK Header
KINK_AP_REQ payload
[ [KINK_ENCRYPT]
[ KINK_ERROR payload ]
KINK_ISAKMP payload
[Notification Payloads] ]

Thomas, Vilhuber [Page 30]

INTERNET DRAFT KINK December 2003

There are two forms of replies for a STATUS. The normal form is:

REPLY KINK Header
KINK_AP_REP
[ [KINK_ENCRYPT]
[KINK_ERROR]
KINK_ISAKMP
[Notification Payloads] ]

If the respondent responder 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 responder finds a KINK or Kerberos type of error it MUST reply
with a lone KINK_KRB_ERROR or KINK_ERROR payload:

REPLY KINK Header
[KRB_ERROR]
[KINK_KRB_ERROR]
[KINK_ERROR]

8. Key Derivation

KINK uses the same key derivation mechanisms that [IKE] uses in sec-
tion
section 5.5, which is:

KEYMAT = prf(SKEYID_d, [g(qm)^xy |] protocol | SPI | Ni_b [| Nr_b])

The following differences apply:

o prf is the same hash algorithm found in pseudo-random function corresponding to the session ticket's
key's etype. They are defined in [KCRYPTO].

o SKEYID_d is the session key in the Kerberos service ticket from
the AP-REQ.

Thomas, Vilhuber [Page 31]
^L
Internet-Draft KINK May 2005

o Both Ni_b and Nr_b is optional

By optional, it is meant that are the equivalent part of the nonce payload as described
in section 3.2 of [IKE]. Nr_b is optional. When the responder's
nonce does not exist, Nr_b is treated as if a zero length
nonce value
was supplied.

Note that g(qm)^xy refers to the keying material generated when KE
payloads are supplied using Diffie Hellman key agreement. This is
explained in section 5.5 of [IKE].

Thomas, Vilhuber [Page 31]

INTERNET DRAFT KINK December 2003

The rest of the key derivation (e.g., how to expand KEYMAT) follows
IKE. How to use derived keying materials is up to each service
(e.g., section 4.6.2 of [IPSEC]).

9. Transport Considerations

KINK uses UDP on port [XXX -- TBA by IANA] to transport its messages.
There is one timer T which SHOULD take into consideration round trip
considerations and MUST implement a truncated exponential backoff back off
mechanism. The state machine is simple: any message which expects a
response MUST retransmit the request using timer T. Since Kerberos
requires that messages be retransmitted with new times for replay
protection, the message MUST be recreated each time including the
checksum of the message. Both commands and replies with the ACKREQ
bit set are kept on retransmit timers. When a KINK initiator
receives a REPLY with the ACKREQ bit set, it MUST retain the ability
to regen-
erate regenerate the ACK message for the transaction for a minimum of
its a full retransmission timeout cycle or until it notices that
packets have arrived on the newly constructed SA, whichever comes
first.

When a KINK peer retransmits a message, it MUST create a new Kerberos
authenticator for the AP-REQ so that the peer can differentiate
between replays and dropped packets. This results in a potential
race condition when a retransmission occurs before an in-flight reply
is received/processed. To counter this race condition, the retransmit-
ting
retransmitting party SHOULD keep a list of valid authenticators which
are out-
standing outstanding for any particular transaction.

10. Security Considerations

KINK cobbles together and reuses many parts of both Kerberos and IKE,
the latter which in turn is cobbled together from many other memos.
As such, KINK inherits many of the weaknesses and considerations of
each of its components. However, KINK uses only IKE Phase II
payloads to create and delete security associations, the security considera-
tions
considerations which pertain to IKE Phase I may be safely ignored.

Thomas, Vilhuber [Page 32]
^L
Internet-Draft KINK May 2005

However, being able to ignore IKE's authentication phase necessarily
means that KINK inherits all of the security considerations of
Kerberos authentication as outlined in [KERBEROS] and [KERB]. For
one, a KDC, like a an AAA server, is a point of attack and all that
implies. Much has been written about various shortcomings and
mitigations of Ker-
beros Kerberos and they should be evaluated for any
deployment.

KINK's use of Kerberos presents a couple of considerations. First,
KINK explicitly expects that the KDC will provide adequate entropy
when it generates session keys. Second, Kerberos is used as a user
authentication protocol with the possibility of dictionary attacks on
user passwords. This memo does not describe a particular method to
avoid these pitfalls, but recommends that suitable randomly generated
keys be used for the service principals such as using the -randomkey
option with MIT's "kadmin addprinc" command as well as for clients
when that is practical.

Kerberos itself does not provide for perfect forward secrecy which
makes KINK's reliance on the IKE ability to do PFS somewhat suspect
from an overall system's standpoint. In isolation KINK itself should

Thomas, Vilhuber [Page 32]

INTERNET DRAFT KINK December 2003
be secure from offline analysis from compromised principal
passphrases if PFS is used, but the existence of other Kerberized
service which do not provide PFS makes this a less than optimal
situation on the whole.

10.1. Security Policy Database Considerations

KINK leaves the population of the IPsec security policy database out
of scope. There are, however, considerations which should be pointed
out. First, even though when and when not to initiate a user to user User-to-User
flow is left to the discretion of the KINK implementation, a Kerberos
client which initially authenticated using a symmetric key SHOULD NOT
use a user-user User-to-User flow if the respondent responder is also in the same realm.
Likewise, a KINK initiator which authenticated in a public key realm
SHOULD use a user-user User-to-User flow if the respondent responder is in the same realm.

At a minimum the security policy database for a KINK implementation
SHOULD contain a logical record of the KDC to contact, principal name
for the respondent, responder, and whether the KINK implementation should use a
direct AP-REQ/AP-REP flow, or a User-User User-to-User flow to CREATE/DELETE
the security association.

That said, there is considerable room for improvement on how a KINK
initiator could auto-discover how a respondent responder in a different realm
initially authenticated. This is left as an implementation detail as
well as the subject of possible future standardization efforts which

Thomas, Vilhuber [Page 33]
^L
Internet-Draft KINK May 2005

are outside of the scope of the KINK working group.

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].

In addition, the ISAKMP payload types currently don't have a IANA
registry, but needs one. KINK defines its payload constants as a
sequential set of integers from KINK_ISAKMP_PAYLOAD_BASE to
KINK_ISAKMP_PAYLOAD_BASE+7.

KINK also requires that IANA create a registry for KINK error types.

12. Forward Compatibility Considerations

KINK can accommodate future versions of Quick Mode through the use of
the version field in the ISAKMP payload as well as new domains of
interpretation. In this memo, the only supported Quick Mode version
is 1.0 which corresponds to [IKE]. Likewise, the only DOI suported supported
is

Thomas, Vilhuber [Page 33]

INTERNET DRAFT KINK December 2003 the IPsec domain of interpretation [IPDOI]. New Quick Mode
versions and DOI's MUST be described in subsequent memos.

KINK implementations MUST reject ISAKMP versions which are greater
than the highest currently supported version with a KINK_BADQMVERS
error type. A KINK implementation which receives a KINK_BADQMVERS
message SHOULD be capable of reverting back to version 1.0.

The following sections describe how different quick-modes and dif-
ferent
different DOI's can be used within the KINK framework.

12.1. New Versions of Quick Mode

The ipsec IPsec working group is defining the next generation IKE protocol
(IKEv2) which uses a slightly different quick mode from the one in
IKE v1. While the format of IKEv2 is not yet finalized, it does
serve as an example.

The only difference between the two is the format of the payloads
that contain the IPsec traffic selectors. Formerly, these were over-
loaded
overloaded into the ID payloads, and now they are carried in slightly
more powerful TS (Traffic Selector) payloads.

Thomas, Vilhuber [Page 34]
^L
Internet-Draft KINK May 2005

Were KINK to replace the IKEv2 'CREATE_CHILD_SA' for the current
scheme, we would replace the contents of the KINK_ISAKMP payload
(which currently contains a simplified version of the IKEv1 Quick-
mode payloads) with the set of new payloads. Since the IKEv2
CREATE_CHILD_SA exchange is still part of the IPsec DOI (see A.2),
only the QMMaj version number in the KINK_ISAKMP header would be
bumped to a new (higher) version number to indicate the new expected
format of the contents of the KINK_ISAKMP payload. No other changes
would be needed.

KINK, therefore, merely acts as a transport mechanism to a Quick-mode
exchange.

12.2. New DOI

The KINK message header contains a field called "Domain of Interpre-
tation
Interpretation (DOI)" to allow other domains of interpretation to use
KINK as a secure transport mechanism for keying.

As one example of a new DOI, the MSEC working group is currently
defining the GDOI (Group Domain of Interpretation), which defines a
few new messages, which look like ISAKMP messages, but are not
defined in ISAKMP.

In order to carry GDOI messages in KINK, the DOI field in the KINK
header would indicate that GDOI is being used, instead of IPSEC-DOI,
and the KINK_ISAKMP payload would contain the payloads defined in the

Thomas, Vilhuber [Page 34]

INTERNET DRAFT KINK December 2003
GDOI draft rather than the payloads used by [IKE] Quick Mode. The
version number in the KINK_ISAKMP header is related to the DOI in the
KINK header, so a maj.min version 1.0 under DOI GDOI is different
from a maj.min version 1.0 under DOI IPSEC-DOI.

13. Related Work

The IPsec working group has defined a number of protocols that pro-
vide
provide the ability to create and maintain cryptographically secure
security associations at layer three (ie, the IP layer). This effort
has produced two distinct protocols:

o a mechanism for encrypting and authenticating IP datagram payloads
which assumes a shared secret between the sender and receiver

o a mechanism for IPsec peers to perform mutual authentication and
exchange keying material

The IPsec working group has defined a peer to peer authentication and

Thomas, Vilhuber [Page 35]
^L
Internet-Draft KINK May 2005

keying mechanism, IKE (RFC 2409). One of the drawbacks of a peer to
peer protocol is that each peer must know and implement a site's
security policy which in practice can be quite complex. In addition,
the peer to peer nature of IKE requires the use of Diffie Hellman
(DH) to establish a shared secret. DH, unfortunately, is computation-
ally
computationally quite expensive and prone to denial of service
attacks. IKE also relies on X.509 certificates to realize scalable
authentication of peers. Digital signatures are also computationally
expensive and cer-
tificate certificate based trust models are difficult to deploy
in practice. While IKE does allow for pre-shared symmetric keys, key
distribution is required between all peers -- an O(n2) problem --
which is prob-
lematic problematic for large deployments.

14. Acknowledgments

Many have contributed to the KINK effort, including our working group
chairs Derek Atkins and Jonathan Trostle. The original inspiration
came from Cablelab's Packetcable effort which defined a simplified
version of Kerberized IPsec, including Sasha Medvinsky, Mike Froh,
and Matt Hur and David McGrew. The inspiration for wholly reusing
IKE Phase II is the result of the Tero Kivinen's draft suggesting
grafting Kerberos authentication onto quick mode.

15. References

15.1. Normative References

[KERBEROS]
J. Kohl, C. Neuman.

[IKE]
D. Harkins, D. Carrel. The Kerberos Network Authentication Service
(V5). Internet Key Exchange (IKE). Request
for Comments 1510. 2409.

[IPDOI]
Piper, D., "The Internet IP Security Domain Of Interpretation for
ISAKMP", RFC 2407, November 1998.

[IPSEC]
S. Kent, R. Atkinson. Security Architecture for the Internet
Protocol. Request for Comments 2401.

[IKE]D. Harkins, D. Carrel. The Internet Key Exchange (IKE).
Request for Comments 2409.

Thomas, Vilhuber [Page 35]

INTERNET DRAFT KINK December 2003

[ISAKMP]
Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.

[IPDOI]
Piper, D., "The Internet IP Security Domain Of Interpretation

Thomas, Vilhuber [Page 36]
^L
Internet-Draft KINK May 2005

[ISAKMP-REG]
http://www.iana.org/assignments/isakmp-registry

[KCRYPTO]
K. Raeburn, "Encryption and Checksum Specifications for ISAKMP", Kerberos
5", RFC 2407, November 1998.

15. 3961, February 2005.

[KERBEROS] J. Kohl, C. Neuman. The Kerberos Network
Authentication Service (V5). Request for Comments
1510.

15.2. Informative References

[RFC2412]
Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
November 1998.

[RFC793]
Postel, J., "Transmission Control Protocol", RFC 793, Sep-01-
1981

[KERB]B.C.

[KERB] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication
Service for Computer Networks, IEEE Communications,
32(9):33-38. Sep-
tember September 1994.

[PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S.Medvinsky,
J. Wray, J. Trostle. Public Key Cryptography for
Initial Authentication in Kerberos. draft-ietf-cat-kerberos-pk-init-11.txt

[PKCROSS]
M.Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, A. Medvinsky,
B. Sommerfeld. Public Key Cryptography for Cross-Realm Authen-
tication in Kerberos. draft-ietf-cat-kerberos-pk-cross-06.txt

16. Mailing List

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
a line in the body of the mail with the word SUBSCRIBE in it.

Thomas, Vilhuber [Page 36]

INTERNET DRAFT KINK December 2003

17. Author's draft-ietf-cat-
kerberos-pk-init-11.txt

[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
Sep-01-1981

Authors' Addresses

Shoichi Sakane
Ken'ichi Kamada
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
E-mail: Shouichi.Sakane@jp.yokogawa.com, Ken-ichi.Kamada@jp.yokogawa.com

Michael Thomas
Jan Vilhuber
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
E-mail: {mat,vilhuber}@cisco.com

18. Acknowledgments

Many have contributed to the mat@cisco.com, vilhuber@cisco.com

Thomas, Vilhuber [Page 37]
^L
Internet-Draft KINK effort, including our working group
chairs Derek Atkins and Jonathan Trostle. The original inspiration
came May 2005

Change History (To be removed from Cablelab's Packetcable effort which defined a simplifed
version RFC)

H.07
1) Modified lots of Kerberized IPsec, including Sasha Medvinsky, Mike Froh,
and Matt Hur editorial things.
2) Added I-D boilerplate concerning Copyright and David McGrew. IPR claim disclosure.

Full Copyright Statement

This document is subject to the result of rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the Tero Kivinen's draft suggesting graft-
ing Kerberos authentication onto quick mode.

19. IPR Notice authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per-
tain
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and standards-
related
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

20. Full Copyright

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it

Thomas, Vilhuber [Page 37]

INTERNET DRAFT KINK December 2003

or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. #.PX

Thomas, Vilhuber [Page 38]
^L
----