Network Working Group M. Eisler Internet-Draft Network Appliance, Inc. Document: draft-ietf-nfsv4-ccm-00.txt May 2003 CCM: The Credential Cache GSS Mechanism Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html ABSTRACT This document describes a new mechanism under the GSS [RFC2743]. Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate every message transfer, thereby incurring significant overhead due to the costs of cryptographic computation. While hardware-based cryptographic accelerators can mitigate such overhead, it is more likely that acceleration will be available for lower layer protocols, such as IPsec [RFC2401] than for upper layer protocols like RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- independent upper layer protocols to leverage the data stream protections of lower layer protocols, without the inconvenience of modifying the upper layer protocol to do so. TABLE OF CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Overview of CCM . . . . . . . . . . . . . . . . . . . . . . . 3 3. Token Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 Expires: December 2003 [Page 1] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 3.1. Mechanism Object Identifier . . . . . . . . . . . . . . . . 4 3.2. Context Establishment Tokens . . . . . . . . . . . . . . . . 4 3.2.1. Initial Context Token . . . . . . . . . . . . . . . . . . 4 3.2.2. Subsequent Context Tokens . . . . . . . . . . . . . . . . 6 3.2.2.1. Subsequent Initiator Context Initialization Token . . . 6 3.2.2.2. Response Token . . . . . . . . . . . . . . . . . . . . . 6 3.3. MIC Token . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Delete Token . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Implementation Issues . . . . . . . . . . . . . . . . . . . . 8 4.1. Long Tokens Versus Short Tokens . . . . . . . . . . . . . . 9 4.2. Initiating Contexts Via Short Tokens . . . . . . . . . . . . 9 4.3. Accepting Contexts Via Short Tokens . . . . . . . . . . . 10 4.4. Non-Token Generating GSS-API Routines . . . . . . . . . . 11 4.5. Minor Status Codes . . . . . . . . . . . . . . . . . . . . 11 5. Advice for NFSv4 Implementors . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 10. Informative References . . . . . . . . . . . . . . . . . . 14 11. Author's Address . . . . . . . . . . . . . . . . . . . . . 15 12. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 15 13. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction The GSS framework provides a general means for authenticating clients and servers, as well as providing a general means for encrypting and integrity protecting data exchanged during a session. GSS specifies formats for a set of tokens for authentication, integrity, and privacy. The formats consist of a mechanism independent form, and a mechanism dependent form. An example of a set of mechanism dependent forms is the Kerberos V5 mechanism definition [RFC1964]. It is possible for a protocol to use GSS for one time authentication, or for per message authentication. An example of the former is DAFS [DAFS]. An example of the latter is RPCSEC_GSS. Obviously, it is more secure to authenticate each message. On the other hand, it is also more expensive. However, suppose the data stream of the upper layer protocol (the layer using GSS) is protected at a lower layer protocol from tampering, such as via a cryptographic checksum. If so, it may not be necessary to additionally authenticate each message of the upper layer protocol. Instead, it may suffice to use GSS to authenticate at the beginning of the upper layer protocol's session. To take advantage of one time authentication, existing consumers of GSS that authenticate exclusively on each message have to change. One way to change is to modify the protocol that is using GSS. This has Expires: December 2003 [Page 2] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 disadvantages including, introducing a protocol incompatibility, and effectively introducing another authentication paradigm. Another way to change, is the basis of the proposal in this document: the Credential Cache Mechanism (CCM). CCM allows a GSS initiator and target to bind to a security context of a non-CCM mechanism. Since CCM is yet another mechanism under the GSS, the effect is that there are no modifications to the protocol the GSS consumer is using. 2. Overview of CCM CCM is a "wrapper" mechanism over the set of all other GSS-API mechanisms. When CCM creates a context, it invokes an underlying mechanism to create a child context. CCM determines the underlying mechanism by examining the mechanism object identifier (OID) that it is called with. The prefix will always be the OID of CCM, and the suffix will be the OID of the underlying mechanism. The context initiation and acceptance entry points of CCM wrap the resulting the context tokens with a CCM header. Let us use RPCSEC_GSS and NFSv4 [RFC3010] as an example. Basic understanding of the RPCSEC_GSS protocol is assumed. If an NFSv4 client uses the wrong security mechanism, the server returns the NFS4ERR_WRONGSEC error. The client can then use NFSv4's SECINFO operation to ask the server which GSS mechanism to use. Let us say the client and server are using Kerberos V5 [RFC1964] to secure the traffic. Suppose the TCP connection NFSv4 uses is secured with IPsec. It is therefore not necessary for NFSv4/RPCSEC_GSS to use integrity or privacy. Fortunately, RPCSEC_GSS has an authentication mode, whereby only the header of each remote procedure call and response is integrity protected. So, this minimizes the overhead somewhat, but there is still the cost of the headers being checksummed. Since IPsec is protecting the connection, incurring even that minimal per remote procedure call overhead may not be necessary. Enter CCM. The server detects that the connection is protected with IPsec. Via SECINFO, the client is informed that it should use CCM/Kerberos V5. Via the RPCSEC_GSS protocol, the server authenticates the end-user on the client with Kerberos V5. The context tokens exchanged over RPCSEC_GSS are wrapped inside CCM tokens. 3. Token Formats This section discusses the protocol visible tokens that GSS consumers exchange when using CCM. Expires: December 2003 [Page 3] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 3.1. Mechanism Object Identifier The object identifier used by CCM is: {iso(1)identified-organization(3)dod(6)internet(1)security(5) mechanisms(5)ccm-family( Too Be Defined/Registered with IANA, but at time of this writing, slot 11 was available )ccm-1(1)} This object identifier is not a complete mechanism OID. Complete CCM mechanism OIDs must consist of the CCM prefix OID, followed by a real mechanism OID, such as that of Kerberos V5 as defined in [RFC1964]. GSS defines the generic part of a token in ASN.1 encoding. GSS does not require ASN.1 for the mechanism specific part of a token. This document uses XDR [RFC1832] encoding for the CCM specific part of each token. 3.2. Context Establishment Tokens 3.2.1. Initial Context Token GSS requires that the initial context token from the initiator to the target use the format as described in section 3.1 of RFC2743. The format consists of a mechanism independent prefix, and a mechanism dependent suffix. The mechanism independent token includes the MechType field. Note that MechType must contain the prefix CCM OID followed by the underlying mechanism OID. This is necessary so that the target's context acceptance entry point knows that CCM is being used, and which underlying mechanism is being used. RFC2743 refers to the mechanism dependent token as the innerContextToken. This is the CCM specific token and is defined as follows, in XDR description language: /* creation of CCM context via new underlying context */ typedef struct { opaque wrapped_token<>; } CCM_wrapped_token_t; typedef enum { CCM_DIR_I_TO_T = 0, /* initiator to target */ CCM_DIR_T_TO_I = 1 /* target to initiator */ } CCM_direction_t; typedef struct { CCM_direction_t dir; unsigned int ctx_sh_number; Expires: December 2003 [Page 4] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 } CCM_nonce_t; /* creation of CCM context via existing underlying context */ typedef struct { CCM_nonce_t nonce; opaque ccm_ctx_handle<>; opaque mic_nonce<>; } CCM_wrapped_mic_t; typedef enum { CCM_TKN_LONG = 0, CCM_TKN_SHORT = 1 } CCM_tkn_type_t; /* innerContextToken */ typedef union switch (CCM_tkn_type_t tkn_type) { case CCM_TKN_LONG: CCM_wrapped_token_t long_token; case CCM_TKN_SHORT: CCM_wrapped_mic_t short_token; } CCM_ict_t; When tkn_type is CCM_TKN_LONG, the initiator is simultaneously initiating a CCM context and an underlying mechanism context, thereby producing a long token. A long token is the most straightforward way to create a CCM context, though as will be described later, not necessarily the most efficient way. The long_token's wrapped_token field contains an entire InitialContextToken as generated by the underlying mechanism's context initiation end point. Once an initiator has established an initial CCM context with a target, additional contexts can be established via the CCM_TKN_LONG route or the CCM_TKN_SHORT route. The disadvantage of the CCM_TKN_LONG route is that the underlying mechanism context set up must be repeated, which can be time consuming. Whereas, the CCM_TKN_SHORT route merely requires that the first CCM context's underlying mechanism context be available to produce an integrity checksum. When an application wants to use CCM over multiple sessions and/or multiple connections, it can either generate long tokens with each new session or connection or it can generate short tokens. The short_token is computed as follows. The ccm_ctx_handle is what was returned by the target in response to the creation of a context from a long token request. It uniquely identifies the target's previously created context. The subfield nonce.dir is set to CCM_DIR_I_TO_T. The subfield nonce.ctx_sh_number is the identifier of the short_token relative to the long_token that the initiator is assigning. The value for ctx_sh_number is selected by the initiator such that it is larger than any previous ctx_sh_number for given ccm_ctx_handle. This way, the target need only keep track Expires: December 2003 [Page 5] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 of the largest ctx_sh_number received. The mic_nonce field is equal to the output of Gss_GetMIC() as applied to the nonce field, using the underlying mechanism's context. 3.2.2. Subsequent Context Tokens A subsequent context token can be any subsequent context token from the initiator context initialization entry point, or any response context from the target's context acceptance entry point. The GSS specification [RFC2743] does not prescribe any format. 3.2.2.1. Subsequent Initiator Context Initialization Token The subsequent initiator context initialization token is encoded in XDR and has the previously described type of type CCM_ict_t. Note that the value of the field tkn_type will always be CCM_TKN_LONG in a subsequent context token. 3.2.2.2. Response Token The CCM response token, in XDR encoding is: typedef enum { CCM_OK = 0, /* * Target does not support short tokens */ CCM_SHORT_TKN_NOT_SUPP = 1, /* * ccm_ctx_handle was malformed. */ CCM_HANDLE_MALFORMED = 2, /* * GSS context corresponding to ccm_ctx_handle expired. */ CCM_HANDLE_EXPIRED = 3, /* * ccm_ctx_handle was not found. */ CCM_HANDLE_NOT_FOUND = 4, /* * The ctx_sh_number has already been received * by the target. Expires: December 2003 [Page 6] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 */ CCM_SHORT_TKN_REPLAY = 5, /* * The underlying mechanism had an error. */ CCM_UNDER_MECH_ERR = 6 } CCM_status_t; typedef struct { CCM_status_t status; bool sh_tkn_supp; union switch (CCM_tkn_type_t tkn_type) { case CCM_TKN_LONG: opaque ccm_ctx_handle<>; case CCM_TKN_SHORT: CCM_nonce_t nonce; } tkn_body; /* * Either the underlying context token (CCM_TKN_LONG) or * a MIC token (CCM_TKN_SHORT) of the nonce. */ opaque tkn_stuff<>; } CCM_real_rict_t; /* response token */ typedef union switch (bool response_token) { case TRUE: CCM_real_rict_t resp; case FALSE: void; } CCM_rict_t; If a value of the status response token is CCM_OK, then the CCM context has either been established on the target, or the process of context establishment will continue (because the underlying mechanism's context acceptance entry point returns GSS_S_CONTINUED_NEEDED to the caller). The target must always set the response_token boolean type to TRUE. The reason for this convolution will be apparent in the section entitled "Implementation Issues". Support for short tokens is optional. If they are supported, then sh_tkn_supp is set to TRUE, otherwise it is set to FALSE. If sh_tkn_supp is FALSE, then ccm_ctx_handle should be a zero length string; there's no point in returning a useful ccm_ctx_handle if short tokens are not supported. If the response token is in response to a long_token, then tkn_type Expires: December 2003 [Page 7] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 is set to CCM_TKN_LONG, and tkn_stuff is equal to the output_token as returned by the underlying mechanism's context acceptance routine on the target. The value of tkn_body.ccm_ctx_handle is selected such that it uniquely identifies the CCM context handle, so that it can be referred to for the purpose creating subsequent tokens via the CCM_TKN_SHORT route. If the response token is in response to a long_token, then tkn_type is set to CCM_TKN_SHORT, and tkn_stuff is equal to the output of a GSS_GetMIC() of tkn_body.nonce using the context the underlying mechanism. The value of tkn_body.nonce.dir is set to CCM_DIR_T_TO_I. The value of tkn_body.nonce.ctx_sh_number is set to the value of ctx_sh_number that was in the initiator's context token. 3.3. MIC Token This token corresponds to the PerMsgToken type as defined in section 3.1 of RFC2743. typedef void CCM_mic_t; The CCM_mic_t token is a void value because CCM performs no integrity checksum. A programming API that calls GSS_GetMIC() will thus produce an octet string of zero length. 3.4. Wrap Token This token corresponds to the SealedMessage type as defined in section 3.1 of RFC2743. typedef opaque CCM_wrap_t<>; This token is always equal to the input provided to GSS_Wrap(). 3.5. Delete Token This token is output from GSS_Delete_sec_context(). typedef opaque CCM_del_t<>; This token is always equal to whatever token the underlying mechanism's GSS_Delete_sec_context entry point produces. 4. Implementation Issues The "over the wire" aspects of CCM have been completely specified. However, GSS is usually implemented as an Application Programming Interface (the GSS-API), and security mechanisms are often implemented as modules that are plugged into the GSS-API. It is Expires: December 2003 [Page 8] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 useful to discuss implementation issues and workable resolutions. The reader is cautioned that the author has not implemented CCM, so what follows is at best a series of educated guesses. 4.1. Long Tokens Versus Short Tokens The first time a CCM context is needed between an principal on the initiator and a principal on the target, the initiator has no choice but to create an underlying mechanism context via the long token context exchange. Once that is done, subsequent CCM tokens between the initiator and target can use short tokens. Short tokens are better because with them, no more than one round trip is necessary to establish a CCM context, and because the overhead of the underlying mechanism context establishment is avoided. 4.2. Initiating Contexts Via Short Tokens The key issue is how to associate an CCM established security context with a new CCM context. There are no existing interfaces defined existing programming language bindings of GSS-API for doing so. This section suggests one possible implementation approach. We will assume that GSS-API implementation is in the C programming language and therefore the GSS-API C bindings [RFC2744] are being used. The CCM mechanism implementation will have a table that maps ccm_ctx_handle values to gss_ctx_id_t values (see section 5.19 of [RFC2744]). The latter are GSS-API context handles as returned by gss_init_sec_context(). The former are the context handles as returned in a response token from the CCM target. In addition, each CCM context has a reference to its underlying mechanism context. Let us suppose the application decides it will use CCM. CCM has a well known mechanism OID. The point where the initiator calls GSS_Init_sec_context(), is a logical place to associate an existing CCM context with a new CCM context. Here is where special CCM handling is necessary in order to associate a security context with a CCM context. GSS_Init_sec_context() accepts several different inputs. Normally, the first time GSS_Init_sec_context() is called, the input_token field is NULL. Overloading the input_token is one way to associate a new CCM with the an existing CCM security context. In XDR description language, we can thus imagine the following CCM initial input token format: typedef struct { opaque context_ptr<>; } CCM_initiator_bootstrap_t; typedef union switch (bool response_token) { case TRUE: Expires: December 2003 [Page 9] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 CCM_real_rict_t resp; case FALSE: CCM_initiator_bootstrap_t bootstrap; } CCM_init_sec_context_input_token_t; If this was a response token, then the response_token field will be set to TRUE, and the token processed as if it came from the target as described in the section entitled "Response Token". Otherwise, the caller sets response_token to FALSE. The caller fills in the variable length array bootstrap.context_ptr with the number of octets necessary to store a pointer to a GSS-API security context. In the C programming language, we would thus have something like: /* * What follows is not what an XDR compiler would produce, * but instead is a optimal form for C programming * environments. */ typedef struct { gss_ctx_id_t context_ptr; } CCM_initiator_bootstrap_t; typedef struct { bool response_token; union { CCM_status_t status; CCM_initiator_bootstrap_t bootstrap; } u; } CCM_init_sec_context_input_token_t; The CCM entry point for creating contexts on the initiator side would, if being called for the first time, interpret the presence of the input token as a CCM_initiator_bootstrap_t type. It uses bootstrap.context_ptr to lookup the corresponding ccm_ctx_handle in the aforementioned gss_ctx_id_t to ccm_ctx_handle mapping table. It would then proceed to generate an output token formatted as a CCM_TKN_SHORT initial context token as described in section entitled "Initial Context Token". The first time GSS_Init_sec_context is called, assuming success, it will return GSS_S_CONTINUE_NEEDED, because it will need to process the token returned by the target. The second time it is called, assuming success, it will return GSS_S_COMPLETE, provided the underlying mechanism also returns GSS_S_COMPLETE. 4.3. Accepting Contexts Via Short Tokens The CCM target receives an opaque ccm_ctx_handle value as part of the Expires: December 2003 [Page 10] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 mechanism dependent part of initial context token. Originally, this opaque handle came from the target as a result of previously creating a context via a long token. If the opaque handle is still valid, then the target can easily determine the original CCM context, and from that, the underlying mechanism's context. With the underlying context, GSS_VerifyMIC() can be invoked to verify the mic_nonce of the input token, and GSS_GetMIC() can be used to generate the mic_none of the output token. By comparing the ctx_sh_number in the initiator's token with highest value recorded by the target, the target takes care to ensure that initiator has not replayed a short token. 4.4. Non-Token Generating GSS-API Routines Since the CCM module will record the underlying mechanism's context pointer in its internal data structures, this provides a simple answer to what to do when GSS-API is invoked on a CCM context that does not generate any tokens for the GSS peer. When CCM is called for such an operation, it simply re-invokes the GSS-API call, but on the recorded underlying context. 4.5. Minor Status Codes The values defined in CCM_status_t serve as the minor status codes for CCM. 5. Advice for NFSv4 Implementors The NFSv4.0 specification does not mandate CCM, so clients and servers should not insist on its use. When a server wants a client to try to use CCM, it can return a NFS4ERR_WRONGSEC error to the client. The client will then follow up with a SECINFO request. The response to the SECINFO request should list first a CCM mechanism and then the conventional security flavors the server will accept for access to file object. If the client supports CCM, it will use it. Otherwise, it will have to stick with a conventional flavor. 6. Security Considerations There are many considerations for the use CCM, since it is reducing security at one protocol layer in trade for equivalent security at another layer. In this discussion, we will assume that cryptography is being used in the application and lower protocol layers. * CCM should not be used whenever the combined key strength/algorithm strength of the lower protocol layer securing the connection is weaker than what the underlying GSS context can provide. Expires: December 2003 [Page 11] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 * CCM should not be used if the lower level protocol does not offer comparable or superior security services to that the application would achieve with GSS. For example, if the lower level protocol offers integrity, but the application wants privacy, then CCM is inappropriate. * The use of CCM contexts over secured connections can be characterized nearly secure instead of as secure as using the underlying GSS context for protecting each application message procedure call. The reason is that applications can multiplex the traffic of multiple principals over a single connection and so the ciphertext in the traffic is encrypted with multiple session keys. Whereas, a secure connection method such as IPsec is protected with per host session keys. Therefore, an attacker has more cipher text per session key to perform cryptanalysis via connections protected with IPsec, versus connections protected with GSS. * Related to the previous bullet, the management of private keys for a secure channel is often outside the control of the user of CCM. If the secure channel's private keys are compromised, then all users of the secure channel are compromised. * CCM contexts created during one session or transport connection should not be used for subsequent sessions or transport connections. In other words, full initiator to target authentication should occur each time a session or transport connection is established. Otherwise, there is nothing preventing an attacker from using a CCM context from one authenticated session or connection to trivially established another, unauthenticated session or connection. For efficiency, it is permissible to use a CCM context from a previous session to establish another CCM context via a short token. If the application protocol using CCM has no concept of a session and does not use a connection oriented transport, then there is no sequence of state transitions that tie the CCM context creation steps with the subsequent message traffic of the application protocol. Thus it can be hard to assert that the subsequent message traffic is truly originated by the CCM initiator's principal. For this reason, CCM is not appropriate for use with applications that do not have sessions or do not use connection oriented transports. * The underlying secure channel should be end to end, from initiator to the target. It is permissible for the user to configure the underlying secure channel to not be end to end, but this should only be done if user has confidence in the intermediate end points. For example, suppose the application is Expires: December 2003 [Page 12] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 being used behind a firewall that performs network address translation. It is possible to have an IPsec secure channel from the initiator to the firewall, and a second secure channel from the firewall to the target, but not from the initiator to the target. So, if the firewall is compromised by an attacker in the middle, the use of CCM to avoid per message authentication is useless. Furthermore, without channel bindings, it is not possible for the initiator and target to enforce end to end channel security. Of course, if the initiator's node created a IP-layer tunnel between it and the target, end to end channel security would be achieved, but the initiator and target applications would have no way of knowing that. A future variant of CCM will mandate the implementation of channel bindings for IPsec, SSH, and TLS, such that the session keying material of each of the aforementioned three protocols will be available to underlying mechanisms like Kerberos V5 and SPKM [RFC2847]. This will allow an initiator and target to enforce end to end channel security that cannot be compromised by an attacker in the middle. This variant is not specified in this document because the session-key-based channel bindings in GSS-API and in specific mechanisms are not fully specified. * It has been stated that it is not uncommon to find IPsec deployments where multiple nodes share common private keys [Black]. The use of CCM is discouraged in such environments, since the compromise of one node compromises all the other nodes sharing the same private key. * Applications using CCM must ensure that the binding between the CCM context and the secure channel is legitimate for each message that references the CCM context. In other words, the referenced CCM context in a message must be established in the same secure channel as the message. * When the same secure channel is multiplexing traffic for multiple users, the initiator has to ensure the CCM context is only accessible to the initiator principal that has established it in the first place. One possible way to ensure that is by placing CCM contexts in the privileged address space offering only controlled indexed access. * CCM does not unnecessarily inflate the scope of the trust domain, as does for example AUTH_SYS [RFC1831] over IPSec. By requiring the authentication in the CCM context initialization (using a previously established context), the trust domain does not extend to the client. * Both the traditional mechanisms and CCM rely on the security of Expires: December 2003 [Page 13] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 the client to protect locally logged on users. Compromise of the client impact all users on the same client. CCM does not make the problem worse. * The CCM context must be established over the same secure channel that the subsequent message traffic will be using. This may, the binding between the initial authentication and the subsequent traffic is ensured. 7. IANA Considerations Other than the registration of the CCM OID prefix, there are no IANA considerations. 8. Acknowledgements Dave Noveck, for the observation that NFS version 4 servers could downgrade from integrity service to plain authentication service if IPsec was enabled. David Black, Peng Dai, Sam Hartman, Julian Satran, and Nicolas Williams for their critical comments. Much of the text for the "Security Considerations" section comes directly from Peng. 9. Normative References [RFC2743] J. Linn, Internet RFC2743, "Generic Security Service Application Program Interface Version 2, Update 1", January, 2000. [RFC1832] R. Srinivasan, Internet RFC1832, "XDR: External Data Representation Standard", August, 1995. 10. Informative References [RFC1831] R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call Protocol Specification Version 2", August, 1995. [RFC1964] J. Linn, Internet RFC1964, "The Kerberos Version 5 GSS-API Mechanism", June 1996. [RFC2203] M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS Protocol Specification", September, 1997. Expires: December 2003 [Page 14] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 [RFC2401] S. Kent, R. Atkinson, RFC2401, "Security Architecture for the Internet Protocol ", November, 1998. [RFC2744] J. Wray, RFC2744, "Generic Security Service API Version 2 : C- bindings", January, 2000. [RFC3530] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck, RFC3010, "Network File System (NFS) version 4 Protocol", April 2003. [Black] D. Black, Email message on the NFSv4 working group alias, February 28, 2003. [DAFS] Mark Wittle (Editor), "DAFS Direct Access File System Protocol, Version: 1.00", September 1, 2001. 11. Author's Address Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA Phone: 719-599-9026 EMail: mike@eisler.com 12. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary Expires: December 2003 [Page 15] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism May 2003 rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 13. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: December 2003 [Page 16]