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]