draft-ietf-nfsv4-multi-domain-fs-reqs-07.txt   draft-ietf-nfsv4-multi-domain-fs-reqs-08.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: November 7, 2016 Cryptonector Expires: December 24, 2016 Cryptonector
May 6, 2016 June 22, 2016
Multiple NFSv4 Domain Namespace Deployment Guidelines Multiple NFSv4 Domain Namespace Deployment Guidelines
draft-ietf-nfsv4-multi-domain-fs-reqs-07 draft-ietf-nfsv4-multi-domain-fs-reqs-08
Abstract Abstract
This document discusses issues relevant to the deployment of the This document discusses issues relevant to the deployment of the
NFSv4 protocols in situations allowing for the construction of an NFSv4 protocols in situations allowing for the construction of an
NFSv4 file namespace supporting the use of multiple NFSv4 domains and NFSv4 file 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
constraints on name resolution and security services appropriate to constraints on name resolution and security services appropriate to
the administration of such a system. Such a namespace is a suitable the administration of such a system. Such a namespace is a suitable
way to enable a Federated File System supporting the use of multiple way to enable a Federated File System supporting the use of multiple
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 November 7, 2016. This Internet-Draft will expire on December 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6
4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7
4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7
4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8
5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9
5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9 5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9
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 . . . . . . 11
7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
An NFSv4 domain is defined as a set of users and groups named by a An NFSv4 domain is defined as a set of users and groups named by a
particular domain using the NFSv4 name@domain syntax. This includes particular domain using the NFSv4 name@domain syntax. This includes
NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be
published. Often, a computer which acts as an NFSv4 client and published. Often, a computer which acts as an NFSv4 client and
always acts on behalf of users belonging to a particular NFSv4 domain always acts on behalf of users belonging to a particular NFSv4 domain
is thought of a part of that NFSv4 domain. Similarly, a computer is thought of a part of that NFSv4 domain. Similarly, a computer
skipping to change at page 5, line 33 skipping to change at page 5, line 33
identities (referred to here as "principals") and authorization identities (referred to here as "principals") and authorization
identities ("users" and "groups" of users). NFSv4 supports multiple identities ("users" and "groups" of users). NFSv4 supports multiple
authentication methods, each authenticating an "initiator principal" authentication methods, each authenticating an "initiator principal"
(typically representing a user) to an "acceptor principal" (always (typically representing a user) to an "acceptor principal" (always
corresponding to the NFSv4 server). NFSv4 does not prescribe how to corresponding to the NFSv4 server). NFSv4 does not prescribe how to
represent authorization identities on file systems. All file access represent authorization identities on file systems. All file access
decisions constitute "authorization" and are made by NFSv4 servers decisions constitute "authorization" and are made by NFSv4 servers
using authorization context information and file metadata related to using authorization context information and file metadata related to
authorization, such as a file's access control list (ACL). authorization, such as a file's access control list (ACL).
NFSv4 servers therefore must perform two kinds of mappings: NFSv4 servers may be required to perform two kinds of mappings
depending upon what authentication and authorization information is
sent on the wire, and what is stored in the exported file system.
For example, if an authentication identity such as a Kerberos
principal is sent with authorization information such a "privilege
attribute certificate" (PAC) [PAC] then mapping is not required. See
Section 6.
1. Auth-to-authz: A mapping between the authentication identity and 1. Auth-to-authz: A mapping between the authentication identity and
the authorization context information. the authorization context information.
2. Wire-to-disk: A mapping between the on-the-wire authorization 2. Wire-to-disk: A mapping between the on-the-wire authorization
identity representation and the on-disk authorization identity identity representation and the on-disk authorization identity
representation. representation.
A Name Service such as LDAP often provides these mappings. A Name Service such as LDAP often provides these mappings.
skipping to change at page 7, line 7 skipping to change at page 7, line 11
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 POSIX 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 as there
is no need for a name service for file metadata listing.
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
interaction as the on-the-wire and on-disk representation are the interaction as the on-the-wire and on-disk representation are the
same and the auth-to-authz UID and GID authorization context same and the auth-to-authz UID and GID authorization context
information is provided in the RPC credential. information is provided in the RPC credential.
Meta-data setting and listing: When the NFSv4 clients and servers Meta-data setting and listing: When the NFSv4 clients and servers
implement a stringified UID/GID scheme, where a stringified UID or implement a stringified UID/GID scheme, where a stringified UID or
skipping to change at page 11, line 33 skipping to change at page 11, line 44
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
credential authorization data such as a "privilege attribute credential authorization data such as a "privilege attribute
certificate" (PAC) [PAC] or a "general PAD" (PAD) certificate" (PAC) [PAC] or a "principal authentication data"
[I-D.sorce-krbwg-general-pac]. This is the preferred method as (PAD) [I-D.sorce-krbwg-general-pac]. This is the preferred
the payload is delivered as part of GSS-API authentication, method as the payload is delivered as part of GSS-API
avoids requiring any knowledge of the remote authoritative authentication, avoids requiring any knowledge of the remote
service configuration, and its syntax is well known. authoritative service configuration, and its syntax is well
known.
2. When there is a security agreement between the local and remote 2. When there is a security agreement between the local and remote
NFSv4 domain name services plus regular update data feeds, the NFSv4 domain name services plus regular update data feeds, the
NFSv4 server local NFSv4 domain name service can be authoritative NFSv4 server local NFSv4 domain name service can be authoritative
for principal's in the remote NFSv4 domain. In this case, the for principal's in the remote NFSv4 domain. In this case, the
NFSv4 server makes a query to it's local NFSv4 domain name NFSv4 server makes a query to it's local NFSv4 domain name
service just as it does when servicing a local domain principal. service just as it does when servicing a local domain principal.
While this requires detailed knowledge of the remote NFSv4 While this requires detailed knowledge of the remote NFSv4
domains name service for the update data feeds, the authorization domains name service for the update data feeds, the authorization
context information presented to the NFSv4 server is in the same context information presented to the NFSv4 server is in the same
skipping to change at page 12, line 31 skipping to change at page 12, line 42
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
This RFC discusses security throughout. All the security This RFC discusses security throughout. All the security
considerations of the relevant protocols, such as NFSv4.0 [RFC7530], considerations of the relevant protocols, such as NFSv4.0 [RFC7530],
NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP
[RFC4511], and others, apply. [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace
DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS
Security Addendum [I-D.lever-fedfs-security-addendum] apply.
Authentication and authorization across administrative domains Authentication and authorization across administrative domains
presents security considerations, most of which are treated presents security considerations, most of which are treated
elsewhere, but we repeat some of them here: elsewhere, but we repeat some of them here:
o latency in propagation of revocation of authentication credentials o latency in propagation of revocation of authentication credentials
o latency in propagation of revocation of authorizations o latency in propagation of revocation of authorizations
o latency in propagation of granting of authorizations o latency in propagation of granting of authorizations
o complications in establishing a foreign domain's users' complete o complications in establishing a foreign domain's users' complete
authorization context: only parts may be available to servers authorization context: only parts may be available to servers
o privacy considerations in a federated environment o privacy considerations in a federated environment
Most of these are security considerations of the mechanisms used to Most of these are security considerations of the mechanisms used to
skipping to change at page 13, line 46 skipping to change at page 14, line 10
[I-D.NFSv4.2] [I-D.NFSv4.2]
Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
nfsv4-minorversion2-36 (Work In Progress), April 2015. nfsv4-minorversion2-36 (Work In Progress), April 2015.
[I-D.rpcsec-gssv3] [I-D.rpcsec-gssv3]
Adamson, W. and N. Williams, "Remote Procedure Call (RPC) Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-12 Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-12
(Work In Progress), July 2015. (Work In Progress), July 2015.
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
RFC 1034, November 1987. STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[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", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2203] Eisler, M. and J. Linn, "RPCSEC_GSS Protocol [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997. Specification", RFC 2203, DOI 10.17487/RFC2203, September
1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, DOI 10.17487/
RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
Version 5 Generic Security Service Application Program Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2", RFC 4121, July Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI
2005. 10.17487/RFC4121, July 2005,
<http://www.rfc-editor.org/info/rfc4121>.
[RFC4511] Sermersheim, Ed., J., "Lightweight Directory Access [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006. Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/
RFC4511, June 2006,
<http://www.rfc-editor.org/info/rfc4511>.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed.,
System (NFS) Version 4 Minor Version 1 Protocol", RFC "Network File System (NFS) Version 4 Minor Version 1
5661, January 2010. Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010,
<http://www.rfc-editor.org/info/rfc5661>.
[RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System
version 4 Protocol", RFC 7530, March 2015. (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530,
March 2015, <http://www.rfc-editor.org/info/rfc7530>.
10.2. Informative References 10.2. Informative 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.lever-fedfs-security-addendum]
Lever, C., "Federated Filesystem Security Addendum",
draft-cel-nfsv4-federated-fs-security-addendum-05 (Active
Internet Draft), May 2016.
[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-01 (Work In Kerberos V5", draft-ietf-krb-wg-general-pac-01 (Work In
Progress awaiting merge with other document ), June 2011. Progress awaiting merge with other document ), June 2011.
[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.
[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, DOI 10.17487/RFC2307,
March 1998, <http://www.rfc-editor.org/info/rfc2307>.
[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. DOI 10.17487/RFC5716, January 2010,
<http://www.rfc-editor.org/info/rfc5716>.
[RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace
Database (NSDB) Protocol for Federated File Systems", RFC
7532, DOI 10.17487/RFC7532, March 2015,
<http://www.rfc-editor.org/info/rfc7532>.
[RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed.,
"Administration Protocol for Federated File Systems", RFC
7533, DOI 10.17487/RFC7533, March 2015,
<http://www.rfc-editor.org/info/rfc7533>.
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. 21 change blocks. 
32 lines changed or deleted 69 lines changed or added

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