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

Versions: (draft-eisler-nfsv4-ccm) 00 01 02 03

Network Working Group                                          M. Eisler
Internet-Draft                                   Network Appliance, Inc.
Document: draft-ietf-nfsv4-ccm-00.txt                           May 2003


               CCM: The Credential Cache GSS Mechanism

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/1id-abstracts.html

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

ABSTRACT

   This document describes a new mechanism under the GSS [RFC2743].
   Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate
   every message transfer, thereby incurring significant overhead due to
   the costs of cryptographic computation. While hardware-based
   cryptographic accelerators can mitigate such overhead, it is more
   likely that acceleration will be available for lower layer protocols,
   such as IPsec [RFC2401] than for upper layer protocols like
   RPCSEC_GSS.  CCM can be used as a way to allow GSS mechanism-
   independent upper layer protocols to leverage the data stream
   protections of lower layer protocols, without the inconvenience of
   modifying the upper layer protocol to do so.

TABLE OF CONTENTS

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Overview of CCM  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Token Formats  . . . . . . . . . . . . . . . . . . . . . . . . 3



Expires: December 2003                                          [Page 1]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   3.1.  Mechanism Object Identifier  . . . . . . . . . . . . . . . . 4
   3.2.  Context Establishment Tokens . . . . . . . . . . . . . . . . 4
   3.2.1.  Initial Context Token  . . . . . . . . . . . . . . . . . . 4
   3.2.2.  Subsequent Context Tokens  . . . . . . . . . . . . . . . . 6
   3.2.2.1.  Subsequent Initiator Context Initialization Token  . . . 6
   3.2.2.2.  Response Token . . . . . . . . . . . . . . . . . . . . . 6
   3.3.  MIC Token  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   3.4.  Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . . 8
   3.5.  Delete Token . . . . . . . . . . . . . . . . . . . . . . . . 8
   4.  Implementation Issues  . . . . . . . . . . . . . . . . . . . . 8
   4.1.  Long Tokens Versus Short Tokens  . . . . . . . . . . . . . . 9
   4.2.  Initiating Contexts Via Short Tokens . . . . . . . . . . . . 9
   4.3.  Accepting Contexts Via Short Tokens  . . . . . . . . . . .  10
   4.4.  Non-Token Generating GSS-API Routines  . . . . . . . . . .  11
   4.5.  Minor Status Codes . . . . . . . . . . . . . . . . . . . .  11
   5.  Advice for NFSv4 Implementors  . . . . . . . . . . . . . . .  11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Normative References . . . . . . . . . . . . . . . . . . . .  14
   10.  Informative References  . . . . . . . . . . . . . . . . . .  14
   11.  Author's Address  . . . . . . . . . . . . . . . . . . . . .  15
   12.  IPR Notices . . . . . . . . . . . . . . . . . . . . . . . .  15
   13.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The GSS framework provides a general means for authenticating clients
   and servers, as well as providing a general means for encrypting and
   integrity protecting data exchanged during a session. GSS specifies
   formats for a set of tokens for authentication, integrity, and
   privacy. The formats consist of a mechanism independent form, and a
   mechanism dependent form. An example of a set of mechanism dependent
   forms is the Kerberos V5 mechanism definition [RFC1964].

   It is possible for a protocol to use GSS for one time authentication,
   or for per message authentication. An example of the former is DAFS
   [DAFS].  An example of the latter is RPCSEC_GSS. Obviously, it is
   more secure to authenticate each message. On the other hand, it is
   also more expensive. However, suppose the data stream of the upper
   layer protocol (the layer using GSS) is protected at a lower layer
   protocol from tampering, such as via a cryptographic checksum. If so,
   it may not be necessary to additionally authenticate each message of
   the upper layer protocol. Instead, it may suffice to use GSS to
   authenticate at the beginning of the upper layer protocol's session.

   To take advantage of one time authentication, existing consumers of
   GSS that authenticate exclusively on each message have to change. One
   way to change is to modify the protocol that is using GSS. This has


