NFSv4 Multi-Domain FedFS Requirements
draft-adamson-nfsv4-multi-domain-federated-fs-reqs-00

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 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 March 28, 2013.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Requirements notation
• 2. Introduction
• 3. Background
• 4. Multi-domain Constraints to the NFSv4 Protocol
• 4.1. Name@dns_domain Constraints
• 4.2. RPC Security Constraints
• 5. Cross-Domain Authorization
• 5.1. Authorization Information
• 5.2. Resolving Cross-Domain Authorization Information
• 5.2.1. GSS-API Authorization Payload
• 5.2.2. Using Authoritative Name Services
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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

2. Introduction

The NFSv4.0 [RFC3530] and NFSv4.1 [RFC5661] (NFSv4) protocols enable the construction of a distributed file system which can join NFSv4 servers from multiple administrative domains, each potentially using separate name resolution services and separate security services, into a common multi-domain name space.

The Federated File System (FedFS) [I-D.ietf-nfsv4-federated-fs-reqts] describes requirements and adminstrative tools to construct a uniform server-based namespace that is capable of spanning a whole enterprise and that is easy to manage.

A multi-domain capable filesystem uses local ID forms that can represent identities from both local and remote domains. A multi-domain NFSv4 FedFS joins multiple NFSv4 administrative domains each consisting of NFSv4 servers that export multi-domain capable filesystems, and that employ separate name resolution services and separate security services into a uniform 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 to fully enable a multi-domain NFSv4 federated file system.

3. 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 principals" (always corresponding to the server). NFSv4 does not prescribe how to represent authorization identities on file systems. All file access decisions constitute "authorization" and are made by servers using information about principals (such as username, group memberships, and so on) 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. Between the authentication identity and the authorization context (a principal's user ID, group memberships, etcetera)
2. 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 inter operate in a multi-domain NFSv4 FedFS servers must use such services in compatible ways.

4. Multi-domain Constraints to the NFSv4 Protocol

4.1. Name@dns_domain Constraints

NFSv4 uses a syntax of the form "name@dns_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 a client and server with different internal representations of authorization identity to inter operate even when referring to authorization identities from different administrative domains.

Multi-domain capable sites need to meet the following requirements in order to ensure that clients and servers can map name@dns_domain to internal representations reliably:

• The dns_domain portion of name@dns_domain MUST be unique within the FedFS NFSv4 multi-domain namespace. [ANDROS: IANA help here?] See [RFC3530] section 5.9 "Interpreting owner and owner_group", for a discussion on dns_domain configuration.
• The name portion of name@dns_domain MUST be unique within the specified dns_domain.
• Every local representation of a user and of a group MUST have a canonical name@dns_domain, and it must be possible to return the canonical name@dns_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 service used in a multi-domain NFSv4 FedFS is REQUIRED to employ a method of cross domain trust so that a principal from a security service in one domain can be authenticated in another domain that uses the same security service. 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 NFS 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 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.

A new version of RPCSEC_GSS [I-D.williams-rpcsecgssv3] includes a modernized replacement for AUTH_SYS which addresses this issue.

5. Cross-Domain Authorization

In order to authorize client principal access to files, the NFS server must map the RPCSEC_GSS client principal name or the underlying GSS-API security context to authorization information meaningful to the file system being exported.

5.1. Authorization Information

Here we list the authorization information that a multi-domain FedFS NFSv4 server needs in order to make a file access decision. Note that the server may need to map the global IDs to a local representation.

• UserID: This field contains the principal's global ID and the name@dns_domain form thereof.
• PrimaryGroupID: This field contains the global ID for the principal's primary group, and the name@dns_domain form thereof.
• Groups: This field contains an array of global ID for the groups that the principal is a member of, and the name@dns_domain forms thereof.
• Optional field(s) for privileges, authorizations, implementation-specific items, etcetera, relevant to authorization.

5.2. Resolving Cross-Domain Authorization Information

In the cross-domain case where a client principal is seeking access to files on a server in a different NFSv4 domain, the NFS server needs to obtain, in a secure manner, the authorization information from an authoritative source: e.g. a name service in the client principals NFS domain.

There are several methods the cross-domain authoritative authorization information can be obtained:

1. A mechanism specific GSS-API authorization payload containing credential authorization data.
2. An NFS server local domain name query when there is a security agreement between the two cross-domain name services plus regular update data feeds so that the NFS server local domain name service is authoritative for the client principal domain.
3. A direct query from the NFS server to the client principal authoritative name service.

The authorization data information SHOULD be obtained via the GSS-API name attribute interface [I-D.ietf-kitten-gssapi-naming-exts] either via a single attribute for the credential authorization data or via discrete GSS-API name attributes corresponding to the authorization data elements.

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.

5.2.1. GSS-API Authorization Payload

Authorization context information can sometimes 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] as authorization data. 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 client principal's credential. The General PAD lists user and group global IDs as "universal user identifiers" (UUIDs) as well as their string representations and DNS domains.
• PKIX [RFC5280] certificates allow for extensions that could be used similarly.

When a client principal is authenticated using a GSS-API authorization payload, the server SHOULD extract the payload from the client's ticket and map, if need be, the global IDs to local ID representations.

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 server must parse it into its individual elements.

5.2.2. Using Authoritative Name Services

If a GSS-API authorization payload for the client principal is not available, then the server SHOULD try to map the client principal name to a local notion of user account, and then lookup that user account's authorization context information through authenticated name service lookups.

Authoritative name service queries may also be necessary to construct the name@dns_domain form of a global ID obtained from a GSS-API authorization payload.

6. Security Considerations

Some considerations to come

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses