RFC relevance of mechanism

As per Relevance of the word mechanism, we have this rfc below:

Network Working Group M.
Request for Comments: 2623 Sun Microsystems, Inc
Category: Standards Track June 1999

NFS Version 2 and Version 3 Security Issues and the NFS Protocol'
Use of RPCSEC_GSS and Kerberos V

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This memorandum clarifies various security issues involving the
protocol (Version 2 and Version 3 only) and then describes how
Version 2 and Version 3 of the NFS protocol use the RPCSEC_
security flavor protocol and Kerberos V5. This memorandum
provided so that people can write compatible implementations

Table of

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3
2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 3
2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 4
2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5
2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6
2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 6
2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7
2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 7
2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8
2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 8
2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9
3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 9

Eisler Standards Track [Page 1]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 9
3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 10
3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11
4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 11
4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12
4.2. The NFS Protocol over Kerberos V5 Pseudo
Registration Entry . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations [RFC2434] . . . . . . . . . . . . . . . 14
6.1. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . 14
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.

The NFS protocol provides transparent remote access to shared
systems across networks. The NFS protocol is designed to be machine
operating system, network architecture, and security mechanism,
transport protocol independent. This independence is achieved
the use of ONC Remote Procedure Call (RPC) primitives built on top
an eXternal Data Representation (XDR). NFS protocol Version 2
specified in the Network File System Protocol
[RFC1094]. A description of the initial implementation can be
in [Sandberg]. NFS protocol Version 3 is specified in the NFS
3 Protocol Specification [RFC1813]. A description of some
implementations can be found in [Pawlowski].

For the remainder of this document, whenever it refers to the
protocol, it means NFS Version 2 and Version 3, unless
stated

The RPC protocol is specified in the Remote Procedure Call
Specification Version 2 [RFC1831]. The XDR protocol is specified
External Data Representation Standard [RFC1832].

A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203].
This new flavor allows application protocols built on top of RPC
access security mechanisms that adhere to the GSS-API

Eisler Standards Track [Page 2]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

[RFC2078].

The purpose of this document is to clarify NFS security issues and
specify how the NFS protocol uses RPCSEC_GSS. This document will
describe how NFS works over Kerberos V5, via RPCSEC_GSS

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].

1.1. Overview of RPC Security

The RPC protocol includes a slot for security parameters (referred
as an authentication flavor in the RPC specification [RFC1831])
every call. The contents of the security parameters are
by the type of authentication used by the server and client. A
may support several different flavors of authentication at once
Some of the better known flavors are summarized as follows

* The AUTH_NONE flavor provides null authentication, that is,
authentication information is passed

* The AUTH_SYS flavor provides a UNIX-style user identifier,
identifier, and an array of supplemental group identifiers
each call

* The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057])
provides DES-encrypted authentication parameters based on
network-wide string name, with session keys exchanged via
Diffie-Hellman public key scheme

* The AUTH_KERB4 flavor provides DES encrypted
parameters based on a network-wide string name (the name is
Kerberos Version 4 principal identifier) with session
exchanged via Kerberos Version 4 secret keys

The NFS protocol is not limited to the above list of
flavors

2. Overview of NFS

2.1. Port

Many NFS servers will require that the client send its NFS
from UDP or TCP source ports with values < 1024. The theory is
binding to ports < 1024 is a privileged operation on the client,
so the client is enforcing file access permissions on its end.
theory breaks down because

Eisler Standards Track [Page 3]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

* On many operating systems, there are no constraints on what
what user can bind to

* Just because the client host enforces the privilege on
to ports < 1024 does not necessarily mean that a non-
user cannot gain access to the port binding privilege.
example with a single-user desk-top host running a
operating system, the user may have knowledge of the root
password. And even if he does not have that knowledge,
physical access to the desk-top machine, root privileges
trivially acquired

In some rare cases, when the system administrator can be certain
the clients are trusted and under control (in particular,
from physical attack), relying of trusted ports MAY be a
form of security

In most cases, the use of privileged ports and port monitoring
security is at best an inconvenience to the attacker and SHOULD
be depended on

To maximize interoperability

* NFS clients SHOULD attempt to bind to ports < 1024. In
cases, if they fail to bind (because either the user does
have the privilege to do so, or there is no free port < 1024),
the NFS client MAY wish to attempt the NFS operation over a
>= 1024.

