draft-ietf-nfsv4-rpcsec-gss-v2-01.txt   draft-ietf-nfsv4-rpcsec-gss-v2-02.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track February 20, 2008 Intended status: Standards Track February 24, 2008
Expires: August 23, 2008 Expires: August 27, 2008
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-01.txt draft-ietf-nfsv4-rpcsec-gss-v2-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 23, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
Version 2 is the same as Version 1 but adds support for channel Version 2 is the same as Version 1 but adds support for channel
bindings. bindings.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3
2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3 2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3
3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . . 4 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . . 4
3.1. New Version Number . . . . . . . . . . . . . . . . . . . . 4 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . . 4
3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 4 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 4
3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 5 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5
3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6
4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6
5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 8
1. Introduction and Motivation 1. Introduction and Motivation
RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version
1 (RPCSEC_GSSv1) except that support for channel bindings has been 1 (RPCSEC_GSSv1) except that support for channel bindings has been
added. The primary motivation for channel bindings is to securely added. The primary motivation for channel bindings is to securely
take advantage of hardware assisted encryption that might exist at take advantage of hardware assisted encryption that might exist at
skipping to change at page 3, line 27 skipping to change at page 3, line 27
Once an RPCSEC_GSS target and initiator are mutually assured that Once an RPCSEC_GSS target and initiator are mutually assured that
they are each using the same secure, end to end channel, the overhead they are each using the same secure, end to end channel, the overhead
of computing message integrity codes (MICs) for authenticating and of computing message integrity codes (MICs) for authenticating and
integrity protecting RPC requests and replies can be eliminated integrity protecting RPC requests and replies can be eliminated
because the channel is performing the same function. Similarly, if because the channel is performing the same function. Similarly, if
the channel also provides confidentiality, the overhead of RPCSEC_GSS the channel also provides confidentiality, the overhead of RPCSEC_GSS
privacy protect can also be eliminated. privacy protect can also be eliminated.
2. Channel Bindings Explained 2. Channel Bindings Explained
If a channel between two parties is secure, there must be a shared If a channel between two parties is secure, there must be shared
secret known between the two parties. Either this secret is an information between the two parties. This information might be
inherent part of the channel, or, because the channel is secure, and secret or not. The requirement for secrecy depends on the specifics
has the option of confidentiality, the secret can be exchanged at any of the channel.
time. A higher layer protocol using the secure channel can safely
exploit the channel to the mutual benefit of the higher level parties
if each higher level party can prove:
o They each know the channel's shared secret. For example, the shared information could be the concatenation of the
public key of the source and destination of the channel (where each
public key has a corresponding private key). Suppose the channel is
not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are
two channels, one from the initiator to the MITM, and one from the
MITM to the target. The MITM cannot simply force each channel to use
the same public keys, because the public keys come from private keys,
and the key management system for each node will surely assign unique
or random private keys. At most the MITM can force one end of each
channel to use the same public key. The MIC of public keys from the
initiator will not be verified by the target, because at least one of
public keys will be different. Similarly, the MIC of the public keys
from the target will not be verified by the initiator because at
least one of the public keys will be different.
o The proof of the knowledge of the shared secret is in fact being A higher layer protocol using the secure channel can safely exploit
conveyed by each of the higher level parties, and not some other the channel to the mutual benefit of the higher level parties if each
entities. higher level party can prove:
o They each know the channel's shared information.
o The proof of the knowledge of the shared information is in fact
being conveyed by each of the higher level parties, and not some
other entities.
RPCSEC_GSSv2 simply adds an optional round trip that has the RPCSEC_GSSv2 simply adds an optional round trip that has the
initiator compute a GSS MIC on the channel binding secret, and send initiator compute a GSS MIC on the channel binding's shared
the MIC to the target. The target verifies the MIC, and in turn information, and sends the MIC to the target. The target verifies
sends its own MIC of the secret back to the initiator which verifies the MIC, and in turn sends its own MIC of the shared information to
the target's MIC. This accomplishes three things. First the the initiator which verifies the target's MIC. This accomplishes
initiator and target are mutually authenticated. Second, the three things. First the initiator and target are mutually
initiator and target prove they know the channel's shared secret, and authenticated. Second, the initiator and target prove they know the
thus are using the same channel. Third, the first and second thing channel's shared information, and thus are using the same channel.
are done simultaneously. Third, the first and second things are done simultaneously.
3. The RPCSEC_GSSv2 Protocol 3. The RPCSEC_GSSv2 Protocol
The RPCSEC_GSSv2 protocol is now explained. The entire protocol is The RPCSEC_GSSv2 protocol will now be explained. The entire protocol
not presented. Instead the differences between RPCSEC_GSSv2 and is not presented. Instead the differences between RPCSEC_GSSv2 and
RPCSEC_GSSv1 are shown. RPCSEC_GSSv1 are shown.
3.1. New Version Number 3.1. Compatibility with RPCSEC_GSSv1
The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.
3.2. New Version Number
const RPCSEC_GSS_VERS_1 = 1; const RPCSEC_GSS_VERS_1 = 1;
const RPCSEC_GSS_VERS_2 = 2; /* new */ const RPCSEC_GSS_VERS_2 = 2; /* new */
struct rpc_gss_cred_t { struct rpc_gss_cred_t {
union switch (unsigned int version) { /* version of union switch (unsigned int version) { /* version of
RPCSEC_GSS */ RPCSEC_GSS */
case RPCSEC_GSS_VERS_1: case RPCSEC_GSS_VERS_1:
case RPCSEC_GSS_VERS_2: /* new */ case RPCSEC_GSS_VERS_2: /* new */
struct { struct {
skipping to change at page 4, line 33 skipping to change at page 5, line 5
unsigned int seq_num; /* sequence number */ unsigned int seq_num; /* sequence number */
rpc_gss_service_t service; /* service used */ rpc_gss_service_t service; /* service used */
opaque handle<>; /* context handle */ opaque handle<>; /* context handle */
} rpc_gss_cred_vers_1_t; } rpc_gss_cred_vers_1_t;
As is apparent from the above, the RPCSEC_GSSv2 credential has the As is apparent from the above, the RPCSEC_GSSv2 credential has the
same format as the RPCSSEC_GSSv1 credential. By setting the version same format as the RPCSSEC_GSSv1 credential. By setting the version
field to 2, this indicates that the initiator and target support field to 2, this indicates that the initiator and target support
channel bindings. channel bindings.
3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL
enum rpc_gss_proc_t { enum rpc_gss_proc_t {
RPCSEC_GSS_DATA = 0, RPCSEC_GSS_DATA = 0,
RPCSEC_GSS_INIT = 1, RPCSEC_GSS_INIT = 1,
RPCSEC_GSS_CONTINUE_INIT = 2, RPCSEC_GSS_CONTINUE_INIT = 2,
RPCSEC_GSS_DESTROY = 3, RPCSEC_GSS_DESTROY = 3,
RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ RPCSEC_GSS_BIND_CHANNEL = 4 /* new */
}; };
struct rpc_gss_chan_bind_input { struct rpc_gss_chan_bind_input {
opaque rgcbi_chan_bindings<>; opaque rgcbi_chan_bindings<>;
}; };
Once an RPCSEC_GSSv2 handle has been established over a secure Once an RPCSEC_GSSv2 handle has been established over a secure
channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST
support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and
RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be
used. Unlike those two requests, the arguments of the NULL procedure used. Unlike those two requests, the arguments of the NULL procedure
are not overloaded, because the verifier is of sufficient size for are not overloaded, because the verifier is of sufficient size for
purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to
RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc
were set to RPCSEC_GSS_DATA. The service field is set to were set to RPCSEC_GSS_DATA. The service field is set to
rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS
handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.
When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is
set to the output of GSS_GetMIC() on the RPC header as described in set to the output of GSS_GetMIC() on the RPC header as described in
Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_DATA, the verifier Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
is of an RPC request is set to the output of GSS_GetMIC() on the verifier of an RPC request is set to the output of GSS_GetMIC() on
concatenation of the RPC header ("up to and including the the concatenation of the RPC header ("up to and including the
credential") and the XDR encoding of an instance of type data credential") and the XDR encoding of an instance of type data
rpc_gss_chan_bind_input. rpc_gss_chan_bind_input.
Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC
reply is set to the output of GSS_GetMIC() on the seq_num of the reply is set to the output of GSS_GetMIC() on the seq_num of the
credential of the corresponding request (as described in Section credential of the corresponding request (as described in Section
5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the
concantenation of the seq_num and the XDR encoding of an instance of concantenation of the seq_num and the XDR encoding of an instance of
data type rpc_gss_chan_bind_input. data type rpc_gss_chan_bind_input.
skipping to change at page 5, line 32 skipping to change at page 6, line 4
5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the
concantenation of the seq_num and the XDR encoding of an instance of concantenation of the seq_num and the XDR encoding of an instance of
data type rpc_gss_chan_bind_input. data type rpc_gss_chan_bind_input.
The content of rpc_gss_chan_bind_input has a single field, The content of rpc_gss_chan_bind_input has a single field,
rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of
channel bindings as defined in [3]. The channel bindings are a channel bindings as defined in [3]. The channel bindings are a
"canonical octet string encoding of the channel bindings", starting "canonical octet string encoding of the channel bindings", starting
"with the channel bindings prefix followed by a colon (ASCII 0x3A)." "with the channel bindings prefix followed by a colon (ASCII 0x3A)."
Thus the channel bindings of the initiator are verified when the Thus the channel bindings of the initiator are verified when the
target verifies the verifier via GSS_VerifyMIC(). Similarly, the target verifies the verifier via GSS_VerifyMIC(). Similarly, the
channel bindings of the target are verified when the initiator channel bindings of the target are verified when the initiator
verifies the verifier of the RPC reply via GSS_VerifyMIC(). Errors verifies the verifier of the RPC reply via GSS_VerifyMIC(). Errors
are handled the same way as described in Section 5.3.3.4.2 of [2]. are handled the same way as described in Section 5.3.3.4.2 of [2].
3.3. New Security Service - rpc_gss_svc_channel_prot 3.4. New Security Service - rpc_gss_svc_channel_prot
enum rpc_gss_service_t { enum rpc_gss_service_t {
/* Note: the enumerated value for 0 is reserved. */ /* Note: the enumerated value for 0 is reserved. */
rpc_gss_svc_none = 1, rpc_gss_svc_none = 1,
rpc_gss_svc_integrity = 2, rpc_gss_svc_integrity = 2,
rpc_gss_svc_privacy = 3, rpc_gss_svc_privacy = 3,
rpc_gss_svc_channel_prot = 4 /* new */ rpc_gss_svc_channel_prot = 4 /* new */
}; };
The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is
 End of changes. 16 change blocks. 
39 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/