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

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

INTERNET-DRAFT      KINK                                       M. Froh
                                                             Cybersafe
                                                                M. Hur
                                                             Cybersafe
                                                             D. McGrew
                                                                 Cisco
                                                          S. Medvinsky
                                                              Motorola
                                                             M. Thomas
                                                                 Cisco
                                                           J. Vilhuber
                                                                 Cisco
                                                        September 2000



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


Status of this Memo

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

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

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

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

Action Items:

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

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

   Better discussion of error scenarios

Copyright Notice

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

Abstract

   The KINK Working Group will create a standards track protocol to



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


INTERNET DRAFT                    KINK                    September 2000


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

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

Conventions used in this document

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

1 Introduction

   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 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
   messages with minimal computational effort.

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

   The central key management provided by Kerberos is efficient, because
   it limits computational cost and limits complexity. Initial
   authentication to the KDC may be performed using either symmetric or
   asymmetric keys [PKINIT]; however, subsequent requests for tickets
   utilize symmetric cryptography, which is much more efficient than
   public key cryptography.  Therefore, public key operations are
   limited and are amortized over the lifetime of the Kerberos tickets.
   For example, a server may use a single public key exchange with the
   KDC to efficiently establish multiple security associations with
   other servers. Since Kerberos principal keys (used for initial
   asymmetric authentication) are stored in the KDC, the number of



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


INTERNET DRAFT                    KINK                    September 2000


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

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

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

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

