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

Versions: 00

Network Working Group                                          M. Eisler
Internet-Draft                                   Network Appliance, Inc.
Document: draft-eisler-nfsv4-ccm-00.txt                    February 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 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

   The list of Internet-Draft Shadow Directories can be accessed at


   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.

   The document also defines how RPCSEC_GSS uses CCM.


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2

Expires: August 2003                                            [Page 1]

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

   2.  Overview of CCM  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Token Formats  . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.1.  Context Establishment Tokens . . . . . . . . . . . . . . . . 4
   3.1.1.  Initial Context Token  . . . . . . . . . . . . . . . . . . 4
   3.1.2.  Response Token . . . . . . . . . . . . . . . . . . . . . . 4
   3.1.3.  Additional Context Tokens  . . . . . . . . . . . . . . . . 5
   3.2.  MIC Token  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.3.  Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.4.  Delete Token . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Implementation Issues  . . . . . . . . . . . . . . . . . . . . 6
   4.1.  Initiating Contexts  . . . . . . . . . . . . . . . . . . . . 6
   4.2.  Accepting Contexts . . . . . . . . . . . . . . . . . . . . . 7
   4.3.  Non-Token Generating GSS-API Routines  . . . . . . . . . . . 8
   4.4.  Minor Status Codes . . . . . . . . . . . . . . . . . . . . . 8
   5.  How RPCSEC_GSS Uses CCM  . . . . . . . . . . . . . . . . . . . 8
   6.  Advice for NFSv4 Implementors  . . . . . . . . . . . . . . . . 9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  10
   10.  Normative References  . . . . . . . . . . . . . . . . . . .  11
   11.  Informative References  . . . . . . . . . . . . . . . . . .  11
   12.  Author's Address  . . . . . . . . . . . . . . . . . . . . .  11
   13.  IPR Notices . . . . . . . . . . . . . . . . . . . . . . . .  11
   14.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . .  12

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 consists of a mechanism independent form, and a
   mechanism dependent form. An example of a 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, if at a lower layer in the protocol
   stack, the data stream the upper layer protocol (one that is using
   GSS) is protected from tampering, such as via a cryptographic
   checksum, 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

   To take advantage of one time authentication, existing consumers of
   GSS that authenticate exclusively on each message have to change. One

Expires: August 2003                                            [Page 2]

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

   way to change is to modify the protocol that is using GSS. This has
   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 a previously created GSS security content over a non-
   CCM mechanism, to a CCM security context. Since CCM is yet another
   mechanism under the CCM, the effect is that there are no
   modifications to the protocol the GSS consumer is using.

2.  Overview of CCM

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

   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 authenticates the end-user on the client with
   Kerberos V5. This happens as result of one complete round trip of an
   NFSv4 COMPOUND procedure using RPCSEC_GSS over a Kerberos V5 security
   content. Next, the server determines that IPsec is protecting the
   connection. As a result, the next time the client issues a an NFSv4
   operation with the Kerberos V5 context, the server returns
   NFS4ERR_WRONGSEC. The client issues another SECINFO, and is told to
   use CCM. The client, via the RPCSEC_GSS protocol proceeds to create a
   CCM context. The innerContextToken of the InitialContextToken
   contains the RPCSEC_GSS handle that corresponds to the Kerberos V5
   context. The server verifies the handle corresponds to a valid
   Kerberos V5 context, and returns a response token (and another
   RPCSEC_GSS handle) confirming the use of CCM. Internally the server
   makes a record to associate the second handle with the original

   The client then issues its first remote procedure call using the
   established CCM context. The server maps the CCM context's RPCSEC_GSS
   handle to original handle, which in turn maps to the original
   Kerberos V5 context, which in turn maps to user principal issuing the
   request. The server has thus identified the user without incurring

Expires: August 2003                                            [Page 3]

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

   the cost of a cryptographic operation.

3.  Token Formats

   This section discusses the protocol visible tokens that GSS consumers
   exchange when using CCM.  The object identifier used by CCM is:

        mechanisms(5)ccm( Too Be Defined/Registered with IANA, but at
        time of this writing, slot 11 was available )}

   GSS defines the generic part of a token in ASN.1 encoding. GSS does
   not require ASN.1 for mechanism specific part of a token. This
   document uses XDR [RFC1832] encoding for the CCM specific part of
   each token.

3.1.  Context Establishment Tokens

