INTERNET-DRAFT      KINK                                       M. Thomas
                                                             J. Vilhuber
                                                        January 21, 2003

             Kerberized Internet Negotiation of Keys (KINK)

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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   The Kerberized Internet Negotiation of Keys protocol (KINK) defines a
   low-latency, computationally inexpensive, easily managed, and
   cryptographically sound protocol to set up and maintain IPsec
   security associations using Kerberos authentication. KINK reuses many
   ISAKMP Quick Mode payloads to create, delete and maintain IPsec
   security associations 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",
   document are to be interpreted as described in RFC-2119.

Thomas, Vilhuber                                                [Page 1]

INTERNET DRAFT                    KINK                      January 2003

Table of Contents

 Introduction ....................................................    2
 Terminology .....................................................    2
 Protocol Overview ...............................................    4
 Message Flows ...................................................    5
  Standard KINK Message Flow .....................................    5
  GETTGT Message Flow ............................................    5
  CREATE Security Association ....................................    5
  DELETE Security Association ....................................    7
  STATUS Message Flow ............................................   10
 KINK Message Format .............................................   10
  KINK Payloads ..................................................   13
 KINK Quick Mode Payload Profile .................................   22
  General Quick Mode Differences .................................   22
  Security Association Payloads ..................................   23
  Proposal and Transform Payloads ................................   23
  Identification Payloads ........................................   23
  Nonce Payloads .................................................   24
  Notify Payloads ................................................   24
  Delete Payloads ................................................   25
  KE Payloads ....................................................   25
 IPsec DOI Message Formats .......................................   26
  REPLY Message Considerations ...................................   26
  ACK Message Considerations .....................................   26
  CREATE Message .................................................   27
  DELETE Message .................................................   28
  STATUS Message .................................................   29
 Key Derivation ..................................................   30
 Transport Considerations ........................................   30
 Security Considerations .........................................   31
  Security Policy Database Considerations ........................   31
 IANA Considerations .............................................   32
 Forward Compatibility Considerations ............................   32
  New Versions of Quick Mode .....................................   32
  New DOI ........................................................   33
 Related Work ....................................................   33
 Normative References ............................................   34
 Informative References ..........................................   35
 Mailing List ....................................................   35
 Author's Addresses ..............................................   35
 Acknowledgments .................................................   36
 IPR Notice ......................................................   36
 Full Copyright ..................................................   36

Thomas, Vilhuber                                                [Page 2]

INTERNET DRAFT                    KINK                      January 2003

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 low latency, to have a small footprint, and to avoid or
   minimize the use of public key operations.  In particular, the proto-
   col provides the capability to establish security associations in two
   messages with minimal computational effort.

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

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

   This document specifies the Kerberized Internet Negotiation of Keys
   Protocol and the domain of interpretation (DOI) for establishing and
   maintaining IPsec Security Associations [IPSEC]. No other domains of
   interpretation are defined in this document.

2.  Terminology

     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

Thomas, Vilhuber                                                [Page 3]

INTERNET DRAFT                    KINK                      January 2003

     server's secret key. The combination of a ticket and an authentica-
     tor (which proves freshness and knowledge of the key within the
     ticket) creates an authentication credential.

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

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

     A ticket granting ticket is a normal Kerberos ticket which the KDC
     issues for the Kerberos service. The main purpose of a TGT is to
     capture the results of initial authentication for subsequent ticket
     granting requests, thus providing a single sign-on service.

     Kerberos normally divides the world into clients and servers where
     the server maintains a table of keys (keytab) which is used to
     encrypt/decrypt service tickets. In situations where a principal
     may not have a keytab (ex. a human/client principal rather than a
     service principal), Kerberos provides the means of issuing what is
     known as a User-User ticket.  To produce the User-User ticket, the
     KDC requires the ticket granting tickets from both client princi-
     pals.  Kerberos does not specify a means obtaining a client's
     ticket granting ticket, and is thus application specific.

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


Thomas, Vilhuber                                                [Page 4]

INTERNET DRAFT                    KINK                      January 2003

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

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

     Kerberos defines an standardized message format and transport for
     contacting a KDC to perform initial authentication, and for grant-
     ing subsequent service tickets. When a client needs to authenticate
     to a server, Kerberos provides a standardized message format, but
     leaves the transport as application specific. The messages which
     perform this function are AP-REQ between the client and the server,
     and AP-REP between the server and client if mutual authentication
     is needed.

3.  Protocol Overview

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

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

   KINK directly reuses [ISAKMP] Quick Mode payloads, with some minor
   changes and omissions. In most cases, KINK exchanges are a single
   command and its response. The lone exception is the CREATE command
   which allows a final acknowledgment message when the respondent needs
   a full three-way handshake. This is only needed when the optimistic
   keying route is not taken, though it is expected that that will not
   be the norm. KINK also provides rekeying and dead peer detection as
   basic features.

Thomas, Vilhuber                                                [Page 5]

INTERNET DRAFT                    KINK                      January 2003

4.  Message Flows

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

4.1.  Standard KINK Message Flow

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

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

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

            Figure 1: KINK Message Flow

4.2.  GETTGT Message Flow

   If the initiator determines that it will not be able to get a  normal
   service  ticket  for the respondent (eg, B is a client principal), it
   MUST first fetch the TGT from the respondent 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

Thomas, Vilhuber                                                [Page 6]

INTERNET DRAFT                    KINK                      January 2003

4.3.  CREATE Security Association

   This flow instantiates a security  association.  The  CREATE  command
   takes  an  "optimistic"  approach  where  security  associations  are
   initially created on the expectation that the respondent  will  chose
   the  initial  proposed  payload. The optimistic payload is defined as
   the first transform of the first proposal  of  the  first  conjugate.
   The  initiator  MUST  checks  to  see  if  the optimistic payload was
   selected by comparing all transforms and  attributes  which  MUST  be
   identical  from  the  initiator's  optimistic  proposal with the lone
   exception  of  LIFE_KILOBYTES  and  LIFE_SECONDS.   Both   of   these
   attributes  MAY  be  set to a lower value by the respondent and still
   expect optimistic keying, but MUST NOT be set to a higher value which
   MUST generate an error.

   CREATE'ing a security association on an existing SPI is an  error  in
   KINK and MUST be rejected with an ISAKMP notification of INVALID-SPI.

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

       A creates initial inbound SA (B->A)

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

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

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

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

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

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

            Figure 3: CREATE Message Flow

   The security associations are instantiated as follows: In step one
   host A creates an inbound security association in its security asso-
   ciation database from B->A using the optimistic proposal in the
   ISAKMP SA proposal. It is then ready to receive any messages from B.
   A then sends the CREATE message to B. If B agrees to A's optimistic
   proposal, B instantiates a security association in its database from
   A->B. B then instantiates the security association from B->A. It then
   sends a REPLY to A without a NONCE payload and without requesting an
   ACK. If B does not choose the first proposal, it sends the actual
   choice in the REPLY, a NONCE payload and requests that the REPLY be
   acknowledged. Upon receipt of the REPLY, A modifies the inbound secu-
   rity 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

Thomas, Vilhuber                                                [Page 7]

INTERNET DRAFT                    KINK                      January 2003


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

4.3.1.  CREATE Key Derivation Considerations

   The CREATE command's optimistic approach allows a security 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 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 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.  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 inbound and outbound SA to A

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

       A deletes inbound SA to B

            Figure 4: DELETE Message Flow

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

Thomas, Vilhuber                                                [Page 8]

INTERNET DRAFT                    KINK                      January 2003

   cease all activity on an incoming SA. In this case, it MAY delete the
   incoming SA as well in step one.  If the receiver cannot find an
   appropriate SPI to delete, it MUST return an ISAKMP INVALID_SPI
   notification which also serves to inform the initiator that it can
   delete the incoming SA. For simplicity, KINK does not allow half open
   security associations; thus upon receiving a DELETE, the responder
   MUST delete its security associations, and MUST reply with ISAKMP
   delete notification messages if the SPI is found.

   A race condition with DELETE exists. Packets in flight while the
   DELETE operation is taking place may, due to network reordering, etc,
   arrive after the diagrams above recommend deleting the incoming secu-
   rity association. A KINK implementation SHOULD implement a grace
   timer which SHOULD be set to a period of at least two times the aver-
   age round trip time, or to a configurable value. A KINK implementa-
   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

4.4.1.  Rekeying Security Associations

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

   There are no special semantics for rekeying security associations in
   KINK. That is, in order to rekey an existing security association,
   the initiator must CREATE a new security association followed by
   either DELETE'ing the old security association or letting it time
   out. When identical flow selectors are available on different secu-
   rity associations, KINK implementations SHOULD choose the security
   association most recently created. It should be noted that KINK
   avoids most of the problems of [IKE] rekeying by having a reliable
   delete mechanism.

   Normally a KINK implementation which rekeys existing security associ-
   ations will try to rekey the security association ahead of a hard SA
   expiration. We call this time the rekey time Trekey. In order to
   avoid synchronization with similar implementations, KINK initiators
   MUST randomly pick a rekeying time between Trekey and the SA expira-
   tion time minus the amount of time it would take to go through a full
   retransmission time cycle, Tretrans. Trk SHOULD be set at least twice
   as high as Tretrans.

Thomas, Vilhuber                                                [Page 9]

INTERNET DRAFT                    KINK                      January 2003

4.4.2.  Dead Peer Detection

   In order to determine that a KINK peer has lost its security database
   information, KINK peers MUST record the current epoch for which they
   have valid SADB information and reflect that epoch in each AP-REQ and
   AP-REP message. When a KINK peer creates state for a given security
   association, it MUST also record the principal's epoch as well. If it
   discovers on a subsequent message that the principal's epoch has
   changed, it MUST consider all security associations created by that
   principal as invalid, and take some action such as tearing those SA's

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

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

   The STATUS message has a two-fold effect: First, it elicits a crypto-
   graphically secured (and replay-protected) response from the peer,
   which tells us whether the peer is reachable/alive or not. Further,
   it carries the epoch number of the peer, so we know whether the peer
   has rebooted and lost all state or not. This is crucial to the KINK
   protocol: In IKE, if a peer reboots, we loose all cryptographic con-
   text, 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

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

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

Thomas, Vilhuber                                               [Page 10]

INTERNET DRAFT                    KINK                      January 2003

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

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

4.5.  STATUS Message Flow

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

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

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

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

            Figure 5: STATUS Message Flow

Thomas, Vilhuber                                               [Page 11]

INTERNET DRAFT                    KINK                      January 2003

5.  KINK Message Format

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

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |   Type        | MjVer | MnVer |            Length             |
    |                  Domain of Interpretation  (DOI)              |
    |                          Transaction ID   (XID)               |
    |    CksumLen   |  NextPayload  |A|         Reserved            |
    |                                                               |
    ~                             Cksum                             ~
    |                                                               |
    |                                                               |
    ~                      A series of payloads                     ~
    |                                                               |

                     Figure 6:  Format of a KINK message


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

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

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

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

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

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

Thomas, Vilhuber                                               [Page 12]

INTERNET DRAFT                    KINK                      January 2003

      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. The value of XID is chosen by
      the initiator and MUST be unique with all outstanding transac-
      tions.  XID's MAY be constructed by using a monotonic counter, or
      random number generator.

   o  CksumLen (2 octets) -- CksumLen is the length in octets of the
      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 (1 bit) -- ACK Request. Set to one if the responder requires an
      explicit acknowledgment that a REPLY was received. An initiator
      MUST NOT set this flag, nor should any other command other than
      CREATE request an ACK and then only when the optimistic SA is not

   o  Reserved (15 bits) --  Reserved and must be zero

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

      The format of the Cksum field is as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      |       checksum (variable)     ~     padding  (variable)       |

                     Figure 7: KINK Checksum

Thomas, Vilhuber                                               [Page 13]

INTERNET DRAFT                    KINK                      January 2003

      To compute the checksum, the checksum field is zeroed out and the
      appropriate algorithm is run over the entire message (as given by
      the Length field in the KINK header), and placed in the Checksum
      field. To verify the checksum, the checksum is saved, and the
      checksum field is zeroed out. The checksum algorithm is run over
      the message, and the result is compared with the saved version. If
      they do not match, the message MUST be dropped.

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

5.1.  KINK Payloads

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

      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        |
    |                      value (variable)                         |

                      Figure 8:  Format of a KINK payload


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

          NextPayload    Number
          ----           ------
          KINK_DONE         0         (same as ISAKMP_NEXT_NONE)

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

Thomas, Vilhuber                                               [Page 14]

INTERNET DRAFT                    KINK                      January 2003

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

   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 value of this field depends on the Type.

5.1.1.  KINK Padding Rules

   KINK has the following rules regarding alignment and padding:

   o  All length fields MUST reflect the actual number of octets in the
      structure; ie 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 aligned on 4 octet

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

Thomas, Vilhuber                                               [Page 15]

INTERNET DRAFT                    KINK                      January 2003

5.1.2.  KINK_AP_REQ Payload

   The KINK_AP_REQ payload relays a Kerberos AP-REQ to  the  respondent.
   The  AP-REQ MUST request mutual authentication.  The service that the
   KINK peer SHOULD request is "kink/fqdn@REALM"  where  "kink"  is  the
   KINK  IPsec service, "fqdn" is the fully qualified domain name of the
   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 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        |
    |                         EPOCH                                 |
    |                                                               |
    ~                      KRB_AP_REQ                               ~
    |                                                               |

                      Figure 9:  KINK_AP_REQ Payload

   o  EPOCH - the absolute time at which the creator of the AP-REQ has
      valid security database (SADB) information. Typically this is when
      the KINK keying daemon started if it does not retain SADB informa-
      tion across different restarts. The format of this fields is net-
      work order encoding of the standard posix four octet time stamp.

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

Thomas, Vilhuber                                               [Page 16]

INTERNET DRAFT                    KINK                      January 2003

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

   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        |
    |                         EPOCH                                 |
    |                                                               |
    ~                      KRB_AP_REP                               ~
    |                                                               |

                      Figure 10:  KINK_AP_REP Payload

   o  EPOCH - the absolute time at which the creator of the AP-REP has
      valid security database (SADB) information. Typically this is when
      the KINK keying daemon started if it does not retain SADB informa-
      tion across different restarts. The format of this fields is net-
      work order encoding of the standard posix four octet time stamp.

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

Thomas, Vilhuber                                               [Page 17]

INTERNET DRAFT                    KINK                      January 2003

5.1.4.  KINK_KRB_ERROR Payload

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


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

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

   The value field of this payload has the following format:

     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        |
    |                                                               |
    ~                      KRB_ERROR                                ~
    |                                                               |

                      Figure 11:  KINK_KRB_ERROR Payload


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

Thomas, Vilhuber                                               [Page 18]

INTERNET DRAFT                    KINK                      January 2003

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:

     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           |   RealmName (variable)        ~
    |                                                               |
    ~                      RealmName(variable)                      ~
    |                                                               |

                      Figure 12:  KINK_TGT_REQ Payload


   o  RealmNameLen - The length of the realm name that follows

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

   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.

Thomas, Vilhuber                                               [Page 19]

INTERNET DRAFT                    KINK                      January 2003

5.1.6.  KINK_TGT_REP Payload

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

     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        |
    |        PrincNameLen           |       PrincName (variable)    ~
    |                                                               |
    ~                       PrincName(variable)     +---------------+
    |                                               ~   padding     |
    |          TGTlength            |              TGT (variable)   |
    |                                                               ~
    ~                               TGT (variable)  +---------------+
    |                                               ~   padding     |

                      Figure 13:  KINK_TGT_REQ Payload


   o  PrincNameLen - The length of the principal name that immediately

   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

   o  TGT - the DER encoded TGT of the responder

Thomas, Vilhuber                                               [Page 20]

INTERNET DRAFT                    KINK                      January 2003

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| QMMaj | QMMin |            RESERVED           |
    |                Quick Mode Payloads (variable)                 |

                      Figure 14:  KINK_ISAKMP Payload


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

   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.

   o  RESERVED - reserved and must be zero

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

      The purpose of the Quick Mode version is to allow backward compa-
      tibility 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

Thomas, Vilhuber                                               [Page 21]

INTERNET DRAFT                    KINK                      January 2003

5.1.8.  KINK_ENCRYPT Payload

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

     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|            RESERVED                           |
    |                         Payload (variable)                    |

                      Figure 15:  KINK_ENCRYPT Payload

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

   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.

      The format of the encryption payload uses the normal [KERBEROS]
      semantics of prepending a crypto-specific initialization vector
      and padding the entire message out to the crypto-specific number
      of 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
      checksum in the KINK header.

Thomas, Vilhuber                                               [Page 22]

INTERNET DRAFT                    KINK                      January 2003

5.1.9.  KINK_ERROR Payload

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

     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        |
    |                           ErrorCode                           |

                      Figure 16:  KINK_ERROR Payload

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

6.  KINK Quick Mode Payload Profile

   KINK directly uses ISAKMP payloads to negotiate security associa-
   tions. In particular, KINK uses IKE phase II payload types (aka Quick
   Mode). In general, there should be very few changes necessary to an
   IKE implementation to establish the security associations, and unless
   there is a note to the contrary in the memo, all capabilities and
   requirements in [IKE] MUST be supported. IKE Phase I payloads MUST
   NOT be sent.

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

Thomas, Vilhuber                                               [Page 23]

INTERNET DRAFT                    KINK                      January 2003

6.1.  General Quick Mode Differences

   o    The Security Association Payload header for IP is defined in
        [IPDOI] section 4.6.1. For this memo, the Domain of Interpreta-
        tion 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 optmis-
        tic proposal for CREATE commands to allow SA creation to com-
        plete in two messages.

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

   o    KINK does not use the HASH payload at all.

   o    KINK allows the NONCE payload Nr to be optional to facilitate
        optimistic keying.

6.2.  Security Association Payloads

   KINK supports the  following  security  association  attributes  from

             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.

6.3.  Proposal and Transform Payloads

   KINK directly uses the Proposal and Transform payloads with no
   differences. KINK, however, places additional relevance to the first
   proposal and first transform of each conjugate for optimistic keying.

6.4.  Identification Payloads

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

Thomas, Vilhuber                                               [Page 24]

INTERNET DRAFT                    KINK                      January 2003

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

6.5.  Nonce Payloads

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

Thomas, Vilhuber                                               [Page 25]

INTERNET DRAFT                    KINK                      January 2003

6.6.  Notify Payloads

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

                      NOTIFY MESSAGES - ERROR TYPES

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

                      NOTIFY MESSAGES - STATUS TYPES

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

6.7.  Delete Payloads

   KINK directly uses ISAKMP delete payloads with no changes.

6.8.  KE Payloads

Thomas, Vilhuber                                               [Page 26]

INTERNET DRAFT                    KINK                      January 2003

   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

7.  IPsec DOI Message Formats

   KINK messages are either commands, replies, or acknowledgments. A
   command is sent by an initiator to the respondent.  A reply is sent
   by the respondent to the initiator. If the respondent desires confir-
   mation of the reply, it sets the ACKREQ bit in the message header.
   The ACKREQ bit MUST NOT be set by the respondent except in the lone
   case of a CREATE message for which one of the security associations
   did not use the optimistic payload. In that case, the ACKREQ bit MUST
   be set. All commands, responses and acknowledgments are bound
   together by the XID field of the message header. The XID is normally
   a monotonically incrementing field, and is used by the initiator to
   differentiate between outstanding requests to a responder. The XID
   field does not provide replay protection as that functionality is
   provided by Kerberos mechanisms. In addition, commands and responses
   MUST use a cryptographic hash over the entire message if the two
   peers share a symmetric key via a ticket exchange.

7.1.  REPLY Message Considerations

   The REPLY message is a generic reply which MUST contain either a
   KINK_AP_REP, a KRB-ERROR, or KINK_ERROR payload. REPLY's MAY contain
   additional DOI specific payloads such as ISAKMP payloads which are
   defined in the following sections.  The checksum in the KRB-ERROR
   message is not used, since the KINK header already contains a check-
   sum field.

   The server MUST return a KRB_AP_ERR_SKEW if the server clock and the
   client clock are off by more than the policy-determined clock skew
   limit (usually 5 minutes).  The optional client's time in the KRB-
   ERROR MUST be filled out, and the client MUST compute the difference
   (in seconds) between the two clocks based upon the client and server
   time contained in the KRB-ERROR message.  The client SHOULD store
   this clock difference and use it to adjust its clock in subsequent

7.2.  ACK Message Considerations

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

Thomas, Vilhuber                                               [Page 27]

INTERNET DRAFT                    KINK                      January 2003

   Kerberos error, it SHOULD take remedial action by reinitiating the
   initial command with the appropriate error to instruct the KINK
   receiver how to correct its original problem.

7.3.  CREATE

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

       KINK_ISAKMP payload
            SA Payload[s]
                 Proposal Payloads
                         Transform Payloads
            Nonce Payload (Ni)
            [IDci, IDcr]
            [Notification Payloads]

   Replies are of the following forms:

   REPLY KINK Header
            SA Payload[s]
                   Proposal Payload
                           Transform Payload
            [ Nonce 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  absence  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.

   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.

Thomas, Vilhuber                                               [Page 28]

INTERNET DRAFT                    KINK                      January 2003

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

   REPLY KINK Header
           [Notification Payloads]

   If the respondent finds a Kerberos error for which it can  produce  a
   valid authenticator, the REPLY takes the following form:

   REPLY KINK Header

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

   REPLY KINK Header

7.4.  DELETE

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

       [ KINK_ERROR payload ]
       KINK_ISAKMP payload
           Delete Payload[s]
           [Notification Payloads]

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

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

Thomas, Vilhuber                                               [Page 29]

INTERNET DRAFT                    KINK                      January 2003

   If an IPsec 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 ]
       KINK_ISAKMP payload
           [Notification Payloads]

   If the respondent finds a Kerberos error for which it can  produce  a
   valid authenticator, the REPLY takes the following form:

   REPLY KINK Header

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

   REPLY KINK Header

7.5.  STATUS

   The STATUS command is used in two ways:

   1)   As a means to relay an ISAKMP Notification message

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

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

Thomas, Vilhuber                                               [Page 30]

INTERNET DRAFT                    KINK                      January 2003

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

   REPLY KINK Header
            [Notification Payloads] ]

   If the respondent finds a Kerberos error for which it can  produce  a
   valid authenticator, the REPLY takes the following form:

   REPLY KINK Header

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

     KINK Header

8.  Key Derivation

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

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

   The following differences apply:

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

   o  Nr_b is optional

      By optional, it is meant that the equivalent of a zero length
      nonce 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].

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

Thomas, Vilhuber                                               [Page 31]

INTERNET DRAFT                    KINK                      January 2003

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

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

10.  Security Considerations

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

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

   Kerberos itself does not provide for perfect forward secrecy which
   makes KINK's reliance on the IKE ability to do PFS somewhat suspect
   from an overall system's standpoint. In isolation KINK itself should
   be secure from offline analysis from compromised principal
   passphrases if PFS is used, but the existence of other Kerberized
   service which do not provide PFS makes this a less than optimal
   situation on the whole.

10.1.  Security Policy Database Considerations

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

Thomas, Vilhuber                                               [Page 32]

INTERNET DRAFT                    KINK                      January 2003

   out. First, 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 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.

   At a minimum the security policy database for a KINK implementation
   SHOULD contain a logical record of the KDC to contact, principal name
   for the respondent, 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.

11.  IANA Considerations

   KINK requires that a new well known system port for UDP be created.
   Since KINK uses standard message types from [IKE], KINK does not
   require any new registries. Any new DOI's, ISAKMP types, etc for
   future versions of KINK MUST use the registries defined for [IKE].

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

12.  Forward Compatibility Considerations

   KINK can accommodate future versions of Quick Mode through the use of
   the version field in the ISAKMP payload as well as new domains of
   interpretation. In this memo, the only supported Quick Mode version
   is 1.0 which corresponds to [IKE]. Likewise, the only DOI suported is
   the IPsec domain of interpretation [IPDOI]. New Quick Mode versions
   and DOI's MUST be described in subsequent memos.

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

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

Thomas, Vilhuber                                               [Page 33]

INTERNET DRAFT                    KINK                      January 2003

12.1.  New Versions of Quick Mode

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

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

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

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

12.2.  New DOI

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

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

   In order to carry GDOI messages in KINK, the DOI field in the KINK
   header would indicate that GDOI is being used, instead of IPSEC-DOI,
   and the KINK_ISAKMP payload would contain the payloads defined in the
   GDOI draft rather than the payloads used by [IKE] Quick Mode. The
   version number in the KINK_ISAKMP header is related to the DOI in the
   KINK header, so a maj.min version 1.0 under DOI GDOI is different
   from a maj.min version 1.0 under DOI IPSEC-DOI.

13.  Related Work

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

Thomas, Vilhuber                                               [Page 34]

INTERNET DRAFT                    KINK                      January 2003

   has produced two distinct protocols:

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

     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.

14.  Normative References

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

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

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

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

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

Thomas, Vilhuber                                               [Page 35]

INTERNET DRAFT                    KINK                      January 2003

15.  Informative References

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

        Postel, J., "Transmission Control Protocol", RFC 793, Sep-01-

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

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

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

16.  Mailing List

   Please send comments to the KINK mailing list (
   You can subscribe by sending mail to with
   a line in the body of the mail with the word SUBSCRIBE in it.

17.  Author's Addresses

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

Thomas, Vilhuber                                               [Page 36]

INTERNET DRAFT                    KINK                      January 2003

18.  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 simplifed
   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 graft-
   ing Kerberos authentication onto quick mode.

19.  IPR Notice

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

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

20.  Full Copyright

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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

Thomas, Vilhuber                                               [Page 37]

INTERNET DRAFT                    KINK                      January 2003

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

   This document and the information contained herein is provided on an

Thomas, Vilhuber                                               [Page 38]