WDIFF

draft-ietf-kink-kink-00.txt --> draft-ietf-kink-kink-01.txt

Editor
M. Froh
Cybersafe
M. Hur
Cybersafe
D. McGrew
Cisco
S. Medvinsky
Motorola
M. Thomas
Cisco
J. Vilhuber
Cisco
September 2000
S Medvinsky
Motorola
July 19, 2001

Kerberized Internet Negotiation of Keys (KINK)
draft-ietf-kink-kink-00.txt
draft-ietf-kink-kink-01.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

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

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.

Action Items:

Need to come to agreement on whether ACK is a MUST when respondent
changes cipher suite, keys, etc.

Need to determine whether a "stateful" mode is useful.

Better discussion of error scenarios

Abstract

The KINK Working Group will create a standards track protocol to

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 1]

INTERNET DRAFT KINK September 2000
facilitate centralized key exchange in an application independent
fashion. Participating systems will use the Kerberos architecture as
defined in RFC 1510 for key management and the KINK protocol between
applications. The goal of KINK is to produce a low-latency,
computationally inexpensive, easily managed, and cryptographically
sound protocol that is flexible enough to be able to be extended for
many applications.

The initial focus of the protocol will be keying IPsec security
associations as defined in RFC 2401. Future version of the KINK
protocol may define new objects and Domains of Interpretation to

Thomas et. al. [Page 1]

INTERNET DRAFT KINK July 2001

extend KINK to be suitable for keying other kinds of applications.

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.

1 Introduction

Action Items:

o Which Diffie Hellman group for PFS?

o Word the KINK_ENCRYPT IV use description better

o Better discussion of error scenarios; more specific error codes?

o Should we register the KINK is designed payloads with IANA as ISAKMP types?
This would avoid potential name space collisions.

o Still need to provide talk about when to use U-U vs. normal mode (aka
Discovery).

o Need a secure, scalable mechanism port from IANA

Changes from -00

o Numerous editorial changes

o Change CREATE SA to reflect ACK reliability guidelines. Mention
grace timer for
establishing keys between communicating entities within a centrally
managed environment ACK.

o Make final ACK optional in which DELETE flow. This seems like it is important was a
mistake. Clarify the grace timer.

o Add STATUS verb to maintain consistent
security policy. The security goals reflect the ability of Quick mode to send
mid-SA notifications.

o Reorganize the KINK are header to provide privacy,
authentication, and replay protection of key management messages, not have a short paylaod and
to avoid denial
reserve all of service vulnerabilities whenever possible. The
performance goals the flags.

o Clarify the method of applying the protocol are to incur a low computational
cost, keyed hash over the message.
Also remove redundant checksum type in checksum field (it's
defined to have be the etype of the ticket).

o Clarify the padding rules.

o Clarify in GETTGT/TGTREP that you supply a low latency, realm to have a small footprint, GETTGT and to avoid
or minimize
TGTREP returns the use principal name of public key operations. In particular, to do the
protocol should provide UU with.

o List all of the capability to establish SAs in two
messages with minimal computational effort. appropriate Kerberos Errors that can be

Thomas et. al. [Page 2]

INTERNET DRAFT KINK July 2001

returned. Mention which ones must be handled.

o Add IKE major/minor version in ISAKMP payload header.

o Clarify how to produce the KINK encrypt header.

o Add an INTERNAL ERROR error code.

o Modify the various headers/payloads of section 6 and 8 to more
accurately reflect that we are using IKE Quick Mode directly;
remove text describing ISAKMP headers, refer to 240x.

o Add section for PFS support.

o Change key derivation section to reflect the use of quick mode
method.

o Reflect ACK handling in Transport Considerations

o Add Security Considerations.

1. Introduction

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

Kerberos [KERB] and [RFC1510] provides an efficient mechanism for
trusted third party authentication for clients and servers. (Kerberos
also provides an efficient mechanism for inter-realm authentication
[PKCROSS].) Clients obtain tickets (a ticket is a symmetric key
certificate) cer-
tificate) from an online authentication server (the Key Distribution
Center or KDC). Tickets are used to construct credentials for authenticating authen-
ticating the client to the server. As a result of this authentication, authentica-
tion, the client and the server share a secret (a key, generated by
the KDC, that is encrypted within the ticket).

The central key management provided by Kerberos is efficient, because
it limits computational cost and limits complexity. Initial
authentication authenti-
cation to the KDC may be performed using either symmetric or
asymmetric asym-
metric keys [PKINIT]; however, subsequent requests for tickets
utilize util-
ize symmetric cryptography, which is much more efficient than public
key cryptography. Therefore, public key operations are limited and
are amortized over the lifetime of the Kerberos tickets. For example, exam-
ple, a server may use a single public key exchange with the KDC to

Thomas et. al. [Page 3]

INTERNET DRAFT KINK July 2001

efficiently establish multiple security associations with other
servers. Since Kerberos principal keys (used for initial asymmetric
authentication) are stored in the KDC, the number of

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 2]

INTERNET DRAFT KINK September 2000 principal keys
is order of magnitude O(n) rather than O(n^2), as would be required
for a pre-shared key type of solution.

This document specifies the Kerberized Internet Negotiation of Keys
Protocol and its use to establish and maintain IPsec Security
Associations Associ-
ations [RFC2401]. KINK could be used to maintain Security
Associations Associa-
tions defined in other Domains of Interpretation, though such use is
outside of the scope of this document. It should be noted that KINK
is a complement to and not a replacement for the Internet Key
Exchange [IKE], as KINK requires the use of an online authentication
server and cannot provide identity protection nor perfect forward
secrecy (as described in [RFC2412]). There are many situations in
which centralized key management is desirable.

While Kerberos specifies a standard protocol between the client and
the KDC to get tickets, the actual ticket exchange between client and
server is application specific. KINK is intended to be an
alternative alterna-
tive to requiring each application having its own method of
transporting tran-
sporting and validating service tickets using a protocol which is
efficient and tailored to the specific needs of Kerberos and the
applications for which it provides keying and parameter negotiation.

KINK defines the "on the wire" protocol for establishing keys based
on Kerberos authentication. This is a general protocol that may be
used to securely establish keys for any purpose. This protocol is
ideally suited for environment in which efficiency, scalability, and
central management are important. This document defines the KINK
protocol pro-
tocol and also defines a domain of interpretation to establish and
maintain IPsec security associations. Any other domains of
interpretation interpre-
tation must be defined separately. The protocol takes full advantage
of the features of RFC 2401 but in the context of a centralized keying key-
ing authority.

