[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4430

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

             Kerberized Internet Negotiation of Keys (KINK)

Status of this Memo

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

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

   Internet-Drafts 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

   This document is a submission by the KINK Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the KINK mailing list (ietf-kink@vpnc.org).  You can subscribe by
   sending mail to ietf-kink-request@vpnc.org with a line in the body of
   the mail with the word SUBSCRIBE in it.

   Distribution of this memo is unlimited.

   This Internet-Draft expires in November 28, 2005.

Thomas, Vilhuber                                                [Page 1]

Internet-Draft                    KINK                          May 2005

Copyright Notice

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


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

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.

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

Thomas, Vilhuber                                                [Page 2]

Internet-Draft                    KINK                          May 2005

Table of Contents

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

Thomas, Vilhuber                                                [Page 3]

Internet-Draft                    KINK                          May 2005

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

Thomas, Vilhuber                                                [Page 4]

Internet-Draft                    KINK                          May 2005

1.  Introduction

   KINK is designed to provide a secure, scalable mechanism for
   establishing keys between communicating entities within a centrally
   managed environment in which it is important to maintain consistent
   security policy.  The security goals of KINK are to provide privacy,
   authentication, and replay protection of key management messages, and
   to avoid denial of service vulnerabilities whenever possible.  The
   performance goals of the protocol are to incur 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
   protocol provides the capability to establish IPsec security
   associations in two messages with minimal computational effort.

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

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

2.  Terminology

   Editor's comment: remain it for the order of sections referred from

Thomas, Vilhuber                                                [Page 5]

Internet-Draft                    KINK                          May 2005

   the issue list.

3.  Protocol Overview

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

   KINK uses Kerberos mechanisms to provide mutual authentication and
   replay protection.  For security association establishment, KINK
   provides privacy of the payloads which follow the Kerberos
   authenticator.  KINK's design mitigates denial of service attacks by
   requiring authenticated exchanges before the use of any public key
   operations and the installation of any state.  KINK also provides the
   means of using Kerberos User-to-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

   KINK directly reuses Quick Mode payloads defined in section 5.5 of
   [IKE], with some minor changes and omissions.  In most cases, KINK
   exchanges are a single command and its response.  The exception is
   that the CREATE command may have a third message.  When the responder
   disagrees with the optimistic proposal, it requests the third
   message, an acknowledgement, to the initiator in order to complete a
   non-optimistic keying.  KINK also provides rekeying and dead peer

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
   subject of Kerberos and local policy consideration.  In these flows,
   we assume that A and B both have TGT's from their KDC.

4.1.  Standard KINK Message Flow

Thomas, Vilhuber                                                [Page 6]

Internet-Draft                    KINK                          May 2005

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

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

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

            Figure 1: KINK Message Flow

4.2.  GETTGT Message Flow

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

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

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

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

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

            Figure 2: GETTGT Message Flow

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 responder will choose
   the initial proposed payload.  The optimistic proposal is defined as
   the first transform of the first proposal of the first conjugate.
   The initiator MUST check to see if the optimistic proposal was
   selected by comparing all transforms and attributes which MUST be
   identical from those in the initiator's optimistic proposal with the
   exceptions of LIFE_KILOBYTES and LIFE_SECONDS.  Each of these
   attributes MAY be set to a lower value by the responder and still
   expect optimistic keying, but MUST NOT be set to a higher value which
   MUST generate an error.

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

Thomas, Vilhuber                                                [Page 7]

Internet-Draft                    KINK                          May 2005

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

       A creates initial inbound SA (B->A)

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

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

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

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

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

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

            Figure 3: CREATE Message Flow

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

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

4.3.1.  CREATE Key Derivation Considerations

Thomas, Vilhuber                                                [Page 8]

Internet-Draft                    KINK                          May 2005

   The CREATE command's optimistic approach allows a security
   association 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 this may be suspect, however KINK takes
   advantage of the fact that the KDC provides a reliable source of
   randomness which is used in key derivation.  In many cases, this will
   provide an adequate session key so that B will not require an
   acknowledgment.  Since B is always at liberty to contribute to the
   keying material, this is strictly a tradeoff between the key strength
   versus the number of messages, which KINK implementations may decide
   as a matter of policy.

4.4.  DELETE Security Association

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

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

       A deletes outbound SA to B

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

       B deletes inbound and outbound SA to A

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

       A deletes inbound SA to B

            Figure 4: DELETE Message Flow

   The DELETE command takes a "pessimistic" approach which does not
   delete incoming security associations until it receives
   acknowledgment that the other host has received the DELETE.  The
   exception to the pessimistic approach is if the initiator wants to
   immediately cease all activity on an incoming 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.  KINK does not allow half open
   security associations; thus upon receiving a DELETE, the responder
   MUST delete its security associations, and MUST reply with ISAKMP

Thomas, Vilhuber                                                [Page 9]

Internet-Draft                    KINK                          May 2005

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

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

4.4.1.  Rekeying Security Associations

   KINK requires the initiator of a security association to be
   responsible for rekeying a security association.  The reason is
   twofold: the first is to prevent needless duplication of security
   associations as the result of collisions due to an initiator and
   responder both trying to renew an existing security association.  The
   second reason is due to the client/server nature of Kerberos
   exchanges which expects the client to get and maintain tickets.
   While KINK requires that a KINK host is able to get and maintain
   tickets, in practice it is often 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 DELETE'ing the old security association or letting it time
   out.  When identical flow selectors are available on different
   security associations, KINK implementations SHOULD choose the
   security association most recently created.  It should be noted that
   KINK avoids most of the problems of [IKE] rekeying by having a
   reliable delete mechanism.

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

Thomas, Vilhuber                                               [Page 10]

Internet-Draft                    KINK                          May 2005

   set at least twice as high as Tretrans.

4.4.2.  Dead Peer Detection

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

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

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

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

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

Thomas, Vilhuber                                               [Page 11]

Internet-Draft                    KINK                          May 2005

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

   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

5.  KINK Message Format

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

Thomas, Vilhuber                                               [Page 12]

Internet-Draft                    KINK                          May 2005

       0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |   Type        | MjVer | MnVer |            Length             |
    |                  Domain of Interpretation  (DOI)              |
    |                          Transaction ID   (XID)               |
    |    CksumLen   |  NextPayload  |A|         RESERVED            |
    |                                                               |
    ~                             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 13]

Internet-Draft                    KINK                          May 2005

      Defined values are specified by the ISAKMP Domain of
      Interpretation section in the IANA isakmp-registry [ISAKMP-REG].
      The IANA Assigned Number for the Internet IP Security DOI [IPDOI]
      is one (1).  This field defines the context of all sub-payloads in
      this message.  If 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

   o  XID (4 octets) - The transaction ID.  A KINK transaction is bound
      together by a transaction ID which is created by the command
      initiator and replicated in subsequent messages in the
      transaction.  A transaction is defined as a command, a reply, and
      an optional acknowledgment.  Transaction ID's are used by the
      initiator to discriminate between multiple outstanding requests to
      a responder.  It is not used for replay protection because that
      functionality is provided by Kerberos.  The value of XID is chosen
      by the initiator and MUST be unique with all outstanding
      transactions.  XID's 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 proposal
      is not chosen.

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

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

Thomas, Vilhuber                                               [Page 14]

Internet-Draft                    KINK                          May 2005

   The format of the Cksum field is as follows:

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

                         Figure 7: KINK Checksum

   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 (1 octets) - The type of the next payload

          NextPayload    Number

Thomas, Vilhuber                                               [Page 15]

Internet-Draft                    KINK                          May 2005

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

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

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

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

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

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

5.1.1.  KINK Padding Rules

   KINK has the following rules regarding alignment and padding:

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

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

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

5.1.2.  KINK_AP_REQ Payload

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

Thomas, Vilhuber                                               [Page 16]

Internet-Draft                    KINK                          May 2005

   KINK peer SHOULD request is "kink/fqdn@REALM" where "kink" is the
   KINK IPsec service, "fqdn" is the fully qualified domain name of the
   service host, and REALM is the Kerberos realm of the service.  The
   exception to this rule is when User-to-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  Next Payload, RESERVED, Payload Length - defined in the beginning
      of this section

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

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

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:

Thomas, Vilhuber                                               [Page 17]

Internet-Draft                    KINK                          May 2005

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    | Next Payload  |   RESERVED    |         Payload Length        |
    |                         EPOCH                                 |
    |                                                               |
    ~                      KRB_AP_REP                               ~
    |                                                               |

                      Figure 10:  KINK_AP_REP Payload


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

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

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

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 a KINK Cksum field when
   returning KINK_KRB_ERROR and the appropriate service key is

