draft-ietf-nfsv4-rpcsec-gss-v2-05.txt   draft-ietf-nfsv4-rpcsec-gss-v2-06.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track August 18, 2008 Updates: 2203 (if approved) October 9, 2008
Expires: February 19, 2009 Intended status: Standards Track
Expires: April 12, 2009
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-05.txt draft-ietf-nfsv4-rpcsec-gss-v2-06.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 35
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 February 19, 2009. This Internet-Draft will expire on April 12, 2009.
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 . . . . . . . . . . . . . . . . . . 4
3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . 4 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . 5
3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 4 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 5
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 . . . . . 10
4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 10
5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9 5. Native GSS Channel Bindings . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Operational Recommendation for Deployment . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction and Motivation 1. Introduction and Motivation
RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version This document describes RPCSEC_GSS version 2 (RPCSEC_GSSv2).
1 (RPCSEC_GSSv1) [2] except that support for channel bindings [3] has RPCSEC_GSSv2 is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [2]
been added. The primary motivation for channel bindings is to except that support for channel bindings [3] has been added. The
securely take advantage of hardware assisted encryption that might primary motivation for channel bindings is to securely take advantage
exist at lower levels of the networking protocol stack, such as at of hardware assisted encryption that might exist at lower levels of
the Internet Protocol (IP) layer in the form of IPsec (see [6] and the networking protocol stack, such as at the Internet Protocol (IP)
[7] for information on IPsec channel bindings). The secondary layer in the form of IPsec (see [6] and [7] for information on IPsec
motivation is that even if lower levels are not any more efficient at channel bindings). The secondary motivation is that even if lower
encryption than the RPCSEC_GSS layer, if encryption is occurring at levels are not any more efficient at encryption than the RPCSEC_GSS
the lower level, it can be redundant at the RPCSEC_GSS level. layer, if encryption is occurring at the lower level, it can be
redundant at the RPCSEC_GSS level.
RPCSEC_GSSv2 and RPCSEC_GSSv1 are protocols that exchange tokens
emitted by the Generic Security Services (GSS) framework, which is
defined in [4], and differ only in the support for GSS channel
bindings in RPCSEC_GSSv2. GSS itself supports channel bindings, and
in theory RPCSEC_GSSv2 could use native GSS channel bindings to
achieve the effects described in this section. However, as Section
1.1.6 of [4] states, not all implementations of all GSS mechanisms
support channel bindings. This is sufficient justification for the
approach taken in this document: modify the RPCSEC_GSS protocol to
support channel bindings independent of the capabilities of the GSS
mechanism being used.
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
skipping to change at page 8, line 19 skipping to change at page 9, line 5
RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the
XDR encoding of an instance of data type rgss2_bind_chan_verf_res, XDR encoding of an instance of data type rgss2_bind_chan_verf_res,
which includes a MIC as described below. The data type which includes a MIC as described below. The data type
rgss2_bind_chan_verf_res consists of two fields. 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 target
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.
* RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the * RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the
server did not support the prefix in the rbcva_chan_bind_prefix target 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 target returned a list of prefixes
it does support in the field rbcr_pref_list. it does support in the field rbcr_pref_list. Note that a
channel can have multiple channel bindings each with different
prefixes. The initiator is free to pick its preferred prefix.
If the target does not support the prefix, the status
RGSS2_BIND_CHAN_PREF_NOTSUPP will be returned, and the
initiator can select its next most preferred prefix among the
prefixes the target does support.
* 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 target 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 target
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 array rbcr_oid_list MUST have one the field rbcr_oid_list. The array rbcr_oid_list MUST have one
or more elements. 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
skipping to change at page 9, line 14 skipping to change at page 10, line 7
RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is
RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to
compute rbcmr_bind_chan_hash is that identified by compute rbcmr_bind_chan_hash is that identified by
rbcr_oid_list[0] in the results. 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
RPCSEC_GSSv2 targets MUST support rpc_gss_svc_channel_prot.
The rpc_gss_svc_channel_prot service (Figure 1) 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
skipping to change at page 9, line 41 skipping to change at page 10, line 36
RPCSEC_GSS request with the rgc_version field set to RPCSEC_GSS request with the rgc_version field set to
RPCSEC_GSS_VERS_2. If the target does not recognize RPCSEC_GSS_VERS_2. If the target does not recognize
RPCSEC_GSS_VERS_2, the target will return an RPC error per section RPCSEC_GSS_VERS_2, the target will return an RPC error per section
5.1 of [2]. 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. Native GSS Channel Bindings
To ensure interoperability, implementations of RPCSEC_GSSv2 SHOULD
NOT transfer tokens between the initiator and target that use native
GSS channel bindings (as defined in Section 1.1.6 of [4]).
6. Operational Recommendation for Deployment
RPCSEC_GSSv2 is a superset of RPCSEC_GSSv1, and so can be used in all
situations where RPCSEC_GSSv1 is used. RPCSEC_GSSv2 should be used
when the new functionality, channel bindings, is desired or needed.
7. 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 8. 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. Alex Burlyga and Lars Eggert reviewed the document channel bindings. Alex Burlyga, Lars Eggert, Pasi Eronen, and Dan
and gave valuable feed back for improving its readability. Romascanu reviewed the document and gave valuable feed back for
improving its readability.
7. Security Considerations 9. Security Considerations
The base security considerations consist of: The base security considerations consist of:
o All security considerations from [2]. o All security considerations from [2].
o All security considerations from [3]. o All security considerations from [3].
o All security considerations from the actual secure channel being o All security considerations from the actual secure channel being
used. used.
skipping to change at page 12, line 5 skipping to change at page 13, line 15
A method of mitigation that was considered was to protect the 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 version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and
RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of
RPCSEC_GSS would be in the tokens. This method does not completely RPCSEC_GSS would be in the tokens. This method does not completely
mitigate the attack; it just moves the MIC guessing to the mitigate the attack; it just moves the MIC guessing to the
RPCSEC_GSS_INIT message. In addition without changing GSS, or the RPCSEC_GSS_INIT message. In addition without changing GSS, or the
GSS mechanism, there is no way to include the RPCSEC_GSS version GSS mechanism, there is no way to include the RPCSEC_GSS version
number in the tokens. So for these reasons this method was not number in the tokens. So for these reasons this method was not
selected. selected.
8. IANA Considerations 10. IANA Considerations
None. None.
9. References 11. References
9.1. Normative References 11.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", RFC 2119, 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 [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 11.2. Informative References
[6] Williams, N., "IPsec Channels: Connection Latching", [6] Williams, N., "IPsec Channels: Connection Latching",
draft-ietf-btns-connection-latching-07 (work in progress), draft-ietf-btns-connection-latching-07 (work in progress),
April 2008. April 2008.
[7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 [7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2
and Public Keys", draft-williams-ipsec-channel-binding-01 (work and Public Keys", draft-williams-ipsec-channel-binding-01 (work
in progress), April 2008. in progress), April 2008.
[8] Srinivasan, R., "RPC: Remote Procedure Call Protocol [8] Srinivasan, R., "RPC: Remote Procedure Call Protocol
 End of changes. 20 change blocks. 
43 lines changed or deleted 80 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/