draft-ietf-nfsv4-rpcsec-gss-v2-02.txt   draft-ietf-nfsv4-rpcsec-gss-v2-03.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track February 24, 2008 Intended status: Standards Track May 23, 2008
Expires: August 27, 2008 Expires: November 24, 2008
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-02.txt draft-ietf-nfsv4-rpcsec-gss-v2-03.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 27, 2008. This Internet-Draft will expire on November 24, 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.
Requirements Language Requirements Language
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. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . . 4 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 4
3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 4 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 5
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6
3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 9
4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
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
Internet Protocol (IP) layer in the form of IPsec. The secondary Internet Protocol (IP) layer in the form of IPsec. The secondary
motivation is that even if lower levels are not any more efficient at motivation is that even if lower levels are not any more efficient at
encryption than the RPCSEC_GSS layer, if encryption is occurring at encryption than the RPCSEC_GSS layer, if encryption is occurring at
the lower level, it can be redundant at the RPCSEC_GSS level. the lower level, it can be redundant at the RPCSEC_GSS level.
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 protection can also be eliminated.
The XDR description is provided in this document in a way that makes
it simple for the reader to extract into ready to compile form. The
reader can feed this document into the following shell script to
produce the machine readable XDR description of NFSv4.1:
#!/bin/sh
grep "^ *///" | sed 's?^ *///??'
I.e. if the above script is stored in a file called "extract.sh", and
this docum ent is in a file called "spec.txt", then the reader can
do:
sh extract.sh < spec.txt > rpcsec_gss_v2.x
The effect of the script is to remove leading white space from each
line of the specification, plus a sentinel sequence of "///".
2. Channel Bindings Explained 2. Channel Bindings Explained
If a channel between two parties is secure, there must be shared If a channel between two parties is secure, there must be shared
information between the two parties. This information might be information between the two parties. This information might be
secret or not. The requirement for secrecy depends on the specifics secret or not. The requirement for secrecy depends on the specifics
of the channel. of the channel.
For example, the shared information could be the concatenation of the 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 of the source and destination of the channel (where each
public key has a corresponding private key). Suppose the channel is 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 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 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 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, the same public keys, because a public key derives from a private
and the key management system for each node will surely assign unique key, and the key management system for each node will surely assign
or random private keys. At most the MITM can force one end of each unique or random private keys. At most, the MITM can force one end
channel to use the same public key. The MIC of public keys from the of each channel to use the same public key. The MIC of the public
initiator will not be verified by the target, because at least one of keys from the initiator will not be verified by the target, because
public keys will be different. Similarly, the MIC of the public keys at least one of the public keys will be different. Similarly, the
from the target will not be verified by the initiator because at MIC of the public keys from the target will not be verified by the
least one of the public keys will be different. initiator because at least one of the public keys will be different.
A higher layer protocol using the secure channel can safely exploit A higher layer protocol using the secure channel can safely exploit
the channel to the mutual benefit of the higher level parties if each the channel to the mutual benefit of the higher level parties if each
higher level party can prove: higher level party can prove:
o They each know the channel's shared information. o They each know the channel's shared information.
o The proof of the knowledge of the shared information is in fact 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 being conveyed by each of the higher level parties, and not some
other entities. other entities.
skipping to change at page 4, line 33 skipping to change at page 5, line 7
The RPCSEC_GSSv2 protocol will now be explained. The entire protocol The RPCSEC_GSSv2 protocol will now be explained. The entire protocol
is 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. Compatibility with RPCSEC_GSSv1 3.1. Compatibility with RPCSEC_GSSv1
The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2. The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.
3.2. New Version Number 3.2. New Version Number
const RPCSEC_GSS_VERS_1 = 1; /// enum rpc_gss_service_t {
const RPCSEC_GSS_VERS_2 = 2; /* new */ /// /* Note: the enumerated value for 0 is reserved. */
/// rpc_gss_svc_none = 1,
/// rpc_gss_svc_integrity = 2,
/// rpc_gss_svc_privacy = 3,
/// rpc_gss_svc_channel_prot = 4 /* new */
/// };
///
/// enum rpc_gss_proc_t {
/// RPCSEC_GSS_DATA = 0,
/// RPCSEC_GSS_INIT = 1,
/// RPCSEC_GSS_CONTINUE_INIT = 2,
/// RPCSEC_GSS_DESTROY = 3,
/// RPCSEC_GSS_BIND_CHANNEL = 4 /* new */
/// };
///
/// struct rpc_gss_cred_vers_1_t {
/// rpc_gss_proc_t gss_proc; /* control procedure */
/// unsigned int seq_num; /* sequence number */
/// rpc_gss_service_t service; /* service used */
/// opaque handle<>; /* context handle */
/// };
///
/// const RPCSEC_GSS_VERS_1 = 1;
/// const RPCSEC_GSS_VERS_2 = 2; /* new */
///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2: /* new */
/// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// };
///
struct rpc_gss_cred_t { Figure 3
union switch (unsigned int version) { /* version of
RPCSEC_GSS */
case RPCSEC_GSS_VERS_1:
case RPCSEC_GSS_VERS_2: /* new */
struct {
rpc_gss_proc_t gss_proc; /* control procedure */
unsigned int seq_num; /* sequence number */
rpc_gss_service_t service; /* service used */
opaque handle<>; /* context handle */
} 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 RPCSEC_GSSv1 credential (albeit corrected so that
field to 2, this indicates that the initiator and target support the definition is in legal XDR description language that is also
channel bindings. compatible with [6]. Hence the field "version", a keyword in [6], is
replaced with rgc_version). By setting the rgc_version field to 2,
this indicates that the initiator and target support channel
bindings.
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL
enum rpc_gss_proc_t { /// struct rgss2_bind_chan_MIC_in_args {
RPCSEC_GSS_DATA = 0, /// opaque rbcmia_bind_chan_hash<>;
RPCSEC_GSS_INIT = 1, /// };
RPCSEC_GSS_CONTINUE_INIT = 2, ///
RPCSEC_GSS_DESTROY = 3, /// typedef opaque rgss2_chan_pref<>;
RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ /// typedef opaque rgss2_oid<>;
}; ///
/// struct rgss2_bind_chan_verf_args {
/// rgss2_chan_pref rbcva_chan_bind_prefix;
/// rgss2_oid rbcva_chan_bind_oid_hash;
/// opaque rbcva_chan_mic<>;
/// };
///
struct rpc_gss_chan_bind_input { Figure 4
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 initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 3).
support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT
RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be and 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
the 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 As described in Section 5.3.1 of [2] when gss_proc is
set to the output of GSS_GetMIC() on the RPC header as described in RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output
Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the of GSS_GetMIC() on the RPC header. When gss_proc is
verifier of an RPC request is set to the output of GSS_GetMIC() on RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC request is set to the
the concatenation of the RPC header ("up to and including the XDR encoding on a value of data type rgss2_bind_chan_verf_args. The
credential") and the XDR encoding of an instance of type data rgss2_bind_chan_verf_args data type consists of three fields:
rpc_gss_chan_bind_input.
Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC o rbcva_chan_bind_prefix. This is the channel binding prefix as
reply is set to the output of GSS_GetMIC() on the seq_num of the described in [3] up to, but excluding the colon (ASCII 0x3A) that
credential of the corresponding request (as described in Section separates the prefix from the suffix.
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
concantenation of the seq_num and the XDR encoding of an instance of
data type rpc_gss_chan_bind_input.
The content of rpc_gss_chan_bind_input has a single field, o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of
rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of the hash algorithm used to compute rbcmia_bind_chan_hash. This
channel bindings as defined in [3]. The channel bindings are a field contains an OID encoded in ASN.1 as used by GSS-API in the
"canonical octet string encoding of the channel bindings", starting mech_type argument to GSS_Init_sec_context ([4]). See [5] for the
"with the channel bindings prefix followed by a colon (ASCII 0x3A)." OIDs of the SHA one-way hash algorithms.
Thus the channel bindings of the initiator are verified when the
target verifies the verifier via GSS_VerifyMIC(). Similarly, the
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.4. New Security Service - rpc_gss_svc_channel_prot o rbcva_chan_mic. This is the output of GSS_GetMIC() on the
concatenation of the XDR encoded RPC header ("up to and including
the credential" as per [2]) and the XDR encoding of an instance of
type data rgss2_bind_chan_MIC_in_args. The data type
rgss2_bind_chan_MIC_in_args consists of one field,
rbcmia_bind_chan_hash, which is a hash of the channel bindings as
defined in [3]. The channel bindings are a "canonical octet
string encoding of the channel bindings", starting "with the
channel bindings prefix followed by a colon (ASCII 0x3A)." The
reason a hash of the channel bindings and not the actual channel
bindings are used to compute rbcva_chan_mic is that some channel
bindings, such as those composed of public keys, can be relatively
large, and thus place a higher space burden on the implementations
to manage. One way hashes consume less space.
enum rpc_gss_service_t { /// enum rgss2_bind_chan_status {
/* Note: the enumerated value for 0 is reserved. */ /// RGSS2_BIND_CHAN_OK = 0,
rpc_gss_svc_none = 1, /// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1,
rpc_gss_svc_integrity = 2, /// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2
rpc_gss_svc_privacy = 3, /// };
rpc_gss_svc_channel_prot = 4 /* new */ ///
}; /// union rgss2_bind_chan_res switch
/// (rgss2_bind_chan_status rbcr_stat) {
///
/// case RGSS2_BIND_CHAN_OK:
/// void;
///
/// case RGSS2_BIND_CHAN_PREF_NOTSUPP:
/// rgss2_chan_pref rbcr_pref_list<>;
///
/// case RGSS2_BIND_CHAN_HASH_NOTSUPP:
/// rgss2_oid rbcr_oid_list<>;
/// };
///
/// struct rgss2_bind_chan_MIC_in_res {
/// unsigned int rbcmr_seq_num;
/// opaque rbcmr_bind_chan_hash<>;
/// rgss2_bind_chan_res rbcmr_res;
/// };
///
/// struct rgss2_bind_chan_verf_res {
/// rgss2_bind_chan_res rbcvr_res;
/// opaque rbcvr_mic<>;
/// };
///
The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is Figure 5
being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set
successfully, and the secure channel still exists. When to the output of GSS_GetMIC() on the seq_num of the credential of the
rpc_gss_svc_channel_prot is used, the RPC requests and replies are corresponding request (as described in Section 5.3.3.2 of [2]). When
similar to those of rpc_gss_svc_none except that the verifiers on the gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is
request and reply always have the flavor set to AUTH_NONE, and the set to the XDR encoding of an instance of data type
contents are zero length. rgss2_bind_chan_verf_res. The data type rgss2_bind_chan_verf_res
consists of two fields.
o rbcvr_res. The data type of this field is rgss2_bind_chan_res.
The rgss2_bind_chan_res data type is a switched union consisting
of three cases switched on the status contained in the rbcr_stat
field.
* RGSS2_BIND_CHAN_OK. If this status is returned, the server
accepted the channel bindings, and successfully verified
rbcva_chan_mic in the request. No additional results will be
in rbcvr_res.
* RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the
server did not support the prefix in the rbcva_chan_bind_prefix
field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL
request was rejected. The server returned a list of prefixes
it does support in the field rbcr_pref_list.
* RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the
server did not support the hash algorithm identified in the
rbcva_chan_bind_hash_oid field of the arguments, and thus the
RPCSEC_GSS_BIND_CHANNEL request was rejected. The server
returned a list of OIDs of hash algorithms it does support in
the field rbcr_oid_list.
o rbcvr_mic. The value of this field is equal to the output of
GSS_GetMIC() on the XDR encoding of an instance of data type
rgss2_bind_chan_MIC_in_res. The data type
rgss2_bind_chan_MIC_in_res consists of three fields.
* rbcmr_seq_num. The value of this field is equal the field
seq_num in the RPCSEC_GSS credential (data type
rpc_gss_cred_vers_1_t).
* rbcmr_bind_chan_hash. This is the result of the one way hash
of the channel bindings (including the prefix), using the hash
algorithm identified by the rbcva_chan_bind_oid_hash field in
the arguments to RPCSEC_GSS_BIND_CHANNEL.
* rbcmr_res. The value of this field is equal to the value of
the rbcvr_res field.
3.4. New Security Service - rpc_gss_svc_channel_prot
The rpc_gss_svc_channel_prot service (Figure 3) is valid only if
RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has
been executed successfully, and the secure channel still exists.
When 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 request and reply always have the flavor set to AUTH_NONE, and
the contents are zero length.
Note that even though NULL verifiers are used when Note that even though NULL verifiers are used when
rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are
used. The same credential is used as before, except that service used. In order to identify the principal sending the request, the
field is set to rpc_gss_svc_channel_prot. same credential is used as before, except that service field is set
to rpc_gss_svc_channel_prot.
4. Version Negotiation 4. Version Negotiation
An initiator that supports version 2 of RPCSEC_GSS simply issues an 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. RPCSEC_GSS request with the rgc_version field set to
If the target does not recognize RPCSEC_GSS_VERS_2, the target will RPCSEC_GSS_VERS_2. If the target does not recognize
return an RPC error per section 5.1 of [2]. 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 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 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 initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
version 1 of a target with version 2 of the same target. version 1 of a target with version 2 of the same target.
5. Implementation Notes 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.
6. Acknowledgements 6. Acknowledgements
Nico Williams had the idea for extending RPCSEC_GSS to support Nicolas Williams had the idea for extending RPCSEC_GSS to support
channel bindings. channel bindings.
7. Security Considerations 7. Security Considerations
The security considerations are the same as [2]. The security considerations are the same as [2].
8. IANA Considerations 8. IANA Considerations
None. None.
9. Normative References 9. References
9.1. 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", RFC 2119, 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 [3] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[4] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005.
9.2. Informative References
[6] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
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 US
Phone: +1-719-599-9026 Phone: +1-719-599-9026
Email: email2mre-ietf@yahoo.com Email: mike@eisler.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 27 change blocks. 
105 lines changed or deleted 245 lines changed or added

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