[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

NFSv4 Working Group                                           W. Adamson
Internet-Draft                                                    NetApp
Intended status: Standards Track                             N. Williams
Expires: September 29, 2013                                 Cryptonector
                                                          March 28, 2013


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

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 September 29, 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 September 29, 2013               [Page 1]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


Table of Contents

   1.      Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  4
   3.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   4.      Background . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.      Multi-domain Constraints to the NFSv4 Protocol . . . . . .  7
   5.1.    Name@domain Constraints  . . . . . . . . . . . . . . . . .  7
   5.2.    RPC Security Constraints . . . . . . . . . . . . . . . . .  7
   6.      NFSv4 Multi-domain File Access . . . . . . . . . . . . . .  9
   6.1.    Resolving Multi-domain Authorization Information . . . . .  9
   6.2.    GSS-API Authorization Payload  . . . . . . . . . . . . . . 10
   7.      Setting and Retrieving NFSv4 Multi-domain ACLs . . . . . . 11
   7.1.    Managing Remote Users and Groups . . . . . . . . . . . . . 11
   7.1.1.  Remote User and Group Issues . . . . . . . . . . . . . . . 11
   8.      Security Considerations  . . . . . . . . . . . . . . . . . 13
   9.      References . . . . . . . . . . . . . . . . . . . . . . . . 14
   9.1.    Normative References . . . . . . . . . . . . . . . . . . . 14
   9.2.    Informative References . . . . . . . . . . . . . . . . . . 15
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 16































Adamson & Williams     Expires September 29, 2013               [Page 2]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 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 September 29, 2013               [Page 3]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


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 the requirements and administrative 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 potentially :w 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.


























Adamson & Williams     Expires September 29, 2013               [Page 4]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


3.  Terminology

      (NFSv4) Domain: a set of users, groups and computers administered
      by a single entity, and identified by a DNS domain name.

      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 {domain, name} and
      {domain, ID} via lookups.  Can be applied to local or remote
      domains.  Often provided by a Directory Service such as LDAP.

      ID mapping: Is a mapping between {remote domain, remote 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 September 29, 2013               [Page 5]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 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 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
   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
   servers must use such services in compatible ways.

























Adamson & Williams     Expires September 29, 2013               [Page 6]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 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 a client and server with different internal
   representations of authorization identity to interoperate 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 between name@domain
   and internal representations reliably:

   o  The domain portion of name@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 NFSv4 domain configuration.

   o  The name portion of name@domain MUST be unique within the
      specified 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 domain trust so
   that a principal from a security service in one domain can be
   authenticated in another 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 September 29, 2013               [Page 7]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


   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.  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 September 29, 2013               [Page 8]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


6.  NFSv4 Multi-domain File Access

   In the mult-domain case where a 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 principal's authorization information
   from an authoritative source: e.g. a name service in the principal's
   NFS domain.  The NFS server must map the remote RPCSEC_GSS principal
   to a local representation of ID suitable for use in file system ACLs.
   This may also involve the need to map the remote RPCSEC_GSS principal
   to a name@domain form.  The principal's primary group and group
   membership list must also be mapped into local representations of ID.

   In the local NFSv4 domain case where the principal is seeking access
   to files on a server in the local 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 cross-domain authoritative
   authorization information 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 domain name
       service.

   2.  An authenticated NFS server local domain name query when there is
       a security agreement between the two multi-domain name services
       plus regular update data feeds so that the NFS server local
       domain name service is authoritative for the principal's NFSv4
       domain.

   3.  An authenticated direct query from the NFS server to the
       principal's domain authoritative name service.  This requires the
       NFS server to have detailed knowledge of the remote domain's
       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



Adamson & Williams     Expires September 29, 2013               [Page 9]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


   mentioned methods of obtaining the authorization information which
   demonstrates the usefulness of the API.

6.2.  GSS-API Authorization Payload

   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 along with a
      unique 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.

   When a principal is authenticated using a GSS-API authorization
   payload, the server SHOULD extract the payload from the client's
   ticket and ID-Map or use name services to map the information to
   local ID representations if required.

   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.

   Remote authoritative name service queries may also be necessary to
   construct the name@domain form of an ID obtained from a GSS-API
   authorization payload.








Adamson & Williams     Expires September 29, 2013              [Page 10]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


7.  Setting and Retrieving NFSv4 Multi-domain ACLs

   When servicing a set acl request, the NFS 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 NFS 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 needs to be done against an authoritative
   service.

7.1.  Managing Remote Users and Groups

   In order to add a remote NFSv4 domain's users and groups to file
   system ACLs in the local NFSv4 domain, a local account must be
   created.  This in turn makes the local domain authoritative with
   respect to mapping between name@domain and local representation of
   identity for the remote user.

   Adding a user from a remote NFSv4 domain to a local NFSv4 domain is
   not that different from adding a local user: a local account is
   created giving the remote user a local representation of ID.  Extra
   steps may need to be taken to enable mapping between the remote
   RPCSEC_GSS principal and the local representation of ID, as well as
   the mapping between the local representation of ID and the name@
   (remote)domain.

   Adding a group from a remote NFSv4 domain to a local NFSv4 domain is
   similar to adding a local group: a local account is created giving
   the remote group a local representation of ID.  Extra steps may need
   to be taken to enable mapping between the name@(remote)domain and the
   local representation of ID.

7.1.1.  Remote User and Group Issues

   There are several issues here that need to be resolved, including
   which if any of these questions should be answered in this document:

   1.  Remote user: We want the local name service to be authoritative
       for resolving name@domain to local ID mappings.  Does this mean
       we need to be notified when a remote user is removed from the
       remote domain?  How is this different from a local user?

   2.  Remote user/group: Note that when the authorization context
       information is parsed as part of multi-domain file access, group
       membership for the principal is determined which gives an
       opportunity to update the local domain data concerning the
       principals membership (or not) in remote groups.




Adamson & Williams     Expires September 29, 2013              [Page 11]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


   3.  Remote group: Who gets to add members to a remote group?  The
       remote group owner?  The local domain admin?  Who performs
       membership updates?

   4.  Remote group: We want the local name service to be authoritative
       for resolving name@domain to local ID mappings.  Does this mean
       that we need to be notified if the remote group is removed from
       the remote home domain?

   5.  Remote group: Listing the membership of a remote group may not be
       allowed (expected to work?) due to the problem of knowing about
       and querying all domains that provide members.







































Adamson & Williams     Expires September 29, 2013              [Page 12]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


8.  Security Considerations

   Some considerations to come
















































Adamson & Williams     Expires September 29, 2013              [Page 13]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


9.  References

9.1.  Normative References

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

   [I-D.ietf-nfsv4-federated-fs-reqts]
              Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
              Naik, "Requirements for Federated File Systems",
              draft-ietf-nfsv4-federated-fs-reqts-06 (work in progress),
              October 2009.

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

   [I-D.ietf-kitten-gssapi-naming-exts]
              Williams, N., Johansson, L., Hartman, S., and S.
              Josefsson, "GSS-API Naming Extensions",
              draft-ietf-kitten-gssapi-naming-exts-15 (work in
              progress), May 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 September 29, 2013              [Page 14]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 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 September 29, 2013              [Page 15]


Internet-Draft    NFSv4 Multi-Domain FedFS Requirements       March 2013


Authors' Addresses

   William A. (Andy) Adamson
   NetApp

   Email: andros@netapp.com


   Nicolas Williams
   Cryptonector

   Email: nico@cryptonector.com







































Adamson & Williams     Expires September 29, 2013              [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/