* NFS servers that implement port monitoring SHOULD provide
method to turn it off

* Whether port monitoring is enabled or not, NFS servers
NOT reject NFS requests to the NULL procedure (procedure
0). See subsection 2.3.1, "NULL procedure" for a
explanation

2.1.1. MOUNT

The port monitoring issues and recommendations apply to the
protocol as well

2.2. RPC Security

The NFS server checks permissions by taking the credentials from
RPC security information in each remote request. Each flavor
credentials differently

Eisler Standards Track [Page 4]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

2.2.1. AUTH_

Using the AUTH_SYS flavor of authentication, the server gets
client's effective user identifier, effective group identifier
supplemental group identifiers on each call, and uses them to
access. Using user identifiers and group identifiers implies that
client and server either share the same identifier name space or
local user and group identifier mapping

For those sites that do not implement a consistent user
and group identifier space, NFS implementations must agree on
mapping of user and group identifiers between NFS clients
servers

2.2.2. AUTH_DH and AUTH_KERB

The AUTH_DH and AUTH_KERB4 styles of security are based on
network-wide name. They provide greater security through the use
DES encryption and public keys in the case of AUTH_DH, and
encryption and Kerberos secret keys (and tickets) in the AUTH_KERB
case. Again, the server and client must agree on the identity of
particular name on the network, but the name to identity mapping
more operating system independent than the user identifier and
identifier mapping in AUTH_SYS. Also, because the
parameters are encrypted, a malicious user must know another user'
network password or private key to masquerade as that user
Similarly, the server returns a verifier that is also encrypted
that masquerading as a server requires knowing a network password

2.2.3. RPCSEC_

The RPCSEC_GSS style of security is based on a security-mechanism
specific principal name. GSS-API mechanisms provide security
the use of cryptography. The cryptographic protections are used
the construction of the credential on calls, and in the verifiers
replies. Optionally, cryptographic protections will be in the body
the calls and replies

Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4,
and RPCSEC_GSS does not imply that the NFS protocol is limited
using those five flavors

Eisler Standards Track [Page 5]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

2.3. Authentication for NFS

2.3.1. NULL

The NULL procedure is typically used by NFS clients to determine
an NFS server is operating and responding to requests (in
words, to "ping" the NFS server). Some NFS servers require that
client using the NULL procedure

* send the request from TCP or UDP port < 1024. There does
seem to be any value in this because the NULL procedure is
very low overhead and certainly no more overhead than the
of processing a NULL procedure and returning an
error. Moreover, by sending back an authentication error,
server has confirmed the information that the client
interested in: is the server operating

* be authenticated with a flavor stronger than AUTH_SYS. This is
problem because the RPCSEC_GSS protocol uses NULL for
messages

NFS servers SHOULD

* accept the NULL procedure ping over AUTH_NONE and AUTH_SYS,
addition to other RPC security flavors,

* NOT require that the source port be < 1024 on a NULL
ping

2.3.2. NFS Procedures Used at Mount

Certain NFS procedures are used at the time the NFS client mounts
file system from the server. Some NFS server implementations
not require authentication for these NFS procedures. For
protocol Version 2, these procedures are GETATTR and STATFS.
Version 3, the procedure is FSINFO

The reason for not requiring authentication is described as follows
When the NFS client mounts a NFS server's file system, the
of the caller on the client is typically an administrative entity (
UNIX operating systems, this is usually the "root" user). It
often the case that, for unattended operation in concert with
automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_
credentials for the administrative entity associated with
automounter are not available. If so, the NFS client will
AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount
file system. While an attacker could exploit this
artifact, the exposure is limited to gaining the attributes of a

Eisler Standards Track [Page 6]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

or a file system's characteristics. This OPTIONAL trade off
the opportunity for improved ease of use

2.4. Binding Security Flavors to

NFS servers MAY export file systems with specific security
bound to the export. In the event a client uses a security
that is not the one of the flavors the file system was exported with
NFS server implementations MAY

* reject the request with an error (either an NFS error or an
level authentication error),

* allow the request, but map the user's credentials to a
other than the one the client intended. Typically the user
is the result of this mapping is a user with limited access
the system, such as user "nobody" on UNIX systems

