[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

NFSv4 Working Group                                           W. Adamson
Internet-Draft                                                    NetApp
Intended status: Standards Track                              K. Coffman
Expires: January 4, 2010                    CITI, University of Michigan
                                                            July 3, 2009


                       NFSv4 Multi-Domain Access
               draft-adamson-nfsv4-multi-domain-access-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 4, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








Adamson & Coffman        Expires January 4, 2010                [Page 1]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


Abstract

   The NFS Version 4 [NFSv40] protocol enables the construction of a
   distributed file system which can join NFSv4.0 or NFSv4.1 [NFSv41]
   servers, which potentially use separate name translation services and
   separate security services, into a common name space.

   The protocol supports multiple authentication methods and does not
   restrict how users are represented or authenticated.  As such a
   user's view of the name space may be limited by the authentication
   and authorization privileges they have on the different file servers
   in the name space.

   This document discusses authentication and authorization management
   and proposes two name service attributes that are used for NFSv4 name
   and security principal translations to enable users to traverse and
   access files in a secure, multi-domain NFS Version 4 name space.


































Adamson & Coffman        Expires January 4, 2010                [Page 2]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Background and Motivation  . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Overview of NFSv4 Namespace and Name Translation . . . . .  7
       2.3.1.  NFSv4 Server Pseudo File System  . . . . . . . . . . .  7
       2.3.2.  NFSv4 Referral . . . . . . . . . . . . . . . . . . . .  7
       2.3.3.  NFSv4 ACL Name and GSS Principal Translation . . . . .  7
   3.  Managing Access in a local NFSv4 Environment . . . . . . . . . 11
     3.1.  Security Services  . . . . . . . . . . . . . . . . . . . . 11
     3.2.  DNS Domains  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.3.  The NFSv4 Domain . . . . . . . . . . . . . . . . . . . . . 12
     3.4.  Name Translation Requirements in an NFSv4 Domain . . . . . 12
   4.  Managing Access Across Multiple NFSv4 Domains  . . . . . . . . 15
     4.1.  Name Translation Requirements in the Federated FS  . . . . 16
   5.  New LDAP Attributes and Object Class . . . . . . . . . . . . . 19
     5.1.  Multiple NFSv4 Domain Translation Solution . . . . . . . . 20
     5.2.  Local NFSv4 Domain LDAP Attribute Use  . . . . . . . . . . 22
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27



























Adamson & Coffman        Expires January 4, 2010                [Page 3]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


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 & Coffman        Expires January 4, 2010                [Page 4]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


2.  Introduction

2.1.  Background and Motivation

   Authentication and authorization in NFS4 occurs at the RPC [RFC1831]
   level with the RPC credential presenting the security principal to
   the NFSv4 server for translation into a local representation.
   Setting authorization for file object access occurs in the NFSv4
   layer where NFSv4 acl attribute names are also presented to the NFSv4
   server for translation.  The choice and management of security
   services and name translation services is therefore central to
   enabling access in an NFS Version 4 name space.

   The name space scope directly effects the choice and management of
   name translation and security services.  For example, a single
   enterprise could have a firewalled network, use low security
   protocols, and employ a common identity for users across the file
   servers in the name space.  A grid or a physically distributed
   enterprise environment could require a high security level and
   utilize name and principal translations across different
   administrative domains.

   The Network Information Service [NIS], the Lightweight Directory
   Service [LDAP], and Active Directory [AD-LDAP] are the three broadly
   used client-server directory service protocols for distributing
   system configuration data and providing name translation in managed
   networked environments.  LDAP and Active Directory are used instead
   of NIS in environments where scale and security are issues.  Active
   Directory uses the LDAP protocol for many purposes including name
   translation.  This document uses LDAP as a name service in all
   examples and solutions.

   RFC2307 [RFC2307] defines the LDAP posixAccount object class and an
   associated set of attributes used to resolve account information such
   as user IDs to login names and group IDs to group names.  The
   posixAccount class requires a one-to-one correspondence between the
   user's login name (uid attribute) and the user's integer
   identification number (uidNumber attribute).

   Distributed file systems such as NFS Version 2 [RFC1094], NFS Version
   v3 [RFC1813], and AFS [AFS_ACM] keep this one-to-one correspondence
   either by placing numeric user identifiers on the wire or by
   supporting a single Kerberos [RFC4120] realm and using the user's
   login name as the Kerberos principal.  These distributed file systems
   maintain the one-to-one uid to uidNumber correspondence and can
   continue to use the posixAccount class for name (and Kerberos
   principal) to uidNumber resolution.




Adamson & Coffman        Expires January 4, 2010                [Page 5]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   NFSv4 can have multiple acl attribute names and multiple security
   principals associated with a user and so presents a name to uidNumber
   resolution problem that is not solved by the current LDAP attribute
   set.

   This document demonstrates the need for two new LDAP name service
   attributes and object classes (Section 5) by starting with a simple
   name space (Section 3) and building into one that spans
   administrative domains (Section 4) where each domain requires a name
   service and a high level of security.  The name translation,
   authentication and authorization requirements of the Federated File
   System [FEDFS-REQTS] are discussed throughout.

2.2.  Terminology

   NFSv4:  Refers to both the NFS Version 4 Minor Version 0 [NFSv40] and
      the NFS Version 4 Minor Version 1 [NFSv41] protocols unless
      otherwise stated.

   Local representation:  How a local file system represents users and
      groups which we define as the LDAP posixAccount uidNumber or
      gidNumber.

   NFSv4 ACL name:  The NFSv4 draft recommended attributes "owner" and
      "owner_group", and also users and groups within the "acl"
      attribute.  The name is of the form user@dns_domain.

   GSS principal:  The security principal name in an NFSv4 draft
      supported GSS [RFC2743] Security Mechanism.

   NFSv4 name service:  A service that translates between an NFSv4 ACL
      user name and a uidNumber, a GSS principal and a uidNumber, and an
      NFSv4 ACL group name and a gidNumber.

   Host-based authentication:  An authentication model used by NFSv4
      where the NFSv4 server authenticates the NFSv4 client, and trusts
      the client to authenticate all users.  The AUTH_SYS security
      flavor depends on host-based authentication.

   User-based authentication:  An authentication model used by NFSv4
      where the user principal is authenticated by an NFSv4 server, and
      the NFSv4 server is authenticated by the user principal.  The
      RPCSEC_GSS [RFC2203] Kerberos security mechanism is an example of
      a user-based authentication model.







Adamson & Coffman        Expires January 4, 2010                [Page 6]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   Absent file system:  An export on an NFSv4 server that serves a
      location attribute, but has no data.

   Local NFSv4 environment:  A local NFSv4 environment is one where
      client workstations and file servers share an NFSv4 name service
      and so the exported file systems share an NFSv4 ACL space.

   Foreign user:  A user from a different NFSv4 name service.

2.3.  Overview of NFSv4 Namespace and Name Translation

   To provide a context for the reader two major features of the NFSv4
   name space, the building blocks of the name space, are reviewed in
   brief.  An example of how NFSv4 uses name translation in a single
   client to single server environment is also provided.

2.3.1.  NFSv4 Server Pseudo File System

   The NFSv4 server presents its exports as leaves of a single name
   space, the pseudo file system.  An NFSv4 client mounts the server
   pseudo file system root and uses LOOKUP and READDIR operations to
   browse seamlessly from one export to another.  The server
   administrator can change the server exports without changing the
   client mountpoint.

2.3.2.  NFSv4 Referral

   An NFSv4 server can export an absent file system and such an export
   can be a leaf of the server's pseudo file system.  One of the uses of
   the NFSv4 fs_location attribute is to return the 'real' location of
   an absent file system exported by an NFSv4 server.  An absent file
   system contains no files or directories other than the root.  Any
   reference to it, except to access a small set of attributes useful in
   determining alternate locations, will result in an error,
   NFS4ERR_MOVED.

   The NFSv4 client responds to the NFS4ERR_MOVED error by requesting
   the fs_location attribute which redirects the client to the actual
   file system location.  This provides a means by which file systems
   located on one server can be associated with a name space defined by
   another server, thus allowing a general multi-server name space
   facility.  A designation of such a location, in place of an absent
   file system, is called a "referral".

2.3.3.  NFSv4 ACL Name and GSS Principal Translation

   NFSv4 uses a syntax of the form "user@dns_domain" to represent the
   NFSv4 ACL name.  This design gives a level of indirection that allows



Adamson & Coffman        Expires January 4, 2010                [Page 7]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   the client and server to translate their local representation to a
   common syntax.  The Kerberos identity shares this feature as it is
   also in string form with the syntax of principal@REALM.

       client.business.com         server.business.com
       (BUSINESS.REALM)                (BUSINESS.REALM )

               Figure 1: Single client and server namespace

   An example of the name translations involved for a user Bob to set an
   NFSv4 ACL for Alice across the POSIX interface on client.business.com
   on a file in a Kerberos protected NFSv4 export on server.business.com
   is given.  The client and server share a name service, the DNS
   business.com domain, and the Kerberos BUSINESS.REALM realm.

   This example will be extended in steps from the single client and
   server to a multi-domain federated file system in upcoming sections.


































Adamson & Coffman        Expires January 4, 2010                [Page 8]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   Typical LDAP name service entries for the fictional users Bob Bar and
   Alice Answer.

   # bob, People, business, com
       dn: uid=bob,ou=People,dc=business,dc=com
       objectClass: top
       objectClass: person
       objectClass: organizationalPerson
       objectClass: inetorgperson
       objectClass: posixAccount
       cn: Bob B. Bar
       sn: Bar
       uid: bob
       mail: bob@business.com
       uidNumber: 2975
       gidNumber: 10
       homeDirectory: /users/bob
       loginShell: /bin/csh
       displayName: Bob B. Bar

   # alice, People, business, com
       dn: uid=alice,ou=People,dc=business,dc=com
       objectClass: top
       objectClass: person
       objectClass: organizationalPerson
       objectClass: inetorgperson
       objectClass: posixAccount
       cn: Alice A. Answer
       sn: Answer
       uid: alice
       mail: alice@business.com
       uidNumber: 1002
       gidNumber: 10
       homeDirectory: /users/alice
       loginShell: /bin/csh
       displayName: Alice A. Answer

                                 Figure 2

   Prior to sending the first compound RPC to the server, user-based
   authentication is used to establish a Kerberos GSS context for Bob on
   the client and the server.  At the end of a successful GSS context
   establishment, before the NFSv4 server can grant any file system
   access, Bob's Kerberos GSS principal must be mapped to a uidNumber on
   the file server.  Note that the uidNumber mapping requirement for
   NFSv4 access allows separation of NFSv4 access from general Kerberos
   authentication.




Adamson & Coffman        Expires January 4, 2010                [Page 9]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   The posixAccount class uid attribute can be used for all the name
   translations in this simple example by making Bob's POSIX login name
   and his Kerberos principal name the same, and by stripping the
   '@BUSINESS.REALM' and the '@business.com' from the Kerberos principal
   and the NFSv4 ACL name respectively prior to submitting the names for
   translation.  In other words, the posixAccount uid "bob",the NFSv4
   ACL name "bob@business.com" and the Kerberos principal name "bob@
   BUSINESS_REALM" are all equivalnet.  The server will need a list of
   DNS domains it will accept as valid (business.com in this example)
   and check the @dns_domain portion of an NFSv4 ACL name prior to
   translation.  Also required is the addition of the @business.com to
   translated uids to create the NFSv4 ACL name.

   Step 1: On the NFSv4 server (GSS interface), the @BUSINESS.REALM
   portion of Bob's Kerberos principal is stripped prior to contacting
   the LDAP name service.

           bob@BUSINESS.REALM -> bob -> uidNumber 2975

   Bob now has a Kerberos protected GSS connection to the server, which
   is used to set an acl for 'alice' on a file.  Bob enters the POSIX
   setacl command and the client POSIX interface translates "alice" into
   the local uidNumber.

   Step 2: On the client (POSIX interface)

           alice -> uidNumber 1002

   The NFS4 client translates the uidNumber into a user@dns_domain NFS4
   ACL name required for the NFSv4 SETATTR operation acl attribute which
   is sent to the server.

   Step 3: On the client (NFSv4 interface).  The @business.com portion
   of the name is added after the uidNumber translation.

           uidNumber 1002 -> alice -> alice@business.com

   The server translates the NFS4 ACL name to be used to set the ACL on
   the file system object.

   Step 4: On the server (NFSv4 interface), the @business.com portion of
   the name is stripped prior to contacting the LDAP name service.

           alice@business.com -> alice -> uidNumber 1002

   The server sets the ACL on the file using Alice's uidNumber.





Adamson & Coffman        Expires January 4, 2010               [Page 10]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


3.  Managing Access in a local NFSv4 Environment

   The NFSv4 [NFSv40] draft addresses all of the pieces of NFSv4
   administration each with many options.  Stand alone NFSv4 sites
   choose which options serve their needs.  To address the name
   translation issues of joining stand alone sites into a multi-domain
   NFSv4 namespace such as the federated file system, some common
   choices of the available administration options need to be agreed
   upon.  This section describes these common choices, and then expands
   upon the single client to single server example (Figure 1).

3.1.  Security Services

   As described in section 2.2.1.1 "RPC Security Flavors" of [NFSv41]:

      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 AUTH_SYS security flavor uses a host-based authentication model
   which can only be use in an NFSv4 name space where all clients and
   servers share a name service.  A shared name service is required
   because uidNumbers are passed in the RPC credential, and there is no
   indication of which service translated the user name to the uidNumber
   so collisions can occur between administrative domains.

   The AUTH_NONE security flavor is useful to the multi-domain NFSv4 or
   federated name space to grant universal access to public data without
   any credentials.

   The RPCSEC_GSS security flavor with the Kerberos security mechanism
   is mandated by both NFS Version 4 [NFSv40] [NFSv41] drafts and being
   a user-based authentication model is appropriate for use in the
   multi-domain federated name space.  Multiple Kerberos Realms per
   local NFSv4 environment are supported.  A single Kerberos Realm can
   also be part of multiple local NFSv4 environments, each with a
   distinct name service.

   The RPCSEC_GSS security flavor with an X.509 based security system is
   another user-based authentication module appropriate for use in the
   multi-domain federal name space.

3.2.  DNS Domains

   Multiple DNS domains can be used by the client workstations and file
   servers in a local NFSv4 environment served by a single name service.
   The NFS Version 4 Minor Version 0 [NFSv40] draft specifies a broad



Adamson & Coffman        Expires January 4, 2010               [Page 11]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   relationship between a DNS domain and the dns_domain portion of the
   user@dns_domain in the ACL name.  The only constraint is that servers
   "should accept as valid a set of users for at least one domain".  The
   method the NFSv4 client uses to construct a user@dns_domain name to
   place on the wire is not even discussed, the client machine's DNS
   domain name is one likely choice.

   Given a set of NFSv4 file servers serviced by multiple DNS domains,
   the protocol allows a single user to have different NFSv4 user@
   dns_domain ACL names due to the different DNS domains the NFSv4
   servers belong to.  This becomes confusing to say the least when two
   servers using the same name service return ACLs for the same user
   with different user@dns_domain names.

3.3.  The NFSv4 Domain

   The NFSv4 Domain, roughly the equivalent of an AFS Cell, is the
   collection of administrative services used to build a multi-domain
   NFSv4 federated file system, and is defined as follows.

   The NFSv4 Domain is an independently administered site running NFSv4
   and consists of a collection of NFSv4 file servers and client
   workstations that share a name service, has one or more DNS domains,
   and one or more security services.

   The NFSv4 domain administrator MUST choose one of the DNS domains
   servicing the NFSv4 file servers and client machines to use as the
   NFSv4 Domain name for use with the multi-domain NFSv4 federated file
   system.  The NFSv4 domain name MUST be unique among all NFSv4
   Domains.  All the NFSv4 clients MUST be configured to use the NFSv4
   Domain name as the "dns_domain" portion of the user@dns_domain NFSv4
   ACL name.

   The name service MUST service only one NFSv4 Domain.  The Kerberos
   realms and the DNS domains are independent of the NFSv4 Domain and
   can service more than one NFSv4 Domain.

   The unique NFSv4 Domain name requirement along with the single name
   service per NFSv4 Domain requirement ensures unique user@dns_domain
   names across multiple NFSv4 Domains.  Each NFSv4 user participating
   in a multi-domain NFSv4 name space such as the federated file system
   has exactly one NFSv4 ACL name.

3.4.  Name Translation Requirements in an NFSv4 Domain

   In this section we define an NFSv4 Domain which we will use to
   illustrate NFSv4 ACL name and GSS principal translation requirements,
   expanding upon the Simple Client and Server example (Figure 1).



Adamson & Coffman        Expires January 4, 2010               [Page 12]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   The example NFSv4 Domain is a local NFSv4 environment consisting of a
   collection of client workstations and file servers running NFSv4 that
   share a name service, run multiple Kerberos realms, use multiple DNS
   domains with the file servers joined in a hierarchical name space
   built using NFSv4 pseudo file servers and referral exports.

       NFSv4 Domain name:  business.com
       Kerberos Realm1:  BUSINESS.REALM
       Kerberos Realm1:  BUSINESS_ENG.REALM
       DNS Domain:         business.com
       DNS Domain:         business.eng.com

   The NFSv4 Domain business.com name is chosen from one of the DNS
   names.

                  Figure 3: The business.com NFSv4 Domain

   The business.com NFSv4 Domain (Figure 4) has the following name space
   consisting of three servers: root.business.com, server.business.com
   and server.business.eng.com.  There are also two client machines
   shown.  Each machine shows the Kerberos REALM that they belong to in
   parentheses below their name.

   The Kerberos realms BUSINESS.REALM and BUSINESS_ENG.REALM share
   cross-realm trust between them.  This means that authentications done
   in BUSINESS.REALM are accepted in BUSINESS_ENG.REALM, and
   authentications done in BUSINESS_ENG.REALM are accepted in
   BUSINESS.REALM.

   The name space starts at root.business.com which has two referral
   exports, and has no data.  In the Federated FS [FEDFS-PROT], this is
   called the root file server.  The clients mount "/" on
   root.business.com, the root of root.business.com's pseudo file system
   name space.

   Users traverse the client mount point to root.business.com, and then
   cross a referral to either server.business.com's or
   server.business.eng.com's pseudo file system name space root (dotted
   lines).












