idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) == Outdated reference: A later version (-06) exists of draft-cel-nfsv4-federated-fs-security-addendum-05 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 Working Group W. Adamson 3 Internet-Draft NetApp 4 Intended status: Standards Track N. Williams 5 Expires: December 31, 2016 Cryptonector 6 June 29, 2016 8 Multiple NFSv4 Domain Namespace Deployment Guidelines 9 draft-ietf-nfsv4-multi-domain-fs-reqs-09 11 Abstract 13 This document provides guidance on the deployment of the NFSv4 14 protocols for the construction of an NFSv4 file name space in 15 environments with multiple NFSv4 Domains. To participate in an NFSv4 16 mulit-domain file name space, the server must offer a mulit-domain 17 capable file system and support RPCSEC_GSS for user authentication. 18 In most instances, the server must also support identity mapping 19 services. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 31, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Federated File System . . . . . . . . . . . . . . . . . . . . 5 64 4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5 66 4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6 67 5. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 7 68 5.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7 69 5.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 8 70 5.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 8 71 6. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 9 72 6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 9 73 6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9 74 6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 10 75 6.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10 76 6.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 11 77 7. Resolving Multi-domain Authorization Information . . . . . . 11 78 8. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], NFSv4.2 90 [I-D.NFSv4.2] introduce the concept of an NFS Domain. An NFSv4 91 Domain is defined as a set of users and groups using the NFSv4 92 name@domain user and group identification syntax with the same 93 specified @domain. 95 Previous versions of the NFS protocol, such as NFSv3 [RFC1813], use 96 the UNIX-centric user identification mechanism of numeric user and 97 group ID for the uid3 and gid3 [RFC1813] file attributes and for 98 identity in the ONCRPC [RFC5531] authsys_parms AUTH_SYS credential. 99 Section 6.1 of [RFC2624] notes that the use of UNIX-centric numeric 100 IDs limits the scale of NFS to large local work groups. UNIX-centric 101 numeric IDs are not unique across NFSv3 deployments and so are not 102 designed for internet scaling achieved by taking into account 103 multiple naming domains and multiple naming mechanisms (see 104 Section 6.2). The NFSv4 Domain's use of the name@domain syntax 105 provides this internet scaling by allowing servers and clients to 106 translate between the external name@domain string representation to a 107 local or internal numeric (or other identifier) representation which 108 matches internal implementation needs. 110 Multi-domain deployments require support for unique identities across 111 the deployment's name services and security services, as well as the 112 use of multi-domain file systems capable of the on-disk 113 representation of identities belonging to multiple NFSv4 Domains. 114 The name@domain identity syntax can provide unique identities and so 115 enables the NFSv4 multi-domain file name space. 117 Unlike previous versions of NFS, the NFSv4 protocols define a 118 referral mechanism (Section 8.4.3 [RFC7530]) that allows a single 119 server or a set of servers to present a multi-server namespace that 120 encompasses file systems located on multiple servers. This enables 121 the establishment of site-wide, organization-wide, or even a truly 122 global file name space. 124 The NFSv4 protocols name@domain identity syntax and referral 125 mechanism along with the use of RPCSEC_GSS security mechanisms 126 enables the construction of an NFSv4 multi-domain file name space. 128 This document provides guidance on the deployment of the NFSv4 129 protocols for the construction of an NFSv4 file name space in 130 environments with multiple NFSv4 Domains. To participate in an NFSv4 131 mulit-domain file name space, the server must offer a mulit-domain 132 capable file system and support RPCSEC_GSS [RFC2203] for user 133 authentication. In most instances, the server must also support 134 identity mapping services. 136 2. Terminology 138 NFSv4 Domain: A set of users and groups using the NFSv4 139 name@domain user and group identification syntax with the same 140 specified @domain. 142 Stand-alone NFSv4 Domain: A deployment of the NFSv4 protocols and 143 NFSv4 file name space in an environment with a single NFSv4 144 Domain. 146 Local representation of identity: A representation of a user or a 147 group of users capable of being stored persistently within a file 148 system. Typically such representations are identical to the form 149 in which users and groups are represented within internal server 150 API's. Examples are numeric id's such as a uidNumber (UID), 151 gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID) 152 [CIFS]. In some case the identifier space for user and groups 153 overlap, requiring anyone using such an id to know a priori 154 whether the identifier is for a user or a group. 156 Unique identity: An on-the-wire form of identity that is unique 157 across an NFSv4 multi-domain name space that can be mapped to a 158 local representation. For example, the NFSv4 name@domain or the 159 Kerberos principal@REALM. 161 Multi-domain: In this document, the term "multi-domain" always 162 refers to multiple NFSv4 Domains. 164 Multi-domain capable filesystem: A local filesystem that uses a 165 local ID form that can represent NFSv4 identities from multiple 166 domains. 168 Principal: an RPCSEC_GSS [RFC2203] authentication identity. 169 Usually, but not always, a user; rarely, if ever, a group; 170 sometimes a host or server. 172 Authorization Context: A collection of information about a 173 principal such as username, userID, group membership, etcetera 174 used in authorization decisions. 176 Stringified UID or GID: NFSv4 owner and group strings that consist 177 of decimal numeric values with no leading zeros, and which do not 178 contain an '@' sign. See Section 5.9 [RFC5661]. 180 Name Service: Facilities that provides the mapping between {NFSv4 181 Domain, group or user name} and the appropriate local 182 representation of identity. Also includes facilities providing 183 mapping between a security principal and local representation of 184 identity. Can be applied to unique identities or principals from 185 within local and remote domains. Often provided by a Directory 186 Service such as LDAP. 188 Name Service Switch (nsswitch): a facility in provides a variety 189 of sources for common configuration databases and name resolution 190 mechanisms. 192 FedFS: The Federated File System (FedFS) [RFC5716] describes the 193 requirements and administrative tools to construct a uniform NFSv4 194 file server based name space that is capable of spanning a whole 195 enterprise and that is easy to manage. 197 Domain: This term is used in multiple contexts where it has 198 different meanings. Definitions of "nfsv4 domain" and "multi- 199 domain" have already appeared above in Section 1. Below we 200 provide other specific definitions used this document. 202 DNS domain: a set of computers, services, or any internet 203 resource identified by an DNS domain name [RFC1034]. 205 Security realm or domain: a set of configured security 206 providers, users, groups, security roles, and security policies 207 running a single security protocol and administered by a single 208 entity, for example a Kerberos realm. 210 FedFS domain: A file name space that can cross multiple shares 211 on multiple file servers using file-access protocols such as 212 NFSv4. A FedFS domain is typically a single administrative 213 entity, and has a name that is similar to a DNS domain name. 214 Also known as a Federation. 216 Administrative domain: a set of users, groups, computers, and 217 services administered by a single entity. Can include multiple 218 DNS domains, NFSv4 domains, security domains, and FedFS 219 domains. 221 3. Federated File System 223 The FedFS is the standardized method of constructing and 224 administrating an enterprise-wide NFSv4 filesystem, and so is 225 referenced in this document. The issues with multi-domain 226 deployments described in this document apply to all NFSv4 multi- 227 domain deployments, whether they are run as a FedFS or not. 229 Stand-alone NFSv4 Domain deployments can be run in many ways. While 230 a FedFS can be run within all stand-alone NFSv4 domain configurations 231 some of these configurations (Section 5) are not compatible with 232 joining a multi-domain FedFS name space. 234 4. Identity Mapping 236 4.1. NFSv4 Server Identity Mapping 238 NFSv4 servers deal with two kinds of identities: authentication 239 identities (referred to here as "principals") and authorization 240 identities ("users" and "groups" of users). NFSv4 supports multiple 241 authentication methods, each authenticating an "initiator principal" 242 (typically representing a user) to an "acceptor principal" (always 243 corresponding to the NFSv4 server). NFSv4 does not prescribe how to 244 represent authorization identities on file systems. All file access 245 decisions constitute "authorization" and are made by NFSv4 servers 246 using authorization context information and file metadata related to 247 authorization, such as a file's access control list (ACL). 249 NFSv4 servers may be required to perform two kinds of mappings 250 depending upon what authentication and authorization information is 251 sent on the wire, and what is stored in the exported file system. 252 For example, if an authentication identity such as a Kerberos 253 principal is sent with authorization information such a "privilege 254 attribute certificate" (PAC) [PAC] then mapping is not required (see 255 Section 7). 257 1. Auth-to-authz: A mapping between the authentication identity and 258 the authorization context information. 260 2. Wire-to-disk: A mapping between the on-the-wire authorization 261 identity representation and the on-disk authorization identity 262 representation. 264 A Name Service such as LDAP often provides these mappings. 266 Many aspects of these mappings are entirely implementation specific, 267 but some require multi-domain capable name resolution and security 268 services in order to interoperate in a multi-domain environment. 270 NFSv4 servers use these mappings for: 272 1. File access: Both the auth-to-authz and the wire-to-disk mappings 273 may be required for file access decisions. 275 2. Meta-data setting and listing: The auth-to-authz mapping is 276 usually required to service file metadata setting or listing 277 requests such as ACL or UNIX permission setting or listing. This 278 mapping is needed because NFSv4 messages use identity 279 representations of the form name@domain which normally differs 280 from the server's local representation of identity. 282 4.2. NFSv4 Client Identity Mapping 284 A client setting the owner or group attribute will often need access 285 to identity mapping services. This is because API's within the 286 client will specify the identity in a local form (e.g UNIX using a 287 UID/GID) so that when stringified id's cannot be used, the id must be 288 converted to a unique identity form. 290 A client obtaining values for the owner or group attributes will 291 similarly need access to identity mapping services. This is because 292 the client API will need these attributes in a local form, as above. 293 As a result name services need to be available to convert the unique 294 identity to a local form. 296 Note that each of these situations arises because client-side API's 297 require a particular local identity representation. The need for 298 mapping services would not arise if the clients could use the unique 299 representation of identity directly. 301 5. Stand-alone NFSv4 Domain Deployment Examples 303 In order to service as many environments as possible, the NFSv4 304 protocol is designed to allow administrators freedom to configure 305 their NFSv4 domains as they please. 307 Stand-alone NFSv4 Domains can be run in many ways. Here we list some 308 stand-alone NFSv4 Domain deployment examples focusing on the NFSv4 309 server's use of name service mappings (Section 4.1) and security 310 services deployments to demonstrate the need for some multiple NFSv4 311 Domain constraints to the NFSv4 protocol, name service configuration, 312 and security service choices. 314 Typically, stand-alone NFSv4 Domain deployments only provide support 315 for identities belonging to a single NFSv4 Domain. Because all on- 316 disk identities participating in a stand-alone NFSv4 Domain belong to 317 the same NFSv4 Domain, stand-alone NFSv4 Domain deployments have no 318 requirement for exporting multi-domain capable file systems. 320 These examples are for a NFSv4 server exporting a POSIX UID/GID based 321 file system, a typical deployment. These examples are listed in the 322 order of increasing NFSv4 administrative complexity. 324 5.1. AUTH_SYS with Stringified UID/GID 326 This example is the closest NFSv4 gets to being run as NFSv3 as there 327 is no need for a name service for file metadata listing. 329 File access: The AUTH_SYS RPC credential [RFC1831] provides a UID as 330 the authentication identity, and a list of GIDs as authorization 331 context information. File access decisions require no name service 332 interaction as the on-the-wire and on-disk representation are the 333 same and the auth-to-authz UID and GID authorization context 334 information is provided in the RPC credential. 336 Meta-data setting and listing: When the NFSv4 clients and servers 337 implement a stringified UID/GID scheme, where a stringified UID or 338 GID is used for the NFSv4 name@domain on-the-wire identity, then a 339 name service is not required for file metadata listing as the UID or 340 GID can be constructed from the stringified form on the fly by the 341 server. 343 5.2. AUTH_SYS with name@domain 345 Another possibility is to express identity using the form 346 'name@domain', rather than using a stringified UID/GID scheme for 347 file metadata setting and listing. 349 File access: This is the same as in Section 5.1. 351 Meta-data setting and listing: The NFSv4 server will need to use a 352 name service for the wire-to-disk mappings to map between the on-the- 353 wire name@domain syntax and the on-disk UID/GID representation. 354 Often, the NFSv4 server will use the nsswitch interface for these 355 mappings. A typical use of the nsswitch name service interface uses 356 no domain component, just the UID attribute [RFC2307] (or login name) 357 as the name component. This is no issue in a stand-alone NFSv4 358 domain deployment as the NFSv4 Domain is known to the NFSv4 server 359 and can combined with the login name to form the name@domain syntax 360 after the return of the name service call. 362 5.3. RPCSEC_GSS with name@domain 364 RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely 365 authenticate users to servers. The most common mechanism is Kerberos 366 [RFC4121]. 368 This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS 369 security mechanism. 371 File Access: The forms of GSS principal names are mechanism-specific. 372 For Kerberos these are of the form principal@REALM. Sometimes 373 authorization context information is delivered with authentication, 374 but this cannot be counted on. Authorization context information not 375 delivered with authentication has timely update considerations (i.e., 376 generally it's not possible to get a timely update). File access 377 decisions therefore require a wire-to-disk mapping of the GSS 378 principal to a UID, and an auth-to-authz mapping to obtain the list 379 of GIDs as the authorization context. 381 Implementations must never blindly drop a Kerberos REALM name from a 382 Kerberos principal name to obtain a POSIX username, but they may be 383 configured to do so for specific REALMs. 385 Meta-data setting and listing: This is the same as in Section 5.2. 387 6. Multi-domain Constraints to the NFSv4 Protocol 389 Joining NFSv4 Domains under a single file name space imposes slightly 390 on the NFSv4 administration freedom. Here we describe the required 391 constraints. 393 6.1. Name@domain Constraints 395 NFSv4 uses a syntax of the form "name@domain" as the on-the-wire 396 representation of the "who" field of an NFSv4 access control entry 397 (ACE) for users and groups. This design provides a level of 398 indirection that allows NFSv4 clients and servers with different 399 internal representations of authorization identity to interoperate 400 even when referring to authorization identities from different NFSv4 401 Domains. 403 Multi-domain capable sites need to meet the following requirements in 404 order to ensure that NFSv4 clients and servers can map between 405 name@domain and internal representations reliably. While some of 406 these constraints are basic assumptions in NFSv4.0 [RFC7530] and 407 NFSv4.1 [RFC5661], they need to be clearly stated for the multi- 408 domain case. 410 o The NFSv4 Domain portion of name@domain MUST be unique within the 411 multi-domain name space. See [RFC5661] section 5.9 "Interpreting 412 owner and owner_group" for a discussion on NFSv4 Domain 413 configuration. 415 o The name portion of name@domain MUST be unique within the 416 specified NFSv4 Domain. 418 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 419 in a multi-domain deployment. This means that multi-domain-capable 420 servers MUST reject requests that use stringified UID/GIDs. 422 6.1.1. NFSv4 Domain and DNS Services 424 Here we address the relationship between NFSv4 Domain name and DNS 425 domain name in a multi-domain deployment. 427 The definition of an NFSv4 Domain name, the @domain portion of the 428 name@domain syntax, needs clarification to work in a multi-domain 429 file system name space. Section 5.9 [RFC5661] loosely defines the 430 NFSv4 Domain name as a DNS domain name. This loose definition for 431 the NFSv4 Domain name is a good one, as DNS domain names are globally 432 unique. As noted above in Section 6.1, any choice of NFSv4 Domain 433 name can work within a stand-alone NFSv4 Domain deployment whereas 434 the NFSv4 Domain name is required to be unique across a multi-domain 435 deployment. 437 A typical configuration is that there is a single NFSv4 Domain that 438 is served by a single DNS domain. In this case the NFSv4 Domain name 439 can be the same as the DNS domain name. 441 An NFSv4 Domain can span multiple DNS domains. In this case, one of 442 the DNS domain names can be chosen as the NFSv4 Domain name. 444 Multiple NFSv4 Domains can also share a DNS domain. In this case, 445 only one of the NFSv4 Domains can use the DNS domain name, the other 446 NFSv4 Domains must choose another unique NFSv4 Domain name. 448 6.1.2. NFSv4 Domain and Name Services 450 As noted above in Section 6.1, each name@domain is unique across the 451 multi-domain name space and maps, on each NFSv4 server, to the local 452 representation of identity used by that server. Typically, this 453 representation consists of an indication of the particular domain 454 combined with the UID/GID corresponding to the name component. To 455 support such an arrangement, each NFSv4 Domain needs to have a single 456 name resolution service capable of converting the names defined 457 within the domain to the corresponding local representation. 459 6.2. RPC Security Constraints 461 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 463 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 464 (This requirement to implement is not a requirement 465 to use.) Other flavors, such as AUTH_NONE, 466 and AUTH_SYS, MAY be implemented as well. 468 The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used 469 in a multi-domain name space is REQUIRED to employ a method of cross 470 NFSv4 Domain trust so that a principal from a security service in one 471 NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a 472 security service with the same security mechanism. Kerberos is an 473 example of such a security service. 475 The AUTH_NONE [RFC1831] security flavor can be useful in a multi- 476 domain deployment to grant universal read-only access to public data 477 without any credentials. 479 The AUTH_SYS security flavor [RFC1831] uses a host-based 480 authentication model where the weakly authenticated host (the NFSv4 481 client) asserts the user's authorization identities using small 482 integers, uidNumber, and gidNumber [RFC2307], as user and group 483 identity representations. Because this authorization ID 484 representation has no domain component, AUTH_SYS can only be used in 485 a name space where all NFSv4 clients and servers share an [RFC2307] 486 name service. A shared name service is required because uidNumbers 487 and gidNumbers are passed in the RPC credential; there is no 488 negotiation of name space in AUTH_SYS. Collisions can occur if 489 multiple name services are used, so AUTH_SYS MUST NOT be used in a 490 multi-domain file system deployment. 492 6.2.1. NFSv4 Domain and Security Services 494 As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4 495 Domain security services are RPCSEC_GSS based with the Kerberos 5 496 security mechanism being the most commonly (and as of this writing, 497 the only) deployed service. 499 A single Kerberos 5 security service per NFSv4 Domain with the upper 500 case NFSv4 Domain name as the Kerberos 5 REALM name is a common 501 deployment. 503 Multiple security services per NFSv4 Domain is allowed, and brings 504 the issue of mapping multiple Kerberos 5 principal@REALMs to the same 505 local ID. Methods of achieving this are beyond the scope of this 506 document. 508 7. Resolving Multi-domain Authorization Information 510 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 511 server, after authenticating the principal, the server must obtain in 512 a secure manner the principal's authorization context information 513 from an authoritative source such as the name service in the 514 principal's NFSv4 Domain. 516 In the stand-alone NFSv4 Domain case where the principal is seeking 517 access to files on an NFSv4 server in the principal's home NFSv4 518 Domain, the server administrator has knowledge of the local policies 519 and methods for obtaining the principal's authorization information 520 and the mappings to local representation of identity from an 521 authoritative source. E.g., the administrator can configure secure 522 access to the local NFSv4 domain name service. 524 In the multi-domain case where a principal is seeking access to files 525 on an NFSv4 server not in the principal's home NFSv4 Domain, the 526 NFSv4 server may be required to contact the remote name service in 527 the principals NFSv4 Domain. In this case there is no assumption of: 529 o Remote name service configuration knowledge. 531 o The syntax of the remote authorization context information 532 presented to the NFSv4 server by the remote name service for 533 mapping to a local representation. 535 There are several methods the NFSv4 server can use to obtain the 536 NFSv4 Domain authoritative authorization information for a remote 537 principal from an authoritative source. While any detail is beyond 538 the scope of this document, some general methods are listed here. 540 1. A mechanism specific GSS-API authorization payload containing 541 credential authorization data such as a "privilege attribute 542 certificate" (PAC) [PAC] or a "principal authentication data" 543 (PAD) [I-D.sorce-krbwg-general-pac]. This is the preferred 544 method as the payload is delivered as part of GSS-API 545 authentication, avoids requiring any knowledge of the remote 546 authoritative service configuration, and its syntax is well 547 known. 549 2. When there is a security agreement between the local and remote 550 NFSv4 Domain name services plus regular update data feeds, the 551 NFSv4 server local NFSv4 Domain name service can be authoritative 552 for principal's in the remote NFSv4 Domain. In this case, the 553 NFSv4 server makes a query to it's local NFSv4 Domain name 554 service just as it does when servicing a local domain principal. 555 While this requires detailed knowledge of the remote NFSv4 556 Domains name service for the update data feeds, the authorization 557 context information presented to the NFSv4 server is in the same 558 form as a query for a local principal. 560 3. An authenticated direct query from the NFSv4 server to the 561 principal's NFSv4 Domain authoritative name service. This 562 requires the NFSv4 server to have detailed knowledge of the 563 remote NFSv4 Domain's authoritative name service and detailed 564 knowledge of the syntax of the resultant authorization context 565 information. 567 8. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 569 Revisiting the stand-alone (Section 5) NFSv4 Domain deployment 570 examples, we note that due to the use of AUTH_SYS, neither 571 Section 5.1 nor Section 5.2 configurations are suitable for multi- 572 domain deployments. 574 The Section 5.3 configuration example can participate in a multi- 575 domain name space deployment if: 577 o The NFSv4 Domain name is unique across the name space. 579 o All exported file systems are multi-domain capable. 581 o A secure method is used to resolve remote NFSv4 Domain principals 582 authorization information from an authoritative source. 584 9. Security Considerations 586 This RFC discusses security throughout. All the security 587 considerations of the relevant protocols, such as NFSv4.0 [RFC7530], 588 NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP 589 [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace 590 DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS 591 Security Addendum [I-D.lever-fedfs-security-addendum] apply. 593 Authentication and authorization across administrative domains 594 presents security considerations, most of which are treated 595 elsewhere, but we repeat some of them here: 597 o latency in propagation of revocation of authentication credentials 599 o latency in propagation of revocation of authorizations 601 o latency in propagation of granting of authorizations 603 o complications in establishing a foreign domain's users' complete 604 authorization context: only parts may be available to servers 606 o privacy considerations in a federated environment 608 Most of these are security considerations of the mechanisms used to 609 authenticate users to servers and servers to users, and of the 610 mechanisms used to evaluate a user's authorization context. 612 Implementors may be tempted to assume that realm (or "issuer") and 613 NFSv4 Domain are roughly the same thing, but they are not. 614 Configuration and/or lookup protocols (such as LDAP) and associated 615 schemas are generally required in order to evaluate a user 616 principal's authorization context (see Section 7). In the simplest 617 scheme a server has access to a database mapping all known principal 618 names to usernames whose authorization context can be evaluated using 619 operating system interfaces that deal in usernames rather than 620 principal names. 622 Note that clients may also need to evaluate a server's authorization 623 context when using labeled security [I-D.NFSv4.2] (e.g., is the 624 server authorized to handle content at a given security level, for 625 the given client process subject label). 627 When the server accepts user credential from more than one realm, it 628 is important to remember that the server must verify that the client 629 it is talking to has a credential for the name the client has 630 presented the server, and that that credential's issuer (i.e., its 631 realm) is allowed to issue it. Usually the service principal realm 632 authorization function is implemented by the security mechanism, but 633 the implementor should check this. 635 10. IANA Considerations 637 There are no IANA considerations in this document. 639 11. References 641 11.1. Normative References 643 [I-D.NFSv4.2] 644 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 645 nfsv4-minorversion2-36 (Work In Progress), April 2015. 647 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 648 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 649 . 651 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 652 Version 3 Protocol Specification", RFC 1813, DOI 10.17487/ 653 RFC1813, June 1995, 654 . 656 [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol 657 Specification Version 2", RFC 1831, DOI 10.17487/RFC1831, 658 August 1995, . 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 662 RFC2119, March 1997, 663 . 665 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 666 Specification", RFC 2203, DOI 10.17487/RFC2203, September 667 1997, . 669 [RFC2743] Linn, J., "Generic Security Service Application Program 670 Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ 671 RFC2743, January 2000, 672 . 674 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 675 Version 5 Generic Security Service Application Program 676 Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 677 10.17487/RFC4121, July 2005, 678 . 680 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 681 Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/ 682 RFC4511, June 2006, 683 . 685 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 686 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 687 May 2009, . 689 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 690 "Network File System (NFS) Version 4 Minor Version 1 691 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 692 . 694 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 695 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 696 March 2015, . 698 11.2. Informative References 700 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 701 Internet File System (CIFS) Protocol", January 2013. 703 [I-D.lever-fedfs-security-addendum] 704 Lever, C., "Federated Filesystem Security Addendum", 705 draft-cel-nfsv4-federated-fs-security-addendum-05 (Active 706 Internet Draft), May 2016. 708 [I-D.sorce-krbwg-general-pac] 709 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 710 Kerberos V5", draft-ietf-krb-wg-general-pac-01 (Work In 711 Progress awaiting merge with other document ), June 2011. 713 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 714 in Kerberos Tickets for Access Control to Resources", 715 October 2002. 717 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 718 Information Service", RFC 2307, DOI 10.17487/RFC2307, 719 March 1998, . 721 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 722 2624, DOI 10.17487/RFC2624, June 1999, 723 . 725 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 726 Naik, "Requirements for Federated File Systems", RFC 5716, 727 DOI 10.17487/RFC5716, January 2010, 728 . 730 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 731 Database (NSDB) Protocol for Federated File Systems", RFC 732 7532, DOI 10.17487/RFC7532, March 2015, 733 . 735 [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., 736 "Administration Protocol for Federated File Systems", RFC 737 7533, DOI 10.17487/RFC7533, March 2015, 738 . 740 Appendix A. Acknowledgments 742 Andy Adamson would like to thank NetApp, Inc. for its funding of his 743 time on this project. 745 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 746 David Noveck for their review. 748 Authors' Addresses 750 William A. (Andy) Adamson 751 NetApp 753 Email: andros@netapp.com 755 Nicolas Williams 756 Cryptonector 758 Email: nico@cryptonector.com