If a client uses AUTH_NONE, the server's options are the same as
above, except that AUTH_NONE carries with it no user identity.
order to allow the request, on many operating systems the server
assign a user identity. Typically this assignment will be a user
limited access on the system, such as user "nobody" on UNIX systems

2.5. Anonymous

The following passage is excerpted verbatim from RFC 1813,
4.4 "Permission Issues" (except that "may" has been changed
"MAY"):

In most operating systems, a particular user (on UNIX, the uid 0)
has access to all files, no matter what permission and
they have. This superuser permission MAY not be allowed on
server, since anyone who can become superuser on their
could gain access to all remote files. A UNIX server by
maps uid 0 to a distinguished value (UID_NOBODY), as well
mapping the groups list, before doing its access checking.
server implementation MAY provide a mechanism to change
mapping. This works except for NFS version 3 protocol root
systems (required for diskless NFS version 3 protocol
support), where superuser access cannot be avoided.
options are used, on the server, to restrict the set of
allowed superuser access

The issues identified as applying to NFS protocol Version 3 in
above passage also apply to Version 2.

Eisler Standards Track [Page 7]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

2.6. Host-based Access

In some NFS server implementations, a host-based access
method is used whereby file systems can be exported to lists
clients. File systems may also be exported for read-only or read
write access. Several of these implementations will check
only at mount time, during the request for the file handle via
MOUNT protocol handshake. The lack of authorization checking
subsequent NFS requests has the following consequences

* NFS servers are not able to repudiate access to the file
by an NFS client after the client has mounted the file system

* An attacker can circumvent the MOUNT server's access control
gain access to a file system that the attacker is not
for. The circumvention is accomplished by either stealing a
handle (usually by snooping the network traffic between
legitimate client and server) or guessing a file handle.
this attack to succeed, the attacker must still be
impersonate a user's credentials, which is simple for AUTH_SYS
but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS

* WebNFS clients that use the public file handle lookup [RFC2054]
will not go through the MOUNT protocol to acquire initial
handle of the NFS file system. Enforcing access control via
MOUNT protocol is going to be a little use. Granted, some
server implementations cope with this by limiting the use of
public file handle to file systems exported to every client
the Internet

Thus, NFS server implementations SHOULD check the client'
authorization on each NFS request

2.7. Security Flavor

Any application protocol that supports multiple styles of
will have the issue of negotiating the security method to be used
NFS Version 2 had no support for security flavor negotiation. It
up to the client to guess, or depend on prior knowledge. Often
prior knowledge would be available in the form of security
specified in a directory service used for the purpose
automounting

The MOUNT Version 3 protocol, associated with NFS Version 3,
the problem by having the response to the MNT procedure include
list of flavors in the MNT procedure. Note that because some
servers will export file systems to specific lists of clients,
different access (read-only versus read-write), and with

Eisler Standards Track [Page 8]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

security flavors, it is possible a client might get back
security flavors in the list returned in the MNT response. The use
one flavor instead of another might imply read-only instead of read
write access, or perhaps some other degradation of access. For
reason, a NFS client SHOULD use the first flavor in the list that
supports, on the assumption that the best access is provided by
first flavor. NFS servers that support the ability to export
systems with multiple security flavors SHOULD either present the
accessing flavor first to the client, or leave the order under
control of the system administrator

2.8. Registering

When one develops a new RPC security flavor, iana@iana.org MUST
contacted to get a unique flavor assignment. To simplify NFS
and server administration, having a simple ASCII string name for
flavor is useful. Currently, the following assignments exist

flavor string

AUTH_NONE
AUTH_SYS
AUTH_DH
AUTH_KERB4 krb

A string name for a new flavor SHOULD be assigned. String
assignments can be registered by contacting iana@iana.org

3. The NFS Protocol's Use of RPCSEC_

3.1. Server

When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-
via a GSS_C_NT_HOSTBASED_SERVICE name type
GSS_C_NT_HOSTBASED_SERVICE names are of the form

service@

For NFS, the "service" element

3.2.

RPCSEC_GSS is a single security flavor over which different
mechanisms can be multiplexed. Within a mechanism, GSS-API
for the support of multiple quality of protections (QOPs), which
pairs of cryptographic algorithms. Each algorithm in the QOP

Eisler Standards Track [Page 9]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