Adamson & Coffman        Expires January 4, 2010               [Page 13]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


       client.business.eng.com         client.business.eng.com
       ( BUSINESS.REALM )                ( BUSINESS_ENG.REALM )

                      root.business.com
                      ( BUSINESS.REALM )
                        /        \
                       /          \
       server.business.com        server.business.eng.com
       ( BUSINESS.REALM )         ( BUSINESS_ENG.REALM )


      Figure 4: NFSv4 Domain with multiple Kerberos and DNS services

   The NFSv4 ACL name and GSS principal translations are similar to the
   single client and server example (Figure 1).  The addition of a
   second Kerberos Realm with cross realm trust means that there are now
   potentially two GSS principal names associated with each posixAccount
   uid and uidNumber. e.g. bob@BUSINESS.REALM and bob@
   BUSINESS_ENG.REALM.

   Note that there is no requirement that the principal portion of the
   two principal@REALM Kerberos names are the same.  The posixAccount
   object class could still be used for all the name translations in
   this NFSv4 Domain example only by making Bob's POSIX login name and
   his Kerberos principal name in both realms the same.


























Adamson & Coffman        Expires January 4, 2010               [Page 14]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


4.   Managing Access Across Multiple NFSv4 Domains

   This section presents the name translation problems in joining
   multiple NFSv4 Domains (Section 3.3) into a single NFSv4 namespace.
   These problems are addressed in a following section (Section 5.1).
   The federated file system [FEDFS-REQTS] is used in the example.

   The example (Figure 6) shows two NFSv4 Domains joined into a
   federation: the business.com NFSv4 Domain (Figure 3) and a new NFSv4
   Domain, university.edu (Figure 5).

       NFSv4 Domain name:  university.edu
       Kerberos Realm:  UNIVERSITY.REALM
       DNS Domain:         university.edu

                 Figure 5: The university.edu NFSv4 Domain

   The NFSv4 Domain university.edu has a single Kerberos realm and a
   single DNS domain with two file servers root.university.edu and
   server.university.edu joined into a simple namespace with one
   referral.

    client.business.com                 client.university.edu
    ( BUSINESS.REALM )                   ( UNIVERSITY.REALM )


                       federated_root.business.com
                             /                \
                            /                  \
               root.business.com             root.university.edu
               ( BUSINESS.REALM )            ( UNIVERSITY.REALM )
                  /        \                           |
                 /          \                          |
   server.business.com   server.business.eng.com   server.university.edu
   ( BUSINESS.REALM )    ( BUSINESS_ENG.REALM )    ( UNIVERSITY.REALM )


             Figure 6: A federation of multiple NFSv4 Domains

   The two NFSv4 Domains, business.com and university.edu are joined
   into a federated file system via junctions [FEDFS-PROT] (e.g.
   referrals) denoted by dashed lines which join a 'leaf' of
   federated_root.business.com's pseudo file system with the pseudo file
   system root of either root.business.com or root.university.edu.  The
   root fileset [FEDFS-PROT] is the top-level fileset of the federation
   namespace, and is hosted by the NFSv4 Domain business.com on the file
   server federated_root.business.com.  Both root.business.com and
   root.university.edu export their pseudo file systems with Kerberos



