idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-11.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 (September 1, 2016) is 2794 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 5, 2017 Cryptonector 6 September 1, 2016 8 Multiple NFSv4 Domain Namespace Deployment Requirements 9 draft-ietf-nfsv4-multi-domain-fs-reqs-11 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 5, 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 . . . . . . . 8 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 syntax can provide unique identities and so enables 115 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 syntax and referral mechanism along 125 with the use of RPCSEC_GSS security mechanisms enables the 126 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 Meta-data setting and listing: This is the same as in Section 5.2. 380 6. Multi-domain Constraints to the NFSv4 Protocol 382 Joining NFSv4 Domains under a single file name space imposes slightly 383 on the NFSv4 administration freedom. Here we describe the required 384 constraints. 386 6.1. Name@domain Constraints 388 NFSv4 uses a syntax of the form "name@domain" (see Section 5.9 389 [RFC7530]) as the on-the-wire representation of the "who" field of an 390 NFSv4 access control entry (ACE) for users and groups. This design 391 provides a level of indirection that allows NFSv4 clients and servers 392 with different internal representations of authorization identity to 393 interoperate even when referring to authorization identities from 394 different NFSv4 Domains. 396 Multi-domain capable sites need to meet the following requirements in 397 order to ensure that NFSv4 clients and servers can map between 398 name@domain and internal representations reliably. While some of 399 these constraints are basic assumptions in NFSv4.0 [RFC7530] and 400 NFSv4.1 [RFC5661], they need to be clearly stated for the multi- 401 domain case. 403 o The NFSv4 Domain portion of name@domain MUST be unique within the 404 multi-domain name space. See [RFC5661] section 5.9 "Interpreting 405 owner and owner_group" for a discussion on NFSv4 Domain 406 configuration. 408 o The name portion of name@domain MUST be unique within the 409 specified NFSv4 Domain. 411 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 412 in a multi-domain deployment. This means that multi-domain-capable 413 servers MUST reject requests that use stringified UID/GIDs. 415 6.1.1. NFSv4 Domain and DNS Services 417 Here we address the relationship between NFSv4 Domain name and DNS 418 domain name in a multi-domain deployment. 420 The definition of an NFSv4 Domain name, the @domain portion of the 421 name@domain syntax, needs clarification to work in a multi-domain 422 file system name space. Section 5.9 [RFC5661] loosely defines the 423 NFSv4 Domain name as a DNS domain name. This loose definition for 424 the NFSv4 Domain name is a good one, as DNS domain names are globally 425 unique. As noted above in Section 6.1, any choice of NFSv4 Domain 426 name can work within a stand-alone NFSv4 Domain deployment whereas 427 the NFSv4 Domain name is required to be unique across a multi-domain 428 deployment. 430 A typical configuration is that there is a single NFSv4 Domain that 431 is served by a single DNS domain. In this case the NFSv4 Domain name 432 can be the same as the DNS domain name. 434 An NFSv4 Domain can span multiple DNS domains. In this case, one of 435 the DNS domain names can be chosen as the NFSv4 Domain name. 437 Multiple NFSv4 Domains can also share a DNS domain. In this case, 438 only one of the NFSv4 Domains can use the DNS domain name, the other 439 NFSv4 Domains must choose another unique NFSv4 Domain name. 441 6.1.2. NFSv4 Domain and Name Services 443 As noted above in Section 6.1, each name@domain is unique across the 444 multi-domain name space and maps, on each NFSv4 server, to the local 445 representation of identity used by that server. Typically, this 446 representation consists of an indication of the particular domain 447 combined with the UID/GID corresponding to the name component. To 448 support such an arrangement, each NFSv4 Domain needs to have a single 449 name resolution service capable of converting the names defined 450 within the domain to the corresponding local representation. 452 6.2. RPC Security Constraints 454 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 456 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 457 (This requirement to implement is not a requirement 458 to use.) Other flavors, such as AUTH_NONE, 459 and AUTH_SYS, MAY be implemented as well. 461 The underlying RPCSEC_GSS [RFC2203] GSS-API security mechanism used 462 in a multi-domain name space is REQUIRED to employ a method of cross 463 NFSv4 Domain trust so that a principal from a security service in one 464 NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a 465 security service with the same security mechanism. Kerberos is an 466 example of such a security service. 468 The AUTH_NONE [RFC5531] security flavor can be useful in a multi- 469 domain deployment to grant universal read-only access to public data 470 without any credentials. 472 The AUTH_SYS security flavor [RFC5531] uses a host-based 473 authentication model where the weakly authenticated host (the NFSv4 474 client) asserts the user's authorization identities using small 475 integers, uidNumber, and gidNumber [RFC2307], as user and group 476 identity representations. Because this authorization ID 477 representation has no domain component, AUTH_SYS can only be used in 478 a name space where all NFSv4 clients and servers share an [RFC2307] 479 name service. A shared name service is required because uidNumbers 480 and gidNumbers are passed in the RPC credential; there is no 481 negotiation of name space in AUTH_SYS. Collisions can occur if 482 multiple name services are used, so AUTH_SYS MUST NOT be used in a 483 multi-domain file system deployment. 485 6.2.1. NFSv4 Domain and Security Services 487 As noted above in Section 6.2, caveat AUTH_NONE, multiple NFSv4 488 Domain security services are RPCSEC_GSS based with the Kerberos 5 489 security mechanism being the most commonly (and as of this writing, 490 the only) deployed service. 492 A single Kerberos 5 security service per NFSv4 Domain with the upper 493 case NFSv4 Domain name as the Kerberos 5 REALM name is a common 494 deployment. 496 Multiple security services per NFSv4 Domain is allowed, and brings 497 the need of mapping multiple Kerberos 5 principal@REALMs to the same 498 local ID. Methods of achieving this are beyond the scope of this 499 document. 501 7. Stand-alone Examples in an NFSv4 Multi-domain Deployment 503 In this section we revisit the stand-alone NFSv4 Domain deployment 504 examples in Section 5 noting what is prohibiting them from 505 participating in an NFSv4 multi-domain deployment. 507 Note that because all on-disk identities participating in a stand- 508 alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4 509 Domain deployments have no requirement for exporting multi-domain 510 capable file systems. To participate in an NFSv4 multi-domain 511 deployment, all three examples in Section 5 would need to export 512 multi-domain capable file systems. 514 Due to the use of AUTH_SYS and stringified UID/GIDs the first stand- 515 alone deployment example in Section 5.1 is not suitable for 516 participation in an NFSv4 multi-domain deployment. 518 The second example in described in Section 5.2 does use the 519 name@domain syntax, but the use of AUTH_SYS prohibits its 520 participation in an NFSv4 multi-domain deployment. 522 The third example in Section 5.3 can participate in a multi-domain 523 name space deployment if: 525 o The NFSv4 Domain name is unique across the name space. 527 o All exported file systems are multi-domain capable. 529 o A secure method is used to resolve remote NFSv4 Domain principals 530 authorization information from an authoritative source. 532 8. Resolving Multi-domain Authorization Information 534 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 535 server, after authenticating the principal, the server SHOULD obtain 536 in a secure manner the principal's authorization context information 537 from an authoritative source such as the name service in the 538 principal's NFSv4 Domain. 540 In the stand-alone NFSv4 Domain case where the principal is seeking 541 access to files on an NFSv4 server in the principal's home NFSv4 542 Domain, the server administrator has knowledge of the local policies 543 and methods for obtaining the principal's authorization information 544 and the mappings to local representation of identity from an 545 authoritative source. E.g., the administrator can configure secure 546 access to the local NFSv4 domain name service. 548 In the multi-domain case where a principal is seeking access to files 549 on an NFSv4 server not in the principal's home NFSv4 Domain, the 550 NFSv4 server may be required to contact the remote name service in 551 the principals NFSv4 Domain. In this case there is no assumption of: 553 o Remote name service configuration knowledge. 555 o The syntax of the remote authorization context information 556 presented to the NFSv4 server by the remote name service for 557 mapping to a local representation. 559 There are several methods the NFSv4 server can use to obtain the 560 NFSv4 Domain authoritative authorization information for a remote 561 principal from an authoritative source. While any detail is beyond 562 the scope of this document, some general methods are listed here. 564 1. A mechanism specific GSS-API authorization payload containing 565 credential authorization data such as a "privilege attribute 566 certificate" (PAC) [PAC] or a "principal authentication data" 567 (PAD) [I-D.sorce-krbwg-general-pac]. This is the preferred 568 method as the payload is delivered as part of GSS-API 569 authentication, avoids requiring any knowledge of the remote 570 authoritative service configuration, and its syntax is well 571 known. 573 2. When there is a security agreement between the local and remote 574 NFSv4 Domain name services plus regular update data feeds, the 575 NFSv4 server local NFSv4 Domain name service can be authoritative 576 for principal's in the remote NFSv4 Domain. In this case, the 577 NFSv4 server makes a query to it's local NFSv4 Domain name 578 service just as it does when servicing a local domain principal. 579 While this requires detailed knowledge of the remote NFSv4 580 Domains name service for the update data feeds, the authorization 581 context information presented to the NFSv4 server is in the same 582 form as a query for a local principal. 584 3. An authenticated direct query from the NFSv4 server to the 585 principal's NFSv4 Domain authoritative name service. This 586 requires the NFSv4 server to have detailed knowledge of the 587 remote NFSv4 Domain's authoritative name service and detailed 588 knowledge of the syntax of the resultant authorization context 589 information. 591 9. Security Considerations 593 This RFC discusses security throughout. All the security 594 considerations of the relevant protocols, such as NFSv4.0 [RFC7530], 595 NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP 596 [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace 597 DB Protocol [RFC7532], FedFS Administration Protocol [RFC7533], FedFS 598 Security Addendum [I-D.lever-fedfs-security-addendum] apply. 600 Authentication and authorization across administrative domains 601 presents security considerations, most of which are treated 602 elsewhere, but we repeat some of them here: 604 o latency in propagation of revocation of authentication credentials 606 o latency in propagation of revocation of authorizations 608 o latency in propagation of granting of authorizations 610 o complications in establishing a foreign domain's users' complete 611 authorization context: only parts may be available to servers 613 o privacy considerations in a federated environment 615 Most of these are security considerations of the mechanisms used to 616 authenticate users to servers and servers to users, and of the 617 mechanisms used to evaluate a user's authorization context. 619 Implementors may be tempted to assume that realm (or "issuer") and 620 NFSv4 Domain are roughly the same thing, but they are not. 621 Configuration and/or lookup protocols (such as LDAP) and associated 622 schemas are generally required in order to evaluate a user 623 principal's authorization context (see Section 8). In the simplest 624 scheme a server has access to a database mapping all known principal 625 names to usernames whose authorization context can be evaluated using 626 operating system interfaces that deal in usernames rather than 627 principal names. 629 Note that clients may also need to evaluate a server's authorization 630 context when using labeled security [I-D.NFSv4.2] (e.g., is the 631 server authorized to handle content at a given security level, for 632 the given client process subject label). 634 When the server accepts user credential from more than one realm, it 635 is important to remember that the server must verify that the client 636 it is talking to has a credential for the name the client has 637 presented the server, and that that credential's issuer (i.e., its 638 realm) is allowed to issue it. Usually the service principal realm 639 authorization function is implemented by the security mechanism, but 640 the implementor should check this. 642 10. IANA Considerations 644 There are no IANA considerations in this document. 646 11. References 648 11.1. Normative References 650 [I-D.NFSv4.2] 651 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 652 nfsv4-minorversion2-36 (Work In Progress), April 2015. 654 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 655 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 656 . 658 [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS 659 Version 3 Protocol Specification", RFC 1813, DOI 10.17487/ 660 RFC1813, June 1995, 661 . 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 665 RFC2119, March 1997, 666 . 668 [RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 669 Specification", RFC 2203, DOI 10.17487/RFC2203, September 670 1997, . 672 [RFC2743] Linn, J., "Generic Security Service Application Program 673 Interface Version 2, Update 1", RFC 2743, DOI 10.17487/ 674 RFC2743, January 2000, 675 . 677 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 678 Version 5 Generic Security Service Application Program 679 Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 680 10.17487/RFC4121, July 2005, 681 . 683 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 684 Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/ 685 RFC4511, June 2006, 686 . 688 [RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., 689 "Network File System (NFS) Version 4 Minor Version 1 690 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, 691 . 693 [RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System 694 (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, 695 March 2015, . 697 11.2. Informative References 699 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 700 Internet File System (CIFS) Protocol", January 2013. 702 [I-D.lever-fedfs-security-addendum] 703 Lever, C., "Federated Filesystem Security Addendum", 704 draft-cel-nfsv4-federated-fs-security-addendum-05 (Active 705 Internet Draft), May 2016. 707 [I-D.sorce-krbwg-general-pac] 708 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 709 Kerberos V5", draft-ietf-krb-wg-general-pac-01 (Work In 710 Progress awaiting merge with other document ), June 2011. 712 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 713 in Kerberos Tickets for Access Control to Resources", 714 October 2002. 716 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 717 Information Service", RFC 2307, DOI 10.17487/RFC2307, 718 March 1998, . 720 [RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 721 2624, DOI 10.17487/RFC2624, June 1999, 722 . 724 [RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol 725 Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, 726 May 2009, . 728 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 729 Naik, "Requirements for Federated File Systems", RFC 5716, 730 DOI 10.17487/RFC5716, January 2010, 731 . 733 [RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace 734 Database (NSDB) Protocol for Federated File Systems", RFC 735 7532, DOI 10.17487/RFC7532, March 2015, 736 . 738 [RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., 739 "Administration Protocol for Federated File Systems", RFC 740 7533, DOI 10.17487/RFC7533, March 2015, 741 . 743 Appendix A. Acknowledgments 745 Andy Adamson would like to thank NetApp, Inc. for its funding of his 746 time on this project. 748 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 749 David Noveck for their review. 751 Authors' Addresses 753 William A. (Andy) Adamson 754 NetApp 756 Email: andros@netapp.com 758 Nicolas Williams 759 Cryptonector 761 Email: nico@cryptonector.com