Expires: December 2003                                          [Page 2]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   disadvantages including, introducing a protocol incompatibility, and
   effectively introducing another authentication paradigm.  Another way
   to change, is the basis of the proposal in this document:  the
   Credential Cache Mechanism (CCM). CCM allows a GSS initiator and
   target to bind to a security context of a non-CCM mechanism. Since
   CCM is yet another mechanism under the GSS, the effect is that there
   are no modifications to the protocol the GSS consumer is using.

2.  Overview of CCM

   CCM is a "wrapper" mechanism over the set of all other GSS-API
   mechanisms. When CCM creates a context, it invokes an underlying
   mechanism to create a child context. CCM determines the underlying
   mechanism by examining the mechanism object identifier (OID) that it
   is called with. The prefix will always be the OID of CCM, and the
   suffix will be the OID of the underlying mechanism. The context
   initiation and acceptance entry points of CCM wrap the resulting the
   context tokens with a CCM header.

   Let us use RPCSEC_GSS and NFSv4 [RFC3010] as an example. Basic
   understanding of the RPCSEC_GSS protocol is assumed.  If an NFSv4
   client uses the wrong security mechanism, the server returns the
   NFS4ERR_WRONGSEC error. The client can then use NFSv4's SECINFO
   operation to ask the server which GSS mechanism to use.

   Let us say the client and server are using Kerberos V5 [RFC1964] to
   secure the traffic. Suppose the TCP connection NFSv4 uses is secured
   with IPsec. It is therefore not necessary for NFSv4/RPCSEC_GSS to use
   integrity or privacy. Fortunately, RPCSEC_GSS has an authentication
   mode, whereby only the header of each remote procedure call and
   response is integrity protected.  So, this minimizes the overhead
   somewhat, but there is still the cost of the headers being
   checksummed. Since IPsec is protecting the connection, incurring even
   that minimal per remote procedure call overhead may not be necessary.

   Enter CCM. The server detects that the connection is protected with
   IPsec. Via SECINFO, the client is informed that it should use
   CCM/Kerberos V5.  Via the RPCSEC_GSS protocol, the server
   authenticates the end-user on the client with Kerberos V5. The
   context tokens exchanged over RPCSEC_GSS are wrapped inside CCM
   tokens.

3.  Token Formats

   This section discusses the protocol visible tokens that GSS consumers
   exchange when using CCM.





Expires: December 2003                                          [Page 3]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


3.1.  Mechanism Object Identifier

   The object identifier used by CCM is:

        {iso(1)identified-organization(3)dod(6)internet(1)security(5)
        mechanisms(5)ccm-family( Too Be Defined/Registered with IANA,
        but at time of this writing, slot 11 was available )ccm-1(1)}

   This object identifier is not a complete mechanism OID. Complete CCM
   mechanism OIDs must consist of the CCM prefix OID, followed by a real
   mechanism OID, such as that of Kerberos V5 as defined in [RFC1964].

   GSS defines the generic part of a token in ASN.1 encoding. GSS does
   not require ASN.1 for the mechanism specific part of a token.

   This document uses XDR [RFC1832] encoding for the CCM specific part
   of each token.

3.2.  Context Establishment Tokens