Adamson & Coffman        Expires January 4, 2010               [Page 15]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   security only, requiring users to present appropriate Kerberos
   credentials to traverse the namespace.  The pseudo file system on
   federated_root.business.com is exported with AUTH_NULL to allow
   universal access.

   The BUSINESS.REALM realm has a cross-realm trust relationship with
   UNIVERSITY.REALM which means that Bob and Alice can use their
   BUSINESS.REALM Kerberos credentials to gain access to
   UNIVERSITY.REALM protected resources.

   The client machines mount federated_root.business.com's pseudo file
   system root, and users traverse the junctions as their Kerberos
   credentials and uidNumber translations allow.

   Note that the 'trick' of stripping the @REALM or the @dns_domain
   portions of names that was used in the examples in Section 2.3.3 and
   Section 3.4 will not work here because the business.com NFSv4 Domain
   and the university.edu NFSv4 Domain do not share a name service.

4.1.  Name Translation Requirements in the Federated FS

   This section looks at the NFSv4 ACL name and GSS principal
   translations required for a user in the the business.com NFSv4 Domain
   to traverse the federated name space (Figure 6) and access a file in
   the university.edu NFSv4 Domain.

   Once again, the POSIX setacl operation example is used.
   Specifically, the translations required for the user bob on
   client.business.com to set an NFSv4 ACL for alice@business.com across
   the federated name space (Figure 6) on a file foo exported by
   server@university.edu are examined.

   Bob logs into client.business.edu and performs the following POSIX
   setacl command.

     % setacl -m u:alice:r /nfsv4/root_university/server_university/foo

      Figure 7: A POSIX setacl granting alice read access to file foo

   The POSIX interface on client.business.com translates "alice" into
   the local uidNumber.

   Step 1: On client.business.com (POSIX interface)

           alice -> uidNumber 1002

                                 Figure 8




