draft-ietf-nfsv4-rpcsec-gss-v2-03.txt   draft-ietf-nfsv4-rpcsec-gss-v2-04.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track May 23, 2008 Intended status: Standards Track August 18, 2008
Expires: November 24, 2008 Expires: February 19, 2009
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-03.txt draft-ietf-nfsv4-rpcsec-gss-v2-04.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 November 24, 2008. This Internet-Draft will expire on February 19, 2009.
Copyright Notice
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 [[Comment.1: (RFC Editor please
bindings. add reference to the RFC2203 item in the References, since xml2rfc
does not allow xrefs in abstracts)]] adds support for channel
bindings [[Comment.2: (RFC Editor please add reference to the RFC5056
item in the References)]].
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 . . . . . . . . . . . . . . . . . . . . 5 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 5
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6
3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 9 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 9
4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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 (See [6] and [7]
motivation is that even if lower levels are not any more efficient at for information on IPsec channel binding). The secondary motivation
encryption than the RPCSEC_GSS layer, if encryption is occurring at is that even if lower levels are not any more efficient at encryption
the lower level, it can be redundant at the RPCSEC_GSS level. than the RPCSEC_GSS layer, if encryption is occurring at 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 protection can also be eliminated. privacy protection can also be eliminated.
The XDR description is provided in this document in a way that makes 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 it simple for the reader to extract into ready to compile form. The
reader can feed this document into the following shell script to reader can feed this document into the following shell script to
produce the machine readable XDR description of NFSv4.1: produce the machine readable XDR description of RPCSEC_GSSv2:
#!/bin/sh #!/bin/sh
grep "^ *///" | sed 's?^ *///??' grep "^ *///" | sed 's?^ *///??'
I.e. if the above script is stored in a file called "extract.sh", and 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 this docum ent is in a file called "spec.txt", then the reader can
do: do:
sh extract.sh < spec.txt > rpcsec_gss_v2.x sh extract.sh < spec.txt > rpcsec_gss_v2.x
skipping to change at page 5, line 40 skipping to change at page 5, line 40
/// 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 */
/// ///
/// union rpc_gss_cred_t switch (unsigned int rgc_version) { /// union rpc_gss_cred_t switch (unsigned int rgc_version) {
/// case RPCSEC_GSS_VERS_1: /// case RPCSEC_GSS_VERS_1:
/// case RPCSEC_GSS_VERS_2: /* new */ /// case RPCSEC_GSS_VERS_2: /* new */
/// rpc_gss_cred_vers_1_t rgc_cred_v1; /// rpc_gss_cred_vers_1_t rgc_cred_v1;
/// }; /// };
/// ///
Figure 3 Figure 1
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 RPCSEC_GSSv1 credential (albeit corrected so that same format as the RPCSEC_GSSv1 credential (albeit corrected so that
the definition is in legal XDR description language that is also the definition is in legal XDR description language that is also
compatible with [6]. Hence the field "version", a keyword in [6], is compatible with [8]. Hence the field "version", a keyword in [8], is
replaced with rgc_version). By setting the rgc_version field to 2, replaced with rgc_version). By setting the rgc_version field to 2,
this indicates that the initiator and target support channel this indicates that the initiator and target support channel
bindings. bindings.
3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL
/// struct rgss2_bind_chan_MIC_in_args { /// struct rgss2_bind_chan_MIC_in_args {
/// opaque rbcmia_bind_chan_hash<>; /// opaque rbcmia_bind_chan_hash<>;
/// }; /// };
/// ///
/// typedef opaque rgss2_chan_pref<>; /// typedef opaque rgss2_chan_pref<>;
/// typedef opaque rgss2_oid<>; /// typedef opaque rgss2_oid<>;
/// ///
/// struct rgss2_bind_chan_verf_args { /// struct rgss2_bind_chan_verf_args {
/// rgss2_chan_pref rbcva_chan_bind_prefix; /// rgss2_chan_pref rbcva_chan_bind_prefix;
/// rgss2_oid rbcva_chan_bind_oid_hash; /// rgss2_oid rbcva_chan_bind_oid_hash;
/// opaque rbcva_chan_mic<>; /// opaque rbcva_chan_mic<>;
/// }; /// };
/// ///
Figure 4 Figure 2
Once an RPCSEC_GSSv2 handle has been established over a secure Once an RPCSEC_GSSv2 handle has been established over a secure
channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 3). channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1).
Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT
and 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.
As described in Section 5.3.1 of [2] when gss_proc is The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA
RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output request in that the verifiers of both contain MICs. As described in
of GSS_GetMIC() on the RPC header. When gss_proc is Section 5.3.1 of [2], when gss_proc is RPCSEC_GSS_DATA, the verifier
RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC request is set to the of an RPC request is set to the output of GSS_GetMIC() on the RPC
XDR encoding on a value of data type rgss2_bind_chan_verf_args. The header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an
rgss2_bind_chan_verf_args data type consists of three fields: RPC request is set to the XDR encoding on a value of data type
rgss2_bind_chan_verf_args, which includes a MIC as described below.
The rgss2_bind_chan_verf_args data type consists of three fields:
o rbcva_chan_bind_prefix. This is the channel binding prefix as o rbcva_chan_bind_prefix. This is the channel binding prefix as
described in [3] up to, but excluding the colon (ASCII 0x3A) that described in [3] up to, but excluding the colon (ASCII 0x3A) that
separates the prefix from the suffix. separates the prefix from the suffix.
o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of
the hash algorithm used to compute rbcmia_bind_chan_hash. This the hash algorithm used to compute rbcmia_bind_chan_hash. This
field contains an OID encoded in ASN.1 as used by GSS-API in the field contains an OID encoded in ASN.1 as used by GSS-API in the
mech_type argument to GSS_Init_sec_context ([4]). See [5] for the mech_type argument to GSS_Init_sec_context ([4]). See [5] for the
OIDs of the SHA one-way hash algorithms. OIDs of the SHA one-way hash algorithms.
skipping to change at page 7, line 51 skipping to change at page 7, line 51
/// opaque rbcmr_bind_chan_hash<>; /// opaque rbcmr_bind_chan_hash<>;
/// rgss2_bind_chan_res rbcmr_res; /// rgss2_bind_chan_res rbcmr_res;
/// }; /// };
/// ///
/// struct rgss2_bind_chan_verf_res { /// struct rgss2_bind_chan_verf_res {
/// rgss2_bind_chan_res rbcvr_res; /// rgss2_bind_chan_res rbcvr_res;
/// opaque rbcvr_mic<>; /// opaque rbcvr_mic<>;
/// }; /// };
/// ///
Figure 5 Figure 3
When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA
to the output of GSS_GetMIC() on the seq_num of the credential of the reply in that the verifiers of both contain MICs. When gss_proc is
corresponding request (as described in Section 5.3.3.2 of [2]). When RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of
gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is GSS_GetMIC() on the seq_num of the credential of the corresponding
set to the XDR encoding of an instance of data type request (as described in Section 5.3.3.2 of [2]). When gss_proc is
rgss2_bind_chan_verf_res. The data type rgss2_bind_chan_verf_res RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the
consists of two fields. XDR encoding of an instance of data type rgss2_bind_chan_verf_res,
which includes a MIC as described below. 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. 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 The rgss2_bind_chan_res data type is a switched union consisting
of three cases switched on the status contained in the rbcr_stat of three cases switched on the status contained in the rbcr_stat
field. field.
* RGSS2_BIND_CHAN_OK. If this status is returned, the server * RGSS2_BIND_CHAN_OK. If this status is returned, the server
accepted the channel bindings, and successfully verified accepted the channel bindings, and successfully verified
rbcva_chan_mic in the request. No additional results will be rbcva_chan_mic in the request. No additional results will be
in rbcvr_res. in rbcvr_res.
skipping to change at page 8, line 33 skipping to change at page 8, line 35
server did not support the prefix in the rbcva_chan_bind_prefix server did not support the prefix in the rbcva_chan_bind_prefix
field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL
request was rejected. The server returned a list of prefixes request was rejected. The server returned a list of prefixes
it does support in the field rbcr_pref_list. it does support in the field rbcr_pref_list.
* RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the * RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the
server did not support the hash algorithm identified in the server did not support the hash algorithm identified in the
rbcva_chan_bind_hash_oid field of the arguments, and thus the rbcva_chan_bind_hash_oid field of the arguments, and thus the
RPCSEC_GSS_BIND_CHANNEL request was rejected. The server RPCSEC_GSS_BIND_CHANNEL request was rejected. The server
returned a list of OIDs of hash algorithms it does support in returned a list of OIDs of hash algorithms it does support in
the field rbcr_oid_list. the field rbcr_oid_list. The array rbcr_oid_list MUST have one
or more elements.
o rbcvr_mic. The value of this field is equal to the output of 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 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. The data type
rgss2_bind_chan_MIC_in_res consists of three fields. rgss2_bind_chan_MIC_in_res consists of three fields.
* rbcmr_seq_num. The value of this field is equal the field * rbcmr_seq_num. The value of this field is equal the field
seq_num in the RPCSEC_GSS credential (data type seq_num in the RPCSEC_GSS credential (data type
rpc_gss_cred_vers_1_t). rpc_gss_cred_vers_1_t).
* rbcmr_bind_chan_hash. This is the result of the one way hash * rbcmr_bind_chan_hash. This is the result of the one way hash
of the channel bindings (including the prefix), using the hash of the channel bindings (including the prefix). If rbcr_stat
algorithm identified by the rbcva_chan_bind_oid_hash field in is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm
the arguments to RPCSEC_GSS_BIND_CHANNEL. that is used to compute rbcmr_bind_chan_hash is that identified
by the rbcva_chan_bind_oid_hash field in the arguments to
RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is
RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to
compute rbcmr_bind_chan_hash is that identified by
rbcr_oid_list[0] in the results.
* rbcmr_res. The value of this field is equal to the value of * rbcmr_res. The value of this field is equal to the value of
the rbcvr_res field. the rbcvr_res field.
3.4. New Security Service - rpc_gss_svc_channel_prot 3.4. New Security Service - rpc_gss_svc_channel_prot
The rpc_gss_svc_channel_prot service (Figure 3) is valid only if The rpc_gss_svc_channel_prot service (Figure 1) is valid only if
RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has
been executed successfully, and the secure channel still exists. been executed successfully, and the secure channel still exists.
When rpc_gss_svc_channel_prot is used, the RPC requests and replies 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 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 request and reply always have the flavor set to AUTH_NONE, and
the contents are zero length. 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. In order to identify the principal sending the request, the used. In order to identify the principal sending the request, the
skipping to change at page 9, line 46 skipping to change at page 10, line 8
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
Nicolas 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. Alex Burlyga and Lars Eggert reviewed the document
and gave valuable feed back for improving its readability.
7. Security Considerations 7. Security Considerations
The security considerations are the same as [2]. The base security considerations consist of:
o All security considerations from [2].
o All security considerations from [3].
o All security considerations from the actual secure channel being
used.
Even though RPCSEC_GSS_DATA requests that use
rpc_gss_svc_channel_prot protection do not involve construction of
more GSS tokens, nonetheless, the target SHOULD stop allowing
RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection
once the GSS context expires.
With the use of channel bindings, it becomes extremely critical that
the message integrity code (MIC) used by the GSS mechanism that
RPCSEC_GSS is using be difficult to forge. While this requirement is
true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs,
the distinction in the seriousness is that for RPCSEC_GSSv1, forging
a single MIC at most allows the attacker to succeed in injecting one
bogus request. Whereas, with RPCSEC_GSSv2 combined with channel
bindings, by forging a single MIC all the attacker will succeed in
injecting bogus requests as long as the channel exists. An example
illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man in the
middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target.
The attack is as follows.
o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT
message and changes the version number from 1 to 2 before
forwarding to the RPCSEC_GSSv2 target, and changes the reply's
version number from 2 to 1 before forwarding to the RPCSEC_GSSv1
initiator. Neither the client nor the server notice.
o Once the RPCSEC_GSS handle is in an established state, the
initiator sends its first RPCSEC_GSS_DATA request. The MITM
constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message
integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely
the RPCSEC_GSSv2 target will reject the request. The MITM
continues to re-iterate each time the initiator sends another
RPCSEC_GSS_DATA request. With enough iterations, the probability
of a MIC from an RPCSEC_GSS_DATA being successfully verified in
the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM
succeeds, it can send RPCSEC_GSS_DATA requests with a security
service of rpc_gss_svc_channel_prot, which does not have MICs in
the RPC request's verifier.
The implementation of RPCSEC_GSSv2 can use at least two methods to
thwart these attacks.
o The target SHOULD require a stronger MIC (e.g. if HMACs are used
for the MICs, require the widest possible HMAC in terms of bit
length that the GSS mechanism supports) when sending an
RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA
request. If HMACs are being used, and the target expects N
RPCSEC_GSS_DATA requests to be sent on the context before it
expires, then the target SHOULD require an HMAC for
RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what
it normally requires for RPCSEC_GSS_DATA requests. If a long
enough MIC is not available, then the target could artificially
limit the number of RPCSEC_GSS_DATA requests it will allow on the
context before deleting the context.
o Each time an RPCSEC_GSSv2 target experiences a failure to verify
the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce
the lifetime of the underlying GSS context, by a significant
fraction, thereby preventing the MITM from using the established
context for its attack. A possible heuristic is that the if the
target believes the possibility that failure to verify the MIC was
because of an attack is X percent, then contexts lifetime would be
reduced by X percent. For simplicity, an implement might set X to
be 50 percent, so that the context lifetime is halved on each
failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus
rapidly reduced to zero on subsequent requests. For example, with
a context like time of 8 hours (or 28800 seconds), 15 failed
attempts by the MITM would cause the context to be destroyed.
A method of mitigation that was considered was to protect the
RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and
RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of
RPCSEC_GSS would be in the tokens. This method does not completely
mitigate the attack; it just moves the MIC guessing to the
RPCSEC_GSS_INIT message. In addition without changing GSS, or the
GSS mechanism, there is no way to include the RPCSEC_GSS version
number in the tokens. So for these reasons this method was not
selected.
8. IANA Considerations 8. IANA Considerations
None. None.
9. References 9. References
9.1. Normative 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
skipping to change at page 10, line 36 skipping to change at page 12, line 32
[4] Linn, J., "Generic Security Service Application Program [4] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
and Identifiers for RSA Cryptography for use in the Internet and Identifiers for RSA Cryptography for use in the Internet
X.509 Public Key Infrastructure Certificate and Certificate X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 4055, June 2005. Revocation List (CRL) Profile", RFC 4055, June 2005.
9.2. Informative References 9.2. Informative References
[6] Srinivasan, R., "RPC: Remote Procedure Call Protocol [6] Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-07 (work in progress),
April 2008.
[7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2
and Public Keys", draft-williams-ipsec-channel-binding-01 (work
in progress), April 2008.
[8] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995. 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
US US
skipping to change at page 11, line 44 skipping to change at line 578
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 21 change blocks. 
48 lines changed or deleted 152 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/