draft-ietf-nfsv4-nfssec-03.txt   rfc2623.txt 
Network Working Group M. Eisler Network Working Group M. Eisler
Internet Draft January 1999 Request for Comments: 2623 Sun Microsystems, Inc.
Document: draft-ietf-nfsv4-nfssec-03.txt Category: Standards Track June 1999
NFS Version 2 and Version 3 Security Issues and the NFS Protocol's NFS Version 2 and Version 3 Security Issues and the NFS Protocol's
Use of RPCSEC_GSS and Kerberos V5 Use of RPCSEC_GSS and Kerberos V5
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet standards track protocol for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Please refer to the current edition of the "Internet
working documents as Internet-Drafts. Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Comments on this document should be sent to Copyright (C) The Internet Society (1999). All Rights Reserved.
"nfsv4-wg@sunroof.eng.sun.com", the NFS Version 4 Working Group
discussion list.
Abstract Abstract
This memorandum clarifies various security issues involving the NFS This memorandum clarifies various security issues involving the NFS
protocol (Version 2 and Version 3 only) and then describes how the protocol (Version 2 and Version 3 only) and then describes how the
Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS
security flavor protocol and Kerberos V5. This memorandum is security flavor protocol and Kerberos V5. This memorandum is
provided so that people can write compatible implementations. provided so that people can write compatible implementations.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3 1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3
2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 4 2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 3
2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 5 2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 4
2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5 2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5
2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6 2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6
2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 7 2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 6
2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7 2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7
2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 8 2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 7
2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8 2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8
2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 9 2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 8
2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9 2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9
3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 10 3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 9
3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 10 3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 9
3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 11 3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 10
3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11 3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11
4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 12 4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 11
4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12 4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12
4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor 4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor
Registration Entry . . . . . . . . . . . . . . . . . . . . 13 Registration Entry . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations [RFC2434] . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. String Name of Pseudo Flavor . . . . . . . . . . . . . . . 15
6.2.1. Name Space Size . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Outside Review . . . . . . . . . . . . . . . . . . . . . 15
6.3. GSS-API Mechanism OID . . . . . . . . . . . . . . . . . . 15
6.4. GSS-API Mechanism Algorithm Values . . . . . . . . . . . . 15
6.5. RPCSEC_GSS Security Service . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The NFS protocol provides transparent remote access to shared file The NFS protocol provides transparent remote access to shared file
systems across networks. The NFS protocol is designed to be machine, systems across networks. The NFS protocol is designed to be machine,
operating system, network architecture, and security mechanism, and operating system, network architecture, and security mechanism, and
transport protocol independent. This independence is achieved through transport protocol independent. This independence is achieved through
the use of Remote Procedure Call (RPC) primitives built on top of an the use of ONC Remote Procedure Call (RPC) primitives built on top of
eXternal Data Representation (XDR). NFS protocol Version 2 is an eXternal Data Representation (XDR). NFS protocol Version 2 is
specified in the Network File System Protocol Specification specified in the Network File System Protocol Specification
[RFC1094]. A description of the initial implementation can be found [RFC1094]. A description of the initial implementation can be found
in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version
3 Protocol Specification [RFC1813]. A description of some initial 3 Protocol Specification [RFC1813]. A description of some initial
implementations can be found in [Pawlowski]. implementations can be found in [Pawlowski].
For the remainder of this document, whenever it refers to the NFS For the remainder of this document, whenever it refers to the NFS
protocol, it means NFS Version 2 and Version 3, unless otherwise protocol, it means NFS Version 2 and Version 3, unless otherwise
stated. stated.
skipping to change at page 9, line 40 skipping to change at page 9, line 17
write access, or perhaps some other degradation of access. For this write access, or perhaps some other degradation of access. For this
reason, a NFS client SHOULD use the first flavor in the list that it reason, a NFS client SHOULD use the first flavor in the list that it
supports, on the assumption that the best access is provided by the supports, on the assumption that the best access is provided by the
first flavor. NFS servers that support the ability to export file first flavor. NFS servers that support the ability to export file
systems with multiple security flavors SHOULD either present the best systems with multiple security flavors SHOULD either present the best
accessing flavor first to the client, or leave the order under the accessing flavor first to the client, or leave the order under the
control of the system administrator. control of the system administrator.
2.8. Registering Flavors 2.8. Registering Flavors
When one develops a new RPC security flavor, iana@isi.edu MUST be When one develops a new RPC security flavor, iana@iana.org MUST be
contacted to get a unique flavor assignment. To simplify NFS client contacted to get a unique flavor assignment. To simplify NFS client
and server administration, having a simple ASCII string name for the and server administration, having a simple ASCII string name for the
flavor is useful. Currently, the following assignments exist: flavor is useful. Currently, the following assignments exist:
flavor string name flavor string name
AUTH_NONE none AUTH_NONE none
AUTH_SYS sys AUTH_SYS sys
AUTH_DH dh AUTH_DH dh
AUTH_KERB4 krb4 AUTH_KERB4 krb4
A string name for a new flavor SHOULD be assigned. String name A string name for a new flavor SHOULD be assigned. String name
assignments can be registered by contacting nfs-ana@sun.com. In the assignments can be registered by contacting iana@iana.org.
future, this function may be transferred to iana@isi.edu.
3. The NFS Protocol's Use of RPCSEC_GSS 3. The NFS Protocol's Use of RPCSEC_GSS
3.1. Server Principal 3.1. Server Principal
When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API
via a GSS_C_NT_HOSTBASED_SERVICE name type. via a GSS_C_NT_HOSTBASED_SERVICE name type.
GSS_C_NT_HOSTBASED_SERVICE names are of the form: GSS_C_NT_HOSTBASED_SERVICE names are of the form:
service@hostname service@hostname
skipping to change at page 11, line 37 skipping to change at page 11, line 12
objective of the caller is to deny CPU service to legitimate users of objective of the caller is to deny CPU service to legitimate users of
the NFS server's machine processors. the NFS server's machine processors.
Thus, in general, clients SHOULD NOT assume that they will be Thus, in general, clients SHOULD NOT assume that they will be
permitted to alter the <mechanism, QOP, service> triple once the data permitted to alter the <mechanism, QOP, service> triple once the data
exchange phase of RPCSEC_GSS has started. exchange phase of RPCSEC_GSS has started.
3.4. Registering Pseudo Flavors and Mappings 3.4. Registering Pseudo Flavors and Mappings
Pseudo flavor numbers MUST be registered via same method as regular Pseudo flavor numbers MUST be registered via same method as regular
RPC security flavor numbers via iana@isi.edu. RPC security flavor numbers via iana@iana.org.
Once the pseudo flavor number has been assigned, registrants SHOULD Once the pseudo flavor number has been assigned, registrants SHOULD
register the mapping with nfs-ana@sun.com. The mapping registration register the mapping with iana@iana.org. The mapping registration
MUST contain: MUST contain:
* the pseudo flavor number, an ASCII string name for the flavor * the pseudo flavor number, an ASCII string name for the flavor
(for example "none" has been assigned for AUTH_NONE), and (for example "none" has been assigned for AUTH_NONE), and
* the <mechanism, algorithm(s), service> triple. As per the GSS- * the <mechanism, algorithm(s), service> triple. As per the GSS-
API specification, the mechanism MUST be identified with a API specification, the mechanism MUST be identified with a
unique ISO object identifier (OID). The reason why the second unique ISO object identifier (OID). The reason why the second
component of the triple is not necessarily a QOP value is that component of the triple is not necessarily a QOP value is that
GSS-API allows mechanisms much latitude in the mapping of the GSS-API allows mechanisms much latitude in the mapping of the
algorithm used in the default quality of protection (See algorithm used in the default quality of protection (See
subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed
discussion). With some mechanisms, the second component of the discussion). With some mechanisms, the second component of the
triple will be a QOP. Internally, on the NFS implementation, it triple will be a QOP. Internally, on the NFS implementation, it
is expected that the triple would use a QOP for the second is expected that the triple would use a QOP for the second
component. component.
The mapping registration SHOULD also contain: The mapping registration SHOULD also contain:
* A reference to an RFC (typically an Informational RFC) * A reference to an RFC describing how the NFS protocol works
describing how the NFS protocol MUST work over the pseudo over the pseudo flavor(s), including the pseudo flavor
flavor(s), including the pseudo flavor number(s), string name(s) number(s), string name(s) for the flavor(s), and any other
for the flavor(s), and any other issues, including how the issues, including how the registrant is interpreting the GSS-API
registrant is interpreting the GSS-API mechanism. mechanism.
* A reference to the GSS-API mechanism used. * A reference to the GSS-API mechanism used.
An example of a complete registration is provided in subsection 4.2, An example of a complete registration is provided in subsection 4.2,
"The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry." "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry."
4. The NFS Protocol over Kerberos V5 4. The NFS Protocol over Kerberos V5
The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS
security flavor. The GSS-API security mechanism for Kerberos V5 that security flavor. The GSS-API security mechanism for Kerberos V5 that
the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos
V5 GSS-API description [RFC 1964]. V5 GSS-API description [RFC1964].
4.1. Issues with Kerberos V5 QOPs 4.1. Issues with Kerberos V5 QOPs
The Kerberos V5 GSS-API description defines three algorithms for The Kerberos V5 GSS-API description defines three algorithms for
integrity: integrity:
* DES MAC MD5 * DES MAC MD5
* MD2.5 * MD2.5
skipping to change at page 14, line 21 skipping to change at page 13, line 46
3 == mechanism's OID 3 == mechanism's OID
4 == QOP 4 == QOP
5 == RPCSEC_GSS service 5 == RPCSEC_GSS service
1 2 3 4 5 1 2 3 4 5
----------------------------------------------------------- -----------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none 390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity 390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy 390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy
The reference for the GSS-API mechanism with the above OID is RFC The reference for the GSS-API mechanism with the above OID is
1964. [RFC1964].
The reference for how the NFS protocol MUST work over Kerberos V5 is The reference for how the NFS protocol MUST work over Kerberos V5 is
this document. this document.
5. Security Considerations 5. Security Considerations
Version 3 of the MOUNT protocol is used to negotiate the security Version 3 of the MOUNT protocol is used to negotiate the security
flavor to be used by the NFS Version 3 client. If the NFS client uses flavor to be used by the NFS Version 3 client. If the NFS client uses
a weak security flavor like AUTH_SYS to query a Version 3 MOUNT a weak security flavor like AUTH_SYS to query a Version 3 MOUNT
server, then the following attacks are possible by an attacker in the server, then the following attacks are possible by an attacker in the
skipping to change at page 15, line 5 skipping to change at page 14, line 31
advance what security flavors the MOUNT server supports. advance what security flavors the MOUNT server supports.
* If the client and server support a common set of security * If the client and server support a common set of security
flavors, such that the client considers one preferable to the flavors, such that the client considers one preferable to the
other (for example, one might have privacy and other not), other (for example, one might have privacy and other not),
unless the client uses a strong security flavor in the MOUNT unless the client uses a strong security flavor in the MOUNT
protocol query, an attacker in the middle could cause the client protocol query, an attacker in the middle could cause the client
to use the weaker form of security. Again, a client could to use the weaker form of security. Again, a client could
contact the MOUNT server using a stronger form of security. contact the MOUNT server using a stronger form of security.
6. IANA Considerations [RFC2434]
This memorandum describes how NFS Version 2 and Version 3 work over
RPC's RPCSEC_GSS security flavor. This memorandum requires that
triples of { GSS-API mechanism OID, GSS-API mechanism algorithm,
RPCSEC_GSS security service } be mapped to a unique RPC security
flavor number, which is a pseudo flavor that does not appear in an
RPC protocol header. This memorandum also encourages that an ASCII
string name be registered with the triple.
Thus there are five different kinds of objects to consider guidelines
for.
6.1. Pseudo Flavor Number
The considerations of assignment, allocation, and delegation of
pseudo flavor numbers are no different than that the considerations
for RPC security flavors, as both are assigned from the same number
space. IANA is already responsible for the assigned of RPC security
flavors, and because this memorandum does not specify the RPC
protocol [RFC1831], it is beyond the scope of this memorandum to
guide IANA in the assignment of flavor numbers.
6.2. String Name of Pseudo Flavor
This memorandum introduces the concept of a string name to be
associated with the RPC pseudo flavor number, and so it is within the
scope of this memorandum to provide guidance to IANA.
6.2.1. Name Space Size
There are no limits placed on the length of the unique string name by
this memorandum, so the size of the name space is infinite. However,
IANA may want to prevent the hoarding or reservation of names. The
simplest way to do this is by requiring the registrant to provide the
GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS
security service, and flavor number, with the request for a flavor
name. If the registrant does not have a flavor number, then
guidelines for flavor number assignments will indirectly limit the
assignment of flavor names.
6.2.2. Delegation
The simplest way to handle delegation is to delegate portions of the
RPC security flavor number space with the RPC flavor name space. The
guidelines for delegation of the flavor name space are thus
equivalent to guidelines for delegations of the flavor number space.
6.2.3. Outside Review
Because string names can be trademarks, IANA may want to seek legal
counsel to review a proposed pseudo flavor name. Other than that, no
outside review is necessary.
6.3. GSS-API Mechanism OID
This memorandum assumes that the mechanism OID associated with the
pseudo flavor has already been allocated. OIDs are allocated by the
International Standards Organization and the International
Telecommunication Union. Both organizations have delegated assignment
authority for subsets of the OID number space to other organizations.
Presumably, IANA has received authority to assign OIDs to GSS-API
mechanisms. Because this memorandum does not specify the GSS-API
protocol (see [RFC2078]) it is beyond the scope of this memorandum to
guide IANA in the assignment of GSS-API mechanism OIDs.
6.4. GSS-API Mechanism Algorithm Values
This memorandum assumes that the algorithm value for a given GSS-API
mechanism has already been allocated. Algorithm values are controlled
by the owner of the GSS-API mechanism, though the owner may delegate
assignment of algorithm values to a body such as IANA. Because this
memorandum does not specify GSS-API mechanisms, such as [RFC1964], it
is beyond the scope of this memorandum to guide IANA in the
assignment of a mechanism's algorithm value(s).
6.5. RPCSEC_GSS Security Service
There are only three security services and they are enumerated and
described in [RFC2203]. No guideline to IANA is necessary.
References References
[RFC1094] Sun Microsystems, Inc. (1989). "NFS: Network File System [RFC1094] Sun Microsystems, Inc., "NFS: Network File System
Protocol specification," RFC 1094. Protocol Specification", RFC 1094, March 1989.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1094.txt http://www.ietf.org/rfc/rfc1094.txt
[Sandberg] [Sandberg]
Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
B.. (1985). "Design and Implementation of the Sun Network B. (1985). "Design and Implementation of the Sun Network
Filesystem," Proceedings of the 1985 Summer USENIX Filesystem," Proceedings of the 1985 Summer USENIX
Technical Conference. Technical Conference.
[RFC1813] Callaghan, B., Pawlowski, B., Staubach, P. (1995). "NFS [RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS
Version 3 Protocol Specification," RFC 1813. Version 3 Protocol Specification", RFC 1813, June 1995.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1813.txt http://www.ietf.org/rfc/rfc1813.txt
[RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2," RFC 1831. Specification Version 2", RFC 1831, August 1995.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1831.txt http://www.ietf.org/rfc/rfc1831.txt
[RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation [RFC1832] Srinivasan, R., "XDR: External Data Representation
Standard," RFC 1832. Standard", RFC 1832, August 1995.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1832.txt http://www.ietf.org/rfc/rfc1832.txt
[Pawlowski] [Pawlowski]
Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., Pawlowski, B., Juszczak, C., Staubach, P., Smith, C.,
Lebel, D., Hitz, D. (1994). "NFS Version 3 Design and Lebel, D. and D. Hitz, "NFS Version 3 Design and
Implementation," Proceedings of the USENIX Summer 1994 Implementation", Proceedings of the USENIX Summer 1994
Technical Conference. Technical Conference.
[RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification," RFC 2203. Specification", RFC 2203, September 1997.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2203.txt http://www.ietf.org/rfc/rfc2203.txt
[RFC2078] Linn, J. (1997). "Generic Security Service Application [RFC2078] Linn, J., "Generic Security Service Application
Program Interface, Version 2," RFC 2078. Program Interface, Version 2", RFC 2078, January 1997.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2078.txt http://www.ietf.org/rfc/rfc2078.txt
[RFC1057] Sun Microsystems, Inc. "RPC: Remote Procedure Call Protocol [RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call
Specification Version 2," RFC 1057. This RFC is being Protocol Specification Version 2", RFC 1057, June 1988.
referenced for its description of the AUTH_DH (AUTH_DES) This RFC is being referenced for its description of the
RPC security flavor. AUTH_DH (AUTH_DES) RPC security flavor.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1057.txt http://www.ietf.org/rfc/rfc1057.txt
[RFC2119] Bradner, S. (1997). "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels", BCP 14, RFC 2119, March 1997.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt http://www.ietf.org/rfc/rfc2119.txt
[Callaghan] [Callaghan]
Callaghan, B., Singh, S. (1993). "The Autofs Automounter," Callaghan, B., Singh, S. (1993). "The Autofs Automounter,"
Proceedings of the 1993 Summer USENIX Technical Conference. Proceedings of the 1993 Summer USENIX Technical Conference.
[RFC1964] Linn, J. (1996). "The Kerberos Version 5 GSS-API [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism," RFC 1964. Mechanism", RFC 1964, June 1996.
http://info.internet.isi.edu/in-notes/rfc/files/rfc1964.txt http://www.ietf.org/rfc/rfc1964.txt
[RFC2054] Callaghan, B. (1996). "WebNFS Client Specification," RFC [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC
2054. 2054, October 1996.
http://info.internet.isi.edu/in-notes/rfc/files/rfc2054.txt http://www.ietf.org/rfc/rfc2054.txt
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
http://www.ietf.org/rfc/rfc2434.txt
[MIT] Massachusetts Institute of Technology (1998). "Kerberos: [MIT] Massachusetts Institute of Technology (1998). "Kerberos:
The Network Authentication Protocol." The Web site for The Network Authentication Protocol." The Web site for
downloading MIT's implementation of Kerberos V5, including downloading MIT's implementation of Kerberos V5, including
implementations of RFC 1510 and RFC 1964. implementations of RFC 1510 and RFC 1964.
http://web.mit.edu/kerberos/www/index.html http://web.mit.edu/kerberos/www/index.html
Acknowledgments Acknowledgments
The author thanks: The author thanks:
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve * Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve
Nahm, and David Robinson for their review comments. Nahm, Joyce Reynolds, and David Robinson for their review
comments.
* John Linn, for his explanation of QOP handling in RFC 1964. * John Linn, for his explanation of QOP handling in RFC 1964.
Author's Address Author's Address
Address comments related to this memorandum to: Address comments related to this memorandum to:
nfsv4-wg@sunroof.eng.sun.com nfsv4-wg@sunroof.eng.sun.com
Mike Eisler Mike Eisler
Sun Microsystems, Inc. Sun Microsystems, Inc.
5565 Wilson Road 5565 Wilson Road
Colorado Springs, CO 80919 Colorado Springs, CO 80919
Phone: 1-719-599-9026 Phone: 1-719-599-9026
E-mail: mre@eng.sun.com EMail: mre@eng.sun.com
14. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of eveloping
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 37 change blocks. 
88 lines changed or deleted 174 lines changed or added

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