One document matched: draft-ietf-nfsv4-ccm-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-18 23:25:32 |