Thomas, Vilhuber                                               [Page 18]

Internet-Draft                    KINK                          May 2005

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

   The value field of this payload has the following format:

     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  Next Payload, RESERVED, Payload Length - defined in the beginning
      of this section

   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:

     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

Thomas, Vilhuber                                               [Page 19]

Internet-Draft                    KINK                          May 2005


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

   o  RealmNameLen - The length of the realm name that follows

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

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

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_REP Payload


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

   o  PrincNameLen - The length of the principal name that immediately

Thomas, Vilhuber                                               [Page 20]

Internet-Draft                    KINK                          May 2005

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

   o  TGTlength - The length of TGT that immediately follows

   o  TGT - the DER encoded TGT of the responder

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  Next Payload, RESERVED, Payload Length - defined in the beginning
      of this section

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

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

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

   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 message,
   KINK explicitly requires that a new ISAKMP header be used for each
   discrete SA operation.  In other words, a KINK sender MUST NOT send
   multiple quick mode transactions within a single KINK_ISAKMP payload.

   The purpose of the Quick Mode version is to allow backward

Thomas, Vilhuber                                               [Page 21]

Internet-Draft                    KINK                          May 2005

   compatibility with IKE and ISAKMP if there are subsequent revisions.
   At the present time, the Quick Mode major and minor versions are set
   to one and zero (1.0) respectively.  These versions do not correspond
   to the ISAKMP version in the ISAKMP header.  A compliant KINK
   implementation MUST support receipt of 1.0 payloads.  It MAY support
   subsequent versions (both sending and receiving), and SHOULD provide
   a means to resort back to Quick Mode version 1.0 if the KINK peer is
   unable to process future versions.  A compliant KINK implementation
   MUST NOT mix Quick Mode versions in any given transaction.

5.1.8.  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|            RESERVED2                          |
    |                         Payload (variable)                    |

                      Figure 15:  KINK_ENCRYPT Payload


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

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

   o  RESERVED2 - reserved and must be zero

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

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

Thomas, Vilhuber                                               [Page 22]

Internet-Draft                    KINK                          May 2005

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

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


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

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

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

6.  KINK Quick Mode Payload Profile

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

Thomas, Vilhuber                                               [Page 23]

Internet-Draft                    KINK                          May 2005

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

   Unlike IKE, KINK defines specific commands for creation, deletion,
   and status of security associations, mainly to facilitate predictable
   SA creation/deletion (see section 4.3 and 4.4).  As such, KINK places
   certain restrictions on what payloads may be sent with which
   commands, and some additional restrictions and semantics of some of
   the payloads.  Implementors should refer to [IKE] and [ISAKMP] for
   the actual format and semantics.  If a particular IKE phase II
   payload is not mentioned here, it means that there are no differences
   in its use.

6.1.  General Quick Mode Differences

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

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

   o    IKE Quick Mode (phase 2) uses the hash algorithm used in main
        mode (phase 1) to generate the keying material.  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

Thomas, Vilhuber                                               [Page 24]

Internet-Draft                    KINK                          May 2005

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

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

6.3.  Proposal and Transform Payloads

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

6.4.  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.  KINK restricts the ID types to the following values:

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

6.5.  Nonce Payloads

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

6.6.  Notify Payloads

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

Thomas, Vilhuber                                               [Page 25]

Internet-Draft                    KINK                          May 2005

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

                      NOTIFY MESSAGES - ERROR TYPES

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

                      NOTIFY MESSAGES - STATUS TYPES

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

6.7.  Delete Payloads

   KINK directly uses ISAKMP delete payloads with no changes.

6.8.  KE Payloads

Thomas, Vilhuber                                               [Page 26]

Internet-Draft                    KINK                          May 2005

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

7.  IPsec DOI Message Formats

   KINK messages are either commands, replies, or acknowledgments.  A
   command is sent by an initiator to the responder.  A reply is sent by
   the responder to the initiator.  If the responder desires
   confirmation of the reply, it sets the ACKREQ bit in the message
   header.  The ACKREQ bit MUST NOT be set by the responder except in
   the lone case of a CREATE message for which one of the security
   associations did not use the optimistic proposal.  In that case, the
   ACKREQ bit MUST be set.  All commands, responses, and acknowledgments
   are bound together by the XID field of the message header.  The XID
   is normally a monotonically incrementing field, and is used 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
   contain additional DOI specific payloads such as ISAKMP payloads
   which are defined in the following sections.  The checksum in the
   KRB-ERROR message is not used, since the KINK header already contains
   a checksum field.

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

7.2.  ACK Message Considerations

Thomas, Vilhuber                                               [Page 27]

Internet-Draft                    KINK                          May 2005

   ACK's are sent only when the ACKREQ bit is set in a REPLY message.
   ACK's MUST NOT contain any payloads beside a lone AP-REQ header.  If
   the initiator detects an error in the AP-REP or any other KINK or
   Kerberos error, it SHOULD take remedial action by reinitiating the
   initial command with the appropriate error to instruct the KINK
   receiver how to correct its original problem.

7.3.  CREATE Message

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

       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 SAs in
   the optimistic proposal installed by the initiator are valid.  If any
   of the first proposals are not chosen by the recipient, it MUST
   include the nonce payload as well to indicate that the initiator's
   outgoing SA's must be modified.

Thomas, Vilhuber                                               [Page 28]

Internet-Draft                    KINK                          May 2005

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

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

   REPLY KINK Header
           [Notification Payloads]

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

   REPLY KINK Header

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

   REPLY KINK Header

7.4.  DELETE Message

   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:

Thomas, Vilhuber                                               [Page 29]

Internet-Draft                    KINK                          May 2005

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

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

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

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

   REPLY KINK Header

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

   REPLY KINK Header

7.5.  STATUS Message

   The STATUS command is used in two ways:

   1)   As a means to relay an ISAKMP Notification message

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

Thomas, Vilhuber                                               [Page 30]

Internet-Draft                    KINK                          May 2005

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

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

   REPLY KINK Header
            [Notification Payloads] ]

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

   REPLY KINK Header

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

   REPLY KINK Header

8.  Key Derivation

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

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

   The following differences apply:

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

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

Thomas, Vilhuber                                               [Page 31]

Internet-Draft                    KINK                          May 2005

   o  Both Ni_b and Nr_b are the part of the nonce payload as described
      in section 3.2 of [IKE].  Nr_b is optional.  When the responder's
      nonce does not exist, Nr_b is treated as if a zero length value
      was supplied.

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

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

9.  Transport Considerations

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

   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
   retransmitting party SHOULD keep a list of valid authenticators which
   are outstanding for any particular transaction.

10.  Security Considerations

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

Thomas, Vilhuber                                               [Page 32]

Internet-Draft                    KINK                          May 2005

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

   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
   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-to-User flow if the responder is also in the same realm.
   Likewise, a KINK initiator which authenticated in a public key realm
   SHOULD use a User-to-User flow if the responder is in the same realm.

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

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

Thomas, Vilhuber                                               [Page 33]

Internet-Draft                    KINK                          May 2005

   are outside of the scope of the KINK working group.

11.  IANA Considerations

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

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

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

12.  Forward Compatibility Considerations

   KINK can accommodate future versions of Quick Mode through the use of
   the version field in the ISAKMP payload as well as new domains of
   interpretation.  In this memo, the only supported Quick Mode version
   is 1.0 which corresponds to [IKE].  Likewise, the only DOI supported
   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
   different DOI's can be used within the KINK framework.

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
   overloaded into the ID payloads, and now they are carried in slightly
   more powerful TS (Traffic Selector) payloads.

Thomas, Vilhuber                                               [Page 34]

Internet-Draft                    KINK                          May 2005

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

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

12.2.  New DOI

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

   As one example of a new DOI, the MSEC working group is currently
   defining 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
   provide the ability to create and maintain cryptographically secure
   security associations at layer three (ie, the IP layer).  This effort
   has produced two distinct protocols:

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

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

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

Thomas, Vilhuber                                               [Page 35]

Internet-Draft                    KINK                          May 2005

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

14.  Acknowledgments

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

15.  References

15.1.  Normative References

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

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

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

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

Thomas, Vilhuber                                               [Page 36]

Internet-Draft                    KINK                          May 2005


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

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

15.2.  Informative References

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

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

   [RFC793]      Postel, J., "Transmission Control Protocol", RFC 793,

Authors' Addresses

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

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

Thomas, Vilhuber                                               [Page 37]

Internet-Draft                    KINK                          May 2005

Change History (To be removed from RFC)

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

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related 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

Thomas, Vilhuber                                               [Page 38]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/