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

               CCM:

               The Credential Cache GSS Channel Conjunction Mechanism (CCM) for GSS
                        draft-ietf-nfsv4-ccm-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/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 suite of new mechanism mechanisms 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.  Conventions Used in this Document . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. 3
   3.  Overview of CCM  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Token Formats  . . . . . 4
   3.1.  Example Application of CCM  . . . . . . . . . . . . . . . . . 4
   3.2.  A Suite of CCM Mechanisms . . 3
   3.1.  Mechanism Object Identifier . . . . . . . . . . . . . . . . 4
   3.2.  Context Establishment Tokens
   3.3.  QOPs  . . . . . . . . . . . . . . . . . . . 4
   3.2.1.  Initial Context Token . . . . . . . . . 5
   4.  Token Formats . . . . . . . . . 4
   3.2.2.  Subsequent Context Tokens . . . . . . . . . . . . . . . . 6
   3.2.2.1.  Subsequent Initiator Context Initialization Token
   4.1.  Mechanism Object Identifier . . . . . . . 6
   3.2.2.2.  Response Token . . . . . . . . . . 6
   4.2.  Tokens for the CCM-BIND mechanisms  . . . . . . . . . . . . . 6
   3.3.  MIC Token
   4.3.  Context Establishment Tokens for CCM-BIND Mechanisms  . . . . 6
   4.3.1.  Initial Context Token for CCM-BIND  . . . . . . . . . . . . 7
   4.3.2.  Subsequent Context Tokens for CCM-BIND  . . . . . . . . . . 8
   3.4.  Wrap 7
   4.3.2.1.  Subsequent Initiator Context Initialization Token for
             CCM-BIND  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   3.5.  Delete 7
   4.3.2.2.  Response Token for CCM-BIND . . . . . . . . . . . . . . . 7
   4.4.  MIC Token for CCM-BIND  . . . . . . . . . . 8
   4.  Implementation Issues . . . . . . . . . 7
   4.5.  Wrap Token for CCM-BIND . . . . . . . . . . . 8
   4.1.  Long Tokens Versus Short Tokens . . . . . . . . 7
   4.6.  Other Tokens for CCM-BIND . . . . . . 9
   4.2.  Initiating Contexts Via Short Tokens . . . . . . . . . . . . 9
   4.3.  Accepting Contexts Via Short 8
   4.7.  Tokens for CCM-MIC  . . . . . . . . . . .  10
   4.4.  Non-Token Generating GSS-API Routines . . . . . . . . . .  11
   4.5.  Minor Status Codes 8
   4.8.  Context Establishment Tokens for CCM-MIC  . . . . . . . . . . 8
   4.8.1.  Initial Context Token for CCM-MIC . . . . . . . . . . . .  11
   5.  Advice . 8
   4.8.2.  Subsequent Context Tokens for NFSv4 Implementors CCM-MIC . . . . . . . . . . . 9
   4.8.2.1.  Subsequent Initiator Context Initialization Token for
             CCM-MIC . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . 9
   4.8.2.2.  Response Token for CCM-MIC  . . . . . . . . . . . . . .  10
   4.9.  MIC Token for CCM-MIC . . .  14
   8.  Acknowledgements . . . . . . . . . . . . . . . .  12
   4.10.  Wrap Token for CCM-MIC . . . . . .  14
   9.  Normative References . . . . . . . . . . . .  12
   4.11.  Context Deletion Token . . . . . . . .  14
   10.  Informative References . . . . . . . . . .  12
   4.12.  Exported Context Token . . . . . . . .  14
   11.  Author's Address . . . . . . . . . .  12
   4.13.  Other Tokens for CCM-MIC . . . . . . . . . . .  15
   12.  IPR Notices . . . . . .  12
   5.  GSS Channel Bindings for Common Secure Channel Protocols  . .  12
   5.1.  GSS Channel Bindings for IKEv1  . . . . . . . . . . . . . .  13
   5.2.  GSS Channel Bindings for IKEv2  . .  15
   13.  Copyright Notice . . . . . . . . . . . .  13
   5.3.  GSS Channel Bindings for SSHv2  . . . . . . . . .  16

1.  Introduction

   The . . . . .  13
   5.4.  GSS Channel Bindings for TLS  . . . . . . . . . . . . . . .  13
   6.  Use of Channel Bindings with CCM-BIND and SPKM  . . . . . . .  13
   7.  CCM-KEY and Anonymous IPsec . . . . . . . . . . . . . . . . .  14
   8.  Other Protocol Issues for CCM . . . . . . . . . . . . . . . .  14
   9.  Implementation Issues . . . . . . . . . . . . . . . . . . . .  15
   9.1.  Management of gss_targ_ctx  . . . . . . . . . . . . . . . .  15
   9.2.  CCM-BIND Versus CCM-MIC . . . . . . . . . . . . . . . . . .  15
   9.3.  Initiating CCM-MIC Contexts . . . . . . . . . . . . . . . .  16
   9.4.  Accepting CCM-MIC Contexts  . . . . . . . . . . . . . . . .  17
   9.5.  Non-Token Generating GSS-API Routines . . . . . . . . . . .  17
   9.6.  CCM-MIC and GSS_Delete_sec_context()  . . . . . . . . . . .  17
   9.7.  GSS Status Codes  . . . . . . . . . . . . . . . . . . . . .  18
   9.7.1.  Status Codes for CCM-BIND . . . . . . . . . . . . . . . .  18
   9.7.2.  Status Codes for CCM-MIC  . . . . . . . . . . . . . . . .  18
   9.7.2.1.  CCM-MIC: GSS_Accept_sec_context() status codes  . . . .  18
   9.7.2.2.  CCM-MIC: GSS_Init_sec_context() status codes  . . . . .  19
   9.8.  Channel Bindings on the Target  . . . . . . . . . . . . . .  20
   10.  Advice for NFSv4 Implementors  . . . . . . . . . . . . . . .  21
   11.  Man in the Middle Attacks without CCM-KEY  . . . . . . . . .  21
   12.  Security Considerations  . . . . . . . . . . . . . . . . . .  22
   13.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  25
   14.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  26
   15.  Normative References . . . . . . . . . . . . . . . . . . . .  27
   16.  Informative References . . . . . . . . . . . . . . . . . . .  28
   17.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  28
   18.  IPR Notices  . . . . . . . . . . . . . . . . . . . . . . . .  29
   19.  Copyright Notice . . . . . . . . . . . . . . . . . . . . . .  29

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

2.  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 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
   Channel Conjunction Mechanism (CCM).  CCM allows a GSS initiator and
   target to conjunct (bind) a secure session (or channel) at one
   protocol layer with (e.g.  IPsec) a security context of a non-CCM GSS
   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.

3.  Overview

   CCM is a "wrapper" mechanism over the set of all other GSS
   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.

3.1.  Example Application of CCM

   Let us use RPCSEC_GSS and NFSv4 [RFC3530] as our 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
   and encrypted 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.2.  A Suite of CCM Mechanisms

   CCM consists of a suite of GSS mechanisms.  CCM-NULL, CCM-ADDR, and
   CCM-KEY bind a GSS mechanism context to a secure channel via GSS
   channel bindings (see section 1.1.6 of RFC2743).  As noted in
   RFC2743, the purpose of channel bindings are to limit the scope
   within which an intercepted GSS context token can be used by an
   attacker.  CCM-KEY requires the use of channel bindings that are
   derived from the secure channel's encryption keys.  CCM-ADDR requires
   the use of channel bindings that are derived from network addresses
   associated with the secure channel.  For environments where it is not
   feasible to use key-based channel bindings (e.g., the programming
   interfaces to get them are not available) or address-based channel
   bindings (e.g., the secure channel may be constructed over a path
   that requires the use of Network Address Translation), CCM-NULL is
   also defined.  CCM-NULL requires the use of null channel bindings.

   As discussed later in this document CCM-MIC exists for the purpose of
   optimizing the use of CCM.

   Implementations that claim compliance with this document are REQUIRED
   to implement CCM-KEY and CCM-MIC.  CCM-NULL and CCM-ADDR
   implementation are OPTIONAL.  Specifications that make normative
   references to CCM are free to mandate any subset of the suite CCM
   mechanisms.

   Because the GSS channel bindings to IPsec [RFC2401, RFC2409, IKEv2]
   have not been previously defined, and to ensure the usefulness of
   CCM, they are defined in this document.

   Also, the SPKM (1, 2 and 3) [RFC2025, RFC2847] mechanism is not clear
   on how channel bindings work with SPKM; a simple clarification is
   provided.

   CCM-MIC is intended to reduce the instances of full GSS context
   establishment to a per- {initiator principal, target} tuple.  CCM-MIC
   is used to establish a new context by proving that the initiator and
   target both have a previously established, unexpired GSS context; the
   proof is accomplished by exchanging MICs made with the previously
   established GSS context.  The CCM-MIC context creation entry points
   utilize the CCM_REAL_QOP (discussed later Overview section) in the
   value to generate and verify the MICs.  The type of channel bindings
   used when initiating CCM-MIC contexts MUST match that used when
   creating the previously established context.

