NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Andy Adamson , Nicolás Williams | ||
| Last updated | 2013-04-17 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02
NFSv4 Working Group W. Adamson
Internet-Draft NetApp
Intended status: Standards Track N. Williams
Expires: October 19, 2013 Cryptonector
April 17, 2013
NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-02
Abstract
This document describes constraints to the NFSv4.0 and NFSv4.1
protocols as well as the use of multi-domain capable file systems,
name resolution services, and security services required to fully
enable a multi-domain NFSv4 federated file system.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 19, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Adamson & Williams Expires October 19, 2013 [Page 1]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8
5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8
5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . . 8
6. NFSv4 Multi-domain File Access . . . . . . . . . . . . . . . 10
6.1. Resolving Multi-domain Authorization Information . . . . . . 10
6.2. GSS-API Authorization Payload . . . . . . . . . . . . . . . 11
7. Setting and Retrieving NFSv4 Multi-domain ACLs . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Adamson & Williams Expires October 19, 2013 [Page 2]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Adamson & Williams Expires October 19, 2013 [Page 3]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
2. Introduction
The NFSv4.0 [RFC3530] and NFSv4.1 [RFC5661] (hereafter referred to as
NFSv4) protocols enable the construction of a distributed file system
which can join NFSv4 servers from multiple NFSv4 domains, each
potentially using separate name resolution services and separate
security services, into a common multi-domain name space.
The Federated File System (FedFS) [RFC5716] describes the
requirements and administrative tools to construct a uniform file
server based namespace that is capable of spanning a whole enterprise
and that is easy to manage.
An NFSv4 multi-domain capable filesystem uses local ID forms that can
represent identities from both local and remote NFSv4 domains. An
NFSv4 multi-domain FedFS joins multiple NFSv4 domains each consisting
of NFSv4 servers that export multi-domain capable filesystems, and
that employ potentially separate name resolution services and
separate security services into a uniform NFSv4 server-based name
space capable of spanning multiple enterprises.
This document describes constraints to the NFSv4.0 and NFSv4.1
protocols as well as the use of multi-domain capable file systems,
name resolution services, and security services required to fully
enable an NFSv4 multi-domain federated file system.
Adamson & Williams Expires October 19, 2013 [Page 4]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
3. Terminology
Domain: This term is used in multiple contexts where it has
different meanings. Here we provide specific definitions.
DNS domain: a set of computers, services, or any internet
resource identified by an DNS domain name [RFC1034].
Security realm or domain: a set of configured security
providers, users, groups, security roles, and security policies
running a single security protocol and administered by a single
entity. E.g. a Kerberos Realm. While a typical configuration
is to use the uppercase DNS domain name as the Kerberos realm
name they are independent.
NFSv4 domain: a set of users, groups and computers running
NFSv4 protocols administered by a single entity, and identified
by a unique NFSv4 domain name. See [RFC5661] Section 5.9
"Interpreting owner and owner_group". An NFSv4 domain can
include multiple DNS domains and multiple security realms.
Multi-domain: In this document this always refers to multiple
NFSv4 domains.
FedFS domain: A file name space that can cross multiple shares
on multiple file servers using file-access protocols such as
NFSv4 or CIFS [CIFS]. A FedFS domain is typically a single
administrative entity, and has a name that is similar to a DNS
domain name. Also known as a Federation.
Administrative domain: a set of users, groups, computers and
services administered by a single entity. Can include multiple
DNS domains, NFSv4 domains, security domains, and FedFS
domains.
Local representation of identity: an object such as a uidNumber
(UID) or gidNumber (GID) [RFC2307], or a Windows Security
Identifier (SID), or other such representation of a user or a
group of users on-disk in a file system.
Global ID: A representation of identity that is globally unique.
Examples include the name@domain or ID@domain NFSv4 syntax, and
the Windows Security Identifier (SID).
Name Service: provides the mapping between {NFSv4 domain, name}
and {NFSv4 domain, ID} via lookups. Can be applied to local or
remote domains. Often provided by a Directory Service such as
LDAP.
Adamson & Williams Expires October 19, 2013 [Page 5]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
ID mapping: Is a mapping between {remote NFSv4 domain, remote
NFSv4 domain ID} and {local representation of identity}.
Principal: an RPCSEC_GSS authentication identity. Usually, but
not always, a user; rarely, if ever, a group; sometimes a host.
Authorization Context: A collection of information about a
principal such as username, userID, group membership, etcetera
used in authorization decisions.
Adamson & Williams Expires October 19, 2013 [Page 6]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
4. Background
NFSv4 deals with two kinds of identities: authentication identities
(referred to here as "principals") and authorization identities
("users" and "groups" of users). NFSv4 supports multiple
authentication methods, each authenticating an "initiator principal"
(typically representing a user) to an "acceptor principal" (always
corresponding to the NFSv4 server). NFSv4 does not prescribe how to
represent authorization identities on file systems. All file access
decisions constitute "authorization" and are made by NFSv4 servers
using authorization context information and file metadata related to
authorization, such as a file's access control list (ACL).
NFSv4 servers therefore must perform two kinds of mappings:
1. A mapping between the authentication identity and the
authorization context information.
2. A mapping between the on-the-wire authorization identity
representation and the on-disk authorization identity
representation.
Many aspects of these mappings are entirely implementation specific,
but some require multi-domain capable name resolution and security
services. In order to interoperate in a multi-domain NFSv4 FedFS
file system, NFSv4 servers must use such services in compatible ways.
Adamson & Williams Expires October 19, 2013 [Page 7]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
5. Multi-domain Constraints to the NFSv4 Protocol
5.1. Name@domain Constraints
NFSv4 uses a syntax of the form "name@domain" as the on wire
representation of the "who" field of an NFSv4 access control entry
(ACE) for users and groups. This design provides a level of
indirection that allows NFSv4 clients and servers with different
internal representations of authorization identity to interoperate
even when referring to authorization identities from different NFSv4
domains.
NFSv4 multi-domain capable sites need to meet the following
requirements in order to ensure that NFSv4 clients and servers can
map between name@domain and internal representations reliably:
o The NFSv4 domain portion of name@domain MUST be unique within the
FedFS NFSv4 multi-domain namespace. See [RFC3530] section 5.9
"Interpreting owner and owner_group" for a discussion on NFSv4
domain configuration.
o The name portion of name@domain MUST be unique within the
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.
5.2. RPC Security Constraints
As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors":
NFSv4.1 clients and servers MUST implement RPCSEC_GSS.
(This requirement to implement is not a requirement
to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS,
MAY be implemented as well.
The underlying RPCSEC_GSS security mechanism used in a multi-domain
NFSv4 FedFS is REQUIRED to employ a method of cross NFSv4 domain
trust so that a principal from a security service in one NFSv4 domain
can be authenticated in another NFSv4 domain that uses a security
service with the same security mechanism. Kerberos, and PKU2U
[I-D.zhu-pku2u] are examples of such security services.
The AUTH_NONE security flavor can be useful in a multi-domain NFSv4
FedFS to grant universal access to public data without any
Adamson & Williams Expires October 19, 2013 [Page 8]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
credentials.
The AUTH_SYS security flavor uses a host-based authentication model
where the weakly authenticated host (the NFSv4 client) asserts the
user's authorization identities using small integers, uidNumber and
gidNumber [RFC2307], as user and group identity representations.
Because this authorization ID representation has no DNS domain
component, AUTH_SYS can only be used in a name space where all NFSv4
clients and servers share an [RFC2307] name service. A shared name
service is required because uidNumbers and gidNumbers are passed in
the RPC credential; there is no negotiation of namespace in AUTH_SYS.
Collisions can occur if multiple name services are used. AUTH_SYS
can not be used in an NFSv4 multi-domain federated file system.
A new version of RPCSEC_GSS [I-D.williams-rpcsecgssv3] includes a
modernized replacement for AUTH_SYS which addresses this issue.
Adamson & Williams Expires October 19, 2013 [Page 9]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
6. NFSv4 Multi-domain File Access
In the mult-domain case where a principal is seeking access to files
on a NFSv4 server in a different NFSv4 domain, the NFSv4 server must
[ANDROS: MUST?] obtain, in a secure manner, the principal's
authorization information from an authoritative source: e.g. a name
service in the principal's NFSv4 domain. The NFSv4 server then needs
to map the remote principal and the authorization information such as
the principal's primary group and group membership list into a local
representation of ID suitable for use in file system ACLs. This is
the first mapping described in Section 4 "Background".
In the local NFSv4 domain case where the principal is seeking access
to files on an NFSv4 server in the local NFSv4 domain, the server has
knowledge of the local policies and methods for obtaining the
principal's authorization information and the mapping to local
representation of identity. In the multi-domain case there can be no
assumption of such knowledge.
6.1. Resolving Multi-domain Authorization Information
There are several methods the remote NFSv4 domain authoritative
authorization information for a principal can be obtained:
1. A mechanism specific GSS-API authorization payload containing
credential authorization data. This is the preferred method as
it avoids requiring any knowledge of a remote NFSv4 domain name
service.
2. An authenticated NFSv4 server local NFSv4 domain name query when
there is a security agreement between the two multi-domain name
services plus regular update data feeds so that the NFSv4 server
local NFSv4 domain name service is authoritative for the
principal's remote NFSv4 domain. This requires the local NFSv4
domain to have detailed knowledge of the remote NFSv4 domain's
name authoritative name service.
3. An authenticated direct query from the NFSv4 server to the
principal's NFSv4 domain authoritative name service. This
requires the NFSv4 server to have detailed knowledge of the
remote NFSv4 domain's authoritative name service. [ANDROS:
Define a protocol for this?]
The authorization data information should be obtained via the GSS-API
name attribute interface [RFC6680] either via a single attribute for
the credential authorization data or via discrete GSS-API name
attributes corresponding to the authorization data elements.
Adamson & Williams Expires October 19, 2013 [Page 10]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
Note that the retrieval of attribute values used by the GSS-API name
attribute interface implementation could utilize any of the above
mentioned methods of obtaining the authorization information which
demonstrates the usefulness of the API.
6.2. GSS-API Authorization Payload
To avoid requiring detailed knowledge of remote NFSv4 domain name
services, authorization context information SHOULD be obtained from
the credentials authenticating a principal; the GSS-API represents
such information as attributes of the initiator principal name.
For example:
o Kerberos 5 [RFC4120] has a method for conveying "authorization
data", both client-asserted as well as KDC-authenticated
authorization data. Some KDC implementation, notably Windows
KDCs, use this feature to convey a "privilege attribute
certificate" [PAC] listing the principal's user and group global
IDs as "security identifiers" (SIDs).
o Some KDCs (will) issue Kerberos Tickets with the General PAD
[I-D.sorce-krbwg-general-pac] (PAD) as Kerberos authorization data
listing user and group names along with their uidNumber and
gidNumber [RFC2307], the name of the DNS domain [ANDROS: review
General PAD RFC to ensure this can be the NFSv4 domain] along with
a unique DNS domain identifier and other information. The General
PAD authorization data MUST be authenticated in the sense that its
contents must come from an authenticated, trusted source, such as
a name server or the issuer of the principal's credential.
o PKIX [RFC5280] certificates allow for extensions that could be
used similarly.
The authorization context information in a GSS-API authorization
payload can be considered a single, authenticated, discrete GSS-API
name attribute, in which case the NFSv4 server must parse it into its
individual elements and ID-Map or use name services to map the
information to local ID representations. [ANDROS: clarify - is it
one name attribute or not. If not, how can you tell?]
Adamson & Williams Expires October 19, 2013 [Page 11]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
7. Setting and Retrieving NFSv4 Multi-domain ACLs
When servicing a set acl request, the NFSv4 server must be able to
map the name@domain in the ACE who field to a local representation of
ID. When servicing a get acl request, the NFSv4 server must be able
to map the local representation of ID in the file system ACL to the
name@domain form. This mapping between name@domain and local
representation of ID must [ANDROS: MUST?] be done against an
authoritative source. This is the second mapping described in
Section 4 "Background".
The local name-service is authoritative for these mappings for remote
users and groups when one of the first two methods in (Section 6.1)
is used to keep the local name-service updated with remote
information.
Adamson & Williams Expires October 19, 2013 [Page 12]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
8. Security Considerations
Some considerations to come
Adamson & Williams Expires October 19, 2013 [Page 13]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "Network File System
(NFS) version 4 Protocol", RFC 3530, April 2003.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol",
RFC 5661, January 2010.
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
Naik, "Requirements for Federated File Systems", RFC 5716,
January 2010.
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "Generic Security Service Application
Programming Interface (GSS-API) Naming Extensions",
RFC 6680, August 2012.
[I-D.zhu-pku2u]
Zhu, L., Altman, J., and N. Williams, "Public Key
Cryptography Based User-to-User Authentication - (PKU2U)",
draft-zhu-pku2u-09 (work in progress), November 2008.
[I-D.sorce-krbwg-general-pac]
Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for
Kerberos V5", draft-sorce-krbwg-general-pac-01 (work in
progress), December 2010.
[PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data
in Kerberos Tickets for Access Control to Resources",
October 2002.
Adamson & Williams Expires October 19, 2013 [Page 14]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
[CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common
Internet File System (CIFS) Protocol", January 2013.
9.2. Informative References
[I-D.williams-rpcsecgssv3]
Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-williams-rpcsecgssv3-02 (work
in progress), May 2011.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
Adamson & Williams Expires October 19, 2013 [Page 15]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements April 2013
Authors' Addresses
William A. (Andy) Adamson
NetApp
Email: andros@netapp.com
Nicolas Williams
Cryptonector
Email: nico@cryptonector.com
Adamson & Williams Expires October 19, 2013 [Page 16]