返回首页

RFC 4430 - Kerberized Internet Negotiation of Keys (KINK)

时间:2006-11-02 来源: 作者: 点击:
NetworkWorkingGroup S.Sakane RequestforComments:4430 K.Kamada Category:StandardsTrackYokogawaElectricCorp. M.Thomas J.Vilhuber CiscoSystems March2006 KerberizedInternetNegotiationofKeys(KINK) StatusofThisMemo ThisdocumentspecifiesanInternetstandardst
  Network Working Group                                              S. Sakane
Request for Comments: 4430                                       K. Kamada
Category: Standards Track                        Yokogawa Electric Corp.
                                                                                   M. Thomas
                                                                                   J. Vilhuber
                                                                              Cisco Systems
                                                                                 March 2006
 
             Kerberized Internet Negotiation of Keys (KINK)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Protocol Overview ...............................................4
   3. Message Flows ...................................................4
      3.1. GETTGT Message Flow ........................................5
      3.2. CREATE Message Flow ........................................6
           3.2.1. CREATE Key Derivation Considerations ................7
      3.3. DELETE Message Flow ........................................8
      3.4. STATUS Message Flow ........................................9
      3.5. Reporting Errors ...........................................9
      3.6. Rekeying Security Associations ............................10
      3.7. Dead Peer Detection .......................................10
           3.7.1. Coping with Dead User-to-User Peers ................12

   4. KINK Message Format ............................................13
      4.1. KINK Alignment Rules ......................................15
      4.2. KINK Payloads .............................................16
           4.2.1. KINK_AP_REQ Payload ................................17
           4.2.2. KINK_AP_REP Payload ................................18
           4.2.3. KINK_KRB_ERROR Payload .............................19
           4.2.4. KINK_TGT_REQ Payload ...............................20
           4.2.5. KINK_TGT_REP Payload ...............................21
           4.2.6. KINK_ISAKMP Payload ................................21
           4.2.7. KINK_ENCRYPT Payload ...............................22
           4.2.8. KINK_ERROR Payload .................................23
   5. Differences from IKE Quick Mode ................................25
      5.1. Security Association Payloads .............................26
      5.2. Proposal and Transform Payloads ...........................26
      5.3. Identification Payloads ...................................26
      5.4. Nonce Payloads ............................................26
      5.5. Notify Payloads ...........................................27
      5.6. Delete Payloads ...........................................28
      5.7. KE Payloads ...............................................28
   6. Message Construction and Constraints for IPsec DOI .............28
      6.1. REPLY Message .............................................28
      6.2. ACK Message ...............................................28
      6.3. CREATE Message ............................................29
      6.4. DELETE Message ............................................30
      6.5. STATUS Message ............................................31
      6.6. GETTGT Message ............................................32
   7. ISAKMP Key Derivation ..........................................32
   8. Key Usage Numbers for Kerberos Key Derivation ..................33
   9. Transport Considerations .......................................33
   10. Security Considerations .......................................34
   11. IANA Considerations ...........................................35
   12. Forward Compatibility Considerations ..........................35
      12.1. New Versions of Quick Mode ...............................36
      12.2. New DOI ..................................................36
   13. Related Work ..................................................36
   14. Acknowledgements ..............................................37
   15. References ....................................................37
      15.1. Normative References .....................................37
      15.2. Informative References ...................................38

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 (SAs) 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
   necessity of using public key cryptography [IKE].  Initial
   authentication to the KDC may be performed using either symmetric
   keys, or asymmetric keys using the Public Key Cryptography for
   Initial Authentication in Kerberos [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.

1.1.  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 [RFC2119].

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

2.  Protocol Overview

   KINK is a command/response protocol that 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
   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 Internet Security Association and Key Management Protocol (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 that 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 acknowledgement in a CREATE
   flow.  A command is a GETTGT, CREATE, DELETE, or STATUS message; a
   response is a REPLY message; and an acknowledgement 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 ticket-granting tickets (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.

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 authentication.  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 to 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 that
   MUST generate a NO-PROPOSAL-CHOSEN error.  The initiator MUST use the
   shorter lifetime.

   When a CREATE command contains an existing Security Parameter Index
   (SPI), the responder MUST reject it and SHOULD return an ISAKMP
   notification with INVALID-SPI.

   When a key exchange (KE) payload is sent from the initiator but the
   responder does not support it, the responder MUST reject it with an
   ISAKMP notification of INVALID-PAYLOAD-TYPE containing a KE payload
   type as its notification data.  When the initiator receives this
   error, it MAY retry without a KE payload (as another transaction) if
   its policy allows that.

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

       A creates an optimistic inbound SA (B->A) unless using a KE.

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

       B creates an inbound SA (A->B).
       B creates an outbound SA (B->A) if optimistic and not using a KE.

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

       A creates an outbound SA (A->B).
       A replaces an inbound SA (B->A) if non-optimistic.
       A creates an inbound SA (B->A) if using a KE.

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

      [ B creates an outbound SA (B->A).                     ]

                       Figure 2: CREATE Message Flow

   Creating SAs has two modes:  2-way handshake and 3-way handshake.
   The initiator usually begins a negotiation expecting a 2-way
   handshake.  When the optimistic proposal is not chosen by the
   responder, the negotiation is switched to a 3-way handshake.  When
   and only when the initiator uses a KE payload, 3-way handshake is
   expected from the beginning.

   A 2-way handshake is performed in the following steps:

      1) The host A creates an inbound SA (B->A) in its SA database
         using the optimistic proposal in the ISAKMP SA proposal.  It is
         then ready to receive any messages from B.
      2) A then sends the CREATE message to B.
      3) If B agrees to A’s optimistic proposal, B creates an inbound SA
         (A->B) and an outbound SA (B->A) in its database.  If B does
         not choose the first proposal or wants to add a Nonce payload,
         switch to step 3 of the 3-way handshake described below.
      4) B then sends a REPLY to A without a Nonce payload and without
         requesting an ACK.
      5) Upon receipt of the REPLY, A creates an outbound SA (A->B).

   A 3-way handshake is performed in the following steps:

      1) The host A sends the CREATE message to B without creating any
         SA.
      2) B chooses one proposal according to its policy.
      3) B creates an inbound SA (A->B) and sends the actual choice in
         the REPLY.  It SHOULD send the optional Nonce payload (as it
         does not increase message count and generally increases entropy
         sources) and MUST request that the REPLY be acknowledged.
      4) Upon receipt of the REPLY, A creates the inbound SA (B->A) (or
         modifies it as necessary, if switched from 2-way), and the
         outbound SA (A->B).
      5) A now sends the ACK message.
      6) Upon receipt of the ACK, B installs the final outbound SA
         (B->A).

   If B does not choose the first proposal, adds a nonce, or accepts the
   KE exchange, then it MUST request an ACK (i.e., set the ACKREQ bit)
   so that it can install the final outbound SA.  The initiator MUST
   always generate an ACK if the ACKREQ bit is set in the KINK header,
   even if it believes that the responder was in error.