2 Terminology

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

   Key Distribution Center (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
     is referred to as the Authentication Server (or service). The
     Ticket-Granting Ticket portion is referred to as the Ticket-
     Granting Server (or service).

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



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


INTERNET DRAFT                    KINK                    September 2000


     for one or more realms.  A fully qualified principal name includes
     a realm name along with a principal name unique within that realm.

3 Protocol Overview

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

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

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

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

   Since the KDC does not possess a symmetric key PKINIT principals KINK
   defines an unauthenticated request for getting a peer's ticket
   granting 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

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



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


INTERNET DRAFT                    KINK                    September 2000


   specifications may be used to apply KINK to other security protocols.



4 Message Flows

   KINK message flows all follow the same pattern between the two peers:
   a command, a response and an optional acknowledgement. The actual
   Kerberos KDC traffic here is for illustrative purposes only. In
   practice, 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


       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 directly  get
   a service ticket for the respondent (ie, B is a PKINIT principal), it
   must fetch the TGT from the respondent first in order to get a  User-
   User service ticket:


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

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

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

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

            Figure 2: GETTGT Message Flow












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


INTERNET DRAFT                    KINK                    September 2000


4.3 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

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

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

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

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

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

      [ B creates the outbound SA to 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
   B->A with the first proposal in the ISAKMP proposal. It is then ready
   to receive any messages from B. A then sends the CREATE message to B.
   B instantiates a security association in its database from A->B. If
   it agreed to A's initial proposal sends a REPLY to A without
   requesting an ACK and also instantiates the security association from
   B->A. If B does not choose the first proposal, it sends the actual
   choice in the REPLY and requests that the REPLY be acknowledged. Upon
   receipt of the REPLY, A modifies the inbound security association as
   necessary, instantiates the security association from A->B, If B
   requested an ACK, A now sends the ACK message. Upon receipt of the
   ACK, B installs the final security association from B->A.

4.3.1 CREATE Key Derivation Considerations

   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



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


INTERNET DRAFT                    KINK                    September 2000


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


4.4 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
   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.  The respondent MUST
   NOT delete its incoming SA until it either receives the final ACK, or
   the transaction 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 two times the average round
   trip time, or to a configurable value. A KINK implementation MAY
   chose to set the grace period to zero at appropriate times to
   ungracefully delete a security association. The behavior described
   here loosely mimics the behavior of the TCP [RFC793] flags FIN and
   RST.






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


INTERNET DRAFT                    KINK                    September 2000


4.4.1 Rekeying Security Associations

   KINK requires the initiator of a security association to be
   responsible for rekeying a security association. The reason is
   twofold: we would like to prevent needless duplication of security
   associations as the result of collisions due to an initiator and
   respondent 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 be able to get and maintain tickets,
   in practice it probably advantageous for servers to wait for clients
   to initiate sessions so that they do not need maintain a large ticket
   cache.

   There are no special semantics for rekeying security associations in
   KINK. That is, in order to rekey an existing security association,
   the initiator must CREATE a new security association followed by
   either DETETE'ing 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.


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   |    Flags      |      NextPayload              |
    +---------------+---------------+-------------------------------+
    |                                                               |
    ~                           Cksum                               ~
    |                                                               |
    +-------------------------------+-------------------------------+
    |                                                               |
    ~            A series of payloads                               ~
    |                                                               |
    +-------------------------------+-------------------------------+

                     Figure 5:  Format of a KINK message

   Fields:

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




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


INTERNET DRAFT                    KINK                    September 2000


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

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

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

   o  Length (16 bits) - Length of the message in octets

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

   o  Flags (8 bits)

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

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

   o  Cksum (variable) - Keyed checksum (HMAC) over the entire message.
      This field MUST always be present whenever a key is available.
      When a key is not available, this field is not present, and the
      CksumLen field is set to zero. The hash algorithm used is the same



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


INTERNET DRAFT                    KINK                    September 2000


      as specified in the etype for the Kerberos session key in the Ker-
      beros ticket.  If the etype does not specify a hash algorithm, the
      SHA1 MUST be used.  The format of the Cksum field MUST mimic the
      Kerberos checksum structure (without the ASN.1 encoding) as fol-
      lows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +---------------+---------------+---------------+---------------+
      |       Kerberos cksumtype      |     checksum (variable)       |
      +---------------+---------------+---------------+---------------+

                     Figure 6: KINK Checksum

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


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

      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
       KRB_AP_REQ       1
       KRB_AP_REP       2
       KRB_ERROR        3
       KRB_TGT_REQ      4
       KRB_TGT_REP      5
       ISAKMP_PAYLOAD   6
       KINK_ENCRYPT     7
       KINK_ERROR       8




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


INTERNET DRAFT                    KINK                    September 2000


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

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

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

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

5.1.1 KRB_AP_REQ Payload

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

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

                      Figure 8:  KRB_AP_REQ Payload

5.1.2 KRB_AP_REP Payload

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

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

                      Figure 9:  KRB_AP_REP Payload
















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


INTERNET DRAFT                    KINK                    September 2000


5.1.3 KRB_ERROR Payload

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

     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 10:  KRB_ERROR Payload

5.1.4 KRB_TGT_REQ 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        |
    +---------------+---------------+---------------+---------------+
    |        RealmNameLen           |   RealmName (variable)        ~
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                      RealmName(variable)                      ~
    |                                                               |
    +---------------------------------------------------------------+

                      Figure 11:  KRB_TGT_REQ Payload

   Fields:

o  PrincipalNameLen - The length of the realm name that follows

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


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













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


INTERNET DRAFT                    KINK                    September 2000


5.1.5 KRB_TGT_REP Payload



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

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    | Next Payload  |   RESERVED    |         Payload Length        |
    +---------------+---------------+---------------+---------------+
    |        RealmNameLen           |       RealmName (variable)    ~
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                       RealmName(variable)                     ~
    |                                                               |
    +---------------------------------------------------------------+
    |                                                               |
    ~                        TGT                                    ~
    |                                                               |
    +---------------------------------------------------------------+

                      Figure 12:  KRB_TGT_REQ Payload

   Fields:

o  RealmNameLen - The length of the realm name that follows

o  RealmName - The realm that the initiator requested a TGT for.

o  TGT - the DER encoded TGT of the responder


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

                      Figure 13:  ISAKMP_PAYLOAD Payload

   Fields:

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



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


INTERNET DRAFT                    KINK                    September 2000


   ISAKMP payloads.


5.1.7 KINK_ENCRYPT


   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.

     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.


5.1.8 KINK_ERROR



   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



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


INTERNET DRAFT                    KINK                    September 2000


    RESERVED         5 - 8191
    Private Use     8192 - 16383

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

6 KINK Messages


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

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

6.3 DELETE


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

6.4 REPLY

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



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


INTERNET DRAFT                    KINK                    September 2000


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

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

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


6.5 ACK


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

   ACK
     KINK Header
     [KRB_AP_REQ]
     [KINK_ERROR]
     [KRB_ERROR]


7 IPSEC DOI-specific Payload Formats

   These payloads follow the conventions and values established by
   [ISAKMP]. In other words, each payload has a generic, well-
   established header. Only certain payloads will be reused from
   [ISAKMP], however. The rest of ISAKMP will not be used, since Ker-
   beros provides the equivalent functionality.

   Only the payloads listed in this document will be valid for KINK.








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


INTERNET DRAFT                    KINK                    September 2000


7.1 Security Association Payload

   When using the IP Domain of Interpretation, the protocol, transform
   identifiers, and Security association Identifiers from section 4.4 in
   [IPDOI] MUST be used.


7.1.1 Security Association Payload Format

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

   Given this restriction, the Security Association Payload  looks  like
   this:

     0                    1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    !  Next Payload !   RESERVED    !        Payload Length         !
    +---------------+---------------+---------------+---------------+
    !                Domain of Interpretation (IPSec)               |
    +---------------+---------------+---------------+---------------+
    !                       Situation                               !
    +---------------+---------------+---------------+---------------+
    !                                                               !
    ~                     List of Proposal Payloads                 ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 16: Security Association Payload Format
























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


INTERNET DRAFT                    KINK                    September 2000


7.1.2 Proposal Payload Format

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

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

                Figure 17: Proposal Payload Format

7.1.3 Transform Payload Format

          0              1                 2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +---------------+---------------+---------------+---------------+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +---------------+---------------+---------------+---------------+
    !  Transform #  !  Transform-Id !           RESERVED2           !
    +---------------+---------------+---------------+---------------+
    !                                                               !
    ~                     List of SA Attributes                     ~
    !                                                               !
    +---------------+---------------+---------------+---------------+

                Figure 18: Transform Payload Format



















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


INTERNET DRAFT                    KINK                    September 2000


7.1.4 Security Association Attributes


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

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

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

7.2 Identification Payloads

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

           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         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   ID Type     !             DOI Specific ID Data              !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                     Identification Data                       ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 19: Identification Payload Format

The Identification Payload fields are defined as follows:


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

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

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

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

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




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


INTERNET DRAFT                    KINK                    September 2000


    or IP DOI, this field has the following format:

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

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

   Valid ID-types for KINK are:

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

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


7.3 Nonce Payloads

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

          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        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                            Nonce Data                         ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 20: Nonce Payload Format

The Nonce Payload fields are defined as follows:


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

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




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


INTERNET DRAFT                    KINK                    September 2000


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

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


7.4 Delete Payloads

          0              1                 2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !              Domain of Interpretation  (DOI)                  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Protocol-Id  !   SPI Size    !           # of SPIs           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~               Security Parameter Index(es) (SPI)              ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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





























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


INTERNET DRAFT                    KINK                    September 2000


7.4 Notify Payloads


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

          0              1                 2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Next Payload  !   RESERVED    !         Payload Length        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !              Domain of Interpretation  (DOI)                  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Protocol-ID  !   SPI Size    !      Notify Message Type      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                Security Parameter Index (SPI)                 ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                                                               !
    ~                       Notification Data                       ~
    !                                                               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 22:  Notification Payload Format

The Notification Payload fields are defined as follows:

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

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

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

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

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

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



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


INTERNET DRAFT                    KINK                    September 2000


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

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

o  SPI (variable length) - Security Parameter Index.  The receiving
   entity's SPI. The use of the SPI field is described in section 2.4 of
   [ISAKMP].  The length of this field is determined by the SPI Size
   field and is not necessarily aligned to a 4 octet boundary.

o  Notification Data (variable length) - Informational or error data
   transmitted in addition to the Notify Message Type.  Values for this
   field are DOI-specific.

   The following Notify Types are taken directly from [ISAKMP] with
   unsupported values removed.

                      NOTIFY MESSAGES - ERROR TYPES

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

                      NOTIFY MESSAGES - STATUS TYPES

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



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


INTERNET DRAFT                    KINK                    September 2000


                 Private Use            32768 - 40959
                 RESERVED (Future Use)  40960 - 65535




8 IPsec DOI Message Formats

   8.1 CREATE

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

   CREATE contains the following payloads:
     KINK Header
     KRB_AP_REQ payload
     [KINK_ENCRYPT]
       ISAKMP_PAYLOAD payload
            SA Payload
                 Proposal Payloads
                         Transform Payloads
            Nonce Payload
            [ ID Payloads ]
   Replies are of the following forms:

   REPLY
     KINK Header
     KRB_AP_REP payload
     [KINK_ENCRYPT]
       ISAKMP_PAYLOAD payload
            SA Payload
                   Proposal Payload
                           Transform Payload
            [ Nonce Payload ]
            [ ID Payload ] Note that there MUST  be  a  single  proposal
   payload and a single transform payload in REPLY messages.
   If an IPspec DOI specific error is encountered, the  respondent  must
   reply with a Notify payload describing the error:

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










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


INTERNET DRAFT                    KINK                    September 2000


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

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

8.2 DELETE


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

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

There are three forms of replies for a DELETE

The normal form is:

REPLY
  KINK Header
  KRB_AP_REP | KRB_ERROR payload
  [KINK_ENCRYPT]
    [ KINK_ERROR payload ]
    ISAKMP_PAYLOAD payload
          Delete Payload
If an IPspec DOI specific error  is  encountered,  the  respondent  must
reply with a Notify payload describing the error:

REPLY
  KINK Header
  KRB_AP_REP payload
  [ KINK_ENCRYPT payload ]
    [ KINK_ERROR payload ]
    ISAKMP_PAYLOAD payload
          Notify payload
If the respondent finds an Kerberos type of error it MUST reply  with  a
lone KRB_ERROR payload:

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






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


INTERNET DRAFT                    KINK                    September 2000


9 Key Derivation

   During the establishment of SAs the initiator and responder each pro-
   vide random nonces that add entropy to the KDC supplied session key
   in order to derive the SA keying material (KEYMAT).

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

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

   The initator MUST add entropy in the form of a random nonce to the
   ticket session key when it instantiates the optimistic security asso-
   ciation.  The HMAC 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 SHA1 MUST be used. The
   results are placed in the subkey field of the AP-REQ.  The number of
   subkey bits MUST be large enough to generate keying material for the
   largest encryption and integrity algorithms proposed.

   Bits for the security association keys are taken from the generated
   key in network order starting with the key for the initiator's
   inbound security association with the integrity algorithm key first
   followed by the encryption algorithm, and repeated for for the
   initiator's outbound security association. There is no implied pad-
   ding between the encryption and integrity keying material.

   The respondent MAY choose to add more entropy to the key, but if it
   does, it SHOULD request an ACK message before it sends data on the
   newly created security association. It MUST place the concatenation
   of the two nonces it choses in the subkey field of the AP-REP. The
   nonce sizes MUST be the same size that the initiator chose. Upon
   receipt of the AP-REP, the initiator MUST compare the second nonce to
   determine if the respondent added entropy to the keying material. If
   it has, the initiator MUST modify the keys for the initial security
   association using the rules described above.
   The following flow illustrates the derivation of keys:

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

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

                Figure 23: Key Derivation

   K0 is used to instantiate the optimistic incoming security associa-
   tion from B->A. K1 is always the key that is used for the security



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


INTERNET DRAFT                    KINK                    September 2000


   association between A->B. The value of the subkey in the AP-REQ is
   always Nonce1. The value of the subkey in the AP-REP is the concate-
   nation of Nonce2 and Nonce3 where Nonce3 is equal to zero if B does
   not desire to add entropy to the optimistic security association B-
   >A.



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


11 Security Considerations



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

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

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






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


INTERNET DRAFT                    KINK                    September 2000


13 Related Work

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

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

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

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



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.  September 1994.


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


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




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


INTERNET DRAFT                    KINK                    September 2000


[RFC2401]
   S. Kent, R. Atkinson.  Security Architecture for the Internet Proto-
   col.  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.


16 Author's Addresses

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

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

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




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


INTERNET DRAFT                    KINK                    September 2000


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



17 Expiration


   This memo is filed as <draft-ietf-kink-kink-00.txt>, and expires
   February, 2001.











































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


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