Network Working Group M. Eisler Internet-Draft Network Appliance, Inc. Document: draft-eisler-nfsv4-ccm-00.txt February 2003 CCM: The Credential Cache GSS Mechanism Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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. The document also defines how RPCSEC_GSS uses CCM. TABLE OF CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 Expires: August 2003 [Page 1] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 2. Overview of CCM . . . . . . . . . . . . . . . . . . . . . . . 3 3. Token Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Context Establishment Tokens . . . . . . . . . . . . . . . . 4 3.1.1. Initial Context Token . . . . . . . . . . . . . . . . . . 4 3.1.2. Response Token . . . . . . . . . . . . . . . . . . . . . . 4 3.1.3. Additional Context Tokens . . . . . . . . . . . . . . . . 5 3.2. MIC Token . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Delete Token . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Issues . . . . . . . . . . . . . . . . . . . . 6 4.1. Initiating Contexts . . . . . . . . . . . . . . . . . . . . 6 4.2. Accepting Contexts . . . . . . . . . . . . . . . . . . . . . 7 4.3. Non-Token Generating GSS-API Routines . . . . . . . . . . . 8 4.4. Minor Status Codes . . . . . . . . . . . . . . . . . . . . . 8 5. How RPCSEC_GSS Uses CCM . . . . . . . . . . . . . . . . . . . 8 6. Advice for NFSv4 Implementors . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . 11 11. Informative References . . . . . . . . . . . . . . . . . . 11 12. Author's Address . . . . . . . . . . . . . . . . . . . . . 11 13. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 11 14. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The GSS framework provides a general means for authenticating clients and servers, as well as providing a general means for encrypting and integrity protecting data exchanged during a session. GSS specifies formats for a set of tokens for authentication, integrity, and privacy. The formats consists of a mechanism independent form, and a mechanism dependent form. An example of a mechanism dependent forms is the Kerberos V5 mechanism definition [RFC1964]. It is possible for a protocol to use GSS for one time authentication, or for per message authentication. An example of the former is DAFS [DAFS]. An example of the latter is RPCSEC_GSS. Obviously, it is more secure to authenticate each message. On the other hand, it is also more expensive. However, if at a lower layer in the protocol stack, the data stream the upper layer protocol (one that is using GSS) is protected from tampering, such as via a cryptographic checksum, it may not be necessary to additionally authenticate each message of the upper layer protocol. Instead, it may suffice to use GSS to authenticate at the beginning of the upper layer protocol's session. To take advantage of one time authentication, existing consumers of GSS that authenticate exclusively on each message have to change. One Expires: August 2003 [Page 2] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 way to change is to modify the protocol that is using GSS. This has disadvantages including, introducing a protocol incompatibility, and effectively introducing another authentication paradigm. Another way to change, is the basis of the proposal in this document: the Credential Cache Mechanism (CCM). CCM allows a GSS initiator and target to bind a previously created GSS security content over a non- CCM mechanism, to a CCM security context. Since CCM is yet another mechanism under the CCM, the effect is that there are no modifications to the protocol the GSS consumer is using. 2. Overview of CCM Let us use RPCSEC_GSS and NFSv4 [RFC3010] as an example. Basic understanding of the RPCSEC_GSS protocol is assumed. NFSv4 has a SECINFO operation which can be used by a client to ask the server which GSS mechanism to use. If a client uses the wrong security mechanism, the server returns the NFS4ERR_WRONGSEC error. Let us say the client and server are using Kerberos V5 [RFC1964] to secure the traffic. Suppose the TCP connection NFSv4 uses is secured with IPsec. It is therefore not necessary for NFSv4/RPCSEC_GSS to use integrity or privacy. Fortunately, RPCSEC_GSS has an authentication mode, whereby only the header of each remote procedure call and response is integrity protected. So, this minimizes the overhead somewhat, but there is still the cost of the headers being checksummed. Since IPsec is protecting the connection, incurring even that minimal per remote procedure call overhead may not be necessary. Enter CCM. The server authenticates the end-user on the client with Kerberos V5. This happens as result of one complete round trip of an NFSv4 COMPOUND procedure using RPCSEC_GSS over a Kerberos V5 security content. Next, the server determines that IPsec is protecting the connection. As a result, the next time the client issues a an NFSv4 operation with the Kerberos V5 context, the server returns NFS4ERR_WRONGSEC. The client issues another SECINFO, and is told to use CCM. The client, via the RPCSEC_GSS protocol proceeds to create a CCM context. The innerContextToken of the InitialContextToken contains the RPCSEC_GSS handle that corresponds to the Kerberos V5 context. The server verifies the handle corresponds to a valid Kerberos V5 context, and returns a response token (and another RPCSEC_GSS handle) confirming the use of CCM. Internally the server makes a record to associate the second handle with the original handle. The client then issues its first remote procedure call using the established CCM context. The server maps the CCM context's RPCSEC_GSS handle to original handle, which in turn maps to the original Kerberos V5 context, which in turn maps to user principal issuing the request. The server has thus identified the user without incurring Expires: August 2003 [Page 3] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 the cost of a cryptographic operation. 3. Token Formats This section discusses the protocol visible tokens that GSS consumers exchange when using CCM. The object identifier used by CCM is: {iso(1)identified-organization(3)dod(6)internet(1)security(5) mechanisms(5)ccm( Too Be Defined/Registered with IANA, but at time of this writing, slot 11 was available )} GSS defines the generic part of a token in ASN.1 encoding. GSS does not require ASN.1 for mechanism specific part of a token. This document uses XDR [RFC1832] encoding for the CCM specific part of each token. 3.1. Context Establishment Tokens 3.1.1. Initial Context Token GSS requires that the initial context token from the initiator to the target uses the format as described in section 3.1 of RFC2743. After the mechanism independent token, the CCM specific token follows. It is defined as follows, in XDR description language: typedef opaque CCM_ict_t<>; The type CCM_ict_t is for an opaque object that is used by the application protocol (that uses GSS) to refer to a previously established GSS context. For application protocols that deal with no more than one GSS context per connection, this opaque object can be a zero length string of octets. 3.1.2. Response Token GSS prescribes no form for the response token to the initial context token. The CCM response token, in XDR encoding is: typedef enum { CCM_OK = 0; CCM_HANDLE_MALFORMED = 1; CCM_HANDLE_EXPIRED = 2; CCM_HANDLE_NOT_FOUND = 3; } CCM_status_t; typedef union switch (bool response_token) { case TRUE: CCM_status_t status; Expires: August 2003 [Page 4] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 case FALSE: void; } CCM_rict_t; If a value of the status response token is CCM_OK, then the CCM context has been established on the server. The target must always set the response_token boolean type to TRUE. The reason for this convolution will be apparent in the section entitled "Implementation Issues". 3.1.3. Additional Context Tokens The context setup handshake between the initiator and target is a single round trip. There are no additional context tokens (no tokens of ASN.1 type SubsequentContextToken). 3.2. MIC Token This token corresponds to the PerMsgToken type as defined in section 3.1 of RFC2743. typedef void CCM_mic_t; The CCM_mic_t token is a void value because CCM performs no integrity checksum. A programming API that calls GSS_GetMIC() will thus produce an octet string of zero length. 3.3. Wrap Token This token corresponds to the SealedMessage type as defined in section 3.1 of RFC2743. typedef opaque CCM_wrap_t<>; This token is always equal to the input provided to GSS_Wrap(). 3.4. Delete Token This token is output from GSS_Delete_sec_context(). typedef void CCM_del_t; The CCM_del_t token is a void value because CCM sends no information with context deletion. A programming API that calls GSS_Delete_sec_context() will thus produce an octet string of zero length. Expires: August 2003 [Page 5] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 4. Implementation Issues The "over the wire" aspects of CCM have been completely specified. However, GSS is usually implemented as an Application Programming Interface (the GSS-API), and security mechanisms are often implemented as modules that are plugged into the GSS-API. It is useful to discuss implementation issues and workable resolutions. The reader is cautioned that the author has not implemented CCM, so what follows is at best a series of educated guesses. 4.1. Initiating Contexts The key issue is how to associate an established security context over one mechanism with that of a CCM context. There are no existing interfaces defined in GSS-API for doing so. Since CCM is predicated on the application's protocol being able to manage the handles it uses for match initiator and target security contents, any such solution is going to require that the application give special treatment to CCM. Thus implementing CCM as a complete module that plugs into the GSS-API may not be necessary. Nor may it even be possible. Let us suppose the application decides it will use CCM. CCM has a well known mechanism OID. The point where the initiator calls GSS_Init_sec_context(), seems to be the logical place to associate an existing context with a CCM context. Here is where special CCM handling is necessary in order to associate a security context with a CCM context. GSS_Init_sec_context() accepts several different inputs. Normally, the first time GSS_Init_sec_context() is called, the input_token field is NULL. Overloading the input_token is one way (if not the ideal way) to associate CCM with the an existing security content. In XDR description language, we can thus imagine the following CCM initial input token format: typedef struct { opaque context_ptr<>; opaque application_ctx_handle<>; } CCM_initiator_bootstrap_t; typedef union switch (bool response_token) { case TRUE: CCM_status_t status; case FALSE: CCM_initiator_bootstrap_t bootstrap; } CCM_init_sec_context_input_token; If this was a response token, then the response_token field will be set to TRUE, and the token processed as if it came from the target as described in the section entitled "Response Token". Otherwise, the caller sets response_token to FALSE. The caller fills in the subsequent variable length array with the number of octets necessary Expires: August 2003 [Page 6] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 to store a pointer to a GSS-API security content. The second array contains the handle (if any), the application's protocol uses to match initiator security contexts with target contexts. In the C programming language, we would thus have something like: /* * What follows is not what an XDR compiler would produce, * but instead is a optimal form for C programming * environments. */ typedef struct { void *context_ptr; unsigned int len_application_ctx_handle; void *application_ctx_handle; } CCM_initiator_bootstrap_t; typedef struct { bool response_token; union { CCM_status_t status; CCM_initiator_bootstrap_t bootstrap; } u; } CCM_init_sec_context_input_token; The CCM entry point for creating contexts on the initiator side would, if being called for the first time (response_token is FALSE), interpret the respect of the input token as a CCM_initiator_bootstrap_t type. It would then record the context_ptr (the context CCM is associating with), and then proceed to generate an output token equal to to what application_ctx_handle points to. The first time GSS_Init_sec_context is called, assuming success, it will return GSS_S_CONTINUE_NEEDED, because it will need to process the token returned by the target. The second time it is called, assuming success, it will return GSS_S_COMPLETE. 4.2. Accepting Contexts On the target side, we cannot use the a technique similar to what was done on the initiator because the token from the initiator is non- NULL and moreover, has a prescribed format. The CCM target receives an opaque value (or handle) as the mechanism dependent part of initial context token. Originally, this opaque handle came from the target as a result of previously creating a context (the context CCM wants to associate with). The target is thus free to form the handle in any form it wants. The most general form of the handle would include the following information: Expires: August 2003 [Page 7] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 * A unique identifier for the application protocol, assuming GSS- API is being used for multiple applications in the same address space, which is a normal situation for implementations of GSS in operating system kernels. The identifier would be unique across the target's address space. * A reference to the GSS context that CCM wants to associate with. When the target's GSS_Accept_sec_context interface processes the input token, it could then do the following: * Map the application protocol identifier to an operations vector that includes a routine for mapping the GSS context reference to a context pointer. * Invoke the mapping routine, passing the protocol identifier and the context reference as arguments. * Record the context returned by the mapping routine as the context CCM is associating with. * If no context is returned, then generate an output token that has a status of other than CCM_OK. Otherwise generate a token that returns CCM_OK. 4.3. Non-Token Generating GSS-API Routines Since the CCM module will record the associated context's context pointer in its internal data structures, this provides a simple solution to the issue of what to do when GSS-API is invoked on a CCM context that does not generate any tokens for the GSS peer. When CCM is called for such an operation, it simply re-invokes the GSS-API call, but on the recorded associated context. 4.4. Minor Status Codes The values defined in CCM_status_t serve as the minor status codes for CCM. 5. How RPCSEC_GSS Uses CCM Any application protocol that uses CCM must have an end to end agreement on the composition of the initial context token from initiator to the target. The initial context token for CCM is encoded as the XDR type CCM_ict_t as described previously in this document. RPCSEC_GSS is a consumer of GSS, and so can be thought of as the application protocol (and not for example NFSv4, which is layered above). Section 5.2.3.1 of RFC2203 describes the RPCSEC_GSS Expires: August 2003 [Page 8] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 protocol's rpc_gss_init_res structure, and within that structure, a field called "handle" which "serves as the context identifier". The handle field of the rpc_gss_init_res is what the RPCSEC_GSS initiator must use as the content of CCM_ict_t. Note that XDR data type CCM_ict_t and that of rpc_gss_init_res's handle field are exactly the same. 6. Advice for NFSv4 Implementors The NFSv4.0 specification does not mandate CCM, so clients and servers should not insist on its use. When a server wants a client to use CCM, it can return a NFS4ERR_WRONGSEC error to the client. The client will then follow up with a SECINFO request. The response to the SECINFO request should list first CCM and then the conventional security flavors the server will accept for access to file object. If the client supports CCM, it will use it. Otherwise, it will have to stick with a conventional flavor. The server should record some state with the RPCSEC_GSS context that indicates whether a "downgrade" to CCM attempt was made. An example will further illustrate. Suppose NFSv4 is being used over a TCP connection to access a filesystem that the system administrator has configured to be protected via krb5i. Both client and server, via programming interfaces provided by their operating environments, determine that the connection is protected with IPsec. The client therefore issues any SECINFO with AUTH_NONE, since it knows the SECINFO will not be tampered with. The server knows the connection is protected, so rather than requiring { RPCSEC_GSS, Kerberos V5 , privacy } of the client, it requires { RPCSEC_GSS, Kerberos V5, authentication } (krb5). The client then issues one remote procedure call using krb5, which creates a GSS-API security context that is associated with an RPCSEC_GSS handle. The server authenticates the client, processes the operation, and retuns the result. The next time the client uses the same security context and handle, the server returns NFS4ERR_WRONGSEC. After the ensuing SECINFO call the server tells the client to use { RPCSEC_GSS, CCM, authentication }, followed by { RPCSEC_GSS, CCM, authentication } (in case the client does not support CCM. The client then handshakes with the server to create an RPCSEC_GSS context over CCM. Thereafter, as long as the connection remains protected with CCM, the client does not have to use Kerberos V5 again. To reduce round trips, optimizations are possible in above example. Since the client knows IPsec is securing the connection, it can guess that CCM will be permitted. If it already has a CCM context for principal/server pair, it can try to use CCM. If it does not have a CCM context, but has another GSS-API context for the principal/server Expires: August 2003 [Page 9] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 pair, it can optimistically create a CCM context over RPCSEC_GSS. Similarly, since the server knows the connection is protected, when it gets a SECINFO request, it can encode its first three tuple as { RPCSEC_GSS, CCM, authentication}, followed by a tuple with Kerberos V5 in it. If the client has a CCM context for the principal, it can use it on the next remote procedure call. Otherwise, via the second tuple, it knows that it has to use Kerberos V5 to create a Kerberos V5 context from which to derive the CCM context. 7. Security Considerations There are many considerations for the use CCM, since it is reducing security at one protocol layer in trade for equivalent security at another layer. In this discussion, we will assume that cryptography is being used in the application and lower protocol layers. * CCM should not be used whenever the combined key strength/algorithm strength of the lower protocol layer securing the connection is weaker than what the associated GSS context can provide. * CCM should not be used if the lower level protocol does not offer comparable or superior security services that the application would achieve with GSS. For example, if the lower level protocol offers integrity, but the application wants privacy, then CCM is inappropriate. * The use of CCM contexts over secured connections can be characterized nearly secure instead of as secure as using the associated GSS context for protecting each application message procedure call. The reason is that applications can multiplex the traffic of multiple principals over a single connection and so the ciphertext in the traffic is encrypted with multiple session keys. Whereas, a secure connection method such as IPsec is protected with per host sessions keys. Therefore, an attacker has more cipher text to perform cryptanalysis via connections protected with IPsec, versus connections protected with GSS. 8. IANA Considerations There are no issues for IANA. 9. Acknowledgements Dave Noveck, for the observation that NFS version 4 servers could downgrade from integrity service to plain authentication service if IPsec was enabled. Expires: August 2003 [Page 10] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 10. Normative References [RFC2743] J. Linn, Internet RFC2743, "Generic Security Service Application Program Interface Version 2, Update 1", January, 2000. [RFC2203] M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS Protocol Specification", September, 1997. [RFC1832] R. Srinivasan, Internet RFC1832, "XDR: External Data Representation Standard", August, 1995. 11. Informative References [RFC1964] J. Linn, Internet RFC1964, "The Kerberos Version 5 GSS-API Mechanism", June 1996. [DAFS] Mark Wittle (Editor), "DAFS Direct Access File System Protocol, Version: 1.00", September 1, 2001. [RFC3010] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck, RFC3010, "NFS version 4 Protocol", December 2000. 12. Author's Address Mike Eisler 5765 Chase Point Circle Colorado Springs, CO 80919 USA Phone: 719-599-9026 EMail: mike@eisler.com 13. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the Expires: August 2003 [Page 11] INTERNET-DRAFT CCM: The Credential Cache GSS Mechanism February 2003 IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 14. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than 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: August 2003 [Page 12]