CVS shishi/doc/specifications

[shishi-commit]

Update of /home/cvs/shishi/doc/specifications
In directory dopio:/tmp/cvs-serv8058

Added Files:
        draft-ietf-kink-kink-10.txt 
Log Message:
Add.


--- /home/cvs/shishi/doc/specifications/draft-ietf-kink-kink-10.txt     
2005/10/11 15:35:44     NONE
+++ /home/cvs/shishi/doc/specifications/draft-ietf-kink-kink-10.txt     
2005/10/11 15:35:44     1.1






INTERNET-DRAFT                                            Shoichi Sakane
KINK Working Group                                       Ken'ichi Kamada
Expires: April 10, 2006                          Yokogawa Electric Corp.
                                                          Michael Thomas
                                                            Jan Vilhuber
                                                           Cisco Systems
                                                         October 7, 2005


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




Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at
   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

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

   Distribution of this memo is unlimited.

   This Internet-Draft expires in April 10, 2006.




Sakane, Kamada, Thomas, and Vilhuber                            [Page 1]

Internet-Draft                    KINK                      October 2005


Copyright Notice

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


Abstract

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


Conventions used in this document

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

   It is assumed that the readers are familiar with the terms and
   concepts described in Kerberos Version 5 [KERBEROS], IPsec [IPSEC],
   and IKE [IKE].


























Sakane, Kamada, Thomas, and Vilhuber                            [Page 2]

Internet-Draft                    KINK                      October 2005


Table of Contents

    1. Introduction .................................................  5
    2. Protocol Overview ............................................  5
    3. Message Flows ................................................  6
       3.1. GETTGT Message Flow .....................................  7
       3.2. CREATE Message Flow .....................................  7
            3.2.1. CREATE Key Derivation Considerations .............  9
       3.3. DELETE Message Flow .....................................  9
       3.4. STATUS Message Flow ..................................... 10
       3.5. Reporting Errors ........................................ 11
       3.6. Rekeying Security Associations .......................... 11
       3.7. Dead Peer Detection ..................................... 12
            3.7.1. Coping with Dead User-to-User Peers .............. 14
    4. KINK Message Format .......................................... 14
       4.1. KINK Alignment Rules .................................... 17
       4.2. KINK Payloads ........................................... 17
            4.2.1. KINK_AP_REQ Payload .............................. 18
            4.2.2. KINK_AP_REP Payload .............................. 20
            4.2.3. KINK_KRB_ERROR Payload ........................... 20
            4.2.4. KINK_TGT_REQ Payload ............................. 21
            4.2.5. KINK_TGT_REP Payload ............................. 22
            4.2.6. KINK_ISAKMP Payload .............................. 23
            4.2.7. KINK_ENCRYPT Payload ............................. 24
            4.2.8. KINK_ERROR Payload ............................... 25
    5. Differences from IKE Quick Mode .............................. 26
       5.1. Security Association Payloads ........................... 27
       5.2. Proposal and Transform Payloads ......................... 28
       5.3. Identification Payloads ................................. 28
       5.4. Nonce Payloads .......................................... 28
       5.5. Notify Payloads ......................................... 28
       5.6. Delete Payloads ......................................... 29
       5.7. KE Payloads ............................................. 30
    6. Message Construction and Constraints for IPsec DOI ........... 30
       6.1. REPLY Message ........................................... 30
       6.2. ACK Message ............................................. 30
       6.3. CREATE Message .......................................... 30
       6.4. DELETE Message .......................................... 32
       6.5. STATUS Message .......................................... 33
       6.6. GETTGT Message .......................................... 34
    7. ISAKMP Key Derivation ........................................ 34
    8. Key Usage Numbers for Kerberos Key Derivation ................ 35
    9. Transport Considerations ..................................... 35
   10. Implementation Hints ......................................... 36
   11. Security Considerations ...................................... 36
   12. IANA Considerations .......................................... 37
   13. Forward Compatibility Considerations ......................... 38
       13.1. New Versions of Quick Mode ............................. 38



Sakane, Kamada, Thomas, and Vilhuber                            [Page 3]

Internet-Draft                    KINK                      October 2005


       13.2. New DOI ................................................ 38
   14. Related Work ................................................. 39
   15. Acknowledgments .............................................. 39
   16. References ................................................... 39
       16.1. Normative References ................................... 39
       16.2. Informative References ................................. 40
   Authors' Addresses ............................................... 40
   Change History (To be removed from RFC) .......................... 41
   Full Copyright Statement ......................................... 41
   Intellectual Property Statement .................................. 42









































Sakane, Kamada, Thomas, and Vilhuber                            [Page 4]

Internet-Draft                    KINK                      October 2005


1.  Introduction

   KINK is designed to provide a secure, scalable mechanism for
   establishing keys between communicating entities within a centrally
   managed environment in which it is important to maintain consistent
   security policy.  The security goals of KINK are to provide privacy,
   authentication, and replay protection of key management messages, and
   to avoid denial of service vulnerabilities whenever possible.  The
   performance goals of the protocol are to have a low computational
   cost, low latency, and a small footprint.  It is also to avoid or
   minimize the use of public key operations.  In particular, the
   protocol provides the capability to establish IPsec security
   associations (SA) in two messages with minimal computational effort.
   These requirements are described in RFC 3129 [REQ4KINK].

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

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


2.  Protocol Overview

   KINK is a command/response protocol which can create, delete, and
   maintain IPsec SAs.  Each command or response contains a common
   header along with a set of type-length-value payloads.  The type of a



Sakane, Kamada, Thomas, and Vilhuber                            [Page 5]

Internet-Draft                    KINK                      October 2005


   command or a response constrains the payloads sent in the messages of
   the exchange.  KINK itself is a stateless protocol in that each
   command or response does not require storage of hard state for KINK.
   This is in contrast to IKE, which uses Main Mode to first establish
   an ISAKMP SA followed by subsequent Quick Mode exchanges.

   KINK uses Kerberos mechanisms to provide mutual authentication and
   replay protection.  For establishing SAs, KINK provides
   confidentiality for the payloads which follow the Kerberos AP-REQ
   payload.  The design of KINK mitigates denial of service attacks by
   requiring authenticated exchanges before the use of any public key
   operations and the installation of any state.  KINK also provides a
   means of using Kerberos User-to-User mechanisms when there is not a
   key shared between the server and the KDC.  This is typically, but
   not limited to, the case with IPsec peers using PKINIT for initial
   authentication.

   KINK directly reuses Quick Mode payloads defined in section 5.5 of
   [IKE], with some minor changes and omissions.  In most cases, KINK
   exchanges are a single command and its response.  An optional third
   message is required when creating SAs, only if the responder rejects
   the first proposal from the initiator or wants to contribute the
   keying materials.  KINK also provides rekeying and dead peer
   detection.


3.  Message Flows

   All KINK message flows follow the same pattern between the two peers:
   a command, a response, and an optional acknowledgment in a CREATE
   flow.  A command is a GETTGT, CREATE, DELETE, or STATUS message, a
   response is a REPLY message, and an acknowledgment is an ACK message.

   KINK uses Kerberos as the authentication mechanism, therefore a KINK
   host needs to get a service ticket for each peer before actual key
   negotiations.  This is basically a pure Kerberos exchange and the
   actual 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.  As an exception, the GETTGT
   message flow of KINK (described in section 3.1) is used when a User-
   to-User authentication is required.  In this flow, we assume that
   both A and B have TGTs from their KDCs.

   After a service ticket is obtained, KINK uses the CREATE message flow
   (section 3.2), DELETE message flow (section 3.3), and STATUS message
   flow (section 3.4) to manage SAs.  In these flows, we assume that A
   has a service ticket for B.




Sakane, Kamada, Thomas, and Vilhuber                            [Page 6]

Internet-Draft                    KINK                      October 2005


3.1.  GETTGT Message Flow

   This flow is used to retrieve a TGT from the remote peer in User-to-
   User authentication mode.

   If the initiator determines that it will not be able to get a normal
   (non-User-to-User) service ticket for the responder, it can try a
   User-to-User authentcation.  In this case, it first fetches a TGT
   from the responder in order to get a User-to-User service ticket:

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

    2  <-------REPLY+KINK_TGT_REP

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

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

            Figure 1: GETTGT Message Flow

   The initiator MAY support the following events as triggers to go to
   the User-to-User path.  Note that the two errors described below will
   not be authenticated, and how to act on them depends on the policy.

   o  The local policy says that the responder requires a User-to-User
      authentication.

   o  A KRB_AP_ERR_USER_TO_USER_REQUIRED error is returned from the
      responder.

   o  A KDC_ERR_MUST_USE_USER2USER error is returned from the KDC.


3.2.  CREATE Message Flow

   This flow creates SAs.  The CREATE command takes an "optimistic"
   approach, where SAs are initially created on the expectation that the
   responder will choose the initial proposed payload.  The optimistic
   proposal is placed in the first transform payload(s) of the first
   proposal.  The initiator MUST check to see if the optimistic proposal
   was selected by comparing all transforms and attributes which MUST be
   identical from those in the initiator's optimistic proposal with the
   exceptions of LIFE_KILOBYTES and LIFE_SECONDS.  Each of these
   attributes MAY be set to a lower value by the responder and still
   expect optimistic keying, but MUST NOT be set to a higher value which
   MUST generate a NO-PROPOSAL-CHOSEN error.  The initiator MUST use the



Sakane, Kamada, Thomas, and Vilhuber                            [Page 7]

Internet-Draft                    KINK                      October 2005


   shorter lifetime.


[1955 lines skipped]