Internet-Draft NFSv4 Multi-Domain FedFS Requirements October 2020
Adamson & Williams Expires 4 April 2021 [Page]
Workgroup:
NFSv4 Working Group
Internet-Draft:
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-03
Published:
Intended Status:
Standards Track
Expires:
Authors:
W.A. Adamson
NetApp
N. Williams
Cryptonector

NFSv4 Multi-Domain FedFS Requirements

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.

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 https://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 4 April 2021.

▲

Table of Contents

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 [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.
  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.

Here we need to reference the YTB constructed Multi-domain best practices doc. AA

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.

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]. 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.

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.

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:

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 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.

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:

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.
  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:

  • 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).
  • 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.
  • PKIX [RFC5280] certificates allow for extensions that could be used similarly.

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.

7. Security Considerations

Some considerations to come

8. References

8.1. Normative References

[RFC1034]
Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, , <https://www.rfc-editor.org/info/rfc1034>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2307]
Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, DOI 10.17487/RFC2307, , <https://www.rfc-editor.org/info/rfc2307>.
[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, DOI 10.17487/RFC3530, , <https://www.rfc-editor.org/info/rfc3530>.
[RFC4120]
Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, , <https://www.rfc-editor.org/info/rfc4120>.
[RFC5661]
Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, , <https://www.rfc-editor.org/info/rfc5661>.
[RFC5716]
Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "Requirements for Federated File Systems", RFC 5716, DOI 10.17487/RFC5716, , <https://www.rfc-editor.org/info/rfc5716>.
[I-D.zhu-pku2u]
Zhu, L., Altman, J., and N. Williams, "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", Work in Progress, Internet-Draft, draft-zhu-pku2u-09, , <http://www.ietf.org/internet-drafts/draft-zhu-pku2u-09.txt>.
[I-D.sorce-krbwg-general-pac]
Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for Kerberos V5", Work in Progress, Internet-Draft, draft-sorce-krbwg-general-pac-01, , <http://www.ietf.org/internet-drafts/draft-sorce-krbwg-general-pac-01.txt>.
[PAC]
Brezak, J., "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources", .
[CIFS]
Microsoft Corporation, "[MS-CIFS] — v20130118 Common Internet File System (CIFS) Protocol", .

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, DOI 10.17487/RFC5280, , <https://www.rfc-editor.org/info/rfc5280>.

Authors' Addresses

William A. (Andy) Adamson
NetApp
Nicolas Williams
Cryptonector