Adamson & Coffman        Expires January 4, 2010               [Page 16]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   Prior to performing the setacl, the NFS client will need to parse the
   path to the target file on server.university.edu.  Details on the
   translations (if any) involved follow.

   The federated root is mounted at /nfsv4 on client.business.com.
   Since this is exported with AUTH_NULL access is granted and there are
   no translations.

   The junction on federated_root.business.com to root.university.edu is
   (pseudo file system root)/root_university.  Since this is exported
   Kerberos only, a Kerberos GSS context will need to be established
   between Bob and root.university.edu, and root.university.edu will
   need to translate a uidNumber for Bob's Kerberos principal.

   Step 2: On root.university.edu (GSS interface)

           bob@BUSINESS.REALM -> uidNumber ????

   Here is the first problem, which is resolved in Section 5.1, Bob does
   not have an assigned uidNumber in the university.edu NFSv4 Domain
   name service used by root.university.edu.

   The problem of no uidNumber translation for bob@BUSINESS.REALM is
   repeated for the next path elements.  The junction on
   root.business.com to server.university.edu is (pseudo file system
   root)/server_university.  This is also exported Kerberos only, and a
   Kerberos GSS context will need to be established between Bob and
   server.university.edu which will fail on the uidNumber translation.

   Step 3: On server.university.edu (GSS interface)

           bob@BUSINESS.REALM -> uidNumber ????

   This fails for the same reason as Step 2.

   The NFSv4 client needs the uidNumber from the setacl POSIX interface
   in Figure 8 translated into an NFS4 ACL name required for the SETATTR
   operation which peforms the setacl on the server.

   Step 4: On client.business.com (NFSv4 interface).  The @business.com
   portion of the name is added after the uidNumber translation.

           uidNumber 1002 -> alice -> alice@business.com

   The server.university.edu receives the SETATTR and needs to translate
   the NFS4 ACL name alice@business.com into a uidNumber to be used to
   set the ACL on the file system object.




