WDIFF

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

INTERNET-DRAFT Shoichi Sakane
KINK Working Group Ken'ichi Kamada
Expires: January 9, 2006 Yokogawa Electric Corp.
M.
Michael Thomas
J.
Jan Vilhuber
Cisco Systems
Expires: November 28, 2005 May 27,
July 8, 2005

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

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.

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

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

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. January 9, 2006.

Sakane, Kamada, Thomas, and Vilhuber [Page 1]
^L
Internet-Draft KINK May July 2005

Abstract

This document describes the Kerberized Internet Negotiation of Keys
protocol
(KINK) and the domain of interpretation (DOI). protocol. KINK defines a low-latency, computationally
inexpensive, easily managed, and cryptographically sound protocol to
establish and maintain IPsec security associations (SAs) using the Kerberos
authentication system. KINK reuses the payloads of Quick Mode payloads 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. RFC 2119.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 2]
^L
Internet-Draft KINK May July 2005

Table of Contents

1. Introduction ................................................. 5
2. Terminology .................................................. 5
3. Protocol Overview ............................................ 6
4.
3. Message Flows ................................................ 6
4.1. Standard KINK Message Flow .............................. 6
4.2.
3.1. GETTGT Message Flow ..................................... 7
4.3.
3.2. CREATE Security Association ............................. Message Flow ..................................... 7
4.3.1.
3.2.1. CREATE Key Derivation Considerations ............. 8
4.4. DELETE Security Association ............................. 9
4.4.1.
3.3. DELETE Message Flow ..................................... 10
3.4. STATUS Message Flow ..................................... 11
3.5. Reporting Errors ........................................ 11
3.6. Rekeying Security Associations ................... 10
4.4.2. .......................... 11
3.7. Dead Peer Detection .............................. 11
4.5. STATUS Message Flow ..................................... 12
5.
3.7.1. Coping with Dead User-to-User Peers .............. 14
4. KINK Message Format .......................................... 12
5.1. 14
4.1. KINK Alignment Rules .................................... 17
4.2. KINK Payloads ........................................... 15
5.1.1. KINK Padding Rules ............................... 16
5.1.2. 17
4.2.1. KINK_AP_REQ Payload .............................. 16
5.1.3. 18
4.2.2. KINK_AP_REP Payload .............................. 17
5.1.4. 19
4.2.3. KINK_KRB_ERROR Payload ........................... 18
5.1.5. 20
4.2.4. KINK_TGT_REQ Payload ............................. 19
5.1.6. 21
4.2.5. KINK_TGT_REP Payload ............................. 20
5.1.7. 22
4.2.6. KINK_ISAKMP Payload .............................. 21
5.1.8. 22
4.2.7. KINK_ENCRYPT Payload ............................. 22
5.1.9. 24
4.2.8. KINK_ERROR Payload ............................... 23
6. KINK Quick Mode Payload Profile .............................. 23
6.1. 25
5. Differences from IKE General Quick Mode Differences .......................... 24
6.2. ...................... 26
5.1. Security Association Payloads ........................... 24
6.3. 27
5.2. Proposal and Transform Payloads ......................... 25
6.4. 27
5.3. Identification Payloads ................................. 25
6.5. 27
5.4. Nonce Payloads .......................................... 25
6.6. 27
5.5. Notify Payloads ......................................... 25
6.7. 28
5.6. Delete Payloads ......................................... 26
6.8. 29
5.7. KE Payloads ............................................. 26
7. 29
6. Message Construction and Constraints for IPsec DOI Message Formats .................................... 27
7.1. ........... 29
6.1. REPLY Message Considerations ............................ 27
7.2. ........................................... 29
6.2. ACK Message Considerations .............................. 27
7.3. ............................................. 29
6.3. CREATE Message .......................................... 28
7.4. 30
6.4. DELETE Message .......................................... 29
7.5. 31
6.5. STATUS Message .......................................... 30 32
6.6. GETTGT Message .......................................... 33
7. ISAKMP Key Derivation ........................................ 33
8. Key Usage Numbers for Kerberos Key Derivation ............................................... 31 ................ 34
9. Transport Considerations ..................................... 32 34
10. Implementation Hints ......................................... 35
11. Security Considerations ...................................... 32
10.1. Security Policy Database Considerations ................ 33
11. 35
12. IANA Considerations .......................................... 34
12. 36
13. Forward Compatibility Considerations ......................... 34
12.1. 36
13.1. New Versions of Quick Mode ............................. 34
12.2. New DOI ................................................ 35 37

Sakane, Kamada, Thomas, and Vilhuber [Page 3]
^L
Internet-Draft KINK May July 2005

13.

13.2. New DOI ................................................ 37
14. Related Work ................................................. 35
14. 37
15. Acknowledgments .............................................. 36
15. 38
16. References ................................................... 36
15.1. 38
16.1. Normative References ................................... 36
15.2. 38
16.2. Informative References ................................. 37 39
Authors' Addresses ............................................... 37 39
Change History (To be removed from RFC) .......................... 38 40
Full Copyright Statement ......................................... 38 40
Intellectual Property Statement .................................. 38 40

Sakane, Kamada, Thomas, and Vilhuber [Page 4]
^L
Internet-Draft KINK May July 2005

1. Introduction

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

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

The central key management provided by Kerberos is efficient because
it limits computational cost and limits complexity versus IKE's [IKE]
necessity of using public key cryptography. Initial authentication
to the KDC may be performed using either symmetric keys keys, or
asymmetric keys using PKINIT [PKINIT]; however, subsequent requests
for tickets, tickets as well as authenticated exchanges between the client and server
servers 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 SAs 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 protocol, does have
its own security considerations. You can find them discussed in [KERBEROS]
[KERB] and [KERB].

2. Terminology

Editor's comment: remain it for the order of sections referred from [KERBEROS].

Sakane, Kamada, Thomas, and Vilhuber [Page 5]
^L
Internet-Draft KINK May July 2005

the issue list.

2. Protocol Overview

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

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

KINK directly reuses Quick Mode payloads defined in the section 5.5
of [IKE], with some minor changes and omissions. In most cases, KINK
exchanges are a single command and its response. The exception is
that the CREATE command may have a An optional third message. When
message is required when creating SAs, only if the responder
disagrees with the optimistic proposal, it requests rejects
the third
message, an acknowledgement, to first proposal from the initiator in order or wants to complete a
non-optimistic keying. contribute the
keying materials. KINK also provides rekeying and dead peer
detection.

3. Message Flows

All KINK message flows all follow the same pattern between the two peers:
a command, a response, and an optional acknowledgment in a possible CREATE
flow. A command is a GETTGT, CREATE, DELETE, or STATUS message, a
response is a REPLY message, and an acknowledgment with CREATE's.
The is an ACK message.