3.2.1.  Initial Context Token

   GSS requires that the initial context token from the initiator to the
   target use the format as described in section 3.1 of RFC2743. The
   format consists of a mechanism independent prefix, and a mechanism
   dependent suffix. The mechanism independent token includes the
   MechType field.  Note that MechType must contain the prefix CCM OID
   followed by the underlying mechanism OID. This is necessary so that
   the target's context acceptance entry point knows that CCM is being
   used, and which underlying mechanism is being used.

   RFC2743 refers to the mechanism dependent token as the
   innerContextToken. This is the CCM specific token and is defined as
   follows, in XDR description language:

      /* creation of CCM context via new underlying context */
      typedef struct {
              opaque wrapped_token<>;
      } CCM_wrapped_token_t;

      typedef enum {
              CCM_DIR_I_TO_T = 0, /* initiator to target */
              CCM_DIR_T_TO_I = 1  /* target to initiator */
      } CCM_direction_t;

      typedef struct {
              CCM_direction_t dir;
              unsigned int ctx_sh_number;


Expires: December 2003                                          [Page 4]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


      } CCM_nonce_t;

      /* creation of CCM context via existing underlying context */
      typedef struct {
              CCM_nonce_t nonce;
              opaque ccm_ctx_handle<>;
              opaque mic_nonce<>;
      } CCM_wrapped_mic_t;

      typedef enum {
              CCM_TKN_LONG = 0,
              CCM_TKN_SHORT = 1
      } CCM_tkn_type_t;

      /* innerContextToken */
      typedef union switch (CCM_tkn_type_t tkn_type) {
              case CCM_TKN_LONG:
                      CCM_wrapped_token_t     long_token;
              case CCM_TKN_SHORT:
                      CCM_wrapped_mic_t       short_token;
      } CCM_ict_t;

   When tkn_type is CCM_TKN_LONG, the initiator is simultaneously
   initiating a CCM context and an underlying mechanism context, thereby
   producing a long token.  A long token is the most straightforward way
   to create a CCM context, though as will be described later, not
   necessarily the most efficient way. The long_token's wrapped_token
   field contains an entire InitialContextToken as generated by the
   underlying mechanism's context initiation end point.

   Once an initiator has established an initial CCM context with a
   target, additional contexts can be established via the CCM_TKN_LONG
   route or the CCM_TKN_SHORT route. The disadvantage of the
   CCM_TKN_LONG route is that the underlying mechanism context set up
   must be repeated, which can be time consuming. Whereas, the
   CCM_TKN_SHORT route merely requires that the first CCM context's
   underlying mechanism context be available to produce an integrity
   checksum.  When an application wants to use CCM over multiple
   sessions and/or multiple connections, it can either generate long
   tokens with each new session or connection or it can generate short
   tokens.  The short_token is computed as follows. The ccm_ctx_handle
   is what was returned by the target in response to the creation of a
   context from a long token request.  It uniquely identifies the
   target's previously created context.  The subfield nonce.dir is set
   to CCM_DIR_I_TO_T.  The subfield nonce.ctx_sh_number is the
   identifier of the short_token relative to the long_token that the
   initiator is assigning. The value for ctx_sh_number is selected by
   the initiator such that it is larger than any previous ctx_sh_number
   for given ccm_ctx_handle.  This way, the target need only keep track


Expires: December 2003                                          [Page 5]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   of the largest ctx_sh_number received. The mic_nonce field is equal
   to the output of Gss_GetMIC() as applied to the nonce field, using
   the underlying mechanism's context.

3.2.2.  Subsequent Context Tokens

   A subsequent context token can be any subsequent context token from
   the initiator context initialization entry point, or any response
   context from the target's context acceptance entry point.  The GSS
   specification [RFC2743] does not prescribe any format.

3.2.2.1.  Subsequent Initiator Context Initialization Token

   The subsequent initiator context initialization token is encoded in
   XDR and has the previously described type of type CCM_ict_t. Note
   that the value of the field tkn_type will always be CCM_TKN_LONG in a
   subsequent context token.