Adamson & Coffman        Expires January 4, 2010               [Page 17]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   Step 5: On server.university.edu (NFSv4 interface)

           alice@business.com -> uidNumber ????

   Here is another problem. alice@business.com does not have an assigned
   uidNumber in the university.edu NFSv4 Domain name service.  This is
   resolved in Section 5.1












































Adamson & Coffman        Expires January 4, 2010               [Page 18]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


5.  New LDAP Attributes and Object Class

   The NFSv4 name service needs the following capabilities in order to
   be configured to allow foreign users to access files.  The LDAP
   attributes presented here address these needs.

   o  Each foreign user needs an LDAP entry with a uidNumber in the
      local NFSv4 Domain.

   o  Each foreign user's NFSv4 name (user@dns_domain) needs to be
      associated with their uidNumber in the local NFSv4 Domain.

   o  Each GSS principal a foreign user is allowed to authenticate as
      needs to be associated with their uidNumber in the local NFSv4
      Domain.

   These LDAP attributes and object class were developed at the Center
   for Information Technology Integration at the University of Michigan
   and have been experimented with in the Linux idmap daemon 'umich_ldap
   translation' method since 2005.

   A new attribute is defined to hold the NFSv4 ACL name.  It is formed
   by using the posixAccount uid for the 'user' portion, and the unique
   NFSv4 Domain name for the 'dns_domain' portion.

   It is not proposed that the posixAccount uid be replaced with a uid@
   nfsv4_domain syntax in order to separate local and NFSv4 access.  The
   user@dns_domain syntax only has meaning for the NFSv4 file systems
   and would be inappropriate for local POSIX translation.

   The NFSv4Name attribute provides a one-to-one correspondence between
   the unique NFSv4 Domain user@dns_domain NFSv4 ACL name and the
   uidNumber.

   attributetype ( 1.3.6.1.4.1.250.10.5
           NAME ( 'NFSv4Name')
           DESC 'NFS version 4 Name'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
           SINGLE-VALUE)

   A second new attribute is defined to hold the per security mechanism
   GSS principal.  A Kerberos GSSAuthName would have the principal@REALM
   syntax.  An X.509 GSSAuthName would hold the Distinguished Name with
   a syntax such as "/C= /ST= /O= /OU= /CN= /USERID=/Email=".