2. Terminology

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

Key Distribution Center (KDC)

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

Thomas et. al. [Page 4]

INTERNET DRAFT KINK July 2001

is referred to as the Authentication Server (or service). The
Ticket-Granting Ticket portion is referred to as the Ticket-
Granting Server (or service).

Realm
A Kerberos administrative domain. A single KDC may be responsible

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 3]

INTERNET DRAFT KINK September 2000
for one or more realms. A fully qualified principal name includes
a realm name along with a principal name unique within that realm.

3. Protocol Overview

This document specifies a protocol (KINK) that allows two peers to
directly establish symmetric keys, where one peer has already
obtained an authentication credential for the other peer from a
trusted third party known as the Kerberos KDC (Key Distribution
Center). An authentication credential for a server obtained from the
KDC is known as the Kerberos service ticket.

The use of Kerberos tickets minimizes the amount of state that is
required for this key management protocol. It is possible for only
one of the peers to save Kerberos tickets, while the other peer can
remain completely stateless. KINK uses this property to allow
message mes-
sage exchanges to be stateless. That is, a secure session is not
required to exchange KINK messages as each message contains all of
the information required to authenticate the message. This is in
contrast to IKE [IKE] which requires a phase 1 security association
to be created and maintained in order to create subsequent security
associations.

Kerberos tickets utilize only symmetric key cryptography with
relatively rela-
tively small overhead required to process them (as compared to public
key-based protocols). However, an authentication mechanism that is
utilized between a KDC client and the KDC can be either symmetric key
based (as specified by the base Kerberos protocol [RFC1510]) or public pub-
lic key based (as specified by PKINIT [PKINIT]).

KINK hosts are peers in the IPsec sense of the meaning that a KINK
host can initiate or respond to KINK commands. Messages come in three
varieties: commands, replies, and acknowledgments. In most
circumstances, cir-
cumstances, a KINK security association can be installed in two
messages: mes-
sages: a command and a reply. The method here is to use an
"optimistic" "optimis-
tic" algorithm where negotiation proposals are prioritized and the
top choice is installed in the security association database. If for
some reason the respondent does not choose the first proposal, the
respondent may choose another but at the cost of a ACK message so
that it can be guaranteed of delivery.

Since the KDC does not possess a symmetric key PKINIT principals KINK
defines an unauthenticated request for getting a peer's ticket
granting grant-
ing ticket. This allows KINK peers to request a User to User service
ticket. Upon receipt of the User to User service ticket, all messages
exchanges are identical. Discovery issues are discussed in section

Thomas et. al. [Page 5]

INTERNET DRAFT KINK July 2001

XXX.

KINK is intended as a generic key management protocol based on
Kerberos Ker-
beros tickets. It can be used to provide key management for any
security layer above level 2 in the Internet protocol stack,
including includ-
ing application-layer security. This document includes an IPSec DOI
(Domain of Interpretation) that enables KINK to be used directly as
an IPSec key management protocol. Other DOI

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 4]

INTERNET DRAFT KINK September 2000 specifications may be
used to apply KINK to other security protocols.

4. Message Flows

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

4.1

4.1. Standard KINK Message Flow

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

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

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

Figure 1: KINK Message Flow

4.2

Thomas et. al. [Page 6]

INTERNET DRAFT KINK July 2001

4.2. GETTGT Message Flow

If the initiator determines that it will not be able to directly get
a service ticket for the respondent (ie, B is a PKINIT principal), it
must fetch the TGT from the respondent first in order to get a User-
User service ticket:

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

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

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

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

Figure 2: GETTGT Message Flow

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 5]

INTERNET DRAFT KINK September 2000

4.3

4.3. CREATE Security Association

This flow instantiates a security association. The CREATE command
takes an "optimistic" approach where security associations are
initially created on the expectation that the respondent will chose
the initial proposed payload.

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

A creates initial inbound SA (B->A)

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

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

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

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

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

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

Figure 3: CREATE Message Flow

The security associations are instantiated as follows: In step one
host A creates an inbound security association in its database from

Thomas et. al. [Page 7]

INTERNET DRAFT KINK July 2001

B->A with using the first proposal in the ISAKMP SA proposal. It is then
ready to receive any messages from B. A then sends the CREATE message
to B. If B agrees to A's initial proposal and does not desire to con-
tribute entropy to the session key, B instantiates a security association associ-
ation in its database from A->B. If
it agreed to A's initial proposal B then instantiates the security
association from B->A. It then sends a REPLY to A without a NONCE
payload and without requesting an ACK and also instantiates the security association from
B->A. ACK. If B does not choose the first
proposal, it sends the actual choice in the REPLY REPLY, a NONCE and
requests that the REPLY be acknowledged. Upon receipt of the REPLY, A
modifies the inbound security association as necessary, instantiates
the security association from A->B, If B requested an ACK, A now
sends the ACK message. Upon receipt of the ACK, B installs the final
security association from B->A.

4.3.1

If B adds a nonce, or does not choose the first proposal, it SHOULD
request an ACK so that it can install the final outbound security
association. Since ACK's are not reliable [see section on Transport
Considerations], the requestor SHOULD implement a grace timer to
install the outbound security association.

4.3.1. CREATE Key Derivation Considerations

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 6]

INTERNET DRAFT KINK September 2000 keying material, this is
strictly a key strength versus number of messages tradeoff which KINK
implementations may decide as a matter of policy.

4.4

Thomas et. al. [Page 8]

INTERNET DRAFT KINK July 2001

4.4. DELETE Security Association

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

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

A deletes outbound SA to B

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

B deletes outbound SA to A

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

A deletes inbound SA to B

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

[ B deletes inbound SA to A A]

Figure 4: DELETE Message Flow

The DELETE command takes a "pessimistic approach" which does not
delete incoming security associations until it receives
acknowledgment acknowledg-
ment 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 SA. In this case, it MAY delete the
incoming SA as well in step one. The respondent MUST NOT delete its
incoming SA until it either receives the final ACK, or the transaction transac-
tion times out.

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 7]

INTERNET DRAFT KINK September 2000

4.4.1

4.4.1. Rekeying Security Associations

KINK requires the initiator of a security association to be
responsible responsi-
ble for rekeying a security association. The reason is twofold: we would like the
first is to prevent needless duplication of security associations as

Thomas et. al. [Page 9]

INTERNET DRAFT KINK July 2001