of an encryption algorithm for privacy and a checksum algorithm
integrity. RPCSEC_GSS lets one protect the RPC request/response
with plain header authentication, message integrity, and
privacy. Thus RPCSEC_GSS effectively supports M * Q * 3
styles of security, where M is the number of mechanisms supported,
is the average number of QOPs supported for each mechanism, and 3
enumerates authentication, integrity, and privacy

Because RPCSEC_GSS encodes many styles of security, just
RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's
response is not going to be of much use to the NFS client

The solution is the creation of a concept called "pseudo flavors."
Pseudo flavors are 32 bit integers that are allocated out of the
number space as regular RPC security flavors like AUTH_NONE
AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that
pseudo flavor will map to a specific triple of security mechanism
quality of protection, and service. The service will be one
authentication, integrity, and privacy. Note that integrity
authentication, and privacy includes integrity. RPCSEC_GSS
constants named rpc_gss_svc_none, rpc_gss_svc_integrity,
rpc_gss_svc_privacy, for authentication, integrity, and
respectively

Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server
instead return one or more pseudo flavors if the NFS server
RPCSEC_GSS and if the file system has been exported with one or
<mechanism, QOP, service> triples. See section 4, "The NFS
over Kerberos V5" for an example of pseudo flavor to triple mapping

3.3. Changing RPCSEC_GSS

Once an RPCSEC_GSS session or context has been set up (via
RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures
RPCSEC_GSS), the NFS server MAY lock the <mechanism, QOP, service
triple for the duration of the session. While RPCSEC_GSS allows
the use of different QOPs and services on each message, it would
expensive for the NFS server to re-consult its table of exported
systems to see if the triple was allowed. Moreover, by the time
NFS server's dispatch routine was reached, the typical RPC
would already have performed the appropriate GSS-API operation
GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity
privacy services were selected. If the file system being
were not exported with integrity or privacy, or with the
QOP used to perform the integrity or privacy service, then it
be possible to execute a denial of service attack, whereby
objective of the caller is to deny CPU service to legitimate users
the NFS server's machine processors

Eisler Standards Track [Page 10]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

Thus, in general, clients SHOULD NOT assume that they will
permitted to alter the <mechanism, QOP, service> triple once the
exchange phase of RPCSEC_GSS has started

3.4. Registering Pseudo Flavors and

Pseudo flavor numbers MUST be registered via same method as
RPC security flavor numbers via iana@iana.org

Once the pseudo flavor number has been assigned, registrants
register the mapping with iana@iana.org. The mapping
MUST contain

* the pseudo flavor number, an ASCII string name for the
(for example "none" has been assigned for AUTH_NONE),

* the <mechanism, algorithm(s), service> triple. As per the GSS
API specification, the mechanism MUST be identified with
unique ISO object identifier (OID). The reason why the
component of the triple is not necessarily a QOP value is
GSS-API allows mechanisms much latitude in the mapping of
algorithm used in the default quality of protection (
subsection 4.1, "Issues with Kerberos V5 QOPs," for a
discussion). With some mechanisms, the second component of
triple will be a QOP. Internally, on the NFS implementation,
is expected that the triple would use a QOP for the
component

The mapping registration SHOULD also contain

* A reference to an RFC describing how the NFS protocol
over the pseudo flavor(s), including the pseudo
number(s), string name(s) for the flavor(s), and any
issues, including how the registrant is interpreting the GSS-
mechanism

* A reference to the GSS-API mechanism used

An example of a complete registration is provided in subsection 4.2,
"The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry."

4. The NFS Protocol over Kerberos V

The NFS protocol uses Kerberos V5 security using the RPCSEC_
security flavor. The GSS-API security mechanism for Kerberos V5
the NFS/RPCSEC_GSS protocol stack uses is described in the
V5 GSS-API description [RFC1964].

Eisler Standards Track [Page 11]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

4.1. Issues with Kerberos V5

The Kerberos V5 GSS-API description defines three algorithms
integrity

* DES MAC MD

* MD2.5

* DES-

RFC 1964 states that MD2.5 "may be significantly weaker than DES
MD5." RFC 1964 also states that DES-MAC "may not be present in
implementations."

Thus the description of operation of NFS clients and servers
Kerberos V5 is limited to the DES MAC MD5 integrity algorithm