Adamson & Coffman        Expires January 4, 2010               [Page 19]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   This attribute provides a many-to-on correspondence between each GSS
   principal and the uidNumber.

   attributetype ( 1.3.6.1.4.1.250.10.6
           NAME ( 'GSSAuthName')
           DESC 'RPCSEC GSS authenticated user name'
           EQUALITY caseIgnoreIA5Match
           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

   The NFSv4Person class holds the minimal information required for
   NFSv4access.


   objectclass ( 1.3.6.1.4.1.250.10.7 NAME 'NFSv4Person'
           DESC 'NFS version4 person from remote NFSv4 Domain'
           SUP top AUXILIARY
           MUST ( uidNumber $ gidNumber $ NFSv4Name )
           MAY ( cn $ GSSAuthName $ description) )


   The NFSv4Person object class can be added to the LDAP schema, and
   then used with or without the posixAccount object class.  If the
   administrator wants the local or remote user to have local machine
   access, posixAccount attributes are used along with the NFSv4Name and
   GSSAuthName attributes.  If only NFSv4 access is desired, the
   administrator does not use the posixAccount attributes, only the
   NFS4Person class is used.

   The following sections demonstrate the use of the NFSv4Name and
   GSSAuthName attributes.

5.1.  Multiple NFSv4 Domain Translation Solution

   In this section the translation problems demonstrated in the
   federated name translation example (Section 4.1) are solved using the
   new LDAP attributes and classes.

   Bob and Alice have LDAP entries in the business.com NFSv4 Domain
   (Figure 2).  To get access to files in the university.edu NFSv4
   Domain, they need a uidNumber assigned in the university.edu NFSv4
   Domain name service.

   The university.edu NFSv4 Domain administrators want to give
   alice@business.com and bob@business.com access to files in their
   domain, but they do not wish to give these new foreign users access
   to local machines.  So they create new LDAP entries in the
   university.edu NFSv4 Domains LDAP name service without using the
   posixAccount object class.



Adamson & Coffman        Expires January 4, 2010               [Page 20]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   Here is a typical LDAP name service entries using the NFSv4Person
   object class.

   # bob, People, university, edu
       dn: uid=bob,ou=People,dc=university,dc=edu
       objectClass: top
       objectClass: person
       objectClass: organizationalPerson
       objectClass: inetorgperson
       objectClass: NFSv4Person
       cn: Bob B. Bar
       sn: Bar
       uidNumber: 5989
       gidNumber: 100
       displayName: Bob B. Bar
       NFSv4Name: bob@business.com
       GSSAuthName: bob@BUSINESS.REALM

   # alice, People, university, edu
       dn: uid=alice,ou=People,dc=university,dc=edu
       objectClass: top
       objectClass: person
       objectClass: organizationalPerson
       objectClass: inetorgperson
       objectClass: NFSv4Person
       cn: Alice A. Answer
       sn: Answer
       uidNumber: 5990
       gidNumber: 100
       displayName: Alice A. Answer
       NFSv4Name: alice@business.com
       GSSAuthName: alice@BUSINESS.REALM

                                 Figure 9

   The NFSv4Person objectClass is added to the university.edu NFSv4
   Domain LDAP name service schema which allows the addition of the
   NFSv4Name and GSSAuthName attributes to name service entries for the
   fictional foreign users bob@business.com and alice@business.com.

   The uidNumber, gidNumber, NFSv4Name, and GSSAuthName attributes all
   come from the NFSv4Person objectClass.  Note that since the
   posixAccount object class is not used for these users, there is no
   posixAccount uid attribute.

   The association of the GSSAuthName attribute and the uidNumber
   attribute in the Figure 9 LDAP entry for Bob Barr solves the
   translation problem in Step 2 and Step 3 (Section 4.1).



Adamson & Coffman        Expires January 4, 2010               [Page 21]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


           bob@BUSINESS.REALM -> uidNumber 5989

   With the appropriate LDAP query, bob@BUSINESS.REALM can now be
   translated to the uidNumber 5989 in the university.edu NFSv4 Domain.

   The association of the NFSv4Name attribute and the uidNumber
   attribute in the Figure 9 LDAP entry for Alice Answer solves the
   translation problem in Step 5 (Section 4.1).

           alice@business.com -> uidNumber 5990

   With the appropriate LDAP query, alice@business.com can now be
   translated to the uidNumber 5990 in the university.edu NFSv4 Domain.

5.2.  Local NFSv4 Domain LDAP Attribute Use

   Adding the NFSv4Person objectClass to the LDAP schema also has uses
   in the translations within an NFSv4 Domain.

   The use of the GSSAuthName attribute lifts both the restriction of
   using the posixAccount uid for the Kerberos principal and the
   requirement of stripping the @REALM portion of the Kerberos
   principal.

   The use of the NFSv4Name attribute removes the need to strip or add
   the @dns_domain portion of NFSv4 ACL names as they can be directly
   mapped to uidNumbers on both the client and the server.
























Adamson & Coffman        Expires January 4, 2010               [Page 22]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


6.  Summary

   The proposed LDAP attributes and object classes enable NFSv4 name and
   GSS principal translation and therefore NFSv4 federated file system
   access in the following ways.

   o  For local users, the NFSv4Name attribute removes the need for pre
      and post translation processing of the posixAccount uid (login
      name).

   o  For local users, the GSSAuthName attribute removes the need to
      synchronize a user's posixAccount uid with some portion of a GSS
      principal, as well as the pre and post translation processing.

   o  For foreign users the NFSv4Name attribute enables translation of
      an NFSv4 ACL name to a local uidNumber.

   o  For foreign users the GSSAuthName attribute enables translation of
      an GSS principal to a local uidNumber.

   o  The NFSv4Person object class allows the NFSv4Name and GSSAuthName
      attributes to be associated with a user's LDAP entry posixAccount
      attribute set.

   o  The NFSv4Person object class allows the NFSv4Name and GSSAuthName
      attributes to be associated with a user's LDAP entry uidNumber
      without enabling local machine access for that user.

   o  For all users, the removal of the NFSv4Name attribute from an LDAP
      entry removes access to the NFSv4 Domain, and just from the NFSv4
      Doamin.  For users with a posixAccount, local machine access will
      not be affected.



















Adamson & Coffman        Expires January 4, 2010               [Page 23]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


7.  Security Considerations

   None.
















































Adamson & Coffman        Expires January 4, 2010               [Page 24]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


8.  References

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

   [NFSv41]   Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4
              Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (Work
              in Progress), December 2008.

   [FEDFS-PROT]
              Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
              Naik, "NSDB Protocol for Federated Filesystems (Work in
              Progress)", February 2009.

   [FEDFS-REQTS]
              Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M.
              Naik, "Requirements for Federated File Systems (Work in
              Progress)", April 2009.

   [LDAP]     Wahl, M., Howes, T., Ellard, D., and S. Kille,
              "Lightweight Directory Access Protocol (v3)", RFC 2251,
              December 1997.

   [RFC2307]  Howard, L., "An Approach for Using LDAP as a Network
              Information Service", RFC 2307 (Experimental), March 1998.

   [RFC2743]  Linn, J., "Generic Security Service Application Program
              Interface", Version 2 Update 1, RFC 2743, January 2000.

   [RFC1094]  Nowicki, B., "NFS: Network File System Protocol
              Specification", RFC 1094, March 1989.

   [AFS_ACM]  Morris, J., Satyanarayanan, M., Conner, M., Rosenthal, D.,
              and F. Smith, "ANDREW: A Distributed Personal Computing
              Environment  (# 4)", Communications of the ACM Vol. 29,
              No. 3, March 1986.

   [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
              Specification", RFC 2203, September 1997.

   [RFC1813]  Callaghan, B., Pawlowski, P., and P. Staubach, "NFS
              Version 3 Protocol Specification", RFC 1813, June 1995.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.




Adamson & Coffman        Expires January 4, 2010               [Page 25]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


   [RFC1831]  Srinivasan, R., "RPC: Remote Procedure Call Protocol
              Specification Version 2", RFC 1831, August 1995.

   [NIS]      Sun Microsystems, "System and Network Administration",
              March 1990.

   [AD-LDAP]  Microsoft Corporation, "Active Directory LDAP Compliance",
              October 2003.

   [RFC2119]  "Normative References", RFC 2119.









































Adamson & Coffman        Expires January 4, 2010               [Page 26]


Internet-Draft          NFSv4 Multi-Domain Access              July 2009


Authors' Addresses

   William A. (Andy) Adamson
   NetApp

   Email: andros@netapp.com


   Kevin Coffman
   CITI, University of Michigan

   Email: kwc@umich.edu







































Adamson & Coffman        Expires January 4, 2010               [Page 27]


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