NFSv4 Multi-Domain FedFS RequirementsNetAppandros@netapp.com Cryptonectornico@cryptonector.com
Internet
NFSv4 Working Group
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.
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 .
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:
NFSv4 Domain, Pseudo file system and referrals:
The NFSv4.0 and
NFSv4.1
(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):
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.
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.
Here we need to reference the YTB constructed Multi-domain best
practices doc.
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.
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.
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 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. 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.
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.
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:
A mapping between the authentication identity and the
authorization context information.
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.
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.
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:
The NFSv4 domain portion of name@domain
MUST be unique within the FedFS NFSv4 multi-domain
namespace. See
section 5.9 "Interpreting owner and owner_group"
for a discussion on NFSv4 domain configuration.
The name portion of name@domain MUST be unique
within the specified NFSv4 domain.
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.
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
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 , 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 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.
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:
remote name service configuration knowledge
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:
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.
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.
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 .
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:
Kerberos 5 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" listing the principal's user
and group global IDs as "security identifiers" (SIDs).
Some KDCs (will) issue Kerberos Tickets with the
General
PAD (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.
PKIX certificates allow
for extensions that could be used similarly.
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 .
The local name-service is authoritative for these mappings
for remote users and groups
when one of the first two
methods in is used to keep the local name-service
updated with remote information.
Some considerations to come
DOMAIN NAMES - CONCEPTS AND FACILITIESISIKey words for use in RFCs to Indicate Requirement LevelsHarvard University An Approach for Using LDAP as a Network Information Service
Independent ConsultantNetwork File System (NFS) version 4 ProtocolNetAppEMC Corporation The Kerberos Network Authentication Service (V5)
USC-ISI
MIT
MIT
Network File System (NFS) Version 4 Minor Version 1 ProtocolStorspeed, Inc.NetAppNetAppRequirements for Federated File Systems
NetApp
NetApp
BBN Technologies
IBM Almaden
IBM Almaden
Public Key Cryptography Based User-to-User Authentication - (PKU2U)
MicrosoftSunSunA Generalized PAC for Kerberos V5
Red HatMIT Kerberos ConsortiumMIT Kerberos Consortium
Utilizing the Windows 2000 Authorization Data in
Kerberos Tickets for Access Control to Resources
Microsoft Corporation
[MS-CIFS] — v20130118 Common Internet File System (CIFS) Protocol
Microsoft CorporationInternet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
NIST
Microsoft
Trinity College Dublin
Entrust
Vigil Security
NIST