idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-10.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 (August 29, 2016) is 2791 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 5661 (Obsoleted by RFC 8881) == Outdated reference: A later version (-06) exists of draft-cel-nfsv4-federated-fs-security-addendum-05 Summary: 2 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: March 2, 2017 Cryptonector 6 August 29, 2016 8 Multiple NFSv4 Domain Namespace Deployment Requirements 9 draft-ietf-nfsv4-multi-domain-fs-reqs-10 11 Abstract 13 This document presents requirements 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 multi-domain file name space, the server must offer a multi-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 March 2, 2017. 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. Stand-alone Examples in an NFSv4 Multi-domain Deployment . . 11 78 8. Resolving Multi-domain Authorization Information . . . . . . 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 presents requirements 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 multi-domain file name space, the server must offer a multi-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 [RFC4121]. 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 of [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 [RFC4511]. 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 requirements for 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 8). 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 The purpose of this section is to list some typical stand-alone 304 deployment examples to highlight the need for the required restraints 305 to the NFSv4 protocol, name service configuration, and security 306 service choices in an NFSv4 multi-domain environment described in 307 Section 6. 309 Section 7 notes how these stand-alone deployment examples would need 310 to change to participate in an NFSv4 multi-domain deployment. 312 In order to service as many environments as possible, the NFSv4 313 protocol is designed to allow administrators freedom to configure 314 their NFSv4 domains as they please. Stand-alone NFSv4 Domains can be 315 run in many ways. 317 These examples are for a NFSv4 server exporting a POSIX UID/GID based 318 file system, a typical deployment. These examples are listed in the 319 order of increasing NFSv4 administrative complexity. 321 5.1. AUTH_SYS with Stringified UID/GID 323 This example is the closest NFSv4 gets to being run as NFSv3 as there 324 is no need for a name service for file metadata listing. 326 File access: The AUTH_SYS RPC credential [RFC5531] provides a UID as 327 the authentication identity, and a list of GIDs as authorization 328 context information. File access decisions require no name service 329 interaction as the on-the-wire and on-disk representation are the 330 same and the auth-to-authz UID and GID authorization context 331 information is provided in the RPC credential. 333 Meta-data setting and listing: When the NFSv4 clients and servers 334 implement a stringified UID/GID scheme, where a stringified UID or 335 GID is used for the NFSv4 name@domain on-the-wire identity, then a 336 name service is not required for file metadata listing as the UID or 337 GID can be constructed from the stringified form on the fly by the 338 server. 340 5.2. AUTH_SYS with name@domain 342 Another possibility is to express identity using the form 343 'name@domain', rather than using a stringified UID/GID scheme for 344 file metadata setting and listing. 346 File access: This is the same as in Section 5.1. 348 Meta-data setting and listing: The NFSv4 server will need to use a 349 name service for the wire-to-disk mappings to map between the on-the- 350 wire name@domain syntax and the on-disk UID/GID representation. 351 Often, the NFSv4 server will use the nsswitch interface for these 352 mappings. A typical use of the nsswitch name service interface uses 353 no domain component, just the UID attribute [RFC2307] (or login name) 354 as the name component. This is no issue in a stand-alone NFSv4 355 domain deployment as the NFSv4 Domain is known to the NFSv4 server 356 and can combined with the login name to form the name@domain syntax 357 after the return of the name service call. 359 5.3. RPCSEC_GSS with name@domain 361 RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely 362 authenticate users to servers. The most common mechanism is Kerberos 363 [RFC4121]. 365 This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS 366 security mechanism. 368 File Access: The forms of GSS principal names are mechanism-specific. 369 For Kerberos these are of the form principal@REALM. Sometimes 370 authorization context information is delivered with authentication, 371 but this cannot be counted on. Authorization context information not 372 delivered with authentication has timely update considerations (i.e., 373 generally it's not possible to get a timely update). File access 374 decisions therefore require a wire-to-disk mapping of the GSS 375 principal to a UID, and an auth-to-authz mapping to obtain the list 376 of GIDs as the authorization context. 378 Implementations must never blindly drop a Kerberos REALM name from a 379 Kerberos principal name to obtain a POSIX username, but they may be 380 configured to do so for specific REALMs. 382 Meta-data setting and listing: This is the same as in Section 5.2. 384 6. Multi-domain Constraints to the NFSv4 Protocol 386 Joining NFSv4 Domains under a single file name space imposes slightly 387 on the NFSv4 administration freedom. Here we describe the required 388 constraints. 390 6.1. Name@domain Constraints 392 NFSv4 uses a syntax of the form "name@domain" as the on-the-wire 393 representation of the "who" field of an NFSv4 access control entry 394 (ACE) for users and groups. This design provides a level of 395 indirection that allows NFSv4 clients and servers with different 396 internal representations of authorization identity to interoperate 397 even when referring to authorization identities from different NFSv4 398 Domains. 400 Multi-domain capable sites need to meet the following requirements in 401 order to ensure that NFSv4 clients and servers can map between 402 name@domain and internal representations reliably. While some of 403 these constraints are basic assumptions in NFSv4.0 [RFC7530] and 404 NFSv4.1 [RFC5661], they need to be clearly stated for the multi- 405 domain case. 407 o The NFSv4 Domain portion of name@domain MUST be unique within the 408 multi-domain name space. See [RFC5661] section 5.9 "Interpreting 409 owner and owner_group" for a discussion on NFSv4 Domain 410 configuration. 412 o The name portion of name@domain MUST be unique within the 413 specified NFSv4 Domain. 415 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 416 in a multi-domain deployment. This means that multi-domain-capable 417 servers MUST reject requests that use stringified UID/GIDs. 419 6.1.1. NFSv4 Domain and DNS Services 421 Here we address the relationship between NFSv4 Domain name and DNS 422 domain name in a multi-domain deployment. 424 The definition of an NFSv4 Domain name, the @domain portion of the 425 name@domain syntax, needs clarification to work in a multi-domain 426 file system name space. Section 5.9 [RFC5661] loosely defines the 427 NFSv4 Domain name as a DNS domain name. This loose definition for 428 the NFSv4 Domain name is a good one, as DNS domain names are globally 429 unique. As noted above in Section 6.1, any choice of NFSv4 Domain 430 name can work within a stand-alone NFSv4 Domain deployment whereas 431 the NFSv4 Domain name is required to be unique across a multi-domain 432 deployment. 434 A typical configuration is that there is a single NFSv4 Domain that 435 is served by a single DNS domain. In this case the NFSv4 Domain name 436 can be the same as the DNS domain name. 438 An NFSv4 Domain can span multiple DNS domains. In this case, one of 439 the DNS domain names can be chosen as the NFSv4 Domain name. 441 Multiple NFSv4 Domains can also share a DNS domain. In this case, 442 only one of the NFSv4 Domains can use the DNS domain name, the other 443 NFSv4 Domains must choose another unique NFSv4 Domain name. 445 6.1.2. NFSv4 Domain and Name Services 447 As noted above in Section 6.1, each name@domain is unique across the 448 multi-domain name space and maps, on each NFSv4 server, to the local 449 representation of identity used by that server. Typically, this 450 representation consists of an indication of the particular domain 451 combined with the UID/GID corresponding to the name component. To 452 support such an arrangement, each NFSv4 Domain needs to have a single 453 name resolution service capable of converting the names defined 454 within the domain to the corresponding local representation. 456 6.2. RPC Security Constraints 458 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 460 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 461 (This requirement to implement is not a requirement 462 to use.) Other flavors, such as AUTH_NONE, 463 and AUTH_SYS, MAY be implemented as well. 465 The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used 466 in a multi-domain name space is REQUIRED to employ a method of cross 467 NFSv4 Domain trust so that a principal from a security service in one 468 NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a 469 security service with the same security mechanism. Kerberos is an 470 example of such a security service. 472 The AUTH_NONE [RFC5531] security flavor can be useful in a multi- 473 domain deployment to grant universal read-only access to public data 474 without any credentials. 476 The AUTH_SYS security flavor [RFC5531] uses a host-based 477 authentication model where the weakly authenticated host (the NFSv4 478 client) asserts the user's authorization identities using small 479 integers, uidNumber, and gidNumber [RFC2307], as user and group 480 identity representations. Because this authorization ID 481 representation has no domain component, AUTH_SYS can only be used in 482 a name space where all NFSv4 clients and servers share an [RFC2307] 483 name service. A shared name service is required because uidNumbers 484 and gidNumbers are passed in the RPC credential; there is no 485 negotiation of name space in AUTH_SYS. Collisions can occur if 486 multiple name services are used, so AUTH_SYS MUST NOT be used in a 487 multi-domain file system deployment. 489 6.2.1. NFSv4 Domain and Security Services 491 As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4 492 Domain security services are RPCSEC_GSS based with the Kerberos 5 493 security mechanism being the most commonly (and as of this writing, 494 the only) deployed service. 496 A single Kerberos 5 security service per NFSv4 Domain with the upper 497 case NFSv4 Domain name as the Kerberos 5 REALM name is a common 498 deployment. 500 Multiple security services per NFSv4 Domain is allowed, and brings 501 the need of mapping multiple Kerberos 5 principal@REALMs to the same 502 local ID. Methods of achieving this are beyond the scope of this 503 document. 505 7. Stand-alone Examples in an NFSv4 Multi-domain Deployment 507 In this section we revisit the stand-alone NFSv4 Domain deployment 508 examples in Section 5 noting what is prohibiting them from 509 participating in an NFSv4 multi-domain deployment. 511 Note that because all on-disk identities participating in a stand- 512 alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4 513 Domain deployments have no requirement for exporting multi-domain 514 capable file systems. To participate in an NFSv4 multi-domain 515 deployment, all three examples in Section 5 would need to export 516 multi-domain capable file systems. 518 Due to the use of AUTH_SYS and stringified UID/GIDs the first stand- 519 alone deployment example in Section 5.1 is not suitable for 520 participation in an NFSv4 multi-domain deployment. 522 The second example in described in Section 5.2 does use the 523 name@domain identity syntax, but the use of AUTH_SYS prohibits its 524 participation in an NFSv4 multi-domain deployment. 526 The third example in Section 5.3 can participate in a multi-domain 527 name space deployment if: 529 o The NFSv4 Domain name is unique across the name space. 531 o All exported file systems are multi-domain capable. 533 o A secure method is used to resolve remote NFSv4 Domain principals 534 authorization information from an authoritative source. 536 8. Resolving Multi-domain Authorization Information 538 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 539 server, after authenticating the principal, the server must obtain in 540 a secure manner the principal's authorization context information 541 from an authoritative source such as the name service in the 542 principal's NFSv4 Domain. 544 In the stand-alone NFSv4 Domain case where the principal is seeking 545 access to files on an NFSv4 server in the principal's home NFSv4 546 Domain, the server administrator has knowledge of the local policies 547 and methods for obtaining the principal's authorization information 548 and the mappings to local representation of identity from an 549 authoritative source. E.g., the administrator can configure secure 550 access to the local NFSv4 domain name service. 552 In the multi-domain case where a principal is seeking access to files 553 on an NFSv4 server not in the principal's home NFSv4 Domain, the 554 NFSv4 server may be required to contact the remote name service in 555 the principals NFSv4 Domain. In this case there is no assumption of: 557 o Remote name service configuration knowledge. 559 o The syntax of the remote authorization context information 560 presented to the NFSv4 server by the remote name service for 561 mapping to a local representation. 563 There are several methods the NFSv4 server can use to obtain the 564 NFSv4 Domain authoritative authorization information for a remote 565 principal from an authoritative source. While any detail is beyond 566 the scope of this document, some general methods are listed here. 568 1. A mechanism specific GSS-API authorization payload containing 569 credential authorization data such as a "privilege attribute 570 certificate" (PAC) [PAC] or a "principal authentication data" 571 (PAD) [I-D.sorce-krbwg-general-pac]. This is the preferred 572 method as the payload is delivered as part of GSS-API 573 authentication, avoids requiring any knowledge of the remote 574 authoritative service configuration, and its syntax is well 575 known. 577 2. When there is a security agreement between the local and remote 578 NFSv4 Domain name services plus regular update data feeds, the 579 NFSv4 server local NFSv4 Domain name service can be authoritative 580 for principal's in the remote NFSv4 Domain. In this case, the 581 NFSv4 server makes a query to it's local NFSv4 Domain name 582 service just as it does when servicing a local domain principal. 583 While this requires detailed knowledge of the remote NFSv4 584 Domains name service for the update data feeds, the authorization 585 context information presented to the NFSv4 server is in the same 586 form as a query for a local principal. 588 3. An authenticated direct query from the NFSv4 server to the 589 principal's NFSv4 Domain authoritative name service. This 590 requires the NFSv4 server to have detailed knowledge of the 591 remote NFSv4 Domain's authoritative name service and detailed 592 knowledge of the syntax of the resultant authorization context 593 information. 595 9. Security Considerations 597 This RFC discusses security throughout. All the security 598 considerations of the relevant protocols, such as NFSv4.0 [RFC7530], 599 NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP 600 [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace 601 DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS 602 Security Addendum [I-D.lever-fedfs-security-addendum] apply. 604 Authentication and authorization across administrative domains 605 presents security considerations, most of which are treated 606 elsewhere, but we repeat some of them here: 608 o latency in propagation of revocation of authentication credentials 610 o latency in propagation of revocation of authorizations 612 o latency in propagation of granting of authorizations 614 o complications in establishing a foreign domain's users' complete 615 authorization context: only parts may be available to servers 617 o privacy considerations in a federated environment 619 Most of these are security considerations of the mechanisms used to 620 authenticate users to servers and servers to users, and of the 621 mechanisms used to evaluate a user's authorization context. 623 Implementors may be tempted to assume that realm (or "issuer") and 624 NFSv4 Domain are roughly the same thing, but they are not. 625 Configuration and/or lookup protocols (such as LDAP) and associated 626 schemas are generally required in order to evaluate a user 627 principal's authorization context (see Section 8). In the simplest 628 scheme a server has access to a database mapping all known principal 629 names to usernames whose authorization context can be evaluated using 630 operating system interfaces that deal in usernames rather than 631 principal names. 633 Note that clients may also need to evaluate a server's authorization 634 context when using labeled security [I-D.NFSv4.2] (e.g., is the 635 server authorized to handle content at a given security level, for 636 the given client process subject label). 638 When the server accepts user credential from more than one realm, it 639 is important to remember that the server must verify that the client 640 it is talking to has a credential for the name the client has 641 presented the server, and that that credential's issuer (i.e., its 642 realm) is allowed to issue it. Usually the service principal realm 643 authorization function is implemented by the security mechanism, but 644 the implementor should check this. 646 10. IANA Considerations 648 There are no IANA considerations in this document. 650 11. References 652 11.1. Normative References 654 [I-D.NFSv4.2] 655 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 656 nfsv4-minorversion2-36 (Work In Progress), April 2015. 658 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 659 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 660 . 662 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 663 Version 3 Protocol Specification", RFC 1813, DOI 10.17487/ 664 RFC1813, June 1995, 665 . 667 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 668 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 669 RFC2119, March 1997, 670 . 672 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 673 Specification", RFC 2203, DOI 10.17487/RFC2203, September 674 1997, . 676 [RFC2743] Linn, J., "Generic Security Service Application Program 677 Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ 678 RFC2743, January 2000, 679 . 681 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 682 Version 5 Generic Security Service Application Program 683 Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 684 10.17487/RFC4121, July 2005, 685 . 687 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 688 Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/ 689 RFC4511, June 2006, 690 . 692 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 693 "Network File System (NFS) Version 4 Minor Version 1 694 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 695 . 697 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 698 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 699 March 2015, . 701 11.2. Informative References 703 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 704 Internet File System (CIFS) Protocol", January 2013. 706 [I-D.lever-fedfs-security-addendum] 707 Lever, C., "Federated Filesystem Security Addendum", 708 draft-cel-nfsv4-federated-fs-security-addendum-05 (Active 709 Internet Draft), May 2016. 711 [I-D.sorce-krbwg-general-pac] 712 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 713 Kerberos V5", draft-ietf-krb-wg-general-pac-01 (Work In 714 Progress awaiting merge with other document ), June 2011. 716 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 717 in Kerberos Tickets for Access Control to Resources", 718 October 2002. 720 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 721 Information Service", RFC 2307, DOI 10.17487/RFC2307, 722 March 1998, . 724 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 725 2624, DOI 10.17487/RFC2624, June 1999, 726 . 728 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 729 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 730 May 2009, . 732 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 733 Naik, "Requirements for Federated File Systems", RFC 5716, 734 DOI 10.17487/RFC5716, January 2010, 735 . 737 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 738 Database (NSDB) Protocol for Federated File Systems", RFC 739 7532, DOI 10.17487/RFC7532, March 2015, 740 . 742 [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., 743 "Administration Protocol for Federated File Systems", RFC 744 7533, DOI 10.17487/RFC7533, March 2015, 745 . 747 Appendix A. Acknowledgments 749 Andy Adamson would like to thank NetApp, Inc. for its funding of his 750 time on this project. 752 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 753 David Noveck for their review. 755 Authors' Addresses 757 William A. (Andy) Adamson 758 NetApp 760 Email: andros@netapp.com 762 Nicolas Williams 763 Cryptonector 765 Email: nico@cryptonector.com