the result of collisions due to an initiator and respondent both trying try-
ing to renew an existing security association. The second reason is
due to the client server client/server nature of Kerberos exchanges which expects
the client to get and maintain tickets. While KINK requires that a
KINK host be able to get and maintain tickets, in practice it probably is
advantageous for servers to wait for clients to initiate sessions so
that they do not need to maintain a large ticket cache.

There are no special semantics for rekeying security associations in
KINK. That is, in order to rekey an existing security association,
the initiator must CREATE a new security association followed by
either DETETE'ing DELETE'ing the old security association or letting it just
time out. When identical flow selectors are available on different
security associations, KINK implementations SHOULD chose the security
association most recently created.

4.5. STATUS Message Flow

At any point, a sender may send status, normally in the form of DOI
specific payloads to its peer. In the case of the IPsec DOI, these
are generally in the form of ISAKMP Notification Payloads.

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

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

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

Figure 4: STATUS Message Flow

Thomas et. al. [Page 10]

INTERNET DRAFT KINK July 2001

5. KINK Message Format

All values in KINK are formatted in the network byte order: Most
Significant Byte first.

Figure 5: Format of a KINK message

Fields:

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 8]

INTERNET DRAFT KINK September 2000

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

o MjVer (4 bits) - Major protocol version number. This MUST be set
to 1. PacketCable IPSec key management MUST set this to 0.

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

o Length (16 bits) - Length of the message in octets octets. Note that it
is legal within KINK to omit the last bytes of padding in the last
payload in the overall length.

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

Thomas et. al. [Page 11]

INTERNET DRAFT KINK July 2001

The IANA Assigned Number for the Internet IP Security DOI (IPSEC
DOI) is one (1). This field defines the context of all other sub-
payloads in this payloads. If other sub-payloads have a DOI field
(example: Security Association Payload), then the DOI in that
sub-payload MUST be checked against the DOI in this header, and
the values MUST be the same.

o XID (4 octets) - The transaction ID. A KINK transaction is bound
together by a transaction ID which is created by the command ini-
tiator and replicated in subsequent messages in the transaction. A
transaction is defined as a command, a reply, and an optional ack-
nowledgment. Transaction ID's are used by the initiator to
discriminate between multiple outstanding requests to a respon-
dent. It is not used for replay protection because that func-
tionality is provided by Kerberos.

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 Flags (8 bits)

bit 1: ACKREQ - NextPayload (1 octet) -- Indicates the type of the first payload
after the message header

o A (1 bit) -- ACK Request. Set to one if the responder desires an
explicit acknowledgement that a REPLY was received. An initiator
MUST NOT set this flag.
bits 2-8: RSV - Reserved

o NextPayload (1 octet)- Indicates the type of the first payload
after the message header Reserved (15 bits) -- Reserved and must be zero

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 9]

INTERNET DRAFT KINK September 2000 as specified in the etype for the Kerberos session ses-
sion key in the Ker-
beros Kerberos ticket. If the etype does not specify a
hash algorithm, the SHA1 with a 20 byte checksum MUST be used. The
format of the Cksum field MUST mimic the
Kerberos checksum structure (without the ASN.1 encoding) is as fol-
lows: 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
+---------------+---------------+---------------+---------------+
| Kerberos cksumtype | checksum (variable) | padding (variable) |
+---------------+---------------+---------------+---------------+

Figure 6: KINK Checksum

The KINK header is followed immediately by a series of
Type/Length/Value fields, defined in the next section.

5.1

Thomas et. al. [Page 12]

INTERNET DRAFT KINK July 2001

5.1. KINK Payloads

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

Figure 7: Format of a KINK payload

Fields:

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

NextPayload Number
---- ------
KINK_DONE 0
KRB_AP_REQ
KINK_AP_REQ 1
KRB_AP_REP
KINK_AP_REP 2
KRB_ERROR
KINK_KRB_ERROR 3
KRB_TGT_REQ
KINK_TGT_REQ 4
KRB_TGT_REP
KINK_TGT_REP 5
ISAKMP_PAYLOAD
KINK_ISAKMP 6
KINK_ENCRYPT 7
KINK_ERROR 8

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 10]

INTERNET DRAFT KINK September 2000

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

o RESERVED (1 octet) - Unused, MUST be set to 0.

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

o Value (variable) - This field is depends on the Type.

5.1.1. KINK Padding Rules

KINK has the following rules regarding alignment and padding:

Thomas et. al. [Page 13]

INTERNET DRAFT KINK July 2001

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

o Between KINK payloads, checksums, headers or any other other vari-
able length data, the adjacent fields MUST be longword aligned.

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

5.1.2. 5.1.1 KRB_AP_REQ KINK_AP_REQ Payload

The value field of this KINK_AP_REQ payload contains relays a raw Kerberos KRB_AP_REQ.

Figure 8: KRB_AP_REQ Payload

5.1.2 KRB_AP_REP Payload kerberos AP-REQ to the respondent.
The AP-REQ MUST request mutual authetication. The service that the
KINK peer SHOULD request is "ipsec/fqdn@REALM" where "ipsec" is the
KINK IPsec service, "fqdn" is the fully qualified domain name of the
service host, and REALM is the Kerberos realm of the service. The
exception to this rule is when User-User service is requested in
which case the service name MUST be the service returned in the
GetTGT response payload.

The value field of this payload contains a raw Kerberos KRB_AP_REP. has the following format:

Figure 9: KRB_AP_REP 8: KINK_AP_REQ Payload

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber
Fields:

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

Thomas et. al. [Page 11] 14]

INTERNET DRAFT KINK September 2000

5.1.3 KRB_ERROR July 2001

5.1.3. 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 [1510].

The value field of this payload contains a raw Kerberos KRB_ERROR. has the following format:

Figure 10: KRB_ERROR 9: KINK_AP_REP Payload

5.1.4 KRB_TGT_REQ
Fields:

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

Thomas et. al. [Page 15]

INTERNET DRAFT KINK July 2001

5.1.4. KINK_KRB_ERROR Payload

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