NFS clients and servers operating over Kerberos V5 MUST support
DES MAC MD5 integrity algorithm. RFC 1964 lists a single
for privacy: 56 bit DES. NFS clients and servers SHOULD support
56 bit DES privacy algorithm

GSS-API has the concept of a default QOP of zero which
different integrity and privacy algorithms to different GSS-
mechanisms. In Kerberos V5, the default QOP of zero means to use
56 bit DES algorithm (when doing a GSS_Wrap() operation with
conf_req_flag set to 1).

For Kerberos V5, the default QOP of zero means different
algorithms to different implementations of Kerberos V5. Furthermore
during the processing of a token in GSS_Unwrap(),
GSS_VerifyMIC(), at least one reference implementation of
Kerberos V5 GSS-API mechanism [MIT], always returns a QOP of zero
regardless of integrity algorithm encoded in the token. For
implementations, it means that the caller of GSS_Unwrap()
GSS_VerifyMIC() cannot know the actual integrity algorithm used
Given that each integrity algorithm has a different degree
security, this situation may not be acceptable to the user of GSS
API. An implementation of Kerberos V5 under GSS-API for use under
MUST NOT do this

For the purposes of NFS, as a simplification, some Kerberos V5 GSS
API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity
and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the
MAC MD5 integrity that is specified to QOP 0.

Eisler Standards Track [Page 12]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration

Here are the pseudo flavor mappings for the NFS protocol

Kerberos V5 security

columns

1 == number of pseudo
2 == name of pseudo
3 == mechanism's
4 == mechanism's algorithm(s
5 == RPCSEC_GSS

1 2 3 4 5
-----------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_
for integrity
and 56 bit
for privacy

An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5
maps the default QOP to DES MAC MD5 (and vice versa), would
a mapping of

columns

1 == number of pseudo
2 == name of pseudo
3 == mechanism's
4 ==
5 == RPCSEC_GSS

1 2 3 4 5
-----------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_

The reference for the GSS-API mechanism with the above OID
[RFC1964].

The reference for how the NFS protocol MUST work over Kerberos V5
this document

Eisler Standards Track [Page 13]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

5. Security

Version 3 of the MOUNT protocol is used to negotiate the
flavor to be used by the NFS Version 3 client. If the NFS client
a weak security flavor like AUTH_SYS to query a Version 3
server, then the following attacks are possible by an attacker in
middle

* The attacker in the middle can coax the NFS client into using
weaker form of security than what the real NFS server requires
However, once the NFS client selects a security flavor when
sends a request to real NFS server, if the flavor
unacceptable, the NFS client's NFS request will be rejected.
at worst, a denial of service attack is possible. In theory,
NFS client could contact the MOUNT server using a
security flavor, but this would require that the client know
advance what security flavors the MOUNT server supports

* If the client and server support a common set of
flavors, such that the client considers one preferable to
other (for example, one might have privacy and other not),
unless the client uses a strong security flavor in the
protocol query, an attacker in the middle could cause the
to use the weaker form of security. Again, a client
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
RPC's RPCSEC_GSS security flavor. This memorandum requires
triples of { GSS-API mechanism OID, GSS-API mechanism algorithm
RPCSEC_GSS security service } be mapped to a unique RPC
flavor number, which is a pseudo flavor that does not appear in
RPC protocol header. This memorandum also encourages that an
string name be registered with the triple

Thus there are five different kinds of objects to consider
for

6.1. Pseudo Flavor

The considerations of assignment, allocation, and delegation
pseudo flavor numbers are no different than that the
for RPC security flavors, as both are assigned from the same
space. IANA is already responsible for the assigned of RPC
flavors, and because this memorandum does not specify the
protocol [RFC1831], it is beyond the scope of this memorandum
guide IANA in the assignment of flavor numbers

Eisler Standards Track [Page 14]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

6.2. String Name of Pseudo

This memorandum introduces the concept of a string name to
associated with the RPC pseudo flavor number, and so it is within
scope of this memorandum to provide guidance to IANA

6.2.1. Name Space

There are no limits placed on the length of the unique string name
this memorandum, so the size of the name space is infinite. However
IANA may want to prevent the hoarding or reservation of names.
simplest way to do this is by requiring the registrant to provide
GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_
security service, and flavor number, with the request for a
name. If the registrant does not have a flavor number,
guidelines for flavor number assignments will indirectly limit
assignment of flavor names

6.2.2.

The simplest way to handle delegation is to delegate portions of
RPC security flavor number space with the RPC flavor name space.
guidelines for delegation of the flavor name space are
equivalent to guidelines for delegations of the flavor number space

6.2.3. Outside

Because string names can be trademarks, IANA may want to seek
counsel to review a proposed pseudo flavor name. Other than that,
outside review is necessary

6.3. GSS-API Mechanism

This memorandum assumes that the mechanism OID associated with
pseudo flavor has already been allocated. OIDs are allocated by
International Standards Organization and the
Telecommunication Union. Both organizations have delegated
authority for subsets of the OID number space to other organizations
Presumably, IANA has received authority to assign OIDs to GSS-
mechanisms. Because this memorandum does not specify the GSS-
protocol (see [RFC2078]) it is beyond the scope of this memorandum
guide IANA in the assignment of GSS-API mechanism OIDs

6.4. GSS-API Mechanism Algorithm

This memorandum assumes that the algorithm value for a given GSS-
mechanism has already been allocated. Algorithm values are
by the owner of the GSS-API mechanism, though the owner may

Eisler Standards Track [Page 15]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

assignment of algorithm values to a body such as IANA. Because
memorandum does not specify GSS-API mechanisms, such as [RFC1964],
is beyond the scope of this memorandum to guide IANA in
assignment of a mechanism's algorithm value(s).

6.5. RPCSEC_GSS Security

There are only three security services and they are enumerated
described in [RFC2203]. No guideline to IANA is necessary

[RFC1094] Sun Microsystems, Inc., "NFS: Network File
Protocol Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.

[Sandberg
Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon
B. (1985). "Design and Implementation of the Sun
Filesystem," Proceedings of the 1985 Summer
Technical Conference

[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "
Version 3 Protocol Specification", RFC 1813, June 1995.
http://www.ietf.org/rfc/rfc1813.

[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call
Specification Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.

[RFC1832] Srinivasan, R., "XDR: External Data
Standard", RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.

[Pawlowski
Pawlowski, B., Juszczak, C., Staubach, P., Smith, C.,
Lebel, D. and D. Hitz, "NFS Version 3 Design
Implementation", Proceedings of the USENIX Summer 1994
Technical Conference

[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS
Specification", RFC 2203, September 1997.
http://www.ietf.org/rfc/rfc2203.

[RFC2078] Linn, J., "Generic Security Service
Program Interface, Version 2", RFC 2078, January 1997.
http://www.ietf.org/rfc/rfc2078.

Eisler Standards Track [Page 16]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

[RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure
Protocol Specification Version 2", RFC 1057, June 1988.
This RFC is being referenced for its description of
AUTH_DH (AUTH_DES) RPC security flavor
http://www.ietf.org/rfc/rfc1057.

[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119.

[Callaghan
Callaghan, B., Singh, S. (1993). "The Autofs Automounter,"
Proceedings of the 1993 Summer USENIX Technical Conference

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-
Mechanism", RFC 1964, June 1996.
http://www.ietf.org/rfc/rfc1964.

[RFC2054] Callaghan, B., "WebNFS Client Specification",
2054, October 1996.
http://www.ietf.org/rfc/rfc2054.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
an IANA Considerations Section in RFCs", BCP 26,
2434, October 1998.
http://www.ietf.org/rfc/rfc2434.

[MIT] Massachusetts Institute of Technology (1998). "Kerberos
The Network Authentication Protocol." The Web site
downloading MIT's implementation of Kerberos V5,
implementations of RFC 1510 and RFC 1964.
http://web.mit.edu/kerberos/www/index.

The author thanks

* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling,
Nahm, Joyce Reynolds, and David Robinson for their
comments

* John Linn, for his explanation of QOP handling in RFC 1964.

Eisler Standards Track [Page 17]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

Author's

Address comments related to this memorandum to

nfsv4-wg@sunroof.eng.sun.

Mike
Sun Microsystems, Inc
5565 Wilson
Colorado Springs, CO 80919

Phone: 1-719-599-9026
EMail: mre@eng.sun.

Eisler Standards Track [Page 18]

RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999

14. Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implmentation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind
provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose of
Internet standards in which case the procedures for
defined in the Internet Standards process must be followed, or
required to translate it into languages other than English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Eisler Standards Track [Page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX