draft-ietf-nfsv4-rpcsec-gss-v2-00.txt   draft-ietf-nfsv4-rpcsec-gss-v2-01.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track February 18, 2008 Intended status: Standards Track February 20, 2008
Expires: August 21, 2008 Expires: August 23, 2008
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-00.txt draft-ietf-nfsv4-rpcsec-gss-v2-01.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 21, 2008. This Internet-Draft will expire on August 23, 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 12 skipping to change at page 2, line 12
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. New Version Number . . . . . . . . . . . . . . . . . . . . 4
3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5 3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 4
3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 5
4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
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
lower levels of the networking protocol stack, such as at the lower levels of the networking protocol stack, such as at the
skipping to change at page 5, line 16 skipping to change at page 4, line 44
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 {
unsigned int rgcbi_seq_num;
opaque rgcbi_chan_bindings<>; opaque rgcbi_chan_bindings<>;
}; };
struct rpc_gss_bind_channel_arg {
int rgbca_chan_bind_type;
opaque rgbca_MIC_hdr<>;
opaque rgbca_MIC_chan_bindings<>;
};
struct rpc_gss_bind_channel_res {
opaque rgbcr_MIC_seq<>;
opaque rgbcr_MIC_chan_bind<>;
};
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 argument and result of are not overloaded, because the verifier is of sufficient size for
RPCSEC_GSS_BIND_CHANNEL will fit in the RPC verifier. Like purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to
RPCSEC_GSS_DATA, the seq_num field is set as if the procedure was RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc
RPCSEC_GSS_DATA. The service is set to rpc_gss_svc_none, and the were set to RPCSEC_GSS_DATA. The service field is set to
handle is set to that of established RPCSEC_GSS handle. The rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS
argument, of data type rpc_gss_bind_channel_arg is placed in the handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.
request's verifier, with the RPC flavor set to RPCSEC_GSS. The field
rgbca_chan_bind_type identifies the type of channel binding the
client is using. The field rgbca_MIC_hdr is the GSS_GetMIC()
resulted of the RPC header (up to and including the credential. The
field rgbca_MIC_chan_bindings is equal to the result of GSS_GetMIC()
a value of data type rpc_gss_chan_bind_input.
The content of rpcs_gss_chan_bind_input is composed as follows. The When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is
field rgcbi_seq_num is the same as the seq_num in the credential. set to the output of GSS_GetMIC() on the RPC header as described in
The field rgcbi_chan_bindings contains the actual channel bindings. Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_DATA, the verifier
is of an RPC request is set to the output of GSS_GetMIC() on the
concatenation of the RPC header ("up to and including the
credential") and the XDR encoding of an instance of type data
rpc_gss_chan_bind_input.
If the target verifies rgbca_MIC_hdr, then it will return a result. Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC
Otherwise an RPC level error is returned. See section 5.3.3.4.2 of reply is set to the output of GSS_GetMIC() on the seq_num of the
[2]. If the target does not recognize rgbca_chan_bind_type, it will credential of the corresponding request (as described in Section
return a zero length rgbcr_MIC_chan_bind. If the target fails to 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the
verify rgbca_MIC_chan_bindings, it will return an error as per verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the
section 5.3.3.4.2 of [2]. concantenation of the seq_num and the XDR encoding of an instance of
data type rpc_gss_chan_bind_input.
The result pf RPCSEC_GSS_BIND_CHANNEL is returned in The content of rpc_gss_chan_bind_input has a single field,
rpc_gss_bind_channel_res in the RPC verifier of the reply. The rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of
flavor of the verifier is set to RPCSEC_GSS. The field rgbcr_MIC_seq channel bindings as defined in [3]. The channel bindings are a
is the result of the target's execution of GSS_GetMIC() on the "canonical octet string encoding of the channel bindings", starting
seq_num in the credential. The field rgbcr_MIC_chan_bind is the "with the channel bindings prefix followed by a colon (ASCII 0x3A)."
result of the target's execution of GSS_GetMIC() on the a value of
data type rpc_gss_chan_bind_input. After the client successfully Thus the channel bindings of the initiator are verified when the
verifies both MICs, the RPCSEC_GSS context is now associated with the target verifies the verifier via GSS_VerifyMIC(). Similarly, the
secure channel. channel bindings of the target are verified when the initiator
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].
3.3. New Security Service - rpc_gss_svc_channel_prot 3.3. 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
being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed
successfully, and the secure channel still exists. When successfully, and the secure channel still exists. When
rpc_gss_svc_channel_prot is used, the RPC requests and replies are rpc_gss_svc_channel_prot is used, the RPC requests and replies are
similar to those of rpc_gss_svc_none except that the verifiers on the similar to those of rpc_gss_svc_none except that the verifiers on the
request and reply always have the flavor set to AUTH_NONE, and the request and reply always have the flavor set to AUTH_NONE, and the
contents are zero length. contents are zero length.
4. Implementation Notes Note that even though NULL verifiers are used when
rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are
used. The same credential is used as before, except that service
field is set to rpc_gss_svc_channel_prot.
4. Version Negotiation
An initiator that supports version 2 of RPCSEC_GSS simply issues an
RPCSEC_GSS request with the version field set to RPCSEC_GSS_VERS_2.
If the target does not recognize RPCSEC_GSS_VERS_2, the target will
return an RPC error per section 5.1 of [2].
The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
by version 2 of a target with version 1 of the same target. The
initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
version 1 of a target with version 2 of the same target.
5. Implementation Notes
Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been
performed on an RPCSEC_GSSv2 context handle, the initiator's performed on an RPCSEC_GSSv2 context handle, the initiator's
implementation may map application requests for rpc_gss_svc_none and implementation may map application requests for rpc_gss_svc_none and
rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And
if the secure channel has privacy enabled, requests for if the secure channel has privacy enabled, requests for
rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot.
5. Acknowledgements 6. Acknowledgements
Nico Williams had the idea for extending RPCSEC_GSS to support Nico Williams had the idea for extending RPCSEC_GSS to support
channel bindings. channel bindings.
6. Security Considerations 7. Security Considerations
The security considerations are the same as [2]. The security considerations are the same as [2].
7. IANA Considerations 8. IANA Considerations
The rgbca_chan_bind_type field of the RPCSEC_GSS_BIND_CHANNEL None.
arguments requires an IANA registry. Values less than zero, are
reserved for experimentation, and do not have to be registered.
Values greater than or equal to zeor should be registered with IANA
in order to enable interoperability. An entry in the registry must
include the 32 bit binding type, and a reference to an RFC that
describes the channel and its bindings, including how the bindings
are constructed.
8. Normative References 9. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, September 1997.
[3] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Author's Address Author's Address
Mike Eisler Mike Eisler
NetApp NetApp
5765 Chase Point Circle 5765 Chase Point Circle
Colorado Springs, CO 80919 Colorado Springs, CO 80919
USA USA
Phone: +1-719-599-9026 Phone: +1-719-599-9026
Email: email2mre-ietf@yahoo.com Email: email2mre-ietf@yahoo.com
 End of changes. 17 change blocks. 
66 lines changed or deleted 69 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/