KRB5KRB_AP_ERR_BAD_INTEGRITY
KRB5KRB_AP_ERR_TKT_EXPIRED
KRB5KRB_AP_ERR_TKT_NYV
KRB5KRB_AP_ERR_REPEAT
KRB5KRB_AP_ERR_NOT_US
KRB5KRB_AP_ERR_BADMATCH
KRB5KRB_AP_ERR_SKEW
KRB5KRB_AP_ERR_BADADDR
KRB5KRB_AP_ERR_BADVERSION
KRB5KRB_AP_ERR_MSG_TYPE
KRB5KRB_AP_ERR_MODIFIED
KRB5KRB_AP_ERR_BADORDER
KRB5KRB_AP_ERR_ILL_CR_TKT
KRB5KRB_AP_ERR_BADKEYVER
KRB5KRB_AP_ERR_NOKEY
KRB5KRB_AP_ERR_MUT_FAIL
KRB5KRB_AP_ERR_BADDIRECTION
KRB5KRB_AP_ERR_METHOD
KRB5KRB_AP_ERR_BADSEQ
KRB5KRB_AP_ERR_INAPP_CKSUM
KRB5KRB_AP_WRONG_PRINC
KRB5KRB_AP_ERR_TKT_INVALID

A compliant KINK implementation MUST take appropriate action for:

KRB5KRB_AP_ERR_BAD_INTEGRITY
KRB5KRB_AP_ERR_TKT_EXPIRED
KRB5KRB_AP_ERR_REPEAT
KRB5KRB_AP_ERR_SKEW
KRB5KRB_AP_ERR_MUT_FAIL

Note that KINK does not make use of the text or e_data field of the
Kerberos error message, though a compliant KINK implementation MUST
be prepared to receive them.

The value field of this payload has the following format:

Thomas et. al. [Page 16]

INTERNET DRAFT KINK July 2001

Figure 10: KINK_KRB_ERROR Payload

Fields:

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

5.1.5. KINK_TGT_REQ Payload

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

The value field of this payload has the following format:

Figure 11: KRB_TGT_REQ KINK_TGT_REQ Payload

Fields:

o PrincipalNameLen RealmNameLen - The length of the realm name that follows

o RealmName - The realm name that the responder should return a TGT
for.

o RESERVED - reserved and must be zero

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber

Thomas et. al. [Page 12] 17]

INTERNET DRAFT KINK September 2000

5.1.5 KRB_TGT_REP July 2001

5.1.6. KINK_TGT_REP Payload

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

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
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
| RealmNameLen PrincNameLen | RealmName PrincName (variable) ~
+---------------+---------------+---------------+---------------+
| |
~ RealmName(variable) ~ PrincName(variable) +---------------+
| ~ padding |
+---------------------------------------------------------------+
| TGTlength |
~ TGT (variable) |
+-------------------------------+---------------+---------------+
| ~
~ TGT (variable) +---------------+
| ~ padding |
+---------------------------------------------------------------+

Figure 12: KRB_TGT_REQ KINK_TGT_REQ Payload

Fields:

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

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

o TGTlength - The length of TGT that immediately follows

o TGT - the DER encoded TGT of the responder

5.1.6 ISAKMP_PAYLOAD

Thomas et. al. [Page 18]

INTERNET DRAFT KINK July 2001

5.1.7. KINK_ISAKMP Payload

The value field of this payload has the following format:

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
+---------------+---------------+---------------+---------------+
| Next Payload | RESERVED | Payload Length |
+---------------+---------------+---------------+---------------+
+---------------+-------+-------+---------------+---------------+
| InnerNextPload| IkeMj | IkeMn | RESERVED |
+---------------+---------------+---------------+---------------+
+---------------+-------+-------+---------------+---------------+
| Payload IKE Phase II Payloads (variable) |
+---------------+---------------+---------------+---------------+

Figure 13: ISAKMP_PAYLOAD KINK_ISAKMP Payload

Fields:

o InnerNextPload (variable) - First payload type of the inner series of

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 13]

INTERNET DRAFT KINK September 2000 ISAKMP
payloads.

5.1.7 KINK_ENCRYPT

o IkeMj - The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
using the encyption algorithm specified by ISAKMP major version of the etype inner payloads.

o IkeMn - The IKE minor version of the session
key. This payload MUST inner payloads

o RESERVED - reserved and must be zero

The purpose of the final payload in ISAKMP version is to allow backward compati-
bilty with IKE and ISAKMP if there subsequent revisions. At the message.

0 1 2 3
0
present time, the ISAKMP major and minor versions are set to one
and one (1.1) respectively. While strictly speaking the ISAKMP
version is not the same as the IKE version, that is how it is com-
monly construed, and KINK explicitly makes that linkage. A com-
plient KINK implementation MUST support receipt of ISAKMP version
1.1 payloads. It MAY support subsequent versions (both sending and
receiving), and SHOULD provide a means to resort back to ISAKMP
version 1.1 if the KINK peer is unable to process future versions.
A complient KINK implementation MUST NOT mix ISAKMP versions in
any given transaction.

Thomas et. al. [Page 19]

INTERNET DRAFT KINK July 2001

5.1.8. KINK_ENCRYPT Payload

The KINK_ENCRYPT payload encapsulates other payloads and is encrypted
using the encyption 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 14: KINK_ENCRYPT Payload
Fields:

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

5.1.8

o RESERVED - reserved and must be zero

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

[XXX/mat: I'm trying to say use krb5_c_encrypt()
without IV set to NULL. I may be on crack here, so somebody
say something if this is wrong.]

The format of the encryption payload uses the normal [RFC1510]
semantics of prepending a crypto-specific initialization vector
and padding the entire message out to the crypto-specfic number of
bytes. For example, with DES-CBC, the initialization vector will
be 8 octets long, and the entire message will be padded to an 8
octet boundary. Note that KINK Encrypt payload MUST NOT include a
checksum since this is redundant with the message integrity check-
sum in the KINK header.

Thomas et. al. [Page 20]

INTERNET DRAFT KINK July 2001

5.1.9. KINK_ERROR Payload

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

Figure 15: KINK_ERROR Payload

ErrorCode Number
--------- ------
KINK_OK 0
KINK_PROTOERR 1
KINK_INVDOI 2
KINK_INVMAJ 3
KINK_INVMIN 4

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 14]

INTERNET DRAFT KINK September 2000

RESERVED
KINK_INTERR 5
RESERVED 6 - 8191
Private Use 8192 - 16383

o KINK_OK - No error detected
o KINK_PROTOERR - The message was malformed
o KINK_INVDOI - Invalid DOI
o KINK_INVMAJ - Invalid Major Version
o KINK_INVMIN - Invalid Minor Version

6
o KINK_INTERR - An unrecoverable internal error was detected

6. KINK Messages