3.1.1.  Initial Context Token

   GSS requires that the initial context token from the initiator to the
   target uses the format as described in section 3.1 of RFC2743. After
   the mechanism independent token, the CCM specific token follows. It
   is defined as follows, in XDR description language:

      typedef opaque CCM_ict_t<>;

   The type CCM_ict_t is for an opaque object that is used by the
   application protocol (that uses GSS) to refer to a previously
   established GSS context. For application protocols that deal with no
   more than one GSS context per connection, this opaque object can be a
   zero length string of octets.

3.1.2.  Response Token

   GSS prescribes no form for the response token to the initial context
   token. The CCM response token, in XDR encoding is:

      typedef enum {
              CCM_OK = 0;
              CCM_HANDLE_MALFORMED = 1;
              CCM_HANDLE_EXPIRED = 2;
              CCM_HANDLE_NOT_FOUND = 3;
      } CCM_status_t;

      typedef union switch (bool response_token) {
              case TRUE:
                      CCM_status_t status;

Expires: August 2003                                            [Page 4]

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

              case FALSE:
      } CCM_rict_t;

   If a value of the status response token is CCM_OK, then the CCM
   context has been established on the server.  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

3.1.3.  Additional Context Tokens

   The context setup handshake between the initiator and target is a
   single round trip. There are no additional context tokens (no tokens
   of ASN.1 type SubsequentContextToken).

3.2.  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.3.  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.4.  Delete Token

   This token is output from GSS_Delete_sec_context().

      typedef void CCM_del_t;

   The CCM_del_t token is a void value because CCM sends no information
   with context deletion.  A programming API that calls
   GSS_Delete_sec_context() will thus produce an octet string of zero

Expires: August 2003                                            [Page 5]

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

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
   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.  Initiating Contexts

   The key issue is how to associate an established security context
   over one mechanism with that of a CCM context. There are no existing
   interfaces defined in GSS-API for doing so. Since CCM is predicated
   on the application's protocol being able to manage the handles it
   uses for match initiator and target security contents, any such
   solution is going to require that the application give special
   treatment to CCM. Thus implementing CCM as a complete module that
   plugs into the GSS-API may not be necessary. Nor may it even be
   possible.  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(), seems to be the logical place to
   associate an existing context with a 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 (if not the ideal way) to associate CCM with the an
   existing security content.  In XDR description language, we can thus
   imagine the following CCM initial input token format:

      typedef struct {
              opaque context_ptr<>;
              opaque application_ctx_handle<>;
      } CCM_initiator_bootstrap_t;

      typedef union switch (bool response_token) {
              case TRUE:
                      CCM_status_t status;
              case FALSE:
                      CCM_initiator_bootstrap_t bootstrap;
      } CCM_init_sec_context_input_token;

   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
   subsequent variable length array with the number of octets necessary

Expires: August 2003                                            [Page 6]

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

   to store a pointer to a GSS-API security content. The second array
   contains the handle (if any), the application's protocol uses to
   match initiator security contexts with target contexts.  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 {
              void *context_ptr;
              unsigned int len_application_ctx_handle;
              void *application_ctx_handle;
      } 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;

   The CCM entry point for creating contexts on the initiator side
   would, if being called for the first time (response_token is FALSE),
   interpret the respect of the input token as a
   CCM_initiator_bootstrap_t type. It would then record the context_ptr
   (the context CCM is associating with), and then proceed to generate
   an output token equal to to what application_ctx_handle points to.

   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.

4.2.  Accepting Contexts

   On the target side, we cannot use the a technique similar to what was
   done on the initiator because the token from the initiator is non-
   NULL and moreover, has a prescribed format.  The CCM target receives
   an opaque value (or handle) as the mechanism dependent part of
   initial context token.  Originally, this opaque handle came from the
   target as a result of previously creating a context (the context CCM
   wants to associate with). The target is thus free to form the handle
   in any form it wants.  The most general form of the handle would
   include the following information:

Expires: August 2003                                            [Page 7]

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

   *    A unique identifier for the application protocol, assuming GSS-
        API is being used for multiple applications in the same address
        space, which is a normal situation for implementations of GSS in
        operating system kernels.  The identifier would be unique across
        the target's address space.

   *    A reference to the GSS context that CCM wants to associate with.

   When the target's GSS_Accept_sec_context interface processes the
   input token, it could then do the following:

   *    Map the application protocol identifier to an operations vector
        that includes a routine for mapping the GSS context reference to
        a context pointer.

   *    Invoke the mapping routine, passing the protocol identifier and
        the context reference as arguments.

   *    Record the context returned by the mapping routine as the
        context CCM is associating with.

   *    If no context is returned, then generate an output token that
        has a status of other than CCM_OK.  Otherwise generate a token
        that returns CCM_OK.

4.3.  Non-Token Generating GSS-API Routines

   Since the CCM module will record the associated context's context
   pointer in its internal data structures, this provides a simple
   solution to the issue of 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 associated context.

4.4.  Minor Status Codes

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


   Any application protocol that uses CCM must have an end to end
   agreement on the composition of the initial context token from
   initiator to the target. The initial context token for CCM is encoded
   as the XDR type CCM_ict_t as described previously in this document.
   RPCSEC_GSS is a consumer of GSS, and so can be thought of as the
   application protocol (and not for example NFSv4, which is layered
   above). Section of RFC2203 describes the RPCSEC_GSS

Expires: August 2003                                            [Page 8]

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

   protocol's rpc_gss_init_res structure, and within that structure, a
   field called "handle" which "serves as the context identifier". The
   handle field of the rpc_gss_init_res is what the RPCSEC_GSS initiator
   must use as the content of CCM_ict_t. Note that XDR data type
   CCM_ict_t and that of rpc_gss_init_res's handle field are exactly the

6.  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 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 CCM 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. The server should record some state
   with the RPCSEC_GSS context that indicates whether a "downgrade" to
   CCM attempt was made.

   An example will further illustrate.

   Suppose NFSv4 is being used over a TCP connection to access a
   filesystem that the system administrator has configured to be
   protected via krb5i. Both client and server, via programming
   interfaces provided by their operating environments, determine that
   the connection is protected with IPsec. The client therefore issues
   any SECINFO with AUTH_NONE, since it knows the SECINFO will not be
   tampered with. The server knows the connection is protected, so
   rather than requiring { RPCSEC_GSS, Kerberos V5 , privacy } of the
   client, it requires { RPCSEC_GSS, Kerberos V5, authentication }
   (krb5). The client then issues one remote procedure call using krb5,
   which creates a GSS-API security context that is associated with an
   RPCSEC_GSS handle.  The server authenticates the client, processes
   the operation, and retuns the result. The next time the client uses
   the same security context and handle, the server returns
   NFS4ERR_WRONGSEC.  After the ensuing SECINFO call the server tells
   the client to use { RPCSEC_GSS, CCM, authentication }, followed by {
   RPCSEC_GSS, CCM, authentication } (in case the client does not
   support CCM. The client then handshakes with the server to create an
   RPCSEC_GSS context over CCM. Thereafter, as long as the connection
   remains protected with CCM, the client does not have to use Kerberos
   V5 again.

   To reduce round trips, optimizations are possible in above example.
   Since the client knows IPsec is securing the connection, it can guess
   that CCM will be permitted. If it already has a CCM context for
   principal/server pair, it can try to use CCM. If it does not have a
   CCM context, but has another GSS-API context for the principal/server

Expires: August 2003                                            [Page 9]

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

   pair, it can optimistically create a CCM context over RPCSEC_GSS.
   Similarly, since the server knows the connection is protected, when
   it gets a SECINFO request, it can encode its first three tuple as {
   RPCSEC_GSS, CCM, authentication}, followed by a tuple with Kerberos
   V5 in it.  If the client has a CCM context for the principal, it can
   use it on the next remote procedure call. Otherwise, via the second
   tuple, it knows that it has to use Kerberos V5 to create a Kerberos
   V5 context from which to derive the CCM context.

7.  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 associated GSS context
        can provide.

   *    CCM should not be used if the lower level protocol does not
        offer comparable or superior security services 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
        associated 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 sessions keys. Therefore, an attacker
        has more cipher text to perform cryptanalysis via connections
        protected with IPsec, versus connections protected with GSS.

8.  IANA Considerations

   There are no issues for IANA.

9.  Acknowledgements

   Dave Noveck, for the observation that NFS version 4 servers could
   downgrade from integrity service to plain authentication service if
   IPsec was enabled.

Expires: August 2003                                           [Page 10]

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

10.  Normative References

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

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

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

11.  Informative References

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

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

        S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C.  Beame, M.
        Eisler, D. Noveck, RFC3010, "NFS version 4 Protocol", December

12.  Author's Address

   Mike Eisler
   5765 Chase Point Circle
   Colorado Springs, CO 80919

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

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

Expires: August 2003                                           [Page 11]

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

   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
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

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

   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

Expires: August 2003                                           [Page 12]

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