draft-ietf-nfsv4-rpcsec-gss-v2-04.txt   draft-ietf-nfsv4-rpcsec-gss-v2-05.txt 
NFSv4 M. Eisler NFSv4 M. Eisler
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track August 18, 2008 Intended status: Standards Track August 18, 2008
Expires: February 19, 2009 Expires: February 19, 2009
RPCSEC_GSS Version 2 RPCSEC_GSS Version 2
draft-ietf-nfsv4-rpcsec-gss-v2-04.txt draft-ietf-nfsv4-rpcsec-gss-v2-05.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 39 skipping to change at page 1, line 39
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 February 19, 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 [[Comment.1: (RFC Editor please Version 2 is the same as Version 1 but adds support for channel
add reference to the RFC2203 item in the References, since xml2rfc bindings.
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14 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) [2] except that support for channel bindings [3] has
added. The primary motivation for channel bindings is to securely been added. The primary motivation for channel bindings is to
take advantage of hardware assisted encryption that might exist at securely take advantage of hardware assisted encryption that might
lower levels of the networking protocol stack, such as at the exist at lower levels of the networking protocol stack, such as at
Internet Protocol (IP) layer in the form of IPsec (See [6] and [7] the Internet Protocol (IP) layer in the form of IPsec (see [6] and
for information on IPsec channel binding). The secondary motivation [7] for information on IPsec channel bindings). The secondary
is that even if lower levels are not any more efficient at encryption motivation is that even if lower levels are not any more efficient at
than the RPCSEC_GSS layer, if encryption is occurring at the lower encryption than the RPCSEC_GSS layer, if encryption is occurring at
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 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 a ready to compile form.
reader can feed this document into the following shell script to The reader can feed this document into the following shell script to
produce the machine readable XDR description of RPCSEC_GSSv2: 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 document 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
The effect of the script is to remove leading white space from each The effect of the script is to remove leading white space from each
line of the specification, plus a sentinel sequence of "///". 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
 End of changes. 5 change blocks. 
19 lines changed or deleted 15 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/