KINK messages are either commands, replies, or acknowledgments. A
command is sent by an initiator to the respondent. A reply is sent
by the respondent to the initator. If the respondent desires confir-
mation of the reply, it sets the ACKREQ bit in the message header.
The initiator will then respond with an ACK messages. All commands,
responses and acknowledgements are bound together by the XID field of
the message header. The XID is normally a monotonically incrementing
field, and is used by the initiator to differentiate between out-
standing requests to a responder. The XID field does not provide
replay protection as that functionality is provided by Kerberos
mechanisms. In addition, commands and responses MUST use a crypto-
graphic hash over the

Thomas et. al. [Page 21]

INTERNET DRAFT KINK July 2001

cryptographic hash over the entire message if the two peers share a sym-
metric
symmetric key via a ticket exchange.

6.1

6.1. CREATE

This message initiates an establishment of new Security
Association(s). The CREATE message must contain an AP-REQ payload and
any DOI specific payloads. The valid ISAKMP-CREATE payloads are
described in section 7.

CREATE contains the following payloads:
KINK Header
KRB_AP_REQ
KINK_AP_REQ Payload
[KINK_ENCRYPT]
[CREATE-PAYLOADS]

6.3
[ISAKMP-CREATE-PAYLOADS]

6.2. DELETE

This message indicates that the sending peer has deleted or will
shortly delete Security Association(s) with the other peer. The
valid ISAKMP-DELETE payloads are described in section 7.
DELETE contains the following payloads:
KINK Header (with DOI)
KRB_AP_REQ
KINK_AP_REQ Payload
[KINK_ENCRYPT]
[DELETE-PAYLOADS]

6.4
[ISAKMP-DELETE-PAYLOADS]

6.3. REPLY

The REPLY message is a generic reply which must contain either a
KRB_AP_REP
KINK_AP_REP or a KRB-ERROR payload. REPLY's may contain additional
DOI specific payloads such as ISAKMP payloads defined in this document.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 15]

INTERNET DRAFT KINK September 2000 docu-
ment. The valid ISAKMP-REPLY payloads are described in section 7.

REPLY
KINK Header
KRB_AP_REP
KINK_AP_REP | KRB_ERROR KINK_KRB_ERROR Payload
[KINK_ENCRYPT]
[ KINK_ERROR ]
[REPLY-PAYLOADS]
[ISAKMP-REPLY-PAYLOADS]

All REPLY messages must contain either a KRB_AP_REP KINK_AP_REP or KRB_ERROR.
KINK_KRB_ERROR. It may optionally contain a KINK_ERROR. The checksum
in the KRB-ERROR message is not used, since the KINK header already
contains a check-
sum checksum field.

The server MUST return a KRB_AP_ERR_SKEW if the server clock and the
client clock are off by more than the policy-determined clock skew
limit (usually 5 minutes). The optional client's time in the KRB-
ERROR MUST be filled out, and the client MUST compute the difference

Thomas et. al. [Page 22]

INTERNET DRAFT KINK July 2001

(in seconds) between the two clocks based upon the client and server
time contained in the KRB-ERROR message. The client SHOULD store
this clock difference and use it to adjust its clock in subsequent
messages.

6.5

6.4. ACK

This is an acknowledgment returned to the originator of a REPLY mes-
sage. This message MUST NOT contain any payloads beside a lone AP-REQ
header. If the initiator detects an error in the AP-REP or any other
KINK or Kerberos error, it SHOULD take remedial action by reinitiat-
ing the initial command with the appropriate error to instruct the
KINK receiver how to correct its original problem.

ACK
KINK Header
[KINK_AP_REQ]

6.5. STATUS

This is an acknowledgment returned to the originator of a REPLY mes-
sage. This message MUST NOT contain any DOI specific payloads. ACK
MAY contain both KINK_ERROR's and KRB_ERROR's. In particular, if a
command initiator found an error in the AP_REP, it MUST send an ACK
with the proper Kerberos error regardless of the state of the ACKREQ
flag of the respondent. The respondent SHOULD be prepared to receive
an unexpected ACK from the initiator.

ACK The valid ISAKMP-STATUS pay-
loads are described in section 7.

STATUS
KINK Header
[KRB_AP_REQ]
[KINK_ERROR]
[KRB_ERROR]

7
[KINK_AP_REQ]
[KINK_ENCRYPT]
[ KINK_ERROR ]
[ISAKMP-STATUS-PAYLOADS]

7. IPSEC DOI-specific Payload Formats

These ISAKMP Payloads

KINK directly uses IKE/ISAKMP payloads follow the conventions and values established by
[ISAKMP]. to negotiate security associa-
tions. In other words, each particular, KINK uses IKE phase II payload has a generic, well-
established header. Only certain payloads will be reused from
[ISAKMP], however. The rest of ISAKMP will not types (aka Quick
Mode). In general, there should be used, since Ker-
beros provides very few changes necessary to for
an IKE implemenation to establish the equivalent functionality.

Only security associations, and
unless there is a note to the payloads listed contrary in this document will the memo, all capabilities
and requirements in [IKE] MUST be valid supported. IKE Phase I payloads
MUST NOT be sent.

Unlike IKE, KINK defines specific commands for KINK.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber creation, deletion,

Thomas et. al. [Page 16] 23]

INTERNET DRAFT KINK September 2000

7.1 Security Association Payload

When using the IP Domain of Interpretation, the protocol, transform
identifiers, July 2001

and Security association Identifiers from status of security associations, mainly to facilitate predictable
SA creation/deletion (see section 4.4 in
[IPDOI] MUST 4.3 and 4.4). As such, KINK places
certain restrictions on what payloads may be used.

7.1.1 Security Association Payload Format sent with which com-
mands, 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.

7.1. IKE Phase II (Quick Mode) Differences

The following sections detail the differences to standard IKE phase
II payloads which must be incorporated for a complient KINK impleme-
nation.

7.1.1. Security Association Payload Differences

o The Security Association Payload header for IP is defined in
[IPDOI] section 4.6.1. For this memo, the Domain of Interpretation Interpreta-
tion 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).

Given this restriction,

o KINK also expands the semantics of IKE in that the first propo-
sal MUST be the proposal which the sender of a CREATE command is
prepared to receive incoming IPsec datagrams.

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

o PFS uses the Diffie Hellman group used in the phase 1 exchange.
KINK uses XXX.

Thomas et. al. [Page 24]

INTERNET DRAFT KINK July 2001

7.1.2. Security Association Payload looks like
this:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 Attributes Supported

KINK supports the following security association attributes from
[IPDOI]:

class value type
-------------------------------------------------
SA Life Type 1 B
SA Life Duration 2 3 V
Encapsulation Mode 4 B
Authentication Algorithm 5 B
Key Length 6 B
Key Rounds 7 8 9 0 B

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

7.1.3. Identification Payload Differences

The Identification payload carries information that is used to iden-
tify the traffic that is to be protected using the keys exchanges in
this memo. (NB: The payload name is misleading, and should really be
called the selector payload). KINK only restricts the selector types
to the following:

ID Type Value
------- -----
ID_IPV4_ADDR 1 2 3
ID_IPV4_ADDR_SUBNET 4
ID_IPV6_ADDR 5
ID_IPV6_ADDR_SUBNET 6
ID_IPV4_ADDR_RANGE 7
ID_IPV6_ADDR_RANGE 8 9 0 1
+---------------+---------------+---------------+---------------+
! Next Payload ! RESERVED ! Payload Length !
+---------------+---------------+---------------+---------------+
! Domain of Interpretation (IPSec) |
+---------------+---------------+---------------+---------------+
! Situation !
+---------------+---------------+---------------+---------------+
! !
~ List of Proposal Payloads ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Security Association Payload Format

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 17]

INTERNET DRAFT KINK September 2000

7.1.2 Proposal Payload Format

Immediately following the Security Association payload header is a
proposal payload header, as defined in [ISAKMP], section 3.6 (which
in turn contains transform payloads, which contains a set of
attributes as defined in [ISAKMP], section 3.3.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
! Next Payload ! RESERVED ! Payload Length !
+---------------+---------------+---------------+---------------+
! Proposal # ! Protocol-Id ! SPI Size !# of Transforms!
+---------------+---------------+---------------+---------------+
! SPI (variable) !
+---------------+---------------+---------------+---------------+
! !
~ List of Transform Payloads ~
! !
+---------------+---------------+---------------+---------------+

Figure 17: Proposal Payload Format

7.1.3 Transform Payload Format

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
+---------------+---------------+---------------+---------------+
! Next Payload ! RESERVED ! Payload Length !
+---------------+---------------+---------------+---------------+
! Transform # ! Transform-Id ! RESERVED2 !
+---------------+---------------+---------------+---------------+
! !
~ List of SA Attributes ~
! !
+---------------+---------------+---------------+---------------+

Figure 18: Transform Payload Format

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 18]

INTERNET DRAFT KINK September 2000

7.1.4 Security Association Attributes

KINK supports the following security association attributes from
[IPDOI]:

class value type
-------------------------------------------------
SA Life Type 1 B
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.

7.2 Identification Payloads

The Identification payload carries information that is used to
identify the traffic that is to be protected using the keys exchanges
in this memo. (NB: The payload name is misleading, and should really
be called the selector payload).

Figure 19: Identification Payload Format

The Identification Payload fields are defined as follows:

o Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in the
message, then this field will be 0.

o RESERVED (1 octet) - Unused, set to 0.

o Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header.

o ID Type (1 octet) - Specifies the type of Identification being used.
This field is DOI-dependent.

o DOI Specific ID Data (3 octets) - Contains DOI specific Identifica-
tion data. If unused, then this field MUST be set to 0.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 19]

INTERNET DRAFT KINK September 2000

or IP DOI, this field has the following format:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

o Identification Data (variable length) - Contains identity informa-
tion. The values for this field are DOI-specific and the format is
specified by the ID Type field. Specific details for the IETF IP
Security DOI Identification Data are detailed in [IPDOI].

Valid ID-types for KINK are:

ID TypeValue
------------
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

Traffic selection is very Domain of Interpretation specific, so the
contents of ID's MUST depend on the DOI present in SA.

7.3 Nonce Payloads

The Nonce payload contains random data that SHOULD be used in key
generation by both sides. It also provides freshness of the exchange,
in addition to whatever freshness/replay-protection mechanisms the
transport mechanism may provide.

Figure 20: Nonce Payload Format

The Nonce Payload fields are defined as follows:

o Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in the
message, then this field will be 0.

o RESERVED (1 octet) - Unused, set to 0.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 20]

INTERNET DRAFT KINK September 2000

o Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header.

o Nonce Data (variable length) - Contains the random data generated by
the transmitting entity.

7.4 Delete Payloads

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-Id ! SPI Size ! # of SPIs !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index(es) (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 21: Delete Payload Format
For IPSec, the Delete will always refer to a specific connection, and
therefore a specific SPI. The DOI field must therefore always be set to
1 (IP DOI), and the protocol and SPI fields will be set to the protocol
and SPI this deletion pertains to.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 21]

INTERNET DRAFT KINK September 2000

7.4 Notify Payloads

Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the
Notify message to synchronize SA communication. The table below
lists the Notification messages and their corresponding values.
Values in the Private Use range are expected to be DOI-specific
values.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain of Interpretation (DOI) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol-ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Security Parameter Index (SPI) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Notification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22: Notification Payload Format

7.1.4. Nonce Payloads

The Notification Payload fields are defined as follows:

o Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in the
message, then this field will be 0.

o RESERVED (1 octet) - Unused, set to 0.

o Payload Length (2 octets) - Length in octets of the current payload,
including the generic Nonce payload header.

o Domain of Interpretation (4 octets) - Identifies the DOI (as
described in Section 2.1) under which this notification is taking
place. For ISAKMP this value is zero (0) and for the IPSEC DOI it is
one (1). Other DOI's can contains random data that MUST be defined using the description in appen-
dix B.

o Protocol-Id (1 octet) - Specifies the protocol identifier for the
current notification. Examples might include ISAKMP, IPSEC ESP,
IPSEC AH, OSPF, TLS, etc.

o SPI Size (1 octet) - Length used in octets of the SPI as defined key
generation by the

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 22]

INTERNET DRAFT initiating KINK September 2000

Protocol-Id. In the case of ISAKMP, the Initiator and Responder
cookie pair from the ISAKMP Header is the ISAKMP SPI, therefore, the
SPI Size is irrelevant peer, and MAY be from zero (0) to sixteen (16). If
the SPI Size is non-zero, the content of the SPI field MUST be
ignored. The Domain of Interpretation (DOI) will dictate the SPI
Size for other protocols.

o Notify Message Type (2 octets) - Specifies the type of notification
message (see section 3.14.1). Additional text, if specified used by the
DOI, is placed in the Notification Data field.

o SPI (variable length) - Security Parameter Index. The receiving
entity's SPI. The use of
responding KINK peer. In IKE, the SPI field is described in section 2.4 nonce payload also provides proof
of
[ISAKMP]. The length freshness of the exchange, but this field functionality is determined already
provided by Kerberos' use of timestamps for liveliness. A receiving
KINK peer MUST NOT use the SPI Size
field and is not necessarily aligned to a 4 octet boundary.

o nonce payload as the primary freshness
indicator, though it MAY use it as an additional check.

Thomas et. al. [Page 25]

INTERNET DRAFT KINK July 2001

7.1.5. Notify Payloads

Notification Data (variable length) - Informational or information can be error messages specifying why an SA
could not be established. It can also be status data
transmitted in addition that a process
managing an SA database wishes to communicate with a peer process.
For example, a secure front end or security gateway may use the
Notify Message Type. Values for this
field are DOI-specific. message to synchronize SA communication. The following Notify Types are taken directly from [ISAKMP] with
unsupported table below
lists the Notification messages and their corresponding values removed. that
are supported in KINK.

NOTIFY MESSAGES - ERROR TYPES

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

NOTIFY MESSAGES - STATUS TYPES

Status Value
CONNECTED 16384
RESERVED (Future Use) 16385 - 24575
DOI-specific codes 24576 - 32767

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 23]

INTERNET DRAFT KINK September 2000
Private Use 32768 - 40959
RESERVED (Future Use) 40960 - 65535

7.1.6. PFS Support

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

Thomas et. al. [Page 26]

INTERNET DRAFT KINK July 2001

relying on Kerberos benefits from PFS. KINK retains the ability to
use PFS, but relaxes the requirement from must implement to SHOULD
implement.

7.2. IPsec DOI Message Formats

8.1

7.2.1. CREATE

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

CREATE contains the following payloads:
KINK Header
KRB_AP_REQ
KINK_AP_REQ payload
[KINK_ENCRYPT]
ISAKMP_PAYLOAD
KINK_ISAKMP payload
SA Payload Payload[s]
Proposal Payloads
Transform Payloads
Nonce Payload
[ ID Payloads ] (Ni)
[KE]
[IDci, IDcr]
[Notification Payloads]

Note: KINK, like IKE allows the creation of many security
associations in one create command. If any of the optimistic creation
mode proposals is not chosen by the respondent, it MUST request an
ACK.
Replies are of the following forms:

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

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

Thomas et. al. [Page 27]

INTERNET DRAFT KINK July 2001

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

REPLY
KINK Header
KRB_AP_REP
KINK_AP_REP payload
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
ISAKMP_PAYLOAD payload
Notify
KINK_ISAKMP payload

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 24]

INTERNET DRAFT KINK September 2000

If
[Notification Payloads]

Finally, if the respondent finds an Kerberos or KINK type of error it
which it cannot create a AP-REP for, MUST reply with a lone KRB_ERROR
KINK_KRB_ERROR or KINK_ERROR payload:

REPLY
KINK Header
KRB_ERROR payload
[KINK_ENCRYPT]
[ KINK_ERROR
KINK_KRB_ERROR|KINK_ERROR payload ]

8.2

7.2.2. DELETE

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

DELETE contains the following payloads:
KINK Header (with DOI)
KRB_AP_REQ
KINK_AP_REQ payload
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
ISAKMP_PAYLOAD
KINK_ISAKMP payload
Delete Payload Payload[s]
[Notification Payloads]

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

REPLY
KINK Header
KRB_AP_REP | KRB_ERROR
KINK_AP_REP payload
[KINK_ENCRYPT]
[ KINK_ERROR payload ]
ISAKMP_PAYLOAD
KINK_ISAKMP payload
Delete Payload Payload[s]
[Notification Payloads]

Thomas et. al. [Page 28]

INTERNET DRAFT KINK July 2001

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

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

If the respondent finds an a KINK or Kerberos type of error it MUST
reply with a lone KRB_ERROR KINK_KRB_ERROR or KINK_ERROR payload:

REPLY
KINK Header
KRB_ERROR | KINK_KRB_ERROR payload

7.2.3. STATUS

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

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

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

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

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

REPLY
KINK Header
KINK_AP_REP payload
[ KINK_ENCRYPT payload ]
[ KINK_ERROR payload ]

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber
KINK_ISAKMP payload [Notification Payloads]

Thomas et. al. [Page 25] 29]

INTERNET DRAFT KINK September 2000

9 Key Derivation

During July 2001

If the establishment respondent finds a KINK or Kerberos type of SAs the initiator and responder each pro-
vide random nonces that add entropy to the KDC supplied session key
in order to derive the SA keying material (KEYMAT).

KEYMAT = HMAC(Secret, Ni [ | Nr ])

The function is initially called with the session key found in the
service ticket used for Secret and is called recursively with the
resulting KEYMAT until error it has generated proper number of bits.

The initator MUST add entropy in the form of
reply with a random nonce to the
ticket session key when it instantiates the optimistic security asso-
ciation. The HMAC algorithm used is lone KINK_KRB_ERROR or KINK_ERROR payload:

REPLY
KINK Header
KRB_ERROR | KINK_KRB_ERROR payload

8. Key Derivation

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

KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b [ | Nr_b])

The following differences apply:

o SKEYID_d is the
etype for the Kerberos session key in the Kerberos ticket. If the
etype does not specify a hash algorithm, the SHA1 MUST be used. The
results are placed in the subkey field of service ticket from
the AP-REQ. The number

o Nr_b is optional

By optional, it is meant that the equivalent of
subkey bits MUST be large enough a zero length
nonce was supplied.

9. Transport Considerations

KINK uses UDP on port XXX to generate keying material for the
largest encryption transport its messages. There is one
timer T which SHOULD take into consideration round trip considera-
tions and integrity algorithms proposed.

Bits for the security association keys are taken from MUST implement a truncated exponential backoff mechanism.
The state machines is simple: any message which expects a response
must retransmit the generated
key in network order starting request using timer T. Since Kerberos requires
that messages be retransmitted with the key new times for replay protection,
the initiator's
inbound security association with message must be recreated each time including the integrity algorithm key first
followed by checksum of the encryption algorithm, and repeated
message.

Note that in KINK delivery of a final ACK is not reliable. A KINK
implementation that asks for a final ACK MUST be prepared for the
initiator's outbound security association. There is no implied pad-
ding between the encryption and integrity keying material.

The respondent MAY choose to add more entropy to the key, but if it
does, it SHOULD request an ACK message before it sends data on the
newly created security association. It MUST place
not being delivered. Two mechanisms are possible to work around the concatenation
need for a final ACK:

1) A timer of the average round trip time between the two nonces it choses in KINK
peers times some comfort margin can be started. If the subkey field of ACK is
not received within that time period, the AP-REP. The
nonce sizes MUST be requestor can assume
that either its response was lost by the same size initiator, or that the initiator chose. Upon
receipt of
ACK was lost. In the AP-REP, first case, the initiator MUST compare will usually
retransmit the second nonce to
determine if initial request within the respondent added entropy to timeout period. In the keying material. If
it has,
second case, the final cleanup should be performed as if the
initiator MUST modify sent the keys for ACK.

Thomas et. al. [Page 30]

INTERNET DRAFT KINK July 2001

2) If reliability is required, the initial respondent could initiate a
security association using in the rules described above.
The following flow illustrates opposite direction with the derivation of keys:

A B
----- -----
K0=HMAC(SessKey, Nonce1, 0)
AP-REP(subkey=Nonce1)----------------> K1=HMAC(SessKey, Nonce1,
Nonce2)
K2=HMAC(SessKey, Nonce1,
Nonce3) [where Nonce3 MAY
be null]

<-------------------------------- AP-REQ(subkey=Nonce2|Nonce3)

Figure 23: Key Derivation

K0 is used to instantiate same
characteristics. This has the optimistic incoming downside of instantiating two
security associa-
tion from B->A. K1 associations simultaneously and is always not recommended.

10. Security Considerations

KINK cobbles together and reuses many parts of both Kerberos and IKE,
the key that latter which in turn is used for the security

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 26]

INTERNET DRAFT cobbled together from many other memos.
As such, KINK September 2000

association between A->B. The value inherits many of the subkey in weaknesses and considerations of
each of its components. However, KINK only uses IKE Phase II payload
to create and delete security association, the AP-REQ is
always Nonce1. The value security considera-
tions which pertain to IKE Phase I can be safely ignored.

KINK's use of Kerberos presents a couple of considerations. First,
KINK explicitly expects that the subkey KDC will provide adequate entropy
when it generates session keys. Second, Kerberos normally being a
user authentication vehicle allows for potentially weak user and key-
tab keys which in turn can be the AP-REP is weak link in subsequently generated
IPsec security associations. This memo does not describe a particular
method to avoid these pitfalls, but recommends that suitable randomly
generated keys be used for the concate-
nation of Nonce2 service principals and Nonce3 where Nonce3 is equal to zero if B client princi-
pals such as using the -randomkey option with MIT's "kadmin addprinc"
command.

Kerberos itself does not desire to add entropy to the optimistic security association B-
>A.

10 Transport Considerations

KINK uses UDP provide for perfect forward secrecy which
makes KINK's reliance on port XXX the IKE ability to transport its messages. There is one
timer T which SHOULD take into consideration round trip considera-
tions and MUST implement a truncated exponential backoff mechanism.
The state machines do PFS somewhat suspect
from an overall system's standpoint. In isolation KINK itself should
be secure from offline analysis from compromised principal
passphrases if PFS is simple: any message used, but the existence of other Kerberized
service which expects do not provide PFS makes this a response
must retransmit less than optimal
situation on the request using timer T. Since Kerberos whole.

11. IANA Considerations

KINK requires that messages a new well known port UDP be retransmitted with created. Since KINK
uses standard message types from [IKE], KINK does not require any new times
registries. Any new DOI's, ISAKMP types, etc for replay protection,
the message must be recreated each time including the checksum future versions of
KINK MUST use the
message.

11 Security Considerations

12 registries defined for [IKE].

12. Protocol Considerations

12.1

12.1. Security Policy Database Considerations

KINK leaves the population of the IPsec security policy database out
of scope. There are, however, considerations which should be pointed

Thomas et. al. [Page 31]

INTERNET DRAFT KINK July 2001

out. Firstly, even though when and when not to initiate a user to
user flow is left to the discretion of the KINK implemention, a Ker-
beros client which initially authenticated using a symmetric key
SHOULD NOT use a user-user flow if the respondent is also in the same
realm. Likewise, a KINK initiator which authenticated in a public
key realm SHOULD use a user-user flow if the respondent is in the
same realm.

KINK does not define the cross realm behavior. At a minimum a the
security policy database for a KINK implementation SHOULD contain a
logical record of the KDC to contact, principal name for the respon-
dent, and whether the KINK implementation should use a direct AP-
REQ/AP-REP flow, or a User-User flow to CREATE/DELETE the security
association.

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 27]

INTERNET DRAFT KINK September 2000

13. Related Work

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

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

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

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

Thomas et. al. [Page 32]

INTERNET DRAFT KINK July 2001

14. References

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

[KERB]
B.C.

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

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

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

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 28]

INTERNET DRAFT KINK September 2000

[RFC2401]
S. Kent, R. Atkinson. Security Architecture for the Internet Proto-
col.
Protocol. Request for Comments 2401.

[IKE]
D.

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

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

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

15. Mailing List

Please send comments to the KINK mailing list (ietf-kink@vpnc.org).
You can subscribe by sending mail to ietf-kink-request@vpnc.org with
a line in the body of the mail with the word SUBSCRIBE in it.

Thomas et. al. [Page 33]

INTERNET DRAFT KINK July 2001

16. Author's Addresses

Mike Froh
CyberSafe Corporation
180 Elgin Street
Ottawa, Ontario K2P 2K3
Phone: +1 613 234 7300
E-mail: mike.froh@cybersafe.com

Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
E-mail: matt.hur@cybersafe.com

David McGrew
Mike Thomas
Jan Vilhuber
Matthew Hur
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
E-mail: {mcgrew,mat,vilhuber}@cisco.com

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber [Page 29]

INTERNET DRAFT KINK September 2000 {mcgrew,mat,mhur,vilhuber}@cisco.com

Sasha Medvinsky
Motorola
6450 Sequence Drive
San Diego, CA 92121
+1 858 404 2367
E-mail: smedvinsky@gi.com

17 Expiration

This memo is filed as <draft-ietf-kink-kink-00.txt>,

17. Acknowledgements

Many have contributed to the KINK effort, including our working group
chairs Derek Atkins and expires
February, 2001.

Froh, Hur, McGrew, Medvinsky, Thomas, Vilhuber Jonathan Trostle. The original inspiration
came from Cablelab's Packetcable effort which defined a simplifed
version of Kerberized IPsec. The inspiration for wholly reusing IKE
Phase II is the result of the Tero Kivinen's initial draft suggesting
the obvious.

Thomas et. al. [Page 30] 34]

----