3.3.  QOPs

   The CCM mechanisms provide two QOPs: the default QOP (0) that amounts
   to no protection, and a QOP (CCM_REAL_QOP, defined as value 1) that
   maps to the default QOP of the underlying GSS mechanism. The MIC
   tokens for CCM are zero length values.  When qop_req is 0, the wrap
   output tokens for CCM are equal to the input tokens.

        [ XXX - We assume that applications can cope with zero length
        MICs.  We propose that implementations try and find out.  We may
        revisit this by requiring a small (8-32 bits) MIC token.
        However, given that the C bindings of GSS allocates the MIC on
        the heap, this could introduce an unnecessary and expensive
        allocation, we suggest applications be fixed to deal with zero
        length tokens.  ]

4.  Token Formats

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

4.1.  Mechanism Object Identifier

   There are two classes of Mechanism object identifiers (OIDs) for CCM.
   The first class consists of the channel binding specific OIDs, and
   will be referred to as the CCM-BIND mechanisms:

        {iso(1)identified-organization(3)dod(6)internet(1)security(5)
        mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-null(1)}

        {iso(1)identified-organization(3)dod(6)internet(1)security(5)
        mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-addr(2)}

        {iso(1)identified-organization(3)dod(6)internet(1)security(5)
        mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-key(3)}

   The above three object identifiers are not complete mechanism OIDs.
   Complete CCM mechanism OIDs MUST consist of one of the above OIDs as
   prefix, followed by a real mechanism OID, such as that of Kerberos V5
   as defined in [RFC1964].  The second class consists of a single OID
   for the CCM-MIC mechanism.

        {iso(1)identified-organization(3)dod(6)internet(1)security(5)
        mechanisms(5)ccm-family(TBD1)ccm-mic(2)}

   The CCM-MIC OID is a complete mechanism OIDs, and is not a prefix.

   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.

4.2.  Tokens for the CCM-BIND mechanisms

4.3.  Context Establishment Tokens for CCM-BIND Mechanisms

   The CCM-BIND context establishment tokens are simple wrappers around
   a real GSS mechanism's tokens.  The CCM-BIND mechanisms use the same
   number context token exchanges as required by they underlying real
   mechanism.

4.3.1.  Initial Context Token for CCM-BIND

   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.  The MechType MUST be equal to the OID of CCM-NULL,
   CCM-ADDR, or CCM-KEY.  The mechanism dependent portion of the Initial
   Context Token is always equal to the full InitialContextToken as
   returned by the underlying real mechanism.  This will include yet
   another MechType, which will have the underlying mechanism's OID.

4.3.2.  Subsequent Context Tokens for CCM-BIND

   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.

4.3.2.1.  Subsequent Initiator Context Initialization Token for CCM-BIND

   A SubsequentContextToken for a CCM-BIND mechanism is equal to that
   returned by the initiator's context initialization routine of the
   underlying real mechanism.

4.3.2.2.  Response Token for CCM-BIND

   The response token for a CCM-BIND mechanism is equal to that returned
   by the target's context acceptance routine of the underlying real
   mechanism.

4.4.  MIC Token for CCM-BIND

   This token corresponds to the PerMsgToken type as defined in section
   3.1 of RFC2743.  When the qop_req is the default QOP (0), then the
   PerMsgToken is a quantity zero bits in length.  A programming API
   that calls GSS_GetMIC() with the default QOP will thus produce an
   octet string of zero length.

   When the qop_req is CCM_REAL_QOP (1), then PerMsgToken is whatever
   the underlying real mechanism returns from GSS_GetMIC() when passed
   the default QOP value (0).

4.5.  Wrap Token for CCM-BIND

   This token corresponds to the SealedMessage type as defined in
   section 3.1 of RFC2743.  When the qop_req is the default QOP (0),
   then the SealedMessage token is equal to the unmodified input to
   GSS_Wrap().

   When the qop_req is CCM_REAL_QOP (1), then SealedMessage is whatever
   the underlying real mechanism returns from GSS_Wrap(), when passed
   the default QOP value (0).

4.6.  Other Tokens for CCM-BIND

   All other tokens are what the real underlying mechanism returns as a
   token.

4.7.  Tokens for CCM-MIC

4.8.  Context Establishment Tokens for CCM-MIC

4.8.1.  Initial Context Token for CCM-MIC

   The initial context token from the initiator to the target uses 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.  The
   MechType MUST be equal to the OID of CCM-MIC.  RFC2743 refers to the
   mechanism dependent token as the innerContextToken.  This is the
   CCM-MIC specific token and is XDR [RFC1832] encoded as follows, using
   XDR description language:

      typedef struct {
              unsigned int ctx_sh_number;
              unsigned int rand;
      } CCM_nonce_t;

      typedef struct {
              CCM_nonce_t nonce;
              opaque gss_targ_ctx[20];
              opaque chan_bindings<>;
      } CCM_MIC_unwrapped_init_token_t;

      /*
       * The result of CCM_MIC_unwrapped_init_token_t after
       * Invoking GSS_GetMIC() on it.  qop_req is CCM_REAL_QOP, and
       * conf_flag is FALSE.
       */
      typedef opaque CCM_MIC_wrapped_init_token_t<>;

   Once an initiator has established an initial CCM context with a
   target via a CCM-BIND mechanism, the additional contexts can be
   established via the CCM-MIC mechanism.  The disadvantage of re-
   establishing additional contexts via the CCM-BIND route is that the
   underlying mechanism context set up must be repeated, which can be
   expensive.  Whereas, the CCM-MIC mechanism route merely requires that
   the first CCM context's underlying mechanism context be available to
   produce an integrity checksum.  The initial context token for CCM-MIC
   is computed as follows.

   *    The gss_targ_ctx is computed as the SHA-1 checksum of the
        concatenation of SHA-1 [FIPS] checksums of the context tokens
        exchanged by the CCM-BIND mechanism in the order in which they
        were processed. For example, the context handle identifier for a
        CCM-KEY context exchange over a Kerberos V5 context exchange
        would be:  SHA-1( { SHA-1(CCM-KEY's initiator's token), SHA-
        1(CCM-KEY's target's token)) }.  Since the SHA-1 standard
        mandates a 160 bit output, (20 octets), gss_targ_ctx is a fixed
        length, 20 octet string.

   *    The subfield nonce.rand is set a random or pseudo random value.
        It is provided so as to ensure more variability of the the mic
        that GSS will calculate when CCM_MIC_unwrapped_init_token_t is
        GSS_Wrap()ed into CCM_MIC_wrapped_init_token_t.

   *    The subfield nonce.ctx_sh_number is the identifier of the CCM-
        MIC context relative to the CCM-BIND context (as identified by
        gss_targ_ctx) 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 the given
        gss_targ_ctx.  This way, the target need only keep track of the
        largest ctx_sh_number received.  Once ctx_sh_number has reached
        the maximum value for an unsigned 32 bit integer, the given
        gss_targ_ctx can no longer be used.

   *    Once the above fields are calculated, GSS_Wrap() is performed on
        the CCM_MIC_unwrapped_init_token_t value, to produce a
        CCM_MIC_wrapped_init_token_t value that becomes the initial
        context token to send to the target.

4.8.2.  Subsequent Context Tokens for CCM-MIC

   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.

4.8.2.1.  Subsequent Initiator Context Initialization Token for CCM-MIC

   As CCM-MIC has only one round trip for context token exchange, there
   are no subsequent initiator context tokens.

4.8.2.2.  Response Token for CCM-MIC

   The CCM response token, in XDR encoding is:

      typedef enum {
              CCM_OK = 0,

              /*
               * gss_targ_ctx was malformed.
               */
              CCM_ERR_HANDLE_MALFORMED = 1,

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

              CCM_ERR_HANDLE_EXPIRED = 2,

              /*
               * gss_targ_ctx was not found.
               */
              CCM_ERR_HANDLE_NOT_FOUND = 3,

              /*
               * The ctx_sh_number has already been received
               * by the target.  Or the maximum ctx_sh_number has
               * been previously received.
               */
              CCM_ERR_TKN_REPLAY = 4,

              /*
               * Channel binding type mismatch between CCM-BIND context
               * and the CCM-MIC initial context.
               */
              CCM_ERR_CHAN_MISMATCH = 5,

              /*
               * The GSS_Unwrap() failed on initial context token
               */
              CCM_ERR_TKN_UNWRAP = 6,

              /*
               * The GSS_GetMIC() called failed on the target().
               */

              CCM_ERR_TKN_GET_MIC = 7,

              /*
               * The GSS_Wrap() failed on the initiator.  Not reported
               * by target.
               */

              CCM_ERR_TKN_WRAP = 8,

              /*
               * The GSS_VerifyMIC() failed on the initiator.  Not
               * reported by target.
               */

              CCM_ERR_TKN_VER_MIC = 9

      } CCM_MIC_status_t;

      /*
       * GSS errors returned by the underlying mechanism
       */
      typedef struct {
              unsigned int gss_major;
              unsigned int gss_minor;
      } CCM_MIC_real_gss_err_t;

      /*
       * The response context token for CCM-MIC.
       */
      typedef union switch (CCM_MIC_status status) {
              case CCM_OK:
                      opaque mic_init_tkn<>;
              case CCM_ERR_TKN_UNWRAP:
              case CCM_ERR_TKN_GET_MIC:
                      CCM_real_gss_err_t gss_err;
              default:
                      void;
      } CCM_MIC_resp_t;

   If a value of the status field is CCM_OK, then the CCM-MIC context
   has been established on the target.  The field mic_init_tkn is equal
   to the output of GSS_GetMIC() (qop_req is CCM_REAL_QOP (1)) on the
   entire and original token that came from the initiator.  In other
   words, the input_token value to GSS_Accept_sec_context().  This is
   necessary because the inner token from the initiator is wrapped with
   GSS_Wrap(), and thus contains a MIC.  If we performed GSS_GetMIC() on
   the unwrapped inner token, then for some underlying mechanisms, we
   would end up with a mic_init_tkn in the response token equal to what
   was embedded in the request token.

   If the status field is CCM_ERR_TKN_UNWRAP or CCM_ERR_TKN_GET_MIC,
   then gss_err.gss_major and gss_err.minor are set to the major and
   minor GSS statuses as returned by GSS_Unwrap() or GSS_GetMIC().  The
   values for the gss_major field are as defined in [RFC2744].  The
   values for the gss_minor field are both mechanism dependent and
   mechanism implemented dependent.  They are nonetheless potentially
   useful as debugging aids.

4.9.  MIC Token for CCM-MIC

   The MIC token for CCM-MIC is the same as the MIC token for CCM-BIND.

4.10.  Wrap Token for CCM-MIC

   The wrap token for CCM-MIC is the same as the wrap token for CCM-
   BIND.

4.11.  Context Deletion Token

   The context deletion token for CCM-MIC is a zero length token.

4.12.  Exported Context Token

   The Exported context token for CCM-MIC is implementation defined.

4.13.  Other Tokens for CCM-MIC

   All other tokens are the same as corresponding tokens for CCM-BIND.

5.  GSS Channel Bindings for Common Secure Channel Protocols

   For CCM-KEY to be useful and secure, CCM-KEY MUST be used in
   conjunction with channel bindings to bind GSS authentication at the
   application layer to a lower layer in the network that provides
   cryptographic session protection.

   To date only network address type channel bindings have been defined
   for GSS [RFC2743].  But the GSS also allows for channel bindings of
   "transformations of encryption keys" [RFC2743].  The actual generic
   representation of channel bindings is defined in the C-Bindings of
   the GSS-API [RFC2744].

   Modern secure transports generally define some quantity or quantities
   which are either derived from the session keys (or from key exchange
   material) or which are securely exchanged in such a way that both
   peers of any one connection or association can arrive at the same
   derived quantities, while a man-in-the-middle cannot make these
   quantities match for both peers.  Signatures of these quantities can
   be exchanged to prove that there is no man-in-the-middle (because a
   man-in-the-middle cannot cause them to be the same for both peers).
   These quantities correspond to what the GSS framework provides terms "transformations of
   encryption keys" that are referred to in [RFC2743].

   Where a general means secure transport clearly defines a session identifier
   securely derived from session keys or key exchange material, that
   identifier MUST be used as the GSS channel bindings data when CCM-
   BIND is used to bind GSS to that transport.

   This section defines four forms of "transformations of encryption
   keys," one for authenticating clients IKEv1, one for IKEv2, one for SSHv2 and servers, as well one for TLS.
   All four forms are to be used as providing a general means the value of the "application_data"
   field of the gss_channel_bindings_struct type defined in [RFC2744].

5.1.  GSS Channel Bindings for encrypting IKEv1

   IKEv1 does not define a single value which can be used -- by both the
   IPsec initiator and
   integrity protecting responder of an IPsec SA -- to identify a given
   SA.  IKEv1 does, however, define public values derived from the IKEv1
   key exchange: 'HASH_I' and 'HASH_R'.

   For IKEv1, the GSS channel bindings data exchanged during to use with CCM-KEY consists
   of the concatenation of HASH_I and HASH_R octet string values, in
   that order, from the underlying IPsec session being bound to [IKEv1].

5.2.  GSS Channel Bindings for IKEv2

   IKEv2 peers assign and exchange 8-octet "Security Parameters Index"
   (SPI) values, such that a session. pair of SPIs suffices to uniquely identify
   a given IPsec security association.

   For IKEv2 the GSS specifies
   formats channel bindings data to use with CCM-KEY is simply
   the concatenation of the SPIi and SPIr values, in that order, which
   identify the IPsec SA being bound to.

5.3.  GSS Channel Bindings for SSHv2

   SSHv2 defines a set session ID derived from the initial key exchange of tokens
   an SSHv2 connection; this value is not secret and is the same for
   both the client and the server for any given connection.

   For SSHv2 the GSS channel bindings data for use with CCM-KEY consists
   of the SSHv2 session ID.

5.4.  GSS Channel Bindings for authentication, integrity, and
   privacy. The formats consist TLS

   XXX - This section is To Be Defined.

6.  Use of a mechanism independent form, Channel Bindings with CCM-BIND and a
   mechanism dependent form. An example of a set of mechanism dependent
   forms is SPKM

   Whereas the Kerberos V5 mechanism definition [RFC1964].

   It specification [RFC1964] is possible for a protocol quite
   detailed with respect to the use of GSS channel bindings, the same is
   not true for one time authentication,
   or SPKM, which merely provides a field named "channelId"
   for per message authentication. An example of the former passing channel bindings data, as octet strings, from initiators
   to acceptors.  No interpretation is DAFS
   [DAFS].  An example given in RFC2025 for the value of
   the latter is RPCSEC_GSS. Obviously, it is
   more secure channelId field.  Therefore SPKM requires some clarification to
   be usable with channel bindings and CCM-KEY: The channelId field of
   SPKM Context-Data ASN.1 structure MUST be set to authenticate each message. On the other hand, it is
   also more expensive. However, suppose checksum of the
   channel bindings data stream of that is defined for the upper
   layer protocol (the layer Kerberos V5 mechanism
   [RFC1964], using GSS) is protected at a lower layer
   protocol from tampering, such SHA-1 instead of MD5 as via a cryptographic checksum. If so,
   it may not the hash algorithm.

   [Note:  This checksum can be necessary to additionally authenticate each message computed independently of the upper layer protocol. Instead, it may suffice to use GSS to
   authenticate at
   language bindings used by the beginning of application, even though RFC1964
   references the upper layer protocol's session.

   To take advantage C-Bindings of one time authentication, existing consumers the GSS-API [RFC2744] in the
   construction of
   GSS that authenticate exclusively on each message have to change. One
   way to change is to modify this checksum (read the protocol RFC1964 text carefully).]

7.  CCM-KEY and Anonymous IPsec

   For sites that is using GSS. This has
   disadvantages including, introducing do not use IPsec, but use Kerberos V5, SPKM, or
   LIPKEY, deploying IPsec, a PKI infrastructure and certificates for
   use with IKE may prove quite difficult to deploy just for secure
   application (e.g., NFS) performance improvements.  Such sites could
   avoid the need to deploy a protocol incompatibility, PKI and
   effectively introducing another authentication paradigm.  Another way certificates to change, is all clients and
   server by using "anonymous IPsec" for the basis of application (e.g., NFS
   with/ RPCSEC_GSS) and CCM-KEY.

   Though there is no such thing as "anonymous IPsec," the proposal in this document: effect can be
   achieved by using self-signed certificates.

   By using anonymous IPsec with the
   Credential Cache Mechanism (CCM). CCM allows a GSS initiator application and
   target CCM-KEY, the full
   benefit of offloading session cryptography from upper layer protocol
   layer to bind the IP layer can be had without having to a security context of a non-CCM mechanism. Since deploy an
   authentication infrastructure for IPsec.

8.  Other Protocol Issues for CCM

   CCM-BIND is yet another mechanism under the GSS, a trivial mechanism, and normally will return the effect is that there
   are no modifications to same
   major status code as the protocol underlying real mechanism, including
   GSS_S_COMPLETE as returned by GSS_Init_sec_context().  However, the GSS consumer is using.

2.  Overview of CCM

   CCM
   first time GSS_Init_sec_context is called on a "wrapper" CCM-BIND mechanism, if
   the underlying real mechanism over returns GSS_S_COMPLETE, CCM-BIND's
   GSS_Init_sec_context() entry point MUST return GSS_S_CONTINUE_NEEDED
   to the caller.  This way, the initiator will receive another context
   token from the target, even if the set of all other GSS-API
   mechanisms. When CCM creates a context, it invokes an underlying real mechanism context
   set up is done.  The CCM-BIND initiator will need to create a child context. CCM determines record state
   that indicates that the underlying mechanism has reached a completely
   established state (and so is uninterested in any token the target
   returns).  This way, the initiator can process every token produced
   by examining the mechanism object identifier (OID) target's GSS_Accept_sec_context() routine and so calculate
   gss_targ_ctx  value that matches that of the target.

9.  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 it are plugged into the GSS-API.  It is called with.
   useful to discuss implementation issues and workable resolutions.
   The prefix will always be reader is cautioned that the OID of authors have not implemented CCM, and the
   suffix will be the OID so
   what follows is at best a series of the underlying mechanism. The context
   initiation and acceptance entry points educated guesses.

9.1.  Management of CCM wrap the resulting gss_targ_ctx

   The gss_targ_ctx value is computed by the
   context tokens with a CCM header.

   Let us use RPCSEC_GSS initiator and NFSv4 [RFC3010] as an example. Basic
   understanding target based
   on SHA-1 computations of the RPCSEC_GSS protocol CCM-BIND context tokens.  There is assumed.  If an NFSv4
   client uses a
   space/time trade off between the wrong security mechanism, initiator and target storing the server returns
   sequence of context tokens until needed by CCM-BIND, versus computing
   the
   NFS4ERR_WRONGSEC error. The client can SHA-1 checksums and then use NFSv4's SECINFO
   operation to ask disposing of the server which GSS mechanism to use.

   Let us say context tokens when
   CCM-BIND no longer needs them.  If it is likely there will be CCM-MIC
   contexts created for the client CCM-BIND context, and server are using Kerberos V5 [RFC1964] to
   secure if the traffic. Suppose sequence of
   context tokens requires more space than a 20 octet SHA-1 value, then
   the TCP connection NFSv4 uses is secured
   with IPsec. It tradeoff is therefore not necessary for NFSv4/RPCSEC_GSS to use
   integrity or privacy. Fortunately, RPCSEC_GSS has an authentication
   mode, whereby only obvious.

   Since the header bit space of each remote procedure call and
   response is integrity protected.  So, this minimizes the overhead
   somewhat, but there all possible sequences of CCM-BIND context
   tokens is still larger than the cost 160 bit space of possible SHA-1 checksums,
   in theory two or more different CCM-BIND contexts will produce
   produce the headers being
   checksummed. Since IPsec is protecting the connection, incurring even
   that minimal per remote procedure call overhead may not same SHA-1 context, and thus for CCM-MIC context
   initiation, there will be necessary.

   Enter CCM. The server detects that ambiguity as to which CCM-BIND context the connection
   initiator is protected with
   IPsec. Via SECINFO, binding to.  The target can resolve this ambiguity by
   attempting to unwrap the client inner context token from the CCM-MIC
   initiator for each matching CCM-BIND context.  In theory no more than
   one GSS_Unwrap() attempt for each matching CCM-BIND context will
   succeed.  If multiple succeed, then clearly the underlying mechanism
   is informed doing poor job at generating "unique" session keys.  CCM
   implementations that detect this SHOULD log it should use
   CCM/Kerberos V5.  Via so that the RPCSEC_GSS protocol, problem in
   the server
   authenticates underlying mechanism can be discovered and fixed.

9.2.  CCM-BIND Versus CCM-MIC

   The first time a CCM context is needed between an principal on the end-user
   initiator and a principal on the client with Kerberos V5. The
   context tokens exchanged over RPCSEC_GSS are wrapped inside CCM
   tokens.

3.  Token Formats

   This section discusses target, the protocol visible tokens initiator has no choice
   but to create an underlying mechanism context via a CCM-BIND context
   token exchange.  Once that GSS consumers
   exchange when using CCM.

3.1.  Mechanism Object Identifier

   The object identifier used by is done, subsequent 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 contexts between
   the initiator and target can be created via CCM-MIC.  CCM-MIC context
   establishment is not better because no more than one round trip is
   necessary to establish a complete mechanism OID. Complete CCM
   mechanism OIDs must consist context, and because the overhead of the CCM prefix OID, followed by
   establishing a real real, underlying mechanism OID, such as that of Kerberos V5 as context is avoided.

9.3.  Initiating CCM-MIC Contexts

   The key issue is how to associate an CCM-BIND established security
   context with a new CCM-MIC context, There no existing interfaces
   defined in [RFC1964]. the GSS-API for associating one GSS defines context with another.
   This then is the generic part key issue for implementations of a token CCM-MIC.

   We will assume that GSS-API implementation is 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 C programming
   language and therefore the GSS-API C bindings [RFC2744] are being
   used.  The CCM specific part
   of each token.

3.2.  Context Establishment Tokens

3.2.1.  Initial Context Token

   GSS requires mechanism implementation will have a table that maps
   gss_targ_ctx 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 initial context handles as
   returned in a response token from the initiator CCM target.  In addition, each
   CCM context has a reference to its underlying mechanism context.

   Let us suppose the
   target application decides it will use CCM-MIC.  CCM-MIC
   has a well known mechanism OID which the format as described in section 3.1 of RFC2743. application can check for.
   The
   format consists of point where the initiator calls GSS_Init_sec_context(), is a mechanism independent prefix, and
   logical place to associate an existing CCM-BIND context with a mechanism
   dependent suffix. new
   CCM-MIC context.  Here is where special CCM handling is necessary in
   order to associate a security context with a CCM context.  We discuss
   several approaches.

   1.   The mechanism independent token includes first approach is for the
   MechType field.  Note that MechType must contain CCM-MIC's GSS_Init_sec_context()
        entry point to pass as the prefix CCM OID
   followed claimant_cred_handle the
        output_context_handle as returned by GSS_Init_sec_context() for
        a previously created CCM-BIND context.  Such an approach may
        work well with applications that normally pass
        GSS_C_NO_CREDENTIAL as the claimant_cred_handle.

   2.   The second approach derives from the observation that normally,
        the underlying mechanism OID. This first time GSS_Init_sec_context() is necessary so that called, the target's context acceptance entry point knows that CCM input_token
        field is being
   used, NULL and which underlying mechanism the initial context_handle (type gss_ctx_id_t)
        is being used.

   RFC2743 refers also NULL.  The input_token is supposed to be the mechanism dependent token as
        received from the
   innerContextToken. This is target's context acceptance routine, which has
        the CCM specific token and XDR type CCM_MIC_resp_t.  Overloading the input_token is defined as
   follows, one
        way.  By passing 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, /* a non-null input_token, and a NULL pointer
        to the context_handle (using the C bindings calling conventions
        for gss_init_sec_context()), this will tell the CCM-MIC
        initiator that input_token containing information 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;
      } CCM_nonce_t;

      /* creation of CCM
        associate a new CCM-MIC context via with an existing underlying context */ CCM-BIND
        context.  In the C programming language, we could thus have have
        input_token containing:

           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;
                gss_ctx_id_t context_ptr;
           } 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. CCM_MIC_initiator_bootstrap_t;
        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 entry point for creating contexts can be established via on the CCM_TKN_LONG
   route or initiator side
        would, if being called for the first time (*context_handle is
        NULL), interpret the CCM_TKN_SHORT route. The disadvantage presence of the
   CCM_TKN_LONG route is that input token with an invalid
        status as the underlying mechanism context set up
   must be repeated, which can be time consuming. Whereas, CCM_MIC_initiator_bootstrap_t.  It would use
        context_ptr to lookup the
   CCM_TKN_SHORT route merely requires that  corresponding gss_targ_ctx in the first CCM context's
   underlying mechanism context be available
        aforementioned gss_ctx_id_t to produce an integrity
   checksum.  When an application wants gss_targ_ctx mapping table.  It
        would then proceed 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 an output token encoded as follows. The ccm_ctx_handle
   is what was returned by the target XDR
        type CCM_MIC_init_t, described in response to the creation section entitled "Initial
        Context Token for CCM-MIC".

   Regardless 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 approach taken, the short_token relative first time GSS_Init_sec_context
   is called, assuming success, it will return GSS_S_CONTINUE_NEEDED,
   because it will need to process the long_token that token returned by the
   initiator target.
   The second time it is assigning. called, assuming success, it will return
   GSS_S_COMPLETE.

9.4.  Accepting CCM-MIC Contexts

   The CCM-MIC target receives an opaque gss_targ_ctx value for ctx_sh_number is selected by as part of
   the initiator such that it is larger than any previous ctx_sh_number
   for given ccm_ctx_handle.  This way, mechanism dependent part of the initial context token.
   Originally, this opaque handle came from the target need only keep track as a result of
   previously creating a context via a CCM-BIND context exchange.  If
   the largest ctx_sh_number received. The mic_nonce field opaque handle is equal
   to still valid, then the output of Gss_GetMIC() as applied to target can easily
   determine the nonce field, using original CCM-BIND context, and from that, the underlying CCM-BIND
   mechanism's context.

3.2.2.  Subsequent Context Tokens

   A subsequent context token  With the underlying context, GSS_VerifyMIC()
   can be any subsequent context token from invoked (with a qop_req of CCM_REAL_QOP (1)) to verify the initiator context initialization entry point, or any response
   context from
   mic_nonce of 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 input token, and has GSS_GetMIC() can be used to
   generate the previously described type mic_init_tkn field of type CCM_ict_t. Note
   that the value of output token.  By comparing
   the field tkn_type will always be CCM_TKN_LONG 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
   subsequent context short token.

3.2.2.2.  Response Token

   The

9.5.  Non-Token Generating GSS-API Routines

   Since the CCM response token, module will record the underlying mechanism's context
   pointer in XDR encoding is:

      typedef enum {
              CCM_OK = 0,

              /*
               * Target 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 support short generate any 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 for the target.

               */
              CCM_SHORT_TKN_REPLAY = 5,

              /*
               * The underlying mechanism had GSS peer.  When CCM is called
   for such 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 operation, it simply re-invokes the GSS-API call, but on
   the recorded underlying context token (CCM_TKN_LONG) or
               * a MIC token (CCM_TKN_SHORT) of context.

9.6.  CCM-MIC and GSS_Delete_sec_context()

   The CCM-MIC entry point for GSS_Delete_sec_context() should not call
   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; underlying mechanism's GSS_Delete_sec_context() routine.  If a value of it
   did, this would effectively delete all CCM-MIC context's associating
   with the same underlying mechanism.

9.7.  GSS Status Codes

9.7.1.  Status Codes for CCM-BIND

   CCM-BIND mechanisms define no minor status response token codes.  If the underlying
   mechanism is CCM_OK, not available, then the CCM
   context has either been established on the target, or the process a CCM-BIND mechanism will return
   GSS_S_BAD_MECH and minor status of
   context establishment zero.  Otherwise, it will continue (because return
   whatever major and minor status codes 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 mechanism
   returns.

9.7.2.  Status Codes for CCM-MIC

   Generally, major and minor status codes for this
   convolution will be apparent in whatever major
   and minor status codes the section entitled "Implementation
   Issues".

   Support underlying CCM-BIND mechanism returns.
   However, for short tokens GSS_Init_sec_context() and GSS_Accept_sec_context(),
   this is optional. If they not the case because the those operations are supported, then
   sh_tkn_supp is invoking
   routines (GSS_Wrap() and GSS_Unwrap()) that have major statuses that
   are not subsets of the legal status returns from
   GSS_Init_sec_context() and GSS_Accept_sec_context().  Moreover, in
   some cases for GSS_Init_sec_context(), the minor and major status are
   driven from the target, and the target's codes will not always be
   among the legal set to TRUE, otherwise it for GSS_Init_sec_context().

9.7.2.1.  CCM-MIC: GSS_Accept_sec_context() status codes

   The minor status code for GSS_Accept_sec_context is always from the
   set to FALSE. defined in the CCM_MIC_status_t type.  If
   sh_tkn_supp is FALSE, GSS_Unwrap() reports a
   major status failure, then ccm_ctx_handle should the minor status will be a zero length
   string; there's no point in returning a useful ccm_ctx_handle if
   short tokens are not supported.

   If
   CCM_ERR_TKN_UNWRAP, and the response token is in response reported major status will what
   GSS_Unwrap() reports, with exceptions as according to the following
   table:
      major status code from GSS_Unwrap      major status code reported
                                             by GSS_Accept_sec_context
                                             to caller.
      -----------------------------------------------------------------
      GSS_S_BAD_SIG                          GSS_S_BAD_SIG
      GSS_S_CONTEXT_EXPIRED                  GSS_S_DEFECTIVE_TOKEN
      GSS_S_GAP_TOKEN                        GSS_S_DEFECTIVE_TOKEN
      GSS_S_UNSEQ_TOKEN                      GSS_S_DUPLICATE_TOKEN

   If GSS_GetMIC() reports a long_token, major status failure, then tkn_type
   is set to CCM_TKN_LONG, the minor status
   will be CCM_ERR_TKN_GET_MIC, and tkn_stuff is equal to the output_token reported major status will be
   what GSS_GetMIC() reports, with exceptions as
   returned by the underlying mechanism's context acceptance routine on according to the target.
   following table:
      major status code from GSS_GetMIC      major status code reported
                                             by GSS_Accept_sec_context()
                                             to caller.

      ------------------------------------------------------------------
      GSS_S_BAD_QOP                          GSS_S_FAILURE
      GSS_S_CONTEXT_EXPIRED                  GSS_S_DEFECTIVE_TOKEN

   The value of tkn_body.ccm_ctx_handle is selected such
   that it uniquely identifies target will always report the CCM context handle, so that it can be
   referred actual GSS major and minor codes to for the purpose creating subsequent tokens via
   the
   CCM_TKN_SHORT route.

   If initiator.  The initiator will map the response token is GSS major code as
   described in response to a long_token, then tkn_type the next subsection.

9.7.2.2.  CCM-MIC: GSS_Init_sec_context() status codes

   The minor status code for GSS_Init_sec_context is always from the set to CCM_TKN_SHORT, and tkn_stuff is equal to
   defined in the output of a
   GSS_GetMIC() of tkn_body.nonce using CCM_MIC_status_t type.

   If the context minor status code came from the underlying
   mechanism. target, then that will always
   be what GSS_Init_sec_context() reports.  The value most of tkn_body.nonce.dir is set the minor codes
   from the target are to CCM_DIR_T_TO_I.
   The value of  tkn_body.nonce.ctx_sh_number is set be mapped to the value major status code as follows:
      minor status code          major status code
      from target                reported to caller of
   ctx_sh_number
                                 GSS_Init_sec_context()
      ----------------------------------------------------
      CCM_OK                     GSS_S_COMPLETE
      CCM_ERR_HANDLE_MALFORMED   GSS_S_DEFECTIVE_TOKEN
      CCM_ERR_HANDLE_EXPIRED     GSS_S_CREDENTIALS_EXPIRED
      CCM_ERR_HANDLE_NOT_FOUND   GSS_S_CREDENTIALS_EXPIRED
      CCM_ERR_TKN_REPLAY         GSS_S_DUPLICATE_TOKEN
      CCM_ERR_CHAN_MISMATCH      GSS_S_BAD_BINDINGS
      CCM_ERR_TKN_WRAP           GSS_S_FAILURE
      CCM_ERR_TKN_VER_MIC        GSS_S_FAILURE

   Note that was in the initiator's context token.

3.3.  MIC Token

   This token corresponds to above table CCM_ERR_TKN_WRAP and CCM_ERR_TKN_VER_MIC
   MUST not be returned by the PerMsgToken type as defined in section
   3.1 of RFC2743.

      typedef void CCM_mic_t;

   The CCM_mic_t token target.  But if they are, then the
   initiator reports GSS_S_FAILURE.

   If the minor status code from the target is a void value because CCM performs no integrity
   checksum. A programming API that calls GSS_GetMIC() CCM_ERR_TKN_UNWRAP or
   CCM_ERR_TKN_GET_MIC, then the target will thus produce
   an octet string of zero length.

3.4.  Wrap Token

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

      typedef opaque CCM_wrap_t<>;

   This token is always equal to major
   status code it got from GSS_Unwrap() or GSS_GetMIC().  The major
   status from the input provided target will be be reported by GSS_Init_sec_context()
   to its caller with exceptions as according to GSS_Wrap().

3.5.  Delete Token

   This token is output the following table:
      major status code from GSS_Delete_sec_context().

      typedef opaque CCM_del_t<>;

   This token is always equal target          major status code reported
                                             by GSS_Init_sec_context()
                                             to whatever token caller
      -----------------------------------------------------------------
      GSS_S_BAD_QOP                          GSS_S_FAILURE
      GSS_S_BAD_SIG                          GSS_S_BAD_SIG
      GSS_S_CONTEXT_EXPIRED                  GSS_S_DEFECTIVE_TOKEN
      GSS_S_GAP_TOKEN                        GSS_S_DEFECTIVE_TOKEN
      GSS_S_UNSEQ_TOKEN                      GSS_S_DUPLICATE_TOKEN
   If GSS_Wrap() fails on the underlying
   mechanism's GSS_Delete_sec_context entry point produces.

4.  Implementation Issues

   The "over initiator, then the wire" aspects of CCM have been completely specified.
   However, GSS is usually implemented as an Application Programming
   Interface (the GSS-API), minor status will be
   CCM_ERR_TKN_WRAP, and security mechanisms are often
   implemented as modules that are plugged into the GSS-API. It is
   useful major status will what GSS_Wrap() reports,
   with exceptions as according 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 following table:
      major status code from GSS_Wrap      major status code reported
                                           by GSS_Init_sec_context()
                                           to caller
      ---------------------------------------------------------------
      GSS_S_CONTEXT_EXPIRED                GSS_S_DEFECTIVE_TOKEN
                                              or
                                           GSS_S_DEFECTIVE_CREDENTIAL

      GSS_S_BAD_QOP                        GSS_S_FAILURE

   If GSS_VerifyMIC() fails on the
   initiator initiator, then the minor status will
   be CCM_ERR_TKN_VER_MIC, and a principal on the target, major status will what
   GSS_VerifyMIC() reports, with exceptions as according to the initiator has no choice
   but
   following table:
      major status code from GSS_VerifyMIC  major status code reported
                                            by GSS_Init_sec_context()
                                            to create an underlying mechanism context via caller
      ---------------------------------------------------------------
      GSS_S_CONTEXT_EXPIRED                 GSS_S_DEFECTIVE_TOKEN
      GSS_S_GAP_TOKEN                       GSS_S_DEFECTIVE_TOKEN
      GSS_S_UNSEQ_TOKEN                     GSS_S_DUPLICATE_TOKEN

9.8.  Channel Bindings on the long token
   context exchange. Once that is done, subsequent Target

   When an application invokes GSS_Accept_sec_context() on a CCM tokens between token,
   it won't know if channel bindings are required or not.  Of course, it
   could inspect the initiator OID of the input_token and target can use short tokens. Short tokens are
   better because with them, no more than one round trip determine the channel
   bindings directly if it is necessary to
   establish a CCM context, and because CCM-BIND token, but normally
   applications will not parse the overhead of mechanism OID in an input token.  And
   in any case, such inspection for a CCM-MIC token provides no
   information about channel bindings to the underlying
   mechanism context establishment is avoided.

4.2.  Initiating Contexts Via Short Tokens target application.

   The key issue is how application on the target will have to associate an CCM established security context
   with a new try
   GSS_Accept_sec_context() without channel bindings.  If the target CCM context. There are no existing interfaces defined
   existing programming language
   mechanism requires channel bindings of GSS-API for doing so. This
   section suggests one possible implementation approach.

   We (as indicated by the
   GSS_S_BAD_BINDINGS), then the application will assume that GSS-API implementation is in have to re-invoke
   GSS_Accept_sec_context() with the C programming
   language and therefore right channel bindings.  If the GSS-API C
   channel bindings [RFC2744] are being
   used. The the wrong type, then the CCM mechanism implementation will
   indicate GSS_S_BAD_BINDINGS again.  The application will have a table that maps
   ccm_ctx_handle values to gss_ctx_id_t values (see section 5.19
   iterate through all the valid types of
   [RFC2744]). The latter are GSS-API context handles as returned by
   gss_init_sec_context(). bindings.  The former are the context handles as
   returned in a response token from application can
   avoid this iteration if the bindings includes both, address and key
   bindings if at all possible.  The CCM target. In addition, each
   CCM context has a reference to its underlying mechanism context.

   Let us suppose the application decides it will mechanisms should use CCM. CCM has a
   well known mechanism OID. The point where only
   those parts of the initiator calls
   GSS_Init_sec_context(), is application-provided bindings that they care for.

10.  Advice for NFSv4 Implementors

   The NFSv4.0 specification does not mandate CCM, so clients and
   servers should not insist on its use.  When a logical place to associate an existing
   CCM context with server wants a new CCM context. Here is where special CCM
   handling is necessary in order client
   to associate try to use CCM, it can return a security context NFS4ERR_WRONGSEC error to the
   client.  The client will then follow up with a
   CCM context. GSS_Init_sec_context() accepts several different inputs.
   Normally, SECINFO request.  The
   response to the SECINFO request should list first time GSS_Init_sec_context() is called, the
   input_token field is NULL.  Overloading CCM-BIND
   mechanisms it supports, second the input_token is one way to
   associate a new CCM with CCM-MIC mechanism (if supported),
   and finally, the an existing CCM conventional 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:

                      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 flavors the response_token field server will be
   set accept
   for access to TRUE, and file object.  If the token processed as if client supports CCM, it came from the target as
   described  in the section entitled "Response Token". will use
   it.  Otherwise, the
   caller sets response_token it will have to FALSE.  The caller fills in the
   variable length array bootstrap.context_ptr stick with the number of octets
   necessary to store a pointer to a GSS-API security context.  In conventional flavor.

   Since the C
   programming language, we would thus have something like:

      /*
       * What follows is not what an XDR compiler would produce,
       * but instead CCM-MIC OID is general, rather than 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 separate CCM-MIC OID
   for every real mechanism, the first time, interpret the presence of
   the input token as a CCM_initiator_bootstrap_t type.  It uses
   bootstrap.context_ptr NFS server will have be careful to lookup the  corresponding ccm_ctx_handle in make
   sure that a CCM-MIC context is authorized access an object.  For
   example suppose /export is exported such that SPKM-3 is the aforementioned gss_ctx_id_t
   authorized underlying mechanism, and CCM-NULL + SPKM-3 and CCM-MIC
   are similarly authorized to ccm_ctx_handle mapping table.  It
   would access /export.  Suppose CCM-NULL is
   created over a Kerberos V5 context, and then proceed CCM-MIC is used to generate an output token formatted as
   derived a
   CCM_TKN_SHORT initial context token as described in section entitled
   "Initial Context Token".

   The first time GSS_Init_sec_context from the CCM-NULL context.  If the NFS server
   simply records that the OID of CCM-MIC is called, assuming success, it
   will return GSS_S_CONTINUE_NEEDED, because it will need authorized to process access
   /export, then Kerberos V5 authenticated users will be mistakenly
   allowed access.  Instead, the token returned by server needs to examine what context
   the target. The second time it CCM-MIC context is called,
   assuming success, it will return GSS_S_COMPLETE, provided associated with, and check that context's OID
   against 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 authorized list of OIDs for /export.

11.  Man in the
   mechanism dependent part of initial context token.  Originally, Middle Attacks without CCM-KEY

   In this
   opaque handle came from example, NFS with/ RPCSEC_GSS will be the target as a result of previously creating
   a context via a long token.  If application, and
   IPsec the opaque handle is still valid,
   then secure channel.

   Man in the target can easily determine middle (MITM) avoidance means making sure that the original CCM context, client
   and
   from that, server are the underlying mechanism's context. With same at both layers, NFS and IPsec, but since the underlying
   context, GSS_VerifyMIC() can
   principal names at the one layer will be invoked to verify radically different from the mic_nonce of
   names at the input token, and GSS_GetMIC() other, how can one be used certain that there is no MITM at
   the IPsec layer before leaving it to IPsec to provide session
   protection to generate the
   mic_none of NFS layer?  The answer is to use channel bindings,
   which, conceptually, are an exchange, at the output token. By comparing NFS/GSS layer, of
   signatures of the ctx_sh_number in principal names or session ID/keys involved at the
   initiator's token
   IPsec layer.

   Consider an attacker who can cause a client's IPsec stack to
   establish an SA with highest value recorded the attacker, instead of the server intended by
   the target, NFS layer (this is accomplished by spoofing the
   target takes care to ensure DNS server).
   Suppose further that initiator has not replayed a short
   token.

4.4.  Non-Token Generating GSS-API Routines

   Since the CCM module will record attacker can fool the underlying mechanism's context
   pointer in client's IPsec layer
   without also fooling its internal data structures, this provides a simple
   answer to what NFS/RPCSEC_GSS layer (for example, if
   Kerberos V5 is being used as the real mechanism, and avoids the use
   of DNS to do when GSS-API canonicalize the server principal name -- admittedly, this
   avoidance is invoked on unlikely -- a CCM context that
   does DNS spoof attack will be detected by the
   NFS client, because the Kerberos Key Distribution Center (KDC)
   generates tickets associated with pairs of principals, not generate any tokens for host
   names).  Suppose that the GSS peer. When CCM attacker's host is called for
   such an operation, it simply re-invokes in part of the GSS-API call, but on site's
   IPsec infrastructure (perhaps the
   recorded underlying context.

4.5.  Minor Status Codes

   The values defined in CCM_status_t serve as attacker broke into that host).
   Then 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 attacker might be able to use CCM, it can return act as a NFS4ERR_WRONGSEC error to MITM between 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 who gets all the plain text and even gets to file object. If modify
   it, if CCM-NULL is wrapping Kerberos V5 at the RPCSEC_GSS level.
   Both, the client supports CCM, it will and the server would see that IPsec is in use it.
   Otherwise, it will have
   between them, but they would each see a different ID for its IPsec
   peer.  Channel bindings are used to stick prove that the client and server
   each see the same two peer names at the lower (in this case, IPsec)
   layer, and therefore with a conventional flavor.

6. CCM-KEY there is no MITM.

   DNSSEC would of course defeat the attack, but DNSSEC was not, at the
   time this document was written, in widespread use.

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

   *    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
        SHOULD not be used for subsequent sessions or transport
        connections.  In other words, full initiator to target
        authentication should 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 establish
        another, unauthenticated session or connection.  For efficiency,
        it is permissible to use
        a CCM CCM-BIND context from a previous session MAY be used to
        establish another CCM context via a short token. CCM-MIC context.

        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 SHOULD NOT be used
        with applications that do not have sessions or do not use
        connection oriented transports.

   *    The underlying secure channel should 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 being used behind a firewall that performs network address
        translation.  It is possible to have an IPsec secure channel from
        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 mandated by CCM-KEY, 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 without the use of CCM-KEY, the initiator and
        target applications would have no way of knowing that.

   *    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 initiator to message.  The use of CCM-KEY enforces
        this binding.

   *    When the firewall, and a second same secure channel from is multiplexing traffic for
        multiple users, the firewall initiator has to ensure the target, but not from the initiator CCM context is
        only accessible to the
        target. So, if initiator principal that has established
        it in the firewall first place.  One possible way to ensure that is compromised by an attacker
        placing CCM contexts in the
        middle, the use of privileged address space offering
        only controlled indexed access.

   *    CCM to avoid per message authentication is
        useless. Furthermore, without channel bindings, it is does not
        possible unnecessarily inflate the scope of the trust
        domain, as does for example AUTH_SYS [RFC1831] over IPSec.  By
        requiring the initiator and target to enforce end to end
        channel security. Of course, if authentication in the initiator's node created CCM context initialization
        (using a
        IP-layer tunnel between it and previously established context), the target, end trust domain does
        not extend to end channel
        security would be achieved, but the initiator client.

   *    Both the traditional mechanisms and target
        applications would have no way CCM rely on the security of knowing that.

        A future variant
        the client to protect locally logged on users.  Compromise of
        the client impacts all users on the same client.  CCM will mandate does not
        make the implementation of problem worse.

   *    The CCM context MUST be established over the same secure channel bindings for IPsec, SSH, and TLS, such
        that the session
        keying material of each of the aforementioned three protocols subsequent message traffic will be available using.  This way,
        the binding between the initial authentication and the
        subsequent traffic is ensured.  Again, the use of CCM-KEY is one
        way to underlying mechanisms like Kerberos V5 assert this binding.

   *    The section entitled "CCM-KEY and
        SPKM [RFC2847]. This Anonymous IPsec", suggests a
        method for simulating anonymous IPsec via self-signed
        certificates.  If one is careless, this is will allow an initiator and target to
        enforce end to end channel security that cannot neuter all IPsec
        authentication, a real problem for those applications not using
        CCM-KEY.  The use of the self-signed certificates in IPsec
        should be compromised restricted by an attacker port in the middle. This variant IPsec Security Policy
        Database (SPD) only to those application using CCM-KEY.  Note
        however, that port selector support is not specified in
        this document because the session-key-based channel bindings in
        GSS-API and OPTIONAL in specific mechanisms are not fully specified. IPsec.

   *    It has been stated that it    If an application is not uncommon to find using IPsec
        deployments and is not using CCM-KEY, then
        then the site where multiple nodes share common private keys
        [Black]. The use of CCM the application is discouraged in such environments,
        since deployed should configure
        the compromise of one node compromises all IPsec SPD to carefully limit the other ports and nodes
        sharing the same private key.

   *    Applications using CCM must ensure that the binding between the
        CCM context are
        allowed create security  associations to application targets.

   *    CCM-KEY's IPsec bindings use public SA information, and CCM-
        ADDR's bindings are simply public network addresses.  If the
        secure channel is legitimate for each
        message that references IPsec, and non-anonymous certificates are used
        with IKE, then a MITM cannot spoof the CCM context. In other words, target's and initiator's
        IP addresses, because the
        referenced CCM context in a message must attacker will presumably be established in unable to
        spoof the
        same secure channel Certificate Authority that signed the certificates.
        Thus, when IPsec is used as the message. secure channel, and non-
        anonymous certificates are used with IKE, CCM-ADDR is as secure
        as CCM-KEY.

   *    When    CCM contexts should not be used forever without re-
        authenticating periodically via the same secure channel underlying mechanism.  One
        rational approach is multiplexing traffic for
        multiple users, the initiator has CCM context to ensure persist no longer
        than the underlying mechanism context.  Implementing this via
        the CCM context GSS-API is
        only accessible simple.  Applications can periodically invoke
        gss_context_time() to find out how long the initiator principal that has established
        it in context will be
        valid.  Moreover, CCM can enforce this by invoking
        gss_context_time() and the first place. One possible way system time of day API to ensure that is by
        placing CCM contexts in get an
        expiration date when the privileged address space offering
        only controlled indexed access.

   * CCM does not unnecessarily inflate mechanism is established.  Each
        subsequent call can check the scope time of day against the trust
        domain, as does for example AUTH_SYS [RFC1831] over IPSec. By
        requiring
        expiration, and if expired, return GSS_S_CONTEXT_EXPIRED.

13.  IANA Considerations

   XXX Note 1 to IANA: The CCM-BIND mechanism OID prefixes and the authentication CCM-
   MIC mechanism OID must be assigned and registered by IANA.  Please
   look for TBD1 in this document and notify the CCM context initialization
        (using a previously established context), RFC Editor what value
   you have assigned.

   XXX Note 1 to RFC Editor: When IANA has made the trust domain does
        not extend OID assignments,
   please do the following:

   *    Delete the "XXX Note 1 to RFC Editor: ..." paragraph.

   *    Replace occurrences of TBD1 with the client. value assigned by IANA.

   *    Both    Replace the traditional mechanisms "XXX Note 1 to IANA: ..." paragraph with:
             OIDs for the CCM-BIND mechanism prefix, and CCM rely on for the security of CCM-MIC
             mechanism have been assigned by, and registered with IANA,
             with this document as the client reference.

   XXX Note 2 to protect locally logged on users. Compromise of IANA: Please assign RPC flavor numbers for values
   currently place held in this document as TBD2 through TBD10.  Also
   please establish the
        client impact all users on registry that RFC2623 mandates.

   XXX Note 2 to RFC Editor: When IANA has made the same client. CCM does not make RPC flavor number
   assignments, please do the problem worse. following:

   *    The CCM context must be established over    Delete the same secure channel
        that "XXX Note 2 to RFC Editor: ..." paragraph.

   *    Replace occurrences of TBD2 through and including TBD10 withe
        flavor number assignments from IANA.

   Section 6, "IANA Considerations" of [RFC2623] established a registry
   for mapping GSS mechanism OIDs to RPC pseudo flavor numbers.  This
   registry was augmented in the subsequent message traffic will be using. NFSv4 specification [RFC3530] with
   several more entries.  This may, the
        binding between the initial authentication and document adds the subsequent
        traffic is ensured.

7.  IANA Considerations

   Other than following entries to
   the registration registry:

    1 == number of the CCM pseudo flavor
    2 == name of pseudo flavor
    3 == mechanism's OID prefix, there are no IANA
   considerations.

8.
    4 == quality of protection
    5 == RPCSEC_GSS service

   1          2               3                4 5
   --------------------------------------------------------------
   TBD2  ccm-mic         1.3.6.1.5.5.TBD1.2    0 rpc_gss_svc_none

   TBD3  ccm-null-krb5   1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none
                         1.2.840.113554.1.2.2

   TBD4  ccm-addr-krb5   1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none
                         1.2.840.113554.1.2.2

   TBD5  ccm-key-krb5    1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none
                         1.2.840.113554.1.2.2

   TBD6  ccm-null-spkm3  1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

   TBD6  ccm-addr-spkm3  1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

   TBD7  ccm-key-spkm3   1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

   TBD8  ccm-null-lipkey 1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

   TBD9  ccm-addr-lipkey 1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

   TBD10 ccm-addr-lipkey 1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none
                         1.3.6.1.5.5.1.3

14.  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, and Julian
   Satran,
   and Nicolas Williams for their critical comments.  Much of the text for the
   "Security Considerations" section comes directly from David and Peng.

9.

15.  Normative References

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

   [RFC2025]
        C. Adams, RFC2025: "The Simple Public-Key GSS-API Mechanism
        (SPKM)," October 1996, Status: Standards Track.

   [RFC2119]
        S. Bradner, RFC2119, "Key words for use in RFCs to Indicate
        Requirement Levels," March 1997.

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

   [RFC2409]
        D. Harkins and D. Carrel, RFC2119: "The Internet Key Exchange
        (IKE)," November 1998.

   [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

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

   [RFC2847]
        M. Eisler, RFC2847: "LIPKEY - A Low Infrastructure Public Key
        Mechanism Using SPKM," June 2000, Status: Standards Track.

   [FIPS]U.S. Department of Commerce / National Institute of Standards
        and Technology, FIPS PUB 180-1, "Secure Hash Standard", August, 1995.

10. May 11,
        1993.

   [IKEv2]
        C. Kaufman, draft-ietf-ipsec-ikev2-07.txt: "Internet Key
        Exchange (IKEv2) Protocol," A work in progress, April 2003.

        XXX - Note 3 to RFC Editor: In the event this work in progress
        is not approved for publication when the CCM document is, then
        the sections of the CCM document that refer to IKEv2 in a
        normative manner are to be removed for submission as a separate
        document.

   [SSHv2]
        T. Ylonen et. al., draft-ietf-secsh-transport-15.txt: "SSH
        Transport Layer Protocol," A work in progress, September 2002.

        XXX - Note 4 to RFC Editor: In the event this work in progress
        is not approved for publication when the CCM document is, then
        the sections of the CCM document that refer to SSHv2 in a
        normative manner are to be removed for submission as a separate
        document.

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

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

   [RFC2744]
        J. Wray, RFC2744, "Generic Security Service API

   [RFC2623]
        M. Eisler, RFC2623, "NFS Version 2 : C-
        bindings", January, 2000. and Version 3 Security Issues
        and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", June
        1999.

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

   [Black]
        D. Black, Email 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

17.  Authors' Addresses

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

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

12.

   Nicolas Williams
   Sun Microsystems, Inc.
   5300 Riata Trace CT
   Austin, TX 78727
   USA

   EMail: nicolas.williams@sun.com

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

13.

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