3.2.1.  CREATE Key Derivation Considerations

   The CREATE command’s optimistic approach allows an SA 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 SA before it receives any additional keying material from
   B.  This may be suspect under normal circumstances; 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
   acknowledgement.  Since B is always at liberty to contribute to the
   keying material, this is strictly a trade-off between the key
   strength versus the number of messages, which KINK implementations
   may decide as a matter of policy.

3.3.  DELETE Message Flow

   The DELETE command deletes existing SAs.  The domain of
   interpretation (DOI)-specific payloads describe the actual SA to be
   deleted.  For the IPsec DOI, those payloads will include an ISAKMP
   payload containing the list of the SPIs to be deleted.

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

       A deletes outbound SA to B.

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

       B deletes inbound and outbound SA to A.

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

       A deletes inbound SA to B.

                       Figure 3: DELETE Message Flow

   The DELETE command takes a "pessimistic" approach, which does not
   delete inbound SAs until it receives acknowledgement 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 inbound SA.  In this case, it MAY delete the inbound SA as well
   in step 1, above.

   The ISAKMP payload contains ISAKMP Delete payload(s) that indicate
   the inbound SA(s) for the initiator of this flow.  KINK does not
   allow half-open SAs; thus, when the responder receives a DELETE
   command, it MUST delete SAs of both directions, and MUST reply with
   ISAKMP Delete payload(s) that indicate the inbound SA(s) for the
   responder of this flow.  If the responder cannot find an appropriate
   SPI to be deleted, it MUST return an ISAKMP notification with
   INVALID_SPI, which also serves to inform the initiator that it can
   delete the inbound SA.

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

3.4.  STATUS Message Flow

   This flow is used to send any information to a peer or to elicit any
   information from a peer.  An initiator may send a STATUS command to
   the responder at any time, optionally with DOI-specific ISAKMP
   payloads.  In the case of the IPsec DOI, these are generally in the
   form of ISAKMP Notification payloads.  A STATUS command is also used
   as a means of dead peer detection described in section 3.7.

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

    1  STATUS[+ISAKMP]---------->

    2  <-----------REPLY[+ISAKMP]

                       Figure 4: STATUS Message Flow

3.5.  Reporting Errors

   When the responder detects an error in a received command, it can
   send a DOI-specific payload to indicate the error in a REPLY message.
   There are three types of payloads that can indicate errors:
   KINK_KRB_ERROR payloads for Kerberos errors, KINK_ERROR payloads for
   KINK errors, and KINK_ISAKMP payloads for ISAKMP errors.  Details are
   described in sections 4.2.3, 4.2.8, and 4.2.6, respectively.

   If the initiator detects an error in a received reply, there is no
   means to report it back to the responder.  The initiator SHOULD log
   the event and MAY take a remedial action by reinitiating the initial
   command.

   If the server clock and the client clock are off by more than the
   policy-determined clock skew limit (usually 5 minutes), the server
   MUST return a KRB_AP_ERR_SKEW.  The optional client’s time in the
   KRB-ERROR SHOULD be filled out.  If the server protects the error by
   adding the Cksum field and returning the correct client’s time, the

   client SHOULD compute the difference (in seconds) between the two
   clocks based upon the client and server time contained in the
   KRB-ERROR message.  The client SHOULD store this clock difference and
   use it to adjust its clock in subsequent messages.  If the error is
   not protected, the client MUST NOT use the difference to adjust
   subsequent messages, because doing so would allow an attacker to
   construct authenticators that can be used to mount replay attacks.

3.6.  Rekeying Security Associations

   KINK expects the initiator of an SA to be responsible for rekeying
   the SA for two reasons.  The first reason is to prevent needless
   duplication of SAs as the result of collisions due to an initiator
   and responder both trying to renew an existing SA.  The second reason
   is due to the client/server nature of Kerberos exchanges, which
   expects the client to get and maintain tickets.  While KINK expects
   that a KINK host is able to get and maintain tickets, in practice it
   is often advantageous for servers to wait for clients to initiate
   sessions so that they do not need to maintain a large ticket cache.

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

   Normally, a KINK implementation that rekeys existing SAs will try to
   rekey the SA ahead of an SA termination, which may include the hard
   lifetime in time/bytecount or the overflow of the sequence number
   counter.  We call this time "soft lifetime".  The soft lifetime MUST
------分隔线----------------------------
顶一下
(0)
0%
踩一下
(0)
0%
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 密码: 验证码:
推荐内容