draft-ietf-nfsv4-multi-domain-fs-reqs-02.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-03.txt 
NFSv4 Working Group W. Adamson NFSv4 Working Group W. Adamson
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: January 23, 2016 Cryptonector Expires: February 8, 2016 Cryptonector
July 22, 2015 August 7, 2015
Multiple NFSv4 Domain Namespace Deployment Guidelines Multiple NFSv4 Domain Namespace Deployment Guidelines
draft-ietf-nfsv4-multi-domain-fs-reqs-02 draft-ietf-nfsv4-multi-domain-fs-reqs-03
Abstract Abstract
This document describes administrative constraints to the deployment This document describes administrative constraints to the deployment
of the NFSv4 protocols required for the construction of an NFSv4 file of the NFSv4 protocols required for the construction of an NFSv4 file
system namespace supporting the use of multiple NFSv4 domains and system namespace supporting the use of multiple NFSv4 domains and
utilizing multi-domain capable file systems. Also described are utilizing multi-domain capable file systems. Also described are
administrative constraints to name resolution and security services administrative constraints to name resolution and security services
appropriate to such a system. Such a namespace is a suitable way to appropriate to such a system. Such a namespace is a suitable way to
enable a Federated File System supporting the use of multiple NFSv4 enable a Federated File System supporting the use of multiple NFSv4
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 23, 2016. This Internet-Draft will expire on February 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 4 3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 5
4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5
4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6
4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6
4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7
5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8
5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 9 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 8
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9 5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9
5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10
6. Resolving Multi-domain Authorization Information . . . . . . 10 6. Resolving Multi-domain Authorization Information . . . . . . 10
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 11 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
An NFSv4 domain is defined as a set of users, groups and computers An NFSv4 domain is defined as a set of users, groups and computers
running NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661] running NFSv4 protocols (NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
(hereafter referred to as NFSv4) protocols identified by an NFSv4 NFSv4.2 [I-D.NFSv4.2] as of this writing) identified by an NFSv4
domain name. domain name.
The Federated File System (FedFS) [RFC5716] describes the The Federated File System (FedFS) [RFC5716] describes the
requirements and administrative tools to construct a uniform NFSv4 requirements and administrative tools to construct a uniform NFSv4
file server based namespace that is capable of spanning a whole file server based namespace that is capable of spanning a whole
enterprise and that is easy to manage. enterprise and that is easy to manage.
The FedFS is the standardized method of constructing and The FedFS is the standardized method of constructing and
administrating an enterprise wide NFSv4 filesystem, and so is administrating an enterprise wide NFSv4 filesystem, and so is
referenced in this document. The issues with multiple NFSv4 domain referenced in this document. The issues with multiple NFSv4 domain
skipping to change at page 3, line 38 skipping to change at page 3, line 38
domains. domains.
2. Terminology 2. Terminology
Name Service: provides the mapping between {NFSv4 domain, group or Name Service: provides the mapping between {NFSv4 domain, group or
user name} and {NFSv4 domain, local ID}, as well as the mapping user name} and {NFSv4 domain, local ID}, as well as the mapping
between {security principal} and {NFSv4 domain, local ID} via between {security principal} and {NFSv4 domain, local ID} via
lookups. Can be applied to local or remote domains. Often lookups. Can be applied to local or remote domains. Often
provided by a Directory Service such as LDAP. provided by a Directory Service such as LDAP.
Name Service Switch (nsswitch): a facility in provides a variety
of sources for common configuration databases and name resolution
mechanisms.
Domain: This term is used in multiple contexts where it has Domain: This term is used in multiple contexts where it has
different meanings. Here we provide specific definitions used in different meanings. Here we provide specific definitions used in
this document. this document.
DNS domain: a set of computers, services, or any internet DNS domain: a set of computers, services, or any internet
resource identified by an DNS domain name [RFC1034]. resource identified by an DNS domain name [RFC1034].
Security realm or domain: a set of configured security Security realm or domain: a set of configured security
providers, users, groups, security roles, and security policies providers, users, groups, security roles, and security policies
running a single security protocol and administered by a single running a single security protocol and administered by a single
skipping to change at page 6, line 10 skipping to change at page 6, line 17
server's use of name service mappings (Section 3) and security server's use of name service mappings (Section 3) and security
services deployment to demonstrate the need for some multiple NFSv4 services deployment to demonstrate the need for some multiple NFSv4
domain constraints to the NFSv4 protocol, name service configuration, domain constraints to the NFSv4 protocol, name service configuration,
and security service choices. and security service choices.
Because all on-disk identities participating in a stand-alone NFSv4 Because all on-disk identities participating in a stand-alone NFSv4
domain belong to the same NFSv4 domain, stand-alone NFSv4 domain domain belong to the same NFSv4 domain, stand-alone NFSv4 domain
deployments have no requirement for exporting multi-domain capable deployments have no requirement for exporting multi-domain capable
file systems. file systems.
These examples are for a NFSv4 server exporting a 32bit UID/GID based These examples are for a NFSv4 server exporting a POSIX UID/GID based
file system, a typical deployment. These examples are listed in the file system, a typical deployment. These examples are listed in the
order of increasing NFSv4 administrative complexity. order of increasing NFSv4 administrative complexity.
4.1. AUTH_SYS with Stringified UID/GID 4.1. AUTH_SYS with Stringified UID/GID
This example is the closest NFSv4 gets to being run as NFSv3. This example is the closest NFSv4 gets to being run as NFSv3.
File access: The AUTH_SYS RPC credential provides a UID as the File access: The AUTH_SYS RPC credential provides a UID as the
authentication identity, and a list of GIDs as authorization context authentication identity, and a list of GIDs as authorization context
information. File access decisions require no name service information. File access decisions require no name service
skipping to change at page 7, line 7 skipping to change at page 7, line 10
Often, the NFSv4 server will use the nsswitch interface for these Often, the NFSv4 server will use the nsswitch interface for these
mappings. A typical use of the nsswitch name service interface uses mappings. A typical use of the nsswitch name service interface uses
no domain component, just the uid attribute [RFC2307] (or login name) no domain component, just the uid attribute [RFC2307] (or login name)
as the name component. This is no issue in a stand-alone NFSv4 as the name component. This is no issue in a stand-alone NFSv4
domain deployment as the NFSv4 domain is known to the NFSv4 server domain deployment as the NFSv4 domain is known to the NFSv4 server
and can combined with the login name to form the name@domain syntax and can combined with the login name to form the name@domain syntax
after the return of the name service call. after the return of the name service call.
4.3. RPCSEC_GSS with name@domain 4.3. RPCSEC_GSS with name@domain
RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely
authenticate users to servers. The most common mechanism is Kerberos
[RFC4121].
This final example adds the complexity of RPCSEC_GSS with the This final example adds the complexity of RPCSEC_GSS with the
Kerberos 5 GSS security mechanism. Kerberos 5 GSS security mechanism.
File Access: The RPCSEC_GSS Kerberos credential provides a File Access: The forms of GSS principal names are mechanism-specific.
principal@REALM name as the authentication identity, and (as of this For Kerberos these are of the form principal@REALM. Sometimes
writing) no authorization context information. File access decisions authorization context information is delivered with authentication,
therefore require a wire-to-disk mapping of the principal@REALM to a but this cannot be counted on. Authorization context information
UID, and an auth-to-authz mapping to obtain the list of GIDs as the delivered with authentication has timely update considerations (i.e.,
authorization context. generally it's not possible to get a timely update). File access
decisions therefore require a wire-to-disk mapping of the GSS
principal to a UID, and an auth-to-authz mapping to obtain the list
of GIDs as the authorization context.
Deployments can use the nsswitch name service interface for the Implementations must never blindly drop a Kerberos REALM name from a
principal@REALM to UID mapping by stripping off the REALM portion. Kerberos principal name to obtain a POSIX username, but they may be
This requires that the principal portion of the principal@REALM configured to do so for specific REALMs.
matches the uid attribute [RFC2307] (or login name) of the user.
Meta-data setting and listing: This is the same as in Section 4.2. Meta-data setting and listing: This is the same as in Section 4.2.
5. Multi-domain Constraints to the NFSv4 Protocol 5. Multi-domain Constraints to the NFSv4 Protocol
Joining NFSv4 domains under a single file namespace imposes slightly Joining NFSv4 domains under a single file namespace imposes slightly
on the NFSv4 administration freedom. Here we describe the required on the NFSv4 administration freedom. Here we describe the required
constraints. constraints.
5.1. Name@domain Constraints 5.1. Name@domain Constraints
skipping to change at page 7, line 43 skipping to change at page 8, line 4
representation of the "who" field of an NFSv4 access control entry representation of the "who" field of an NFSv4 access control entry
(ACE) for users and groups. This design provides a level of (ACE) for users and groups. This design provides a level of
indirection that allows NFSv4 clients and servers with different indirection that allows NFSv4 clients and servers with different
internal representations of authorization identity to interoperate internal representations of authorization identity to interoperate
even when referring to authorization identities from different NFSv4 even when referring to authorization identities from different NFSv4
domains. domains.
Multiple NFSv4 domain capable sites need to meet the following Multiple NFSv4 domain capable sites need to meet the following
requirements in order to ensure that NFSv4 clients and servers can requirements in order to ensure that NFSv4 clients and servers can
map between name@domain and internal representations reliably. While map between name@domain and internal representations reliably. While
some of these constraints are basic assumptions in NFSv4.0 some of these constraints are basic assumptions in NFSv4.0 [RFC7530]
[I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661], they need to be and NFSv4.1 [RFC5661], they need to be clearly stated for the
clearly stated for the multiple NFSv4 domain case. multiple NFSv4 domain case.
o The NFSv4 domain portion of name@domain MUST be unique within the o The NFSv4 domain portion of name@domain MUST be unique within the
multiple NFSv4 domain namespace. See [RFC5661] section 5.9 multiple NFSv4 domain namespace. See [RFC5661] section 5.9
"Interpreting owner and owner_group" for a discussion on NFSv4 "Interpreting owner and owner_group" for a discussion on NFSv4
domain configuration. domain configuration.
o The name portion of name@domain MUST be unique within the o The name portion of name@domain MUST be unique within the
specified NFSv4 domain. specified NFSv4 domain.
o Every local representation of a user and of a group MUST have a
canonical name@domain, and it must be possible to return the
canonical name@domain for any identity stored on disk, at least
when required infrastructure servers (such as name services) are
online.
Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used
in a multiple NFSv4 domain file system. in a multiple NFSv4 domain file system. This means that multi-
domain-capable servers MUST reject requests that use stringified UID/
Note that for stand-alone NFSv4 domains it does not matter if the GIDs.
choice of the NFSv4 domain name is replicated by another stand-alone
NFSv4 domain deployment. Indeed, if a stringified UID/GID scheme is
used, or just UNIX mode bits are used (NFSv4 ACLs are not set or
listed) and the simple nsswitch interface that strips the @domain and
the @REALM is used, then the domain portion of name@domain can be
ignored, and even be different for each client and server in the
domain.
5.1.1. NFSv4 Domain and DNS Services 5.1.1. NFSv4 Domain and DNS Services
Here we address the relationship between NFSv4 domain name and DNS Here we address the relationship between NFSv4 domain name and DNS
domain name in a multiple NFSv4 domain deployment. domain name in a multiple NFSv4 domain deployment.
The definition of an NFSv4 domain name needs clarification to work in The definition of an NFSv4 domain name needs clarification to work in
a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661] a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661]
loosely defines the NFSv4 domain name as a DNS domain name. This loosely defines the NFSv4 domain name as a DNS domain name. This
loose definition for the NFSv4 domain is a good one, as DNS domain loose definition for the NFSv4 domain is a good one, as DNS domain
skipping to change at page 9, line 21 skipping to change at page 9, line 15
namespace. namespace.
An NFSv4 domain administrator that wants to give NFSv4 local file An NFSv4 domain administrator that wants to give NFSv4 local file
access to a remote user from a remote NFSv4 domain needs to create a access to a remote user from a remote NFSv4 domain needs to create a
local ID for the remote user which can then be assigned on-disk and local ID for the remote user which can then be assigned on-disk and
used for local access decisions. Since the local ID for the remote used for local access decisions. Since the local ID for the remote
user must be able to be mapped to a name@remote-domain, only multi- user must be able to be mapped to a name@remote-domain, only multi-
domain capable file systems can be exported in a multiple NFSv4 domain capable file systems can be exported in a multiple NFSv4
domain namespace. domain namespace.
We note that many file systems exported by NFSv4 use 32 bit POSIX UID We note that many file systems exported by NFSv4 use POSIX UID and
and GIDs as a local ID form and as this local ID form has no domain GIDs as a local ID form and as this local ID form has no domain
component, these file systems are not domain aware and can not component, these file systems are not domain aware and can not easily
participate in a multiple NFSv4 domain namespace. There are ways to participate in a multiple NFSv4 domain namespace. There are ways to
overcome this deficiency, but these practices are beyond the scope of overcome this deficiency, but these practices are beyond the scope of
this document. this document.
5.2. RPC Security Constraints 5.2. RPC Security Constraints
As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors":
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. NFSv4.1 clients and servers MUST implement RPCSEC_GSS.
(This requirement to implement is not a requirement (This requirement to implement is not a requirement
skipping to change at page 10, line 8 skipping to change at page 10, line 4
The AUTH_SYS security flavor uses a host-based authentication model The AUTH_SYS security flavor uses a host-based authentication model
where the weakly authenticated host (the NFSv4 client) asserts the where the weakly authenticated host (the NFSv4 client) asserts the
user's authorization identities using small integers, uidNumber, and user's authorization identities using small integers, uidNumber, and
gidNumber [RFC2307], as user and group identity representations. gidNumber [RFC2307], as user and group identity representations.
Because this authorization ID representation has no domain component, Because this authorization ID representation has no domain component,
AUTH_SYS can only be used in a namespace where all NFSv4 clients and AUTH_SYS can only be used in a namespace where all NFSv4 clients and
servers share an [RFC2307] name service. A shared name service is servers share an [RFC2307] name service. A shared name service is
required because uidNumbers and gidNumbers are passed in the RPC required because uidNumbers and gidNumbers are passed in the RPC
credential; there is no negotiation of namespace in AUTH_SYS. credential; there is no negotiation of namespace in AUTH_SYS.
Collisions can occur if multiple name services are used, so AUTH_SYS Collisions can occur if multiple name services are used, so AUTH_SYS
MUST NOT be used in a multiple NFSv4 domain file system. MUST NOT be used in a multiple NFSv4 domain file system.
While the AUTH_SYS security mechanism can not be used (indeed,
AUTH_SYS is obsolete and of limited use for all of NFS), RPCSEC_GSSv3
can completely replace all uses of AUTH_SYS in a multiple NFSv4
domain file system. Like AUTH_SYS, and unlike RPCSEC_GSSv1/2,
RPCSEC_GSSv3 allows the client to assert and contribute knowledge of
the user process' authorization context.
5.2.1. NFSv4 Domain and Security Services 5.2.1. NFSv4 Domain and Security Services
As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4
domain security services are RPCSEC_GSS based with the Kerberos 5 domain security services are RPCSEC_GSS based with the Kerberos 5
security mechanism being the most commonly (and as of this writing, security mechanism being the most commonly (and as of this writing,
the only) deployed service. the only) deployed service.
A single Kerberos 5 security service per NFSv4 domain with the upper A single Kerberos 5 security service per NFSv4 domain with the upper
case NFSv4 domain name as the Kerberos 5 REALM name is a common case NFSv4 domain name as the Kerberos 5 REALM name is a common
deployment. deployment.
skipping to change at page 10, line 45 skipping to change at page 10, line 49
In the stand-alone NFSv4 domain case where the principal is seeking In the stand-alone NFSv4 domain case where the principal is seeking
access to files on an NFSv4 server in the principal's home NFSv4 access to files on an NFSv4 server in the principal's home NFSv4
domain, the server administrator has knowledge of the local policies domain, the server administrator has knowledge of the local policies
and methods for obtaining the principal's authorization information and methods for obtaining the principal's authorization information
and the mappings to local representation of identity from an and the mappings to local representation of identity from an
authoritative source. E.g., the administrator can configure secure authoritative source. E.g., the administrator can configure secure
access to the local NFSv4 domain name service. access to the local NFSv4 domain name service.
In the multiple NFSv4 domain case where a principal is seeking access In the multiple NFSv4 domain case where a principal is seeking access
to files on an NFSv4 server not in the principal's home NFSv4 domain, to files on an NFSv4 server not in the principal's home NFSv4 domain,
the server is REQUIRED to obtain in a secure manner the principal's the NFSv4 server may be required to contact the remote name service
authorization context information from an authoritative source. In in the principals NFSv4 domain. In this case there is no assumption
this case there is no assumption of: of:
o Remote name service configuration knowledge o Remote name service configuration knowledge
o The syntax of the remote authorization context information o The syntax of the remote authorization context information
presented to the NFSv4 server by the remote name service for presented to the NFSv4 server by the remote name service for
mapping to a local representation. mapping to a local representation.
There are several methods the NFSv4 server can use to obtain the There are several methods the NFSv4 server can use to obtain the
NFSv4 domain authoritative authorization information for a remote NFSv4 domain authoritative authorization information for a remote
principal from an authoritative source. While any detail is beyond principal from an authoritative source. While any detail is beyond
the scope of this document, some general methods are listed here. the scope of this document, some general methods are listed here.
1. A mechanism specific GSS-API authorization payload containing 1. A mechanism specific GSS-API authorization payload containing
skipping to change at page 12, line 10 skipping to change at page 12, line 12
o The NFSv4 domain name is unique across the namespace. o The NFSv4 domain name is unique across the namespace.
o All exported file systems are multi-domain capable. o All exported file systems are multi-domain capable.
o A secure method is used to resolve remote NFSv4 domain principals o A secure method is used to resolve remote NFSv4 domain principals
authorization information from an authoritative source. authorization information from an authoritative source.
8. Security Considerations 8. Security Considerations
There are no security considerations introduced by this document This RFC discusses security throughout. All the security
beyond those described in NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and considerations of the relevant protocols, such as NFSv4.0 [RFC7530],
NFSv4.1 [RFC5661]. NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP
[RFC4511], and others, apply.
Authentication and authorization across administrative domains
presents security considerations, most of which are treated
elsewhere, but we repeat some of them here:
o latency in propagation of revocation of authentication credentials
o latency in propagation of revocation of authorizations
o latency in propagation of granting of authorizations
o complications in establishing a foreign domain's users' complete
authorization context: only parts may be available to servers
o privacy considerations in a federated environment
Most of these are security considerations of the mechanisms used to
authenticate users to servers and servers to users, and of the
mechanisms used to evaluate a user's authorization context. We don't
treat them fully here, but implementors should study the protocols in
question to get a more complete set of security considerations.
Note that clients/users may also need to evaluate a server's
authorization context when using labeled security (e.g., is the
server authorized to handle content at a given security level, for
the given compartments). Even when not using labeled security, since
there could be many realms (credential issuer) for a given server,
it's important to verify that the server a client is talking to has a
credential for the name the client has for the server, and that that
credential's issuer (i.e., its realm) is allowed to issue it.
Usually the service principle realm authorization function is
implemented by the security mechanism, but the implementor should
check this.
Implementors may be tempted to assume that realm (or "issuer") and
NFSv4 domain are roughly the same thing, but they are not.
Configuration and/or lookup protocols (such as LDAP) and associated
schemas are generally required in order to evaluate a user
principal's authorization context. In the simplest scheme a server
has access to a database mapping all known principal names to
usernames whose authorization context can be evaluated using
operating system interfaces that deal in usernames rather than
principal names.
9. Normative References 9. Normative References
[CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common
Internet File System (CIFS) Protocol", January 2013. Internet File System (CIFS) Protocol", January 2013.
[I-D.ietf-nfsv4-rfc3530bis] [I-D.NFSv4.2]
Haynes, T. and D. Noveck, "Network File System (NFS) Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-25 (Work nfsv4-minorversion2-36 (Work In Progress), April 2015.
In Progress), February 2013.
[I-D.rpcsec-gssv3]
Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-12
(Work In Progress), July 2015.
[I-D.sorce-krbwg-general-pac] [I-D.sorce-krbwg-general-pac]
Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for
Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In
Progress awaiting merge with other document ), June 2011. Progress awaiting merge with other document ), June 2011.
[I-D.zhu-pku2u] [I-D.zhu-pku2u]
Zhu, L., Altman, J., and N. Williams, "Public Key Zhu, L., Altman, J., and N. Williams, "Public Key
Cryptography Based User-to-User Authentication - (PKU2U)", Cryptography Based User-to-User Authentication - (PKU2U)",
draft-zhu-pku2u-09 (Work In Progress), November 2008. draft-zhu-pku2u-09 (Work In Progress), November 2008.
skipping to change at page 12, line 44 skipping to change at page 13, line 45
[PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data
in Kerberos Tickets for Access Control to Resources", in Kerberos Tickets for Access Control to Resources",
October 2002. October 2002.
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987. RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2203] Eisler, M. and J. Linn, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network [RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998. Information Service", RFC 2307, March 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, July
2005.
[RFC4511] Sermersheim, Ed., J., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716, Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010. January 2010.
[RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS)
version 4 Protocol", RFC 7530, March 2015.
Appendix A. Acknowledgments Appendix A. Acknowledgments
Andy Adamson would like to thank NetApp, Inc. for its funding of his Andy Adamson would like to thank NetApp, Inc. for its funding of his
time on this project. time on this project.
We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and
David Noveck for their review. David Noveck for their review.
Authors' Addresses Authors' Addresses
 End of changes. 25 change blocks. 
54 lines changed or deleted 125 lines changed or added

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