3.2.2.2.  Response Token

   The CCM response token, in XDR encoding is:

      typedef enum {
              CCM_OK = 0,

              /*
               * Target does not support short tokens
               */
              CCM_SHORT_TKN_NOT_SUPP = 1,

              /*
               * ccm_ctx_handle was malformed.
               */
              CCM_HANDLE_MALFORMED = 2,

              /*
               * GSS context corresponding to ccm_ctx_handle expired.
               */

              CCM_HANDLE_EXPIRED = 3,

              /*
               * ccm_ctx_handle was not found.
               */
              CCM_HANDLE_NOT_FOUND = 4,

              /*
               * The ctx_sh_number has already been received
               * by the target.


Expires: December 2003                                          [Page 6]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


               */
              CCM_SHORT_TKN_REPLAY = 5,

              /*
               * The underlying mechanism had an error.
               */
              CCM_UNDER_MECH_ERR = 6
      } CCM_status_t;

      typedef struct {
              CCM_status_t status;
              bool sh_tkn_supp;
              union switch (CCM_tkn_type_t tkn_type) {
                      case CCM_TKN_LONG:
                              opaque ccm_ctx_handle<>;
                      case CCM_TKN_SHORT:
                              CCM_nonce_t nonce;
              } tkn_body;
              /*
               * Either the underlying context token (CCM_TKN_LONG) or
               * a MIC token (CCM_TKN_SHORT) of the nonce.
               */
              opaque tkn_stuff<>;
      } CCM_real_rict_t;

      /* response token */
      typedef union switch (bool response_token) {
              case TRUE:
                      CCM_real_rict_t resp;
              case FALSE:
                      void;
      } CCM_rict_t;

   If a value of the status response token is CCM_OK, then the CCM
   context has either been established on the target, or the process of
   context establishment will continue (because the underlying
   mechanism's context acceptance entry point returns
   GSS_S_CONTINUED_NEEDED to the caller).  The target must always set
   the response_token boolean type to TRUE. The reason for this
   convolution will be apparent in the section entitled "Implementation
   Issues".

   Support for short tokens is optional. If they are supported, then
   sh_tkn_supp is set to TRUE, otherwise it is set to FALSE.  If
   sh_tkn_supp is FALSE, then ccm_ctx_handle should be a zero length
   string; there's no point in returning a useful ccm_ctx_handle if
   short tokens are not supported.

   If the response token is in response to a long_token, then tkn_type


Expires: December 2003                                          [Page 7]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   is set to CCM_TKN_LONG, and tkn_stuff is equal to the output_token as
   returned by the underlying mechanism's context acceptance routine on
   the target. The value of tkn_body.ccm_ctx_handle is selected such
   that it uniquely identifies the CCM context handle, so that it can be
   referred to for the purpose creating subsequent tokens via the
   CCM_TKN_SHORT route.

   If the response token is in response to a long_token, then tkn_type
   is set to CCM_TKN_SHORT, and tkn_stuff is equal to the output of a
   GSS_GetMIC() of tkn_body.nonce using the context the underlying
   mechanism.  The value of tkn_body.nonce.dir is set to CCM_DIR_T_TO_I.
   The value of  tkn_body.nonce.ctx_sh_number is set to the value of
   ctx_sh_number that was in the initiator's context token.

3.3.  MIC Token

   This token corresponds to the PerMsgToken type as defined in section
   3.1 of RFC2743.

      typedef void CCM_mic_t;

   The CCM_mic_t token is a void value because CCM performs no integrity
   checksum. A programming API that calls GSS_GetMIC() will thus produce
   an octet string of zero length.

3.4.  Wrap Token

   This token corresponds to the SealedMessage type as defined in
   section 3.1 of RFC2743.

      typedef opaque CCM_wrap_t<>;

   This token is always equal to the input provided to GSS_Wrap().

3.5.  Delete Token

   This token is output from GSS_Delete_sec_context().

      typedef opaque CCM_del_t<>;

   This token is always equal to whatever token the underlying
   mechanism's GSS_Delete_sec_context entry point produces.

4.  Implementation Issues

   The "over the wire" aspects of CCM have been completely specified.
   However, GSS is usually implemented as an Application Programming
   Interface (the GSS-API), and security mechanisms are often
   implemented as modules that are plugged into the GSS-API. It is


Expires: December 2003                                          [Page 8]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   useful to discuss implementation issues and workable resolutions.
   The reader is cautioned that the author has not implemented CCM, so
   what follows is at best a series of educated guesses.

4.1.  Long Tokens Versus Short Tokens

   The first time a CCM context is needed between an principal on the
   initiator and a principal on the target, the initiator has no choice
   but to create an underlying mechanism context via the long token
   context exchange. Once that is done, subsequent CCM tokens between
   the initiator and target can use short tokens. Short tokens are
   better because with them, no more than one round trip is necessary to
   establish a CCM context, and because the overhead of the underlying
   mechanism context establishment is avoided.

4.2.  Initiating Contexts Via Short Tokens

   The key issue is how to associate an CCM established security context
   with a new CCM context. There are no existing interfaces defined
   existing programming language bindings of GSS-API for doing so. This
   section suggests one possible implementation approach.

   We will assume that GSS-API implementation is in the C programming
   language and therefore the GSS-API C bindings [RFC2744] are being
   used. The CCM mechanism implementation will have a table that maps
   ccm_ctx_handle values to gss_ctx_id_t values (see section 5.19 of
   [RFC2744]). The latter are GSS-API context handles as returned by
   gss_init_sec_context(). The former are the context handles as
   returned in a response token from the CCM target. In addition, each
   CCM context has a reference to its underlying mechanism context.

   Let us suppose the application decides it will use CCM. CCM has a
   well known mechanism OID. The point where the initiator calls
   GSS_Init_sec_context(), is a logical place to associate an existing
   CCM context with a new CCM context. Here is where special CCM
   handling is necessary in order to associate a security context with a
   CCM context. GSS_Init_sec_context() accepts several different inputs.
   Normally, the first time GSS_Init_sec_context() is called, the
   input_token field is NULL.  Overloading the input_token is one way to
   associate a new CCM with the an existing CCM security context.  In
   XDR description language, we can thus imagine the following CCM
   initial input token format:

      typedef struct {
              opaque context_ptr<>;
      } CCM_initiator_bootstrap_t;

      typedef union switch (bool response_token) {
              case TRUE:


Expires: December 2003                                          [Page 9]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


                      CCM_real_rict_t resp;
              case FALSE:
                      CCM_initiator_bootstrap_t bootstrap;
      } CCM_init_sec_context_input_token_t;

   If this was a response token, then the response_token field will be
   set to TRUE, and the token processed as if it came from the target as
   described  in the section entitled "Response Token".  Otherwise, the
   caller sets response_token to FALSE.  The caller fills in the
   variable length array bootstrap.context_ptr with the number of octets
   necessary to store a pointer to a GSS-API security context.  In the C
   programming language, we would thus have something like:

      /*
       * What follows is not what an XDR compiler would produce,
       * but instead is a optimal form for C programming
       * environments.
       */
      typedef struct {
              gss_ctx_id_t context_ptr;
      } CCM_initiator_bootstrap_t;

      typedef struct {
              bool response_token;
              union {
                      CCM_status_t status;
                      CCM_initiator_bootstrap_t bootstrap;
              } u;
      } CCM_init_sec_context_input_token_t;


   The CCM entry point for creating contexts on the initiator side
   would, if being called for the first time, interpret the presence of
   the input token as a CCM_initiator_bootstrap_t type.  It uses
   bootstrap.context_ptr to lookup the  corresponding ccm_ctx_handle in
   the aforementioned gss_ctx_id_t to ccm_ctx_handle mapping table.  It
   would then proceed to generate an output token formatted as a
   CCM_TKN_SHORT initial context token as described in section entitled
   "Initial Context Token".

   The first time GSS_Init_sec_context is called, assuming success, it
   will return GSS_S_CONTINUE_NEEDED, because it will need to process
   the token returned by the target. The second time it is called,
   assuming success, it will return GSS_S_COMPLETE, provided the
   underlying mechanism also returns GSS_S_COMPLETE.

4.3.  Accepting Contexts Via Short Tokens

   The CCM target receives an opaque ccm_ctx_handle value as part of the


Expires: December 2003                                         [Page 10]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   mechanism dependent part of initial context token.  Originally, this
   opaque handle came from the target as a result of previously creating
   a context via a long token.  If the opaque handle is still valid,
   then the target can easily determine the original CCM context, and
   from that, the underlying mechanism's context. With the underlying
   context, GSS_VerifyMIC() can be invoked to verify the mic_nonce of
   the input token, and GSS_GetMIC() can be used to generate the
   mic_none of the output token. By comparing the ctx_sh_number in the
   initiator's token with highest value recorded by the target, the
   target takes care to ensure that initiator has not replayed a short
   token.


4.4.  Non-Token Generating GSS-API Routines

   Since the CCM module will record the underlying mechanism's context
   pointer in its internal data structures, this provides a simple
   answer to what to do when GSS-API is invoked on a CCM context that
   does not generate any tokens for the GSS peer. When CCM is called for
   such an operation, it simply re-invokes the GSS-API call, but on the
   recorded underlying context.

4.5.  Minor Status Codes

   The values defined in CCM_status_t serve as the minor status codes
   for CCM.

5.  Advice for NFSv4 Implementors

   The NFSv4.0 specification does not mandate CCM, so clients and
   servers should not insist on its use.  When a server wants a client
   to try to use CCM, it can return a NFS4ERR_WRONGSEC error to the
   client. The client will then follow up with a SECINFO request. The
   response to the SECINFO request should list first a CCM mechanism and
   then the conventional security flavors the server will accept for
   access to file object. If the client supports CCM, it will use it.
   Otherwise, it will have to stick with a conventional flavor.

6.  Security Considerations

   There are many considerations for the use CCM, since it is reducing
   security at one protocol layer in trade for equivalent security at
   another layer.  In this discussion, we will assume that cryptography
   is being used in the application and lower protocol layers.

   *    CCM should not be used whenever the combined key
        strength/algorithm strength of the lower protocol layer securing
        the connection is weaker than what the underlying GSS context
        can provide.


Expires: December 2003                                         [Page 11]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   *    CCM should not be used if the lower level protocol does not
        offer comparable or superior security services to that the
        application would achieve with GSS. For example, if the lower
        level protocol offers integrity, but the application wants
        privacy, then CCM is inappropriate.

   *    The use of CCM contexts over secured connections can be
        characterized nearly secure instead of as secure as using the
        underlying GSS context for protecting each application message
        procedure call. The reason is that applications can multiplex
        the traffic of multiple principals over a single connection and
        so the ciphertext in the traffic is encrypted with multiple
        session keys. Whereas, a secure connection method such as IPsec
        is protected with per host session keys. Therefore, an attacker
        has more cipher text per session key to perform cryptanalysis
        via connections protected with IPsec, versus connections
        protected with GSS.

   *    Related to the previous bullet, the management of private keys
        for a secure channel is often outside the control of the user of
        CCM.  If the secure channel's private keys are compromised, then
        all users of the secure channel are compromised.

   *    CCM contexts created during one session or transport connection
        should not be used for subsequent sessions or transport
        connections. In other words, full initiator to target
        authentication should occur each time a session or transport
        connection is established.  Otherwise, there is nothing
        preventing an attacker from using a CCM context from one
        authenticated session or connection to trivially established
        another, unauthenticated session or connection.  For efficiency,
        it is permissible to use a CCM context from a previous session
        to establish another CCM context via a short token.

        If the application protocol using CCM has no concept of a
        session and does not use a connection oriented transport, then
        there is no sequence of state transitions that tie the CCM
        context creation steps with the subsequent message traffic of
        the application protocol.  Thus it can be hard to assert that
        the subsequent message traffic is truly originated by the CCM
        initiator's principal. For this reason, CCM is not appropriate
        for use with applications that do not have sessions or do not
        use connection oriented transports.

   *    The underlying secure channel should be end to end, from
        initiator to the target. It is permissible for the user to
        configure the underlying secure channel to not be end to end,
        but this should only be done if user has confidence in the
        intermediate end points. For example, suppose the application is


Expires: December 2003                                         [Page 12]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


        being used behind a firewall that performs network address
        translation. It is possible to have an IPsec secure channel from
        the initiator to the firewall, and a second secure channel from
        the firewall to the target, but not from the initiator to the
        target. So, if the firewall is compromised by an attacker in the
        middle, the use of CCM to avoid per message authentication is
        useless. Furthermore, without channel bindings, it is not
        possible for the initiator and target to enforce end to end
        channel security. Of course, if the initiator's node created a
        IP-layer tunnel between it and the target, end to end channel
        security would be achieved, but the initiator and target
        applications would have no way of knowing that.

        A future variant of CCM will mandate the implementation of
        channel bindings for IPsec, SSH, and TLS, such that the session
        keying material of each of the aforementioned three protocols
        will be available to underlying mechanisms like Kerberos V5 and
        SPKM [RFC2847]. This will allow an initiator and target to
        enforce end to end channel security that cannot be compromised
        by an attacker in the middle. This variant is not specified in
        this document because the session-key-based channel bindings in
        GSS-API and in specific mechanisms are not fully specified.

   *    It has been stated that it is not uncommon to find IPsec
        deployments where multiple nodes share common private keys
        [Black]. The use of CCM is discouraged in such environments,
        since the compromise of one node compromises all the other nodes
        sharing the same private key.

   *    Applications using CCM must ensure that the binding between the
        CCM context and the secure channel is legitimate for each
        message that references the CCM context. In other words, the
        referenced CCM context in a message must be established in the
        same secure channel as the message.

   *    When the same secure channel is multiplexing traffic for
        multiple users, the initiator has to ensure the CCM context is
        only accessible to the initiator principal that has established
        it in the first place. One possible way to ensure that is by
        placing CCM contexts in the privileged address space offering
        only controlled indexed access.

   *    CCM does not unnecessarily inflate the scope of the trust
        domain, as does for example AUTH_SYS [RFC1831] over IPSec. By
        requiring the authentication in the CCM context initialization
        (using a previously established context), the trust domain does
        not extend to the client.

   *    Both the traditional mechanisms and CCM rely on the security of


Expires: December 2003                                         [Page 13]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


        the client to protect locally logged on users. Compromise of the
        client impact all users on the same client. CCM does not make
        the problem worse.

   *    The CCM context must be established over the same secure channel
        that the subsequent message traffic will be using. This may, the
        binding between the initial authentication and the subsequent
        traffic is ensured.

7.  IANA Considerations

   Other than the registration of the CCM OID prefix, there are no IANA
   considerations.

8.  Acknowledgements

   Dave Noveck, for the observation that NFS version 4 servers could
   downgrade from integrity service to plain authentication service if
   IPsec was enabled. David Black, Peng Dai, Sam Hartman, Julian Satran,
   and Nicolas Williams for their critical comments. Much of the text
   for the "Security Considerations" section comes directly from Peng.

9.  Normative References


   [RFC2743]
        J. Linn, Internet RFC2743, "Generic Security Service Application
        Program Interface Version 2, Update 1", January, 2000.

   [RFC1832]
        R. Srinivasan, Internet RFC1832, "XDR: External Data
        Representation Standard", August, 1995.


10.  Informative References


   [RFC1831]
        R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call
        Protocol Specification Version 2", August, 1995.

   [RFC1964]
        J. Linn, Internet RFC1964, "The Kerberos Version 5 GSS-API
        Mechanism", June 1996.

   [RFC2203]
        M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS
        Protocol Specification", September, 1997.



Expires: December 2003                                         [Page 14]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   [RFC2401]
        S. Kent, R. Atkinson, RFC2401, "Security Architecture for the
        Internet Protocol ", November, 1998.

   [RFC2744]
        J. Wray, RFC2744, "Generic Security Service API Version 2 : C-
        bindings", January, 2000.

   [RFC3530]
        S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.  Beame, M.
        Eisler, D. Noveck, RFC3010, "Network File System (NFS) version 4
        Protocol", April 2003.

   [Black]
        D. Black, Email message on the NFSv4 working group alias,
        February 28, 2003.

   [DAFS]
        Mark Wittle (Editor), "DAFS Direct Access File System Protocol,
        Version: 1.00", September 1, 2001.

11.  Author's Address

   Mike Eisler
   5765 Chase Point Circle
   Colorado Springs, CO 80919
   USA

   Phone: 719-599-9026
   EMail: mike@eisler.com

12.  IPR Notices

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary


Expires: December 2003                                         [Page 15]


INTERNET-DRAFT  CCM: The Credential Cache GSS Mechanism         May 2003


   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


13.  Copyright Notice

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



















Expires: December 2003                                         [Page 16]


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