[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      KINK                                       M. Thomas
                                                                  Editor
                                                                 M. Froh
                                                               Cybersafe
                                                                  M. Hur
                                                               D. McGrew
                                                             J. Vilhuber
                                                                   Cisco
                                                             S Medvinsky
                                                                Motorola
                                                           July 19, 2001


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


Status of this Memo

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

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

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

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

Copyright Notice

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

Abstract

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

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




Thomas et. al.                                                  [Page 1]


INTERNET DRAFT                    KINK                         July 2001


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

Conventions used in this document

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

Action Items:


   o    Which Diffie Hellman group for PFS?

   o    Word the KINK_ENCRYPT IV use description better


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

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

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

   o    Need a port from IANA

Changes from -00



   o    Numerous editorial changes

   o    Change CREATE SA to reflect ACK reliability guidelines.  Mention
        grace timer for ACK.

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

   o    Add STATUS verb to reflect the ability of Quick mode to send
        mid-SA notifications.

   o    Reorganize the KINK header to not have a short paylaod and
        reserve all of the flags.

   o    Clarify the method of applying the keyed hash over the message.
        Also remove redundant checksum type in checksum field (it's
        defined to be the etype of the ticket).

   o    Clarify the padding rules.

   o    Clarify in GETTGT/TGTREP that you supply a realm to GETTGT and
        TGTREP returns the principal name of to do the UU with.

   o    List all of the appropriate Kerberos Errors that can be



Thomas et. al.                                                  [Page 2]


INTERNET DRAFT                    KINK                         July 2001


        returned. Mention which ones must be handled.

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

   o    Clarify how to produce the KINK encrypt header.

   o    Add an INTERNAL ERROR error code.

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

   o    Add section for PFS support.

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

   o    Reflect ACK handling in Transport Considerations

   o    Add Security Considerations.


1.  Introduction

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

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

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



Thomas et. al.                                                  [Page 3]


INTERNET DRAFT                    KINK                         July 2001


   efficiently establish multiple security associations with other
   servers. Since Kerberos principal keys (used for initial asymmetric
   authentication) are stored in the KDC, the number of principal keys
   is order of magnitude O(n) rather than O(n^2), as would be required
   for a pre-shared key type of solution.

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

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

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


2.  Terminology


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


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



Thomas et. al.                                                  [Page 4]


INTERNET DRAFT                    KINK                         July 2001


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


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


3.  Protocol Overview

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

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

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

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

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



Thomas et. al.                                                  [Page 5]


INTERNET DRAFT                    KINK                         July 2001


   XXX.

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




4.  Message Flows

   KINK message flows all follow the same pattern between the two peers:
   a command, a response and an optional acknowledgement. The actual
   Kerberos KDC traffic here is for illustrative purposes only. In prac-
   tice, when a principal obtains various tickets is a subject of Ker-
   beros 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






















Thomas et. al.                                                  [Page 6]


INTERNET DRAFT                    KINK                         July 2001



4.2.  GETTGT Message Flow

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


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

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

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

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

            Figure 2: GETTGT Message Flow


4.3.  CREATE Security Association

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

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

       A creates initial inbound SA (B->A)

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

       B creates inbound  SA  to  A  (A->B).  If  B  chooses  A's  first
   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 acceptible.

    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 database from



Thomas et. al.                                                  [Page 7]


INTERNET DRAFT                    KINK                         July 2001


   B->A using the first proposal in the ISAKMP SA proposal. It is then
   ready to receive any messages from B. A then sends the CREATE message
   to B. If B agrees to A's initial proposal and does not desire to con-
   tribute entropy to the session key, B instantiates a security associ-
   ation 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 and
   requests that the REPLY be acknowledged. Upon receipt of the REPLY, A
   modifies the inbound security association as necessary, instantiates
   the security association from A->B, If B requested an ACK, A now
   sends the ACK message. Upon receipt of the ACK, B installs the final
   security association from B->A.

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


4.3.1.  CREATE Key Derivation Considerations

   The CREATE command's optimistic approach allows a security 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.






















Thomas et. al.                                                  [Page 8]


INTERNET DRAFT                    KINK                         July 2001



4.4.  DELETE Security Association


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

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

       A deletes outbound SA to B

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

       B deletes outbound SA to A

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

       A deletes inbound SA to B

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

    [   B deletes inbound SA to A]

            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
   cease all activity on an incoming SA. In this case, it MAY delete the
   incoming SA as well in step one.  The respondent MUST NOT delete its
   incoming SA until it either receives the final ACK, or the transac-
   tion times out.

   A final race condition with DELETE exists. Packets in flight while
   the DELETE operation is taking place may, due to network reording,
   etc, arrive after the diagrams above recommend deleting the incoming
   security association. A KINK implementation MUST implement a grace
   timer which SHOULD be set to a period of at least two times the 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
   RST.


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



Thomas et. al.                                                  [Page 9]


INTERNET DRAFT                    KINK                         July 2001


   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
   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 just
   time out. When identical flow selectors are available on different
   security associations, KINK implementations SHOULD chose the security
   association most recently created.



4.5.  STATUS Message Flow

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

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

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

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

            Figure 4: STATUS Message Flow

























Thomas et. al.                                                 [Page 10]


INTERNET DRAFT                    KINK                         July 2001



5.  KINK Message Format

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

       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 5:  Format of a KINK message

   Fields:

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

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

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

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

   o  Length (16 bits) - 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 et. al.                                                 [Page 11]


INTERNET DRAFT                    KINK                         July 2001


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

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

   o  CksumLen (2 octets) -- CksumLen is the length in octets of the
      keyed hash of the message. A CksumLen of zero implies that the
      message is unauthenticated. Note that as with payload padding, the
      length here denotes the actual number of octets of the checksum
      structure not including any padding required.

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

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

   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, SHA1 with a 20 byte checksum MUST be used. 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 6: KINK Checksum

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






Thomas et. al.                                                 [Page 12]


INTERNET DRAFT                    KINK                         July 2001



5.1.  KINK Payloads


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

      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 7:  Format of a KINK payload

   Fields:


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

          NextPayload    Number
          ----           ------
          KINK_DONE      0
          KINK_AP_REQ       1
          KINK_AP_REP       2
          KINK_KRB_ERROR    3
          KINK_TGT_REQ      4
          KINK_TGT_REP      5
          KINK_ISAKMP       6
          KINK_ENCRYPT      7
          KINK_ERROR        8

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

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

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

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


5.1.1.  KINK Padding Rules

   KINK has the following rules regarding alignment and padding:




Thomas et. al.                                                 [Page 13]


INTERNET DRAFT                    KINK                         July 2001


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

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

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


5.1.2.  5.1.1 KINK_AP_REQ Payload

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

   The value field of this payload 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_AP_REQ                               ~
    |                                                               |
    +---------------------------------------------------------------+

                      Figure 8:  KINK_AP_REQ Payload
   Fields:

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

















Thomas et. al.                                                 [Page 14]


INTERNET DRAFT                    KINK                         July 2001



5.1.3.  KINK_AP_REP Payload

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

   The value field of this payload 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_AP_REP                               ~
    |                                                               |
    +---------------------------------------------------------------+

                      Figure 9:  KINK_AP_REP Payload
   Fields:

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

































Thomas et. al.                                                 [Page 15]


INTERNET DRAFT                    KINK                         July 2001



5.1.4.  KINK_KRB_ERROR Payload

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

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

   A compliant KINK implementation MUST take appropriate action for:

    KRB5KRB_AP_ERR_BAD_INTEGRITY
    KRB5KRB_AP_ERR_TKT_EXPIRED
    KRB5KRB_AP_ERR_REPEAT
    KRB5KRB_AP_ERR_SKEW
    KRB5KRB_AP_ERR_MUT_FAIL

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

   The value field of this payload has the following format:

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




Thomas et. al.                                                 [Page 16]


INTERNET DRAFT                    KINK                         July 2001


                      Figure 10:  KINK_KRB_ERROR Payload

   Fields:

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



5.1.5.  KINK_TGT_REQ Payload

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

   The value field of this payload has the following format:

     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 11:  KINK_TGT_REQ Payload

   Fields:

   o  RealmNameLen - The length of the realm name that follows

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

   o  RESERVED - reserved and must be zero


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















Thomas et. al.                                                 [Page 17]


INTERNET DRAFT                    KINK                         July 2001



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 12:  KINK_TGT_REQ Payload

   Fields:

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

   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 et. al.                                                 [Page 18]


INTERNET DRAFT                    KINK                         July 2001



5.1.7.  KINK_ISAKMP Payload


   The value field of this payload has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+-------+-------+---------------+---------------+
    | InnerNextPload| IkeMj | IkeMn |            RESERVED           |
    +---------------+-------+-------+---------------+---------------+
    |                IKE Phase II Payloads (variable)               |
    +---------------+---------------+---------------+---------------+

                      Figure 13:  KINK_ISAKMP Payload

   Fields:

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

   o  IkeMj - The ISAKMP major version of the inner payloads.

   o  IkeMn - The IKE minor version of the inner payloads

   o  RESERVED - reserved and must be zero


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















Thomas et. al.                                                 [Page 19]


INTERNET DRAFT                    KINK                         July 2001



5.1.8.  KINK_ENCRYPT Payload



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

     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 14:  KINK_ENCRYPT Payload
   Fields:

   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.

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

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












Thomas et. al.                                                 [Page 20]


INTERNET DRAFT                    KINK                         July 2001



5.1.9.  KINK_ERROR Payload



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

     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 15:  KINK_ERROR Payload

    ErrorCode    Number
    ---------    ------
    KINK_OK          0
    KINK_PROTOERR    1
    KINK_INVDOI      2
    KINK_INVMAJ      3
    KINK_INVMIN      4
    KINK_INTERR     5
    RESERVED         6 - 8191
    Private Use     8192 - 16383

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


6.  KINK Messages


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



Thomas et. al.                                                 [Page 21]


INTERNET DRAFT                    KINK                         July 2001


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


6.1.  CREATE

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

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


6.2.  DELETE


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


6.3.  REPLY

   The REPLY message is a generic reply which must contain either a
   KINK_AP_REP or a KRB-ERROR payload. REPLY's may contain additional
   DOI specific payloads such as ISAKMP payloads defined in this docu-
   ment. The valid ISAKMP-REPLY payloads are described in section 7.

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

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

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



Thomas et. al.                                                 [Page 22]


INTERNET DRAFT                    KINK                         July 2001


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



6.4.  ACK


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

   ACK
     KINK Header
     [KINK_AP_REQ]


6.5.  STATUS


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

   STATUS
     KINK Header
     [KINK_AP_REQ]
     [KINK_ENCRYPT]
       [ KINK_ERROR ]
       [ISAKMP-STATUS-PAYLOADS]



7.  IPSEC DOI-specific ISAKMP Payloads

   KINK directly uses IKE/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 for
   an IKE implemenation 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,



Thomas et. al.                                                 [Page 23]


INTERNET DRAFT                    KINK                         July 2001


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



7.1.  IKE Phase II (Quick Mode) Differences

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


7.1.1.  Security Association Payload Differences


   o    The Security Association Payload header for IP is defined in
        [IPDOI] section 4.6.1. For this memo, the Domain of 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 that the first propo-
        sal MUST be the proposal which the sender of a CREATE command is
        prepared to receive incoming IPsec datagrams.


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


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

















Thomas et. al.                                                 [Page 24]


INTERNET DRAFT                    KINK                         July 2001



7.1.2.  Security Association Attributes Supported


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

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

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

7.1.3.  Identification Payload Differences

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

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


7.1.4.  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.  In IKE, the nonce payload also provides  proof
   of  freshness  of  the  exchange,  but  this functionality is already
   provided by Kerberos' use of timestamps for liveliness.  A  receiving
   KINK  peer  MUST  NOT  use the nonce payload as the primary freshness
   indicator, though it MAY use it as an additional check.












Thomas et. al.                                                 [Page 25]


INTERNET DRAFT                    KINK                         July 2001



7.1.5.  Notify Payloads


   Notification 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



7.1.6.  PFS Support


   IKE requires that perfect forward secrecy be supported through the
   use of the KE payload.  However, Kerberos in general does not provide
   PFS so it is somewhat questionable whether a system which is heavily



Thomas et. al.                                                 [Page 26]


INTERNET DRAFT                    KINK                         July 2001


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



7.2.  IPsec DOI Message Formats


7.2.1.  CREATE

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

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

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

   REPLY
     KINK Header
     KINK_AP_REP payload
     [KINK_ENCRYPT]
       KINK_ISAKMP payload
            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  absense  means  that  the
   optimistic  mode SA's installed by the initiator are valid. If any of
   the first proposals are not chosen by the recipient, it MUST  include
   the  nonce  payload as well to indicate that the initiator's outgoing
   SA's must be modified.




Thomas et. al.                                                 [Page 27]


INTERNET DRAFT                    KINK                         July 2001


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

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


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

   REPLY
     KINK Header
     KINK_KRB_ERROR|KINK_ERROR payload


7.2.2.  DELETE


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

   DELETE contains the following payloads:
     KINK Header
     KINK_AP_REQ payload
     [KINK_ENCRYPT]
       [ KINK_ERROR payload ]
       KINK_ISAKMP payload
           Delete Payload[s]
           [Notification Payloads]


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

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










Thomas et. al.                                                 [Page 28]


INTERNET DRAFT                    KINK                         July 2001



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

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

   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
     KRB_ERROR | KINK_KRB_ERROR payload


7.2.3.  STATUS


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

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


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

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

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

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




Thomas et. al.                                                 [Page 29]


INTERNET DRAFT                    KINK                         July 2001



   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
     KRB_ERROR | KINK_KRB_ERROR payload


8.  Key Derivation

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

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

   The following differences apply:

   o  SKEYID_d is the 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.



9.  Transport Considerations

   KINK uses UDP on port XXX to transport its messages. There is one
   timer T which SHOULD take into consideration round trip considera-
   tions and MUST implement a truncated exponential backoff mechanism.
   The state machines 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.

   Note that in KINK delivery of a final ACK is not reliable. A KINK
   implementation that asks for a final ACK MUST be prepared for the ACK
   not being delivered. Two mechanisms are possible to work around the
   need for a final ACK:


   1)   A timer of the average round trip time between the two KINK
        peers times some comfort margin can be started. If the ACK is
        not received within that time period, the requestor can assume
        that either its response was lost by the initiator, or that the
        ACK was lost.  In the first case, the initiator will usually
        retransmit the initial request within the timeout period. In the
        second case, the final cleanup should be performed as if the
        initiator sent the ACK.




Thomas et. al.                                                 [Page 30]


INTERNET DRAFT                    KINK                         July 2001


   2)   If reliability is required, the respondent could initiate a
        security association in the opposite direction with the same
        characteristics. This has the downside of instantiating two
        security associations simultaneously and is not recommended.


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 only uses IKE Phase II payload
   to create and delete security association, the security considera-
   tions which pertain to IKE Phase I can be safely ignored.

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

   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.



11.  IANA Considerations

   KINK requires that a new well known port 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].



12.  Protocol Considerations




12.1.  Security Policy Database Considerations

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



Thomas et. al.                                                 [Page 31]


INTERNET DRAFT                    KINK                         July 2001


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

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

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



13.  Related Work

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

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

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

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







Thomas et. al.                                                 [Page 32]


INTERNET DRAFT                    KINK                         July 2001


14.  References


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


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


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


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


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


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


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





15.  Mailing List

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




Thomas et. al.                                                 [Page 33]


INTERNET DRAFT                    KINK                         July 2001


16.  Author's Addresses

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

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

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





17.  Acknowledgements

   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. The inspiration for wholly reusing IKE
   Phase II is the result of the Tero Kivinen's initial draft suggesting
   the obvious.




















Thomas et. al.                                                 [Page 34]


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