NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-04
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 | 2014-07-07 | ||
| 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-04
NFSv4 Working Group W. Adamson
Internet-Draft NetApp
Intended status: Standards Track N. Williams
Expires: January 1, 2015 Cryptonector
June 30, 2014
NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-04
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.
Adamson & Williams Expires January 1, 2015 [Page 1]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
Requirements Language
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].
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 January 1, 2015.
Copyright Notice
Copyright (c) 2014 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 January 1, 2015 [Page 2]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 7
4. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8
4.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8
4.2. RPC Security Constraints . . . . . . . . . . . . . . . . . . 8
5. Resolving Multi-domain Authorization Information . . . . . . 10
5.1. GSS-API Authorization Payload . . . . . . . . . . . . . . . 11
6. Setting and Retrieving NFSv4 Multi-domain ACLs . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Adamson & Williams Expires January 1, 2015 [Page 3]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
1. Introduction
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.
The definition of an NFSv4 multi-domain federated file system
combines these concepts:
1. NFSv4 Domain, Pseudo file system and referrals: The NFSv4.0
[I-D.ietf-nfsv4-rfc3530bis] 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.
2. 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.
3. Multi-domain capable filesystem: A local filesystem that uses a
local ID form that can represent identities from both local and
remote domains. For example, an SSID based local ID form where
the SSID contains both a domain and a user or group component.
We note that many file systems exported by NFSv4 use 32 bit POSIX
UID and GIDs as a local ID form and are therefore not domain
aware and not able to participate in an NFSv4 multi-domain
federated file system. There are ways to overcome this
deficiency, but these practices are beyond the scope of this
document.
An NFSv4 multi-domain federated file system uses the FedFS to join
multiple NFSv4 domains each consisting of NFSv4 servers that export
multi-domain capable filesystems, into a uniform NFSv4 server-based
name space capable of spanning multiple enterprises.
Adamson & Williams Expires January 1, 2015 [Page 4]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
2. Terminology
Name Service: provides the mapping between {NFSv4 domain, group or
use name} and {NFSv4 domain, local ID} via lookups. Can be
applied to local or remote domains. Often provided by a Directory
Service such as LDAP.
Domain: This term is used in multiple contexts where it has
different meanings. Here we provide specific definitions used in
this document.
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 running a single name service, 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 but
only one name service.
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.
Adamson & Williams Expires January 1, 2015 [Page 5]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
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 January 1, 2015 [Page 6]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
3. NFSv4 Server Identity Mapping
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 January 1, 2015 [Page 7]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
4. Multi-domain Constraints to the NFSv4 Protocol
In order to service as many environments as possible, the NFSv4
protocol is designed to allow administrators freedom to configure
their NFSv4 domains as they please. Joining NFSv4 domains under a
single file namespace imposes slightly on this freedom. Here we
describe the required constraints.
4.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
[I-D.ietf-nfsv4-rfc3530bis] 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.
4.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
Adamson & Williams Expires January 1, 2015 [Page 8]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
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
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.
Adamson & Williams Expires January 1, 2015 [Page 9]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
5. Resolving Multi-domain Authorization Information
When an RPCSEC_GSS principal is seeking access to files on an NFSv4
server, after authenticating the principal, the server must obtain in
a secure manner the principal's authorization context information
from an authoritative source: e.g. the name service in the
principal's NFSv4 domain.
In the local NFSv4 domain case where the principal is seeking access
to files on an NFSv4 server in the principal's NFSv4 home domain, the
server administrator has knowledge of the local policies and methods
for obtaining the principal's authorization information and the
mappings to local representation of identity. E.g. the administrator
can configure secure access to the local NFSv4 domain name service.
In the multi-domain case where a principal from a remote NFSv4 domain
is seeking access to files on an NFSv4 server not in the principal's
domain, there is no assumption of:
o remote name service configuration knowledge
o the form of the remote authorization context information presented
to the NFSv4 server by the remote name service for mapping to a
local representation.
There are several methods the NFSv4 server can use to obtain the
NFSv4 domain authoritative authorization information for a remote
principal, listed in order of preference:
1. A mechanism specific GSS-API authorization payload containing
credential authorization data described in the following section.
This is the preferred method as it is part of the GSS-API
authentication and avoids requiring any knowledge of a remote
NFSv4 domain name service configuration, and has a set form of
authorization context information to allow mapping to a local
representation.
2. When there is a security agreement between the local and remote
NFSv4 domain name services plus regular update data feeds, the
NFSv4 server local NFSv4 domain name service can be authoritative
for principal's in a remote NFSv4 domain. In this case, the
NFSv4 server makes a query to it's local NFSv4 domain name
service just as it does when servicing a local domain principal.
While this requires detailed knowledge of the remote NFSv4
domains name service, the authorization context information
presented to the NFSv4 server is in the same form as a query for
a local principal.
Adamson & Williams Expires January 1, 2015 [Page 10]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
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 and detailed
knowledge of the form of the resultant authorization context
information.
Once the authorization context data for the remote principal has been
obtained, the remote information must be mapped into local
representations suitable for use in file system ACLs. This is the
first mapping described in Section 3.
5.1. 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.
Adamson & Williams Expires January 1, 2015 [Page 11]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
6. 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 3.
The local name-service is authoritative for these mappings for remote
users and groups when one of the first two methods in (Section 5) is
used to keep the local name-service updated with remote information.
Adamson & Williams Expires January 1, 2015 [Page 12]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
7. Security Considerations
Some considerations to come
Adamson & Williams Expires January 1, 2015 [Page 13]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
8. References
8.1. Normative References
[CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common
Internet File System (CIFS) Protocol", January 2013.
[I-D.ietf-nfsv4-rfc3530bis]
Haynes, T. and D. Noveck, "Network File System (NFS)
version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-25 (Work
In Progress), February 2013.
[I-D.sorce-krbwg-general-pac]
Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for
Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In
Progress awaiting merge with other document ), June 2011.
[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.
[PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data
in Kerberos Tickets for Access Control to Resources",
October 2002.
[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network
Information Service", RFC 2307, March 1998.
[RFC4120] Neuman, C., 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.
Adamson & Williams Expires January 1, 2015 [Page 14]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
8.2. Informative References
[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 January 1, 2015 [Page 15]
Internet-Draft NFSv4 Multi-Domain FedFS Requirements June 2014
Authors' Addresses
William A. (Andy) Adamson
NetApp
Email: andros@netapp.com
Nicolas Williams
Cryptonector
Email: nico@cryptonector.com
Adamson & Williams Expires January 1, 2015 [Page 16]