KINK uses Kerberos as the authentication mechanism, therefore a KINK
host needs to get a service ticket for each peer before actual key
negotiations. This is basically a pure Kerberos exchange and the
actual KDC traffic here is for illustrative purposes only. In
practice, when a principal obtains various tickets is a subject of
Kerberos and local policy consideration. As an exception, the GETTGT
message flow of KINK (described in the section 3.1) is used when a
User-to-User authentication is required. In these flows, this flow, we assume
that both A and B both have TGT's TGTs from their KDC.

4.1. Standard KINK Message Flow KDCs.

Sakane, Kamada, Thomas, and Vilhuber [Page 6]
^L
Internet-Draft KINK May July 2005

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

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

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

Figure 1:

After a service ticket is obtained, KINK Message Flow

4.2. GETTGT Message Flow

If uses the initiator determines that it will not be CREATE message flow
(section 3.2), DELETE message flow (section 3.3), and STATUS message
flow (section 3.4) to manage SAs. In these flows, we assume that A
has a service ticket for B.

3.1. GETTGT Message Flow

This flow is used to retrieve a TGT from the remote peer in User-to-
User authentication mode.

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

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

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

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

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

Figure 2: 1: GETTGT Message Flow

4.3.

The initiator MAY support the following events as triggers to go to
the User-to-User path. Note that the two errors described below will
not be authenticated, and how to act on them depends on the policy.

o The local policy says that the responder requires a User-to-User
authentication.

o A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from the
responder.

o A KDC_ERR_MUST_USE_USER2USER error is returned from the KDC.

3.2. CREATE Security Association Message Flow

This flow instantiates a security association. creates SAs. The CREATE command takes an "optimistic" approach
approach, where security associations SAs are initially created on the expectation that the
responder will choose the initial proposed payload. The optimistic
proposal is defined as placed in the first transform payload(s) of the first proposal of the first conjugate.
proposal. The initiator MUST check to see if the optimistic proposal

Sakane, Kamada, Thomas, and Vilhuber [Page 7]
^L
Internet-Draft KINK July 2005

was selected by comparing all transforms and attributes which MUST be
identical from those in the initiator's optimistic proposal with the
exceptions of LIFE_KILOBYTES and LIFE_SECONDS. Each of these
attributes MAY be set to a lower value by the responder and still
expect optimistic keying, but MUST NOT be set to a higher value which
MUST generate an a NO-PROPOSAL-CHOSEN error.

CREATE'ing The initiator MUST use the
shorter lifetime.

When a security association on CREATE command contains an existing SPI is an error in
KINK SPI, the responder MUST
reject it and SHOULD reply an ISAKMP notification with INVALID-SPI.

When a KE payload is sent from the initiator but the responder does
not support it, the responder MUST be rejected reject it with an ISAKMP
notification of INVALID-SPI.

Thomas, Vilhuber [Page 7]
^L
Internet-Draft KINK May 2005 INVALID-PAYLOAD-TYPE. When the initiator receives
this error, it MAY retry without a KE payload (as another
transaction) if its policy allows that.

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

A creates initial an optimistic inbound SA (B->A) unless using a KE.

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

B creates an inbound SA to A (A->B). If
B chooses A's optimistic
proposal, it creates the an outbound SA as well (B->A). (B->A) if optimistic and not using a KE.

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

A creates an outbound SA and modifies (A->B).
A replaces an inbound SA (B->A) if it first
proposal wasn't acceptable. non-optimistic.
A creates an inbound SA (B->A) if using a KE.

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

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

Figure 3: 2: CREATE Message Flow

Creating SAs has two modes: 2-way handshake and 3-way handshake. The
initiator usually begins a negotiation expecting a 2-way handshake.
When the optimistic proposal is not chosen by the responder, the
negotiation is switched to a 3-way handshake. When and only when the
initiator uses a KE payload, 3-way handshake is expected from the
beginning.

A 2-way handshake is performed in the following steps:

Sakane, Kamada, Thomas, and Vilhuber [Page 8]
^L
Internet-Draft KINK July 2005

1) The security associations are instantiated as follows: In step one host A creates an inbound security association SA (B->A) in its security
association SA database from B->A using
the optimistic proposal in the ISAKMP SA proposal. It is then
ready to receive any messages from B.
2) A then sends the CREATE message to B.
3) If B agrees to A's optimistic proposal, B instantiates a security association creates an inbound SA
(A->B) and an outbound SA (B->A) in its database from
A->B. database. If B then instantiates does not
choose the security association from B->A. It first proposal or wants to add a nonce payload, switch
to the step 3) of a 3-way handshake described below.
4) B then sends a REPLY to A without a NONCE payload and without
requesting an ACK. If B does not choose
5) Upon receipt of the first proposal, it REPLY, A creates an outbound SA (A->B).

A 3-way handshake is performed in the following steps:
1) The host A sends the CREATE message to B without creating any SA.
2) B chooses one proposal according to its policy.
3) B creates an inbound SA (A->B) and sends the actual choice in the
REPLY. It SHOULD send the optional NONCE payload (as it does not
increase message count and generally increases entropy sources)
and MUST request that the REPLY be acknowledged.
4) Upon receipt of the REPLY, A modifies creates the inbound
security association SA (B->A) (or
modifies it as necessary, instantiates the security
association if switched from A->B, If B requested an ACK, 2-way), and the
outbound SA (A->B).
5) A now sends the ACK message.
6) Upon receipt of the ACK, B installs the final security
association from B->A.

Note: if outbound SA (B->A).

If B adds a nonce, or does not choose the first proposal, adds a nonce, or accepts the
KE exchange, then it MUST request an ACK (i.e. set the ACKREQ bit) so
that it can install the final outbound
security association. SA. The initiator MUST always
generate an ACK if the ACKREQ bit is set in the KINK header, even if
it believes that the responder was in error.

4.3.1.

3.2.1. CREATE Key Derivation Considerations

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

The CREATE command's optimistic approach allows a security
association an SA to be created
in two messages rather than three. The implication of a two-message
exchange is that B will not contribute to the key since A must set up
the inbound security association SA before it receives any additional keying material from
B. Under
normal circumstances this This may be suspect, suspect under normal circumstances, however KINK
takes advantage of the fact that the KDC provides a reliable source
of randomness which is used in key derivation. In many cases, this
will provide an adequate session key so that B will not require an
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, which KINK implementations may decide
as a matter of policy.

4.4.

Sakane, Kamada, Thomas, and Vilhuber [Page 9]
^L
Internet-Draft KINK July 2005

3.3. DELETE Security Association Message Flow

The DELETE command deletes an existing security association. SAs. The DOI specific payloads
describe the actual security association SA 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 B.

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

B deletes inbound and outbound SA to A A.

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

A deletes inbound SA to B B.

Figure 4: 3: DELETE Message Flow

The DELETE command takes a "pessimistic" approach approach, which does not
delete incoming security associations inbound SAs until it receives acknowledgment that the other
host has received the DELETE. The exception to the pessimistic
approach is if the initiator wants to immediately cease all activity
on an incoming inbound SA. In this case, it MAY delete the incoming inbound SA as well
in step one. If the receiver cannot find an appropriate SPI to
delete, it MUST return an ISAKMP INVALID_SPI notification notification, which also
serves to inform the initiator that it can delete the incoming inbound SA.
KINK does not allow half open
security associations; half-open SAs; thus upon receiving a DELETE, the
responder MUST delete its security associations, SAs, 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 the DELETE flow exists. Packets Due to network
reordering, etc, packets in flight while the DELETE operation is
taking place may, due to network reordering, etc, may arrive after the diagrams above above, which recommend
deleting the incoming
security association. inbound SA. A KINK implementation SHOULD implement a
grace timer which SHOULD be set to a period of at least two times the
average round trip time, or to a configurable value. A KINK
implementation MAY choose to set the grace period to zero at
appropriate times to delete a security association an SA ungracefully. The behavior
described here loosely mimics is referred from the behavior of the TCP [RFC793]
flags FIN and RST.

4.4.1. Rekeying Security Associations

Sakane, Kamada, Thomas, and Vilhuber [Page 10]
^L
Internet-Draft KINK requires the initiator of July 2005

3.4. STATUS Message Flow

This flow is used to send any information to a security association peer, or to be
responsible for rekeying elicit any
information from a security association. The reason is
twofold: the first is peer. An initiator may send a STATUS command to prevent needless duplication of security
associations as
the result of collisions due to an initiator and responder both trying to renew an existing security association. The
second reason is due to at any time, optionally with DOI specific ISAKMP
payloads. In the client/server nature case of Kerberos
exchanges which expects the client to get and maintain tickets.
While KINK requires that a KINK host is able to get and maintain
tickets, IPsec DOI, these are generally in practice it the
form of ISAKMP Notification Payloads. A STATUS command is often advantageous for servers to wait for
clients to initiate sessions so that they do not need to maintain also used
as a
large ticket cache.

There are no special semantics for rekeying security associations in
KINK. That is, means of Dead Peer Detection described in order to rekey an existing security association, the initiator must CREATE a new security association followed by
either DELETE'ing section 3.7.

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

1 STATUS[+ISAKMP]---------->

2 <-----------REPLY[+ISAKMP]

Figure 4: STATUS Message Flow

3.5. Reporting Errors

When the old security association or letting responder detects an error in a received command, it time
out. When identical flow selectors can
send a DOI specific payload to indicate the error in a REPLY message.
There are available on different
security associations, three types of payloads which can indicate errors;
KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for
KINK implementations SHOULD choose errors, and KINK_ISAKMP payloads for ISAKMP errors. Details are
described in the
security association most recently created. It should be noted that
KINK avoids most each part of this document.

If the problems of [IKE] rekeying by having a
reliable delete mechanism.

Normally initiator detects an error in a KINK implementation which rekeys existing security
associations will try received replay, there is no
means to report it back to rekey the security association ahead of responder. The initiator SHOULD log
the event and MAY take a
hard SA expiration. We call this time remedial action by reinitiating the rekey time Trekey. In
order to avoid synchronization with similar implementations, KINK
initiators initial
command.

If the server clock and the client clock are off by more than the
policy-determined clock skew limit (usually 5 minutes), the server
MUST randomly pick return a rekeying KRB_AP_ERR_SKEW. The optional client's time between Trekey in the
KRB-ERROR MUST be filled out, and the
SA expiration time minus client SHOULD compute the amount of
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 would take to go
through a full retransmission time cycle, Tretrans. Trekey SHOULD be

Thomas, Vilhuber [Page 10] adjust its clock in
subsequent messages.

3.6. Rekeying Security Associations

KINK requires the initiator of an SA to be responsible for rekeying
an SA. The reason is twofold: the first is to prevent needless
duplication of SAs as the result of collisions due to an initiator

Sakane, Kamada, Thomas, and Vilhuber [Page 11]
^L
Internet-Draft KINK May July 2005

set at least twice as high as Tretrans.

4.4.2. Dead Peer Detection

In order

and responder both trying to determine renew an existing SA. The second reason
is due to the client/server nature of Kerberos exchanges which
expects the client to get and maintain tickets. While KINK requires
that a KINK peer has lost its security database
information, KINK peers MUST record the current epoch host is able to get and maintain tickets, in practice it
is often advantageous for which they
have valid security association information servers to wait for a peer and reflect clients to initiate
sessions so that epoch in each AP-REQ and AP-REP message. When they do not need to maintain a KINK peer
creates state large ticket cache.

There are no special semantics for rekeying SAs in KINK. That is, in
order to rekey an existing SA, the initiator must CREATE a given security association, it MUST also record new SA
followed by either deleting the principal's epoch as well. If old SA with the DELETE flow or
letting it discovers timeout. When identical flow selectors are available on a subsequent
message
different SAs, KINK implementations SHOULD choose the SA most
recently created. It should be noted that KINK avoids most of the principal's epoch has changed, it MUST consider all
security associations created
problems of [IKE] rekeying by that principal as invalid, having a reliable delete mechanism.

Normally a KINK implementation which rekeys existing SAs will try to
rekey the SA ahead of an SA termination, which may include the hard
lifetime in time/bytecount or the overflow of the sequence number
counter. We call this time "soft lifetime". The soft lifetime MUST
be randomized to avoid synchronization with similar implementations.
In the case of the lifetime in time, one reasonable approach to
determine the soft lifetime is that picking a random time between T-
rekey and T-retrans and subtracting it from the hard lifetime. Here,
T-rekey is the reasonable maximum rekeying margin, and T-retrans is
the amount of time it would take to go through a full retransmission
cycle. T-rekey SHOULD be at least twice as high as T-retrans.

3.7. 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 SA 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 SA, 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 SAs created by that principal as
invalid, and take some action such as tearing those SA's SAs 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
information available to the KINK peer, including lack of IPsec
traffic, etc), the KINK STATUS message SHOULD be used to coerce an
acknowledgment out of the peer. Since nothing is negotiated about

Sakane, Kamada, Thomas, and Vilhuber [Page 12]
^L
Internet-Draft KINK July 2005

dead peer detection in KINK, each peer can decide its own metric for
'suspicion'
"suspicion" and also what time-outs to use before declaring a peer
dead due to lack of response to the STATUS message. This is
desirable, and does not break interoperability.

The STATUS message has a two-fold twofold effect: First, it elicits a
cryptographically secured (and replay-protected) response from the
peer, which tells us whether the peer is reachable/alive or not.
Further,
Second, 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 lose all
cryptographic 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). 3.4). 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 the section 4.5.

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

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 fail
over versus number of messages sent by nodes with large numbers of
security associations.
SAs.

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
an 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 SAs 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,

Sakane, Kamada, Thomas, and Vilhuber [Page 13]
^L
Internet-Draft KINK July 2005

3.7.1. Coping with Dead User-to-User Peers

When an initiator uses a sender may send status, normally in the form of DOI
specific payloads to User-to-User ticket and a responder has lost
its peer. In previous TGT, the case of usual DPD mechanism does not work, because the IPsec DOI, these
responder cannot decrypt the ticket with its new TGT. In this case,
the following actions are generally in taken.

o When the form responder receives a KINK command with a User-to-User
ticket which cannot be decrypted with its TGT, it returns a REPLY
with a KINK_TGT_REP payload containing the TGT.

o When the initiator receives a KINK_TGT_REP, it retrieves a new
service ticket with the TGT and retries the command.

This does not directly define a method to detect a dead User-to-User
peer, but to recover from the situation that the responder does not
have an appropriate TGT to decrypt a service ticket sent from the
initiator. After recovery, they can exchange their epochs, and usual
DPD mechanism will detect a dead peer if it really has been dead.

The initiator MUST NOT think the peer has been dead on the receipt of ISAKMP Notification Payloads.

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

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

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

Figure 5: STATUS Message Flow

5.
a KINK_TGT_REP because of two reasons. One is that the message is
not authenticated, and the other is that losing a TGT does not
necessarily mean losing the SA database information. The initiator
SHOULD NOT forget the previous service ticket until the new one is
successfully obtained in order to reduce the cost when a forged
KINK_TGT_REP is received.

4. KINK Message Format

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

Sakane, Kamada, Thomas, and Vilhuber [Page 12] 14]
^L
Internet-Draft KINK May July 2005

Figure 6: 5: Format of a KINK message

Fields:

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

Type Value
----- -----
RESERVED 0
CREATE 1
DELETE 2
REPLY 3
GETTGT 4
ACK 5
STATUS 6
RESERVED TO IANA 7 - 127
Private Use 128 - 255

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

o MnVer RESRVED (4 bits) - Minor protocol version number. This -- Reserved and MUST be set
to 0. zero when sent, MUST be
ignored when received.

o Length (2 octets) - -- Length of the message in octets. Note that it It is legal within not
forbidden in KINK to omit that there are unnecessary data after the last bytes of padding in Cksum
field, but the last
payload in Length field MUST represent the overall length. actual length of
the message.

Sakane, Kamada, Thomas, and Vilhuber [Page 15]
^L
Internet-Draft KINK July 2005

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

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

Defined values are specified by the ISAKMP Domain of Interpretation
section in of the IANA isakmp-registry [ISAKMP-REG]. The IANA Assigned
Number for the Internet IP Security DOI [IPDOI] is one (1). This
field defines the context of all sub-payloads in this message. If
sub-payloads have a DOI field (example: (e.g. 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
initiator and replicated in subsequent messages in the
transaction. A transaction is defined as a command, a reply, and
an optional acknowledgment. Transaction ID's IDs are used by the
initiator to discriminate between multiple outstanding requests to
a responder. It is not used for replay protection because that
functionality is provided by Kerberos. The value of XID is chosen
by the initiator and MUST be unique with all outstanding
transactions. XID's XIDs 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.

o A A, or ACKREQ (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 a responder except
for a REPLY to a CREATE request an ACK and then only when the optimistic proposal is not chosen.

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

o CksumLen (2 octets) -- CksumLen is the length in octets of the
cryptographic checksum of the message. A CksumLen of zero implies
that the message is unauthenticated.

o Cksum (variable) - Keyed -- Kerberos keyed checksum over the entire message.
message excluding the Cksum field itself. When any padding bytes
are required at the end of the last payload, they MUST be included
in the calculation. 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 content of this field is the same as output of the
Kerberos 5 get_mic function [KCRYPTO]. The get_mic function used
is specified in by a checksum type, which is a "required checksum
mechanism" of the etype for the Kerberos session key in the
Kerberos ticket. If the etype does checksum type is not specify a hash keyed algorithm, the message MUST be rejected.

Sakane, Kamada, Thomas, and Vilhuber [Page 14] 16]
^L
Internet-Draft KINK May July 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

To compute the checksum, the checksum message MUST be rejected.

To compute the checksum, the CksumLen field is zeroed out and the
appropriate algorithm
Length field is run over filled with the entire message (as given by total packet length without the
Length
checksum. Then, the packet is passed to the get_mic function and
its output is appended to the packet. Any KINK padding after the
Cksum field is not allowed, except the Kerberos internal one which
may be included in the KINK header), output of the get_mic function. Finally,
the CksumLen field is filled with the checksum length and placed in the Checksum field.
Length field is filled with the total packet length including the
checksum.

To verify the checksum, a length-without-checksum is calculated
from the checksum value of Length field, subtracting the CksumLen. The
Length field is saved, filled with the length-without-checksum value and
the checksum CksumLen field is zeroed out. The Then, the packet without
checksum algorithm is run over (offset from 0 to length-without-checksum minus 1 of the message,
received packet) and the result is compared with checksum (offset from length-without-
checksum to the saved version. last) are passed to the verify_mic function. If they do not match,
verification fails, 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. section 4.2.

4.1. KINK Alignment Rules

KINK has the following rules regarding alignment and padding:

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

o KINK headers, payloads, and the Cksum field MUST be aligned on
4-octet boundaries.

o Variable length fields (except the Cksum field) MUST always start
immediately after the last octet of the previous field. I.e.,
they are not aligned to 4-octet boundaries.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 17]
^L
Internet-Draft KINK July 2005

are all implicitly aligned to 4-octet boundaries, though the payload
length field MUST accurately reflect the actual number of octets in
the payload.

Figure 8: 6: Format of a KINK payload

Fields:

o NextPayload Next Payload (1 octets) - -- The type of the next payload payload.

NextPayload Number

Thomas, Vilhuber [Page 15]
^L
Internet-Draft KINK May 2005 Value
---- ------ -----
KINK_DONE 0 (same as ISAKMP_NEXT_NONE)
KINK_AP_REQ KINK_ISAKMP_PAYLOAD_BASE+0 1
KINK_AP_REP KINK_ISAKMP_PAYLOAD_BASE+1 2
KINK_KRB_ERROR KINK_ISAKMP_PAYLOAD_BASE+2 3
KINK_TGT_REQ KINK_ISAKMP_PAYLOAD_BASE+3 4
KINK_TGT_REP KINK_ISAKMP_PAYLOAD_BASE+4 5
KINK_ISAKMP KINK_ISAKMP_PAYLOAD_BASE+5 6
KINK_ENCRYPT KINK_ISAKMP_PAYLOAD_BASE+6 7
KINK_ERROR KINK_ISAKMP_PAYLOAD_BASE+7

NextPayload 8
RESERVED TO IANA 9 - 127
Private Use 128 - 255

Next Payload type KINK_DONE denotes that the current payload is
the final payload 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) - -- Reserved and MUST be set to zero on send, by a
sender, MUST be ignored by a receiver.

o Payload Length (2 octets) - -- The length of this payload, including
the Type type and Length 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; i.e., they do not account for padding bytes.

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

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

5.1.2. type.

4.2.1. KINK_AP_REQ Payload

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

Sakane, Kamada, Thomas, and Vilhuber [Page 16] 18]
^L
Internet-Draft KINK May July 2005

that the KINK peer service SHOULD request use is "kink/fqdn@REALM" "kink/fqdn@REALM", where "kink"
is for the KINK IPsec service, "fqdn" is the fully qualified domain
name of the service host, and REALM "REALM" is the Kerberos realm of the
service. The
exception to this rule is when User-to-User service A principal name is requested in
which case the service name sensitive, and "fqdn" part MUST be
lower case as described in [KERBEROS]. This document does not
specify how to generate the service returned principal name; whole principal names are
stored in local policy, hostnames are obtained from some name
services, etc; but see the
GETTGT response payload. Security Considerations section.

The value field of this payload has the following format:

Figure 9: 7: KINK_AP_REQ Payload

Fields:

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

o EPOCH - the -- The absolute time at which the creator of the AP-REQ has
valid security association SA information. Typically, this is when the KINK keying
daemon started if it does not retain security
association SA information across
different restarts. The format of value in this field is network order encoding of the standard least
significant four octets of so-called POSIX four-
octet time stamp. time, which is the
elapsed seconds (but without counting leap seconds) from
1970-01-01T00:00:00 UTC. For example, 2038-01-19T03:14:07 UTC is
represented as 0x7fffffff.

o KRB_AP_REQ - AP-REQ -- The value field of this payload contains a raw Kerberos KRB_AP_REQ.

5.1.3.
AP-REQ.

4.2.2. KINK_AP_REP Payload

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

Sakane, Kamada, Thomas, and Vilhuber [Page 19]
^L
Internet-Draft KINK July 2005

The value field of this payload has the following format:

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

Figure 10: 8: KINK_AP_REP Payload

Fields:

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

o EPOCH - the -- The absolute time at which the creator of the AP-REP has
valid security association SA information. Typically, this is when the KINK keying
daemon started if it does not retain security
association SA information across
different restarts. The format of value in this field is network order encoding of the standard least
significant four octets of so-called POSIX four-
octet time stamp. time, which is the
elapsed seconds (but without counting leap seconds) from
1970-01-01T00:00:00 UTC. For example, 2038-01-19T03:14:07 UTC is
represented as 0x7fffffff.

o KRB_AP_REP - AP-REP -- The value field of this payload contains a raw Kerberos KRB_AP_REP.

5.1.4.
AP-REP.

4.2.3. 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]
Kerberos error type, but the sender SHOULD send only the following
errors:

KRB_AP_ERR_BAD_INTEGRITY
KRB_AP_ERR_TKT_EXPIRED
KRB_AP_ERR_SKEW
KRB_AP_ERR_NOKEY
KRB_AP_ERR_BADKEYVER type [KERBEROS].

KINK implementations MUST make use of a KINK Cksum field when
returning KINK_KRB_ERROR and the appropriate service key is
available.

Thomas, Vilhuber [Page 18]
^L
Internet-Draft KINK May 2005 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.

Note that KINK does not make use of the text or e_data field of the

Sakane, Kamada, Thomas, and Vilhuber [Page 20]
^L
Internet-Draft KINK July 2005

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: 9: KINK_KRB_ERROR Payload

Fields:

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

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

5.1.5.

4.2.4. 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 service ticket from the KDC KDC.

The value field of this payload has the following format:

Figure 12: 10: KINK_TGT_REQ Payload

Fields:

Sakane, Kamada, Thomas, and Vilhuber [Page 19] 21]
^L
Internet-Draft KINK May July 2005

Fields:

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

o RealmNameLen - PrincName -- The length name of the realm name principal which the initiator want to
communicate with. It is assumed that follows

o RealmName - The realm the initiator knows the
responder's principal name that (including the realm name) in the same
way as the non-User-to-User case. When the requested principal is
"principal@REALM", the responder should return a TGT
for. The responder MUST return a ticket for the principal
krbtgt/REALM@REALM to the initiator whose server
and client principals are "krbtgt/REALM@REALM" and
"principal@REALM" respectively, so that the initiator can obtain a
User-to-User service ticket can be obtained by at the initiator. KDC of the responder's realm.

If the responder is not the requested principal and is unable to get
a TGT for the domain, name, it must reply
with MAY return a KINK_KRB_ERROR payload type.

5.1.6. KINK_TGT_REP Payload KRB_AP_ERR_NOT_US. If the
administrative policy prohibits returning a TGT, it MAY return a
KINK_U2UDENIED.

4.2.5. KINK_TGT_REP Payload

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

Figure 13: 11: KINK_TGT_REP Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined -- 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 service ticket for.

o TGTlength - The length of TGT that immediately follows section.

o TGT - the -- The DER encoded TGT of the responder

5.1.7. responder.

4.2.6. KINK_ISAKMP Payload

The value field of this payload has the following format:

Sakane, Kamada, Thomas, and Vilhuber [Page 22]
^L
Internet-Draft KINK July 2005

Figure 14: 12: KINK_ISAKMP Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined -- Defined in the beginning
of this section 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 [IKE] is somewhat fuzzy about whether
multiple different SA's SAs may be created within a single IKE 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

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.

5.1.8.

Sakane, Kamada, Thomas, and Vilhuber [Page 23]
^L
Internet-Draft KINK July 2005

4.2.7. 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: 13: KINK_ENCRYPT Payload

Fields:

o Next Payload, RESERVED, Payload Length - defined -- Defined in the beginning
of this section. The This payload is the last one in a message, and
accordingly, 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 -- Reserved and must MUST be zero

Note: the when sent, MUST be ignored
when received.

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

The format of the encryption payload uses follows the normal [KERBEROS]
semantics of prepending a crypto-specific initialization vector and
padding Kerberos
semantics. Its content is the entire message out to output of an encrypt function defined
in the crypto-specific number Encryption Algorithm Profile section of

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

bytes. For example, [KCRYPTO]. Parameters
such as encrypt function itself, specific-key, and initial state are
defined with DES-CBC, the initialization vector will be
8 octets long, etype. The encrypt function may have padding in
itself and the entire message will there may be padded to an 8-octet
boundary. Note that some garbage data at the end of the decrypted
plaintext. A KINK Encrypt payload implementation MUST NOT include a checksum
since this is be prepared to ignore such
padding after the last sub-payload inside the KINK_ENCRYPT payload.
Note that each encrypt function has its own integrity protection
mechanism. It is redundant with the message integrity checksum in the KINK header.

5.1.9. header, but
this is unavoidable because it is not always possible to remove the
integrity protection part from the encrypt function.

Sakane, Kamada, Thomas, and Vilhuber [Page 24]
^L
Internet-Draft KINK July 2005

4.2.8. 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: 14: KINK_ERROR Payload

Fields:

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

o ErrorCode - one -- One of the following error values, values in the network ordered: byte
order:

ErrorCode Number Value 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
RESERVED 4 Invalid Minor Version
KINK_INTERR 5 An unrecoverable internal error
KINK_BADQMVERS 6 Unsupported Quick Mode Version
RESERVED
KINK_U2UDENIED 7 Returning a TGT is prohibited
RESERVED TO IANA 8 - 8191
Private Use 8192 - 16383

6.
RESERVED 16384 -

The responder MUST NOT return KINK_OK. When received, the
initiator MAY act as if the specific KINK_ERROR payload were not
present. If the initiator supports multiple Quick Mode versions
or DOIs, KINK_BADQMVERS or KINK_INVDOI is received, and the Cksum
is verified, then it MAY retry with another version or DOI. A
responder SHOULD return a KINK error with KINK_INVMAJ, when it
receives an unsupported KINK version number in the header. When
KINK_U2UDENIED is received, the initiator MAY retry with the non-
User-to-User mode (if not yet been tried).

Sakane, Kamada, Thomas, and Vilhuber [Page 25]
^L
Internet-Draft KINK July 2005

In general, the responder MAY choose to return these errors in
reply to unauthenticated commands, but SHOULD take care to avoid
being involved in denial of service attacks. Similarly, the
initiator MAY choose to act on unauthenticated errors, but SHOULD
take care to avoid denial of service attacks.

5. Differences from IKE General Quick Mode Payload Profile

KINK directly uses ISAKMP payloads to negotiate security
associations. SAs. 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, SAs, 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, SAs, mainly to facilitate predictable SA
creation/deletion (see section 4.3 3.2 and 4.4). 3.3). As such, KINK places
certain restrictions on what payloads may be sent with which
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] the
section 4.6.1. 4.6.1 of [IPDOI]. For this memo, the Domain of
Interpretation MUST be set to 1 (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
optimistic proposal for CREATE commands to allow SA creation to
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. For this
purpose, KINK MUST use a pseudo-random function determined by the hashing algorithm specified in
etype of the session ticket's etype. key.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 26]
^L
Internet-Draft KINK July 2005

5.1. Security Association Payloads

KINK supports the following security association SA 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.

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

5.3. Identification Payloads

The Identification payload carries information that is used to
identify the traffic that is to be protected using by the keys exchanges
in this memo. SA that will be
established. 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.

5.4. Nonce Payloads

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

6.6.

Sakane, Kamada, Thomas, and Vilhuber [Page 27]
^L
Internet-Draft KINK July 2005

5.5. Notify Payloads

Notification

Notify payloads are used to transmit several informational data, such
as error conditions and state transitions to a peer. For example,
notification information transmit 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,

Types in the range 0 - 16383 are intended for reporting errors
[ISAKMP]. An implementation receiving a secure front end or security gateway may use type in this range that it
does not recognize in a response MUST assume that the

Thomas, Vilhuber [Page 25]
^L
Internet-Draft KINK May 2005 corresponding
request has failed entirely. Unrecognized error types in a request
and status types in a request or response MUST be ignored, and they
SHOULD be logged. Notify payloads with status types MAY be added to
any message and MUST be ignored if not recognized. They are intended
to synchronize indicate capabilities, and as part of SA communication. negotiation are used to
negotiate non-cryptographic parameters.

The table below lists the Notification messages and their
corresponding values that
are supported values. This document also does for [IKEv2] to have
explained the usage of the messages clearly. PAYLOAD-MALFORMED
denotes some error types defined by [ISAKMP]. Hence INVALID-
PROTOCOL-ID for example is not used in KINK. this document. KINK_BADQMVERS
is used to tell that the responder can not handle the version of IKE
instead of INVALID-MAJOR-VERSION or INVALID-MINOR-VERSION.

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

Sent if the ISAKMP payload type is not recognized. It is also
sent when the KE Payload is not supported by the responder.
Notification Data MUST contains the one octet payload type.

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.

Sent if the responder has an SPI indicated by the initiator in
case of CREATE flow, or if the responder does not have an SPI
indicated by the initiator in case of DELETE flow.

NO-PROPOSAL-CHOSEN 14

Sent if none of the proposals in the SA payload was
acceptable.

PAYLOAD-MALFORMED 16

Sakane, Kamada, Thomas, and Vilhuber [Page 28]
^L
Internet-Draft KINK July 2005

Sent if the KINK_ISAKMP message received was invalid because
some type, length, or value was out of range. It is also sent
when the request was rejected for reason that was not matched
with other erroe types. To avoid leaking information to
someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types. To
aid debugging, more detailed error information SHOULD be
written to a console or log.

5.6. Delete Payloads

KINK directly uses ISAKMP delete payloads with no changes.

6.8.

5.7. KE Payloads

Thomas, Vilhuber [Page 26]
^L
Internet-Draft KINK 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. The
reasons are described in the Security Considerations section.

6. Message Construction and Constraints for IPsec DOI Message Formats

KINK messages are either

All commands, replies, or acknowledgments. A
command is sent by an initiator to the responder. A reply is sent responses, and acknowledgments are bound together by
the responder to the initiator. If the responder desires
confirmation XID field of the reply, it sets the ACKREQ bit in the message header. The ACKREQ bit MUST NOT be set by the responder except in
the lone case of a CREATE message for which one of the security
associations did not use the optimistic proposal. 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 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 the Kerberos mechanisms. In addition, commands and
responses MUST use a cryptographic hash checksum over the entire message
if the two peers share a symmetric key via a ticket exchange.

7.1.

6.1. REPLY Message Considerations

The REPLY message is a generic reply which MUST contain either a
KINK_AP_REP, a KINK_KRB_ERROR, or a KINK_ERROR payload. REPLY's REPLY
messages 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 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 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.

6.2. ACK Message Considerations

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

ACK's

ACKs are sent only when the ACKREQ bit is set in a REPLY message.
ACK's An
ACK message MUST NOT contain any payloads beside a lone AP-REQ header. If
the initiator detects an error in the AP-REP or any AP-REQ payload and no other payload.

Sakane, Kamada, Thomas, and Vilhuber [Page 29]
^L
Internet-Draft 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. July 2005

6.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 payloads
SA Payload[s] Payload
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 payloads
SA Payload[s]
Proposal Payload
Proposal Payloads
Transform Payload
[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. There will be multiple
proposal payloads only when an SA bundle is negotiated. Also: unlike
IKE, the Nonce Payload Nr is not required, and its absence means if it exists, an
acknowledgment must be requested to indicate that SAs in
the optimistic proposal installed by the initiator are valid. If initiator's
outgoing SAs must be modified. If any of the first proposals are not
chosen by the recipient, it MUST SHOULD 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 payload.

KINK, like IKE IKE, allows the creation of many security associations SAs in one create
command. If any of the optimistic proposals is not chosen by the
responder, it MUST request an ACK.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 30]
^L
Internet-Draft KINK July 2005

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

If the 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 responder finds a Kerberos or KINK type of error
which it cannot create a an 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.

6.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 payloads
Delete Payload[s] Payloads
[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_ERROR]
KINK_ISAKMP payload payloads
Delete Payload[s] Payloads
[Notification Payloads]

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

Sakane, Kamada, Thomas, and Vilhuber [Page 31]
^L
Internet-Draft KINK July 2005

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

If the 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 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
[KINK_KRB_ERROR]
[KINK_ERROR]

7.5.

6.5. STATUS Message

The STATUS command is used in two ways:

1) As a means to relay an ISAKMP Notification message 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_ENCRYPT]
KINK_ISAKMP payload
[Notification Payloads] ] Payloads]]

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

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

If the 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 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
[KINK_KRB_ERROR]
[KINK_ERROR]

8. Key Derivation

KINK uses the same key derivation mechanisms that [IKE] uses in
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 pseudo-random function corresponding to the session
key's etype. They are defined in [KCRYPTO].

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

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

o Both Ni_b and Nr_b are the 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 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].

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 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 32]
^L
Internet-Draft KINK July 2005

If the ACKREQ bit set, responder finds a Kerberos error for which it MUST retain can produce a
valid authenticator, the ability
to regenerate REPLY takes the ACK message for following form:

REPLY KINK Header
KINK_AP_REP
[KINK_ENCRYPT]
KINK_KRB_ERROR

If the transaction for a minimum of
its responder finds a full retransmission timeout cycle KINK or until Kerberos type of error, it notices that
packets have arrived on the newly constructed SA, whichever comes
first.

When MUST
reply with a lone KINK_KRB_ERROR or KINK_ERROR payload:

REPLY KINK peer retransmits a message, it MUST create Header
[KINK_KRB_ERROR]
[KINK_ERROR]

6.6. GETTGT Message

A GETTGT command is only used to carry a new Kerberos
authenticator TGT and is not
related to SA management, therefore it contains only KINK_TGT_REQ
payload and does not contain any DOI specific payload.

There are two forms of replies for a GETTGT. In the AP-REQ so that normal form,
where 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 responder is received/processed. To counter this race condition, allowed to return its TGT, the
retransmitting party SHOULD keep REPLY contains
KINK_TGT_REP payload. If the responder is not allowed to return its
TGT, it MUST reply with a list of valid authenticators which
are outstanding for any particular transaction.

10. Security Considerations KINK_ERROR payload.

7. ISAKMP Key Derivation

KINK cobbles together and reuses many parts uses the same key derivation mechanisms defined in the section
5.5 of both Kerberos and IKE, [IKE], which is:

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

The following differences apply:

o prf is the pseudo-random function corresponding to the latter which session
key's etype. They are defined in turn [KCRYPTO].

o SKEYID_d is cobbled together the session key in the Kerberos service ticket from many other memos.
As such, KINK inherits many of
the weaknesses AP-REQ. Note that subkeys are not used in KINK and considerations of
each MUST be
ignored if received.

o Both Ni_b and Nr_b are the part of its components. However, KINK uses only IKE Phase II the nonce payloads to create (Ni and delete security associations, Nr
respectively) as described in the security
considerations section 3.2 of [IKE]. Nr_b is
optional, which pertain to IKE Phase I may be safely ignored. means that Nr_b is treated as if a zero length
value was supplied when the responder's nonce (Nr) does not exist.

Sakane, Kamada, Thomas, and Vilhuber [Page 32] 33]
^L
Internet-Draft KINK May July 2005

However, being able to ignore IKE's authentication phase necessarily
means

When Nr exists, Nr_b MUST be included in the calculation.

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

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

8. Key Usage Numbers for Kerberos Key Derivation

Kerberos encrypt/decrypt functions and get_mic/verify_mic functions
require "key usage numbers". They are used to generate specific keys
for cryptographic operations so that different keys are used for
different purposes/objects. KINK uses two usage numbers listed
below.

Purpose Usage number
------- ------------
KINK_ENCRYPT (for encryption) XXX -- TBA by rfc1510ter
Cksum (for checksum) XXX -- TBA by rfc1510ter

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 of
Kerberos authentication as outlined in [KERBEROS] and [KERB]. For
one, MUST implement a KDC, like an AAA server, truncated exponential back off
mechanism. The state machine is simple: any message which expects a point of attack and all that
implies. Much has been written about various shortcomings and
mitigations of
response MUST retransmit the request using timer T. Since Kerberos and they should
requires that messages be evaluated retransmitted with new times for any
deployment.

KINK's use of Kerberos presents a couple replay
protection, the message MUST be recreated each time including the
checksum 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 message. Both commands and replies with the possibility of dictionary attacks ACKREQ
bit set are kept on
user passwords. This memo does not describe retransmit timers. When a particular method KINK initiator
receives a REPLY with the ACKREQ bit set, it MUST retain the ability
to
avoid these pitfalls, but recommends that suitable randomly generated
keys be used for regenerate the service principals such as using ACK message for the -randomkey
option with MIT's "kadmin addprinc" command as well as transaction for clients
when a minimum of
its full retransmission timeout cycle or until it notices that is practical.
packets have arrived on the newly constructed SA, whichever comes
first.

When a KINK peer retransmits a message, it MUST create a new Kerberos itself does not provide
authenticator for perfect forward secrecy which
makes KINK's reliance on the IKE ability to do PFS somewhat suspect
from 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 overall system's standpoint. In isolation KINK itself should
be secure from offline analysis from compromised principal
passphrases if PFS in-flight reply
is used, but received/processed. To counter this race condition, the existence
retransmitting party SHOULD keep a list of other Kerberized
service valid authenticators which do not provide PFS makes this a less than optimal
situation on the whole.

10.1. Security Policy Database Considerations

Sakane, Kamada, Thomas, and Vilhuber [Page 34]
^L
Internet-Draft KINK July 2005

are outstanding for any particular transaction.

10. Implementation Hints

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

At a minimum

11. Security Considerations

The principal names are the security policy database identities of the KINK services, but the
traffic which is protected by SAs are identified by DOI specific
selectors (IP addresses, port numbers, etc). Thus an implementation
must take care for the relationship between principal names and the
selectors os SAs.

Sending errors without cryptographic protection must be handled very
carefully. There is a trade-off between wanting to be helpful in
diagnosing a problem and wanting to avoid being a dupe in a denial of
service attack.

KINK implementation
SHOULD contain 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 SAs, the security considerations which
pertain to IKE Phase I may be safely ignored. 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]. For one, a KDC, like an
AAA server, is a logical record point of the KDC to contact, principal name
for the responder, attack and whether the KINK implementation all that implies. Much has been
written about various shortcomings and mitigations of Kerberos and
they should use a
direct AP-REQ/AP-REP flow, or a User-to-User flow to CREATE/DELETE
the security association.

That said, there is considerable room be evaluated for improvement on how any deployment.

The KINK's use of Kerberos presents a couple of considerations.
First, KINK
initiator could auto-discover how a responder in a different realm
initially authenticated. This explicitly expects that the KDC will provide adequate
entropy when it generates session keys. Second, Kerberos is left as an implementation detail as
well used as
a user authentication protocol with the subject possibility of possible future standardization efforts which dictionary
attacks on user passwords. This memo does not describe a particular
method to avoid these pitfalls, but recommends that suitable randomly
generated keys should be used for the service principals such as

Sakane, Kamada, Thomas, and Vilhuber [Page 33] 35]
^L
Internet-Draft KINK May July 2005

are outside of the scope of

using the KINK working group.

11. IANA Considerations

KINK requires that a new -randomkey option with MIT's "kadmin addprinc" command as
well known system port as for UDP be created.
Since KINK uses standard message types from [IKE], KINK clients when that is practical.

Kerberos does not
require any new registries. Any new DOI's, ISAKMP types, etc for
future versions of currently provide perfect forward secrecy in
general. KINK MUST use with the registries defined KE payload can provide PFS for [IKE].

In addition, a service key
from a Kerberos key, but the KE is not mandatory because of the
computational cost. This is a trade-off and operators can choose the
PFS over the cost, and vice versa. KINK itself should be secure from
offline analysis from compromised principal passphrases if PFS is
used, but from an overall system's standpoint, the ISAKMP payload types currently don't have existence of other
Kerberized services which do not provide PFS makes this a less than
optimal situation.

12. IANA Considerations

This document requests 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 assign a well known port number.

This document also requires that requests IANA to create a new registry for KINK,
and register the following identifiers.

KINK error types.

12. Message Types (section 4)
KINK Next Payload Types (section 4.2)
KINK Error Codes (section 4.2.8)

Changes and additions to this registry follows the policies described
below. Their meanings are described in [BCP26].

o Using the numbers in the "Private Use" range is Private Use.

o Assignment from the "RESERVED TO IANA" range needs Standards
Action, or non standards-track RFCs with Expert Review. (Though
the full specification may be a public and permanent document of a
standards body other than IETF, an RFC referring it is needed.)

o Other changes requires Standards Action.

13. 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 supported
is the IPsec domain of interpretation [IPDOI]. New Quick Mode
versions and DOI's DOIs MUST be described in subsequent memos.

KINK implementations MUST reject ISAKMP versions which are greater

Sakane, Kamada, Thomas, and Vilhuber [Page 36]
^L
Internet-Draft KINK July 2005

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
different DOI's can be used within the KINK framework.

12.1.

13.1. New Versions of Quick Mode

The IPsec working group is defining the next generation IKE protocol
(IKEv2)
[IKEv2] which uses a slightly different quick mode from the one in
IKE v1. While the format of IKEv2 is does not yet finalized, use Quick Mode, but 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
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 similar 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 one
in IKEv1. The difference between the new expected
format of two is summarized in the contents
Appendix A in [IKEv2]. Each of the KINK_ISAKMP payload. No other changes
would them must be needed.

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

12.2.
use IKEv2 with KINK.

13.2. New DOI

The KINK message header contains a field called "Domain of
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 defined the GDOI (Group Group
Domain of Interpretation), Interpretation [GDOI], 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
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.

14. Related Work

The IPsec working group has defined a number of protocols that
provide the ability to create and maintain cryptographically secure
security associations
SAs at layer three (ie, (i.e. 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

Sakane, Kamada, Thomas, and Vilhuber [Page 37]
^L
Internet-Draft KINK July 2005

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
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 certificate based trust models are difficult to deploy
in practice. While IKE does allow for a pre-shared symmetric keys, key, key
distribution is required between all peers -- an O(n2) problem --
which is problematic for large deployments.

14.

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

16. References

15.1.

16.1. Normative References

[BCP26] T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

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

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

[IPSEC] S. Kent, R. Atkinson. Security Atkinson, "Security Architecture for the
Internet
Protocol. Request Protocol", RFC 2401, November 1998.

[IPSECBIS] S. Kent, R. Atkinson, "Security Architecture for Comments 2401. the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt,
March 2005.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 36] 38]
^L
Internet-Draft KINK May July 2005

Protocol (ISAKMP)", RFC 2408, November 1998.

[ISAKMP-REG]
http://www.iana.org/assignments/isakmp-registry IANA, "Internet Security Association and Key Management
Protocol (ISAKMP) Identifiers",
<http://www.iana.org/assignments/isakmp-registry>.

[KCRYPTO] K. Raeburn, "Encryption and Checksum Specifications for
Kerberos 5", RFC 3961, February 2005.

[KERBEROS] J. Kohl, C. Neuman. The Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos
Network Authentication Service (V5). Request (V5)", draft-ietf-krb-
wg-kerberos-clarifications-07.txt, Work in Progress,
September 2004.

[REQ4KINK] M. Thomas, "Requirements for Comments
1510.

15.2. Kerberized Internet
Negotiation of Keys", RFC 3129, June 2001.

16.2. Informative References

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

[GDOI] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group
Domain of Interpretation", RFC 3547, July 2003.

[IKEv2] C. Kaufman, Ed, "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17.txt.

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

[RFC793] J. Postel, J., "Transmission Control Protocol", RFC 793,
Sep-01-1981
September 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

Sakane, Kamada, Thomas, and Vilhuber [Page 39]
^L
Internet-Draft KINK July 2005

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

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

Change History (To be removed from RFC)

H.08
1) improved the notify payloads section.
2) simplified the IANA consideration.
3) removed the KINK minor version.
4) improved the message flow section

H.07
1) Modified lots of editorial things.
2) Added I-D boilerplate concerning Copyright and IPR claim
disclosure.

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the 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
Intellectual Property Rights or other rights that might be claimed to
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 nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be

Sakane, Kamada, Thomas, and Vilhuber [Page 40]
^L
Internet-Draft KINK July 2005

found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF Secretariat. on-line IPR repository at
http://www.ietf.org/ipr.

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

Sakane, Kamada, Thomas, and Vilhuber [Page 38] 41]
^L
----