idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 14, 2015) is 3175 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CIFS' == Outdated reference: A later version (-17) exists of draft-ietf-nfsv4-rpcsec-gssv3-12 -- Unexpected draft version: The latest known version of draft-ietf-krb-wg-general-pac is -01, but you're referring to -02. -- Possible downref: Non-RFC (?) normative reference: ref. 'PAC' ** Downref: Normative reference to an Experimental RFC: RFC 2307 ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) ** Downref: Normative reference to an Informational RFC: RFC 5716 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). 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: February 15, 2016 Cryptonector 6 August 14, 2015 8 Multiple NFSv4 Domain Namespace Deployment Guidelines 9 draft-ietf-nfsv4-multi-domain-fs-reqs-04 11 Abstract 13 This document discusses issues relevant to the deployment of the 14 NFSv4 protocols in situations allowing for the construction of an 15 NFSv4 file namespace supporting the use of multiple NFSv4 domains and 16 utilizing multi-domain capable file systems. Also described are 17 constraints on name resolution and security services appropriate to 18 the administration of such a system. Such a namespace is a suitable 19 way to enable a Federated File System supporting the use of multiple 20 NFSv4 domains. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 15, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . 5 66 3.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . . 6 67 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 6 68 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 7 69 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 7 70 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 8 71 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 8 72 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 8 73 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 9 74 5.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . . . 9 75 5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 10 76 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10 77 6. Resolving Multi-domain Authorization Information . . . . . . 11 78 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 12 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 An NFSv4 domain is defined as a set of users and groups named by a 87 particular domain using the NFSv4 name@domain syntax. This includes 88 NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and minor versions yet to be 89 published. Often, a computer which acts as an NFSv4 client and 90 always acts on behalf of users belonging to a particular NFSv4 domain 91 is thought of a part of that NFSv4 domain. Similarly, a computer 92 acting as an NFSv4 server that is only aware of users within a 93 particular NFSv4 domain may be thought of as part of that NFSv4 94 domain. 96 In this document, the term "multi-domain" always refers to multiple 97 NFSv4 domains. 99 The Federated File System (FedFS) [RFC5716] describes the 100 requirements and administrative tools to construct a uniform NFSv4 101 file server based namespace that is capable of spanning a whole 102 enterprise and that is easy to manage. 104 The FedFS is the standardized method of constructing and 105 administrating an enterprise-wide NFSv4 filesystem, and so is 106 referenced in this document. The issues with multi-domain 107 deployments described in this document apply to all multi-domain 108 deployments, whether they are run as a FedFS or not. 110 Stand-alone NFSv4 domain deployments can be run in many ways. While 111 a FedFS can be run within all stand-alone NFSv4 domain configurations 112 some of these configurations (Section 4) are not compatible with 113 joining a multi-domain FedFS namespace. 115 Multi-domain deployments require support for global identities in 116 name services and security services, and file systems capable of the 117 on-disk representation of identities belonging to multiple NFSv4 118 domains. Typically, stand-alone NFSv4 domain deployments only 119 provide support for identities belonging to a single NFSv4 domain. 121 This document describes administration-related constraints applying 122 to the deployment of the NFSv4 protocols in environments supporting 123 the construction of an NFSv4 file system namespace supporting the use 124 of multiple NFSv4 domains and utilizing multi-domain capable file 125 systems. Also described are constraints regarding the name 126 resolution and security services appropriate to such a deployment. 127 Such a namespace is a suitable way to enable a Federated File System 128 supporting the use of multiple NFSv4 domains. 130 2. Terminology 132 Name Service: Facilities that provides the mapping between {NFSv4 133 domain, group or user name} and the appropriate local 134 representation of identity. Also includes facilities providing 135 mapping between a security principal and local representation of 136 identity. Can be applied to global identities or principals from 137 within local and remote domains. Often provided by a Directory 138 Service such as LDAP. 140 Name Service Switch (nsswitch): a facility in provides a variety 141 of sources for common configuration databases and name resolution 142 mechanisms. 144 Domain: This term is used in multiple contexts where it has 145 different meanings. Definitions of "nfsv4 domain" and "multi- 146 domain" have already appeared above in Section 1. Below we 147 provide other specific definitions used this document. 149 DNS domain: a set of computers, services, or any internet 150 resource identified by an DNS domain name [RFC1034]. 152 Security realm or domain: a set of configured security 153 providers, users, groups, security roles, and security policies 154 running a single security protocol and administered by a single 155 entity, for example a Kerberos realm. 157 FedFS domain: A file namespace that can cross multiple shares 158 on multiple file servers using file-access protocols such as 159 NFSv4. A FedFS domain is typically a single administrative 160 entity, and has a name that is similar to a DNS domain name. 161 Also known as a Federation. 163 Administrative domain: a set of users, groups, computers, and 164 services administered by a single entity. Can include multiple 165 DNS domains, NFSv4 domains, security domains, and FedFS 166 domains. 168 Local representation of identity: A representation of a user or a 169 group of users capable of being stored persistently within a file 170 system. Typically such representations are identical to the form 171 in which users and groups are represented within internal server 172 API's. Examples are numeric id's such as a a uidNumber (UID) or 173 gidNumber (GID) [RFC2307], a Windows Security Identifier (SID) 174 [CIFS]. In some case the identifier space for user and groups 175 overlap, requiring the one using such an id to know a priori 176 whether the identifier is for a user or a group. 178 Global identity: An on-the-wire globally unique form of identity 179 that can be mapped to a local representation. For example, the 180 NFSv4 name@domain or the Kerberos principal@REALM. 182 Multi-domain capable filesystem: A local filesystem that uses a 183 local ID form that can represent NFSv4 identities from multiple 184 domains. 186 Principal: an RPCSEC_GSS [RFC2203] authentication identity. 187 Usually, but not always, a user; rarely, if ever, a group; 188 sometimes a host or server. 190 Authorization Context: A collection of information about a 191 principal such as username, userID, group membership, etcetera 192 used in authorization decisions. 194 Stringified UID or GID: NFSv4 owner and group strings that consist 195 of decimal numeric values with no leading zeros, and which do not 196 contain an '@' sign. See Section 5.9 "Interpreting owner and 197 owner_group" [RFC5661]. 199 3. Identity Mapping 201 3.1. NFSv4 Server Identity Mapping 203 NFSv4 servers deal with two kinds of identities: authentication 204 identities (referred to here as "principals") and authorization 205 identities ("users" and "groups" of users). NFSv4 supports multiple 206 authentication methods, each authenticating an "initiator principal" 207 (typically representing a user) to an "acceptor principal" (always 208 corresponding to the NFSv4 server). NFSv4 does not prescribe how to 209 represent authorization identities on file systems. All file access 210 decisions constitute "authorization" and are made by NFSv4 servers 211 using authorization context information and file metadata related to 212 authorization, such as a file's access control list (ACL). 214 NFSv4 servers therefore must perform two kinds of mappings: 216 1. Auth-to-authz: A mapping between the authentication identity and 217 the authorization context information. 219 2. Wire-to-disk: A mapping between the on-the-wire authorization 220 identity representation and the on-disk authorization identity 221 representation. 223 A Name Service such as LDAP often provides these mappings. 225 Many aspects of these mappings are entirely implementation specific, 226 but some require multi-domain capable name resolution and security 227 services in order to interoperate in a multi-domain environment 229 NFSv4 servers use these mappings for: 231 1. File access: Both the auth-to-authz and the wire-to-disk mappings 232 may be required for file access decisions. 234 2. Meta-data setting and listing: The auth-to-authz mapping is 235 usually required to service file metadata setting or listing 236 requests such as ACL or unix permission setting or listing. This 237 mapping is needed because NFSv4 messages use identity 238 representations of the form name@domain which normally differs 239 from the server's local representation of identity. 241 3.2. NFSv4 Client Identity Mapping 243 A client setting the owner or group attribute will often need access 244 to identity mapping services. This is because API's within the 245 client will specify the identity in a local form (e.g UNIX using a 246 uid/gid) so that when stringified id's cannot be used, the id must be 247 converted to a global form. 249 A client obtaining value for the owner or group attributes will 250 similarly need access to identity mapping services. This is because 251 the client API will need these attributes in a a local form, as 252 above. As a result name services need to be available to convert the 253 global identity to a local form. 255 Note that each of these situations arises because client-side API's 256 require a particular local identity representation. The need for 257 mapping services would not arise if the clients could use the global 258 representation of identity directly. 260 4. Stand-alone NFSv4 Domain Deployment Examples 262 In order to service as many environments as possible, the NFSv4 263 protocol is designed to allow administrators freedom to configure 264 their NFSv4 domains as they please. 266 Stand-alone NFSv4 domains can be run in many ways. Here we list some 267 stand-alone NFSv4 domain deployment examples focusing on the NFSv4 268 server's use of name service mappings (Section 3.1) and security 269 services deployment to demonstrate the need for some multiple NFSv4 270 domain constraints to the NFSv4 protocol, name service configuration, 271 and security service choices. 273 Because all on-disk identities participating in a stand-alone NFSv4 274 domain belong to the same NFSv4 domain, stand-alone NFSv4 domain 275 deployments have no requirement for exporting multi-domain capable 276 file systems. 278 Note that stringified identifiers, which are limited to 32 bit 279 unsigned quantities, cannot be validly used to set or interrogate 280 ACL's. This is because a given numeric value may represent the user 281 with that value as a uid and the group with that value as a gid. As 282 there is no way to resolve this ambiguity, aces cannot contain 283 stringified id's to represent a particular identity. This is opposed 284 to identities of the form name@domain, for which the mapping process 285 will determine both the associated local ID and indicate whether a 286 user or group is being designated. 288 These examples are for a NFSv4 server exporting a POSIX UID/GID based 289 file system, a typical deployment. These examples are listed in the 290 order of increasing NFSv4 administrative complexity. 292 4.1. AUTH_SYS with Stringified UID/GID 294 This example is the closest NFSv4 gets to being run as NFSv3. 296 File access: The AUTH_SYS RPC credential provides a UID as the 297 authentication identity, and a list of GIDs as authorization context 298 information. File access decisions require no name service 299 interaction as the on-the-wire and on-disk representation are the 300 same and the auth-to-authz UID and GID authorization context 301 information is provided in the RPC credential. 303 Meta-data setting and listing: When the NFSv4 clients and servers 304 implement a stringified UID/GID scheme, where a stringified UID or 305 GID is used for the NFSv4 name@domain on-the-wire identity, then a 306 name service is not required for file metadata listing as the UID or 307 GID can be constructed from the stringified form on the fly by the 308 server. 310 4.2. AUTH_SYS with name@domain 312 Another possibility is express identity using the form 'name@domain', 313 rather than using use a stringified UID/GID scheme for file metadata 314 setting and listing. 316 File access: This is the same as in Section 4.1. 318 Meta-data setting and listing: The NFSv4 server will need to use a 319 name service for the wire-to-disk mappings to map between the on-the- 320 wire name@domain syntax and the on-disk UID/GID representation. 321 Often, the NFSv4 server will use the nsswitch interface for these 322 mappings. A typical use of the nsswitch name service interface uses 323 no domain component, just the uid attribute [RFC2307] (or login name) 324 as the name component. This is no issue in a stand-alone NFSv4 325 domain deployment as the NFSv4 domain is known to the NFSv4 server 326 and can combined with the login name to form the name@domain syntax 327 after the return of the name service call. 329 4.3. RPCSEC_GSS with name@domain 331 RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely 332 authenticate users to servers. The most common mechanism is Kerberos 333 [RFC4121]. 335 This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS 336 security mechanism. 338 File Access: The forms of GSS principal names are mechanism-specific. 339 For Kerberos these are of the form principal@REALM. Sometimes 340 authorization context information is delivered with authentication, 341 but this cannot be counted on. Authorization context information 342 delivered with authentication has timely update considerations (i.e., 343 generally it's not possible to get a timely update). File access 344 decisions therefore require a wire-to-disk mapping of the GSS 345 principal to a UID, and an auth-to-authz mapping to obtain the list 346 of GIDs as the authorization context. 348 Implementations must never blindly drop a Kerberos REALM name from a 349 Kerberos principal name to obtain a POSIX username, but they may be 350 configured to do so for specific REALMs. 352 Meta-data setting and listing: This is the same as in Section 4.2. 354 5. Multi-domain Constraints to the NFSv4 Protocol 356 Joining NFSv4 domains under a single file namespace imposes slightly 357 on the NFSv4 administration freedom. Here we describe the required 358 constraints. 360 5.1. Name@domain Constraints 362 NFSv4 uses a syntax of the form "name@domain" as the on-the-wire 363 representation of the "who" field of an NFSv4 access control entry 364 (ACE) for users and groups. This design provides a level of 365 indirection that allows NFSv4 clients and servers with different 366 internal representations of authorization identity to interoperate 367 even when referring to authorization identities from different NFSv4 368 domains. 370 Multi-domain capable sites need to meet the following requirements in 371 order to ensure that NFSv4 clients and servers can map between 372 name@domain and internal representations reliably. While some of 373 these constraints are basic assumptions in NFSv4.0 [RFC7530] and 374 NFSv4.1 [RFC5661], they need to be clearly stated for the multi- 375 domain case. 377 o The NFSv4 domain portion of name@domain MUST be unique within the 378 multi-domain namespace. See [RFC5661] section 5.9 "Interpreting 379 owner and owner_group" for a discussion on NFSv4 domain 380 configuration. 382 o The name portion of name@domain MUST be unique within the 383 specified NFSv4 domain. 385 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 386 in a multi-domain deployment. This means that multi-domain-capable 387 servers MUST reject requests that use stringified UID/GIDs. 389 5.1.1. NFSv4 Domain and DNS Services 391 Here we address the relationship between NFSv4 domain name and DNS 392 domain name in a multi-domain deployment. 394 The definition of an NFSv4 domain name needs clarification to work in 395 a multi-domain file system namespace. Section 5.9 [RFC5661] loosely 396 defines the NFSv4 domain name as a DNS domain name. This loose 397 definition for the NFSv4 domain is a good one, as DNS domain names 398 are globally unique. As noted above in Section 5.1, any choice of 399 NFSv4 domain name can work within a stand-alone NFSv4 domain 400 deployment whereas the NFSv4 domain is required to be unique in a 401 multi-domain deployment. 403 A typical configuration is that there is a single NFSv4 domain that 404 is served by a single DNS domain. In this case the NFSv4 domain name 405 can be the same as the DNS domain name. 407 An NFSv4 domain can span multiple DNS domains. In this case, one of 408 the DNS domain names can be chosen as the NFSv4 domain name. 410 Multiple NFSv4 domains can also share a DNS domain. In this case, 411 only one of the NFSv4 domains can use the DNS domain name, the other 412 NFSv4 domains must choose another unique NFSv4 domain name. 414 5.1.2. NFSv4 Domain and Name Services 416 As noted above in Section 5.1, each name@domain is unique across the 417 multi-domain namespace and maps, on each NFSv4 server, to the local 418 representation of identity used by that server. Typically, this 419 representation consists of an indication of the particular domain 420 combined with the uid/gid corresponding to the name component. To 421 support such an arrangement, each NFSv4 domain needs to have a single 422 name resolution service capable of converting the names defined 423 within the domain to the corresponding uid/gid. 425 5.2. RPC Security Constraints 427 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 429 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 430 (This requirement to implement is not a requirement 431 to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, 432 MAY be implemented as well. 434 The underlying RPCSEC_GSS security mechanism used in a multi-domain 435 namespace is REQUIRED to employ a method of cross NFSv4 domain trust 436 so that a principal from a security service in one NFSv4 domain can 437 be authenticated in another NFSv4 domain that uses a security service 438 with the same security mechanism. Kerberos, and PKU2U 439 [I-D.zhu-pku2u] are examples of such security services. 441 The AUTH_NONE security flavor can be useful in a multi-domain 442 deployment to grant universal access to public data without any 443 credentials. 445 The AUTH_SYS security flavor uses a host-based authentication model 446 where the weakly authenticated host (the NFSv4 client) asserts the 447 user's authorization identities using small integers, uidNumber, and 448 gidNumber [RFC2307], as user and group identity representations. 449 Because this authorization ID representation has no domain component, 450 AUTH_SYS can only be used in a namespace where all NFSv4 clients and 451 servers share an [RFC2307] name service. A shared name service is 452 required because uidNumbers and gidNumbers are passed in the RPC 453 credential; there is no negotiation of namespace in AUTH_SYS. 454 Collisions can occur if multiple name services are used, so AUTH_SYS 455 MUST NOT be used in a multi-domain file system deployment. 457 While the AUTH_SYS security mechanism can not be used (indeed, 458 AUTH_SYS is obsolete and of limited use for all of NFS), RPCSEC_GSSv3 459 [I-D.rpcsec-gssv3] can completely replace all uses of AUTH_SYS in a 460 multi-domain file system. Like AUTH_SYS, and unlike RPCSEC_GSSv1/2, 461 RPCSEC_GSSv3 allows the client to assert and contribute knowledge of 462 the user process' authorization context. 464 5.2.1. NFSv4 Domain and Security Services 466 As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 467 domain security services are RPCSEC_GSS based with the Kerberos 5 468 security mechanism being the most commonly (and as of this writing, 469 the only) deployed service. 471 A single Kerberos 5 security service per NFSv4 domain with the upper 472 case NFSv4 domain name as the Kerberos 5 REALM name is a common 473 deployment. 475 Multiple security services per NFSv4 domain is allowed, and brings 476 the issue of mapping multiple Kerberos 5 principal@REALMs to the same 477 local ID. Methods of achieving this are beyond the scope of this 478 document. 480 6. Resolving Multi-domain Authorization Information 482 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 483 server, after authenticating the principal, the server must obtain in 484 a secure manner the principal's authorization context information 485 from an authoritative source such as the name service in the 486 principal's NFSv4 domain. 488 In the stand-alone NFSv4 domain case where the principal is seeking 489 access to files on an NFSv4 server in the principal's home NFSv4 490 domain, the server administrator has knowledge of the local policies 491 and methods for obtaining the principal's authorization information 492 and the mappings to local representation of identity from an 493 authoritative source. E.g., the administrator can configure secure 494 access to the local NFSv4 domain name service. 496 In the multi-domain case where a principal is seeking access to files 497 on an NFSv4 server not in the principal's home NFSv4 domain, the 498 NFSv4 server may be required to contact the remote name service in 499 the principals NFSv4 domain. In this case there is no assumption of: 501 o Remote name service configuration knowledge 503 o The syntax of the remote authorization context information 504 presented to the NFSv4 server by the remote name service for 505 mapping to a local representation. 507 There are several methods the NFSv4 server can use to obtain the 508 NFSv4 domain authoritative authorization information for a remote 509 principal from an authoritative source. While any detail is beyond 510 the scope of this document, some general methods are listed here. 512 1. A mechanism specific GSS-API authorization payload containing 513 credential authorization data such as a "privilege attribute 514 certificate" (PAC) [PAC] or a "general PAD" (PAD) 515 [I-D.sorce-krbwg-general-pac]. This is the preferred method as 516 the payload is delivered as part of GSS-API authentication, 517 avoids requiring any knowledge of the remote authoritative 518 service configuration, and its syntax is well known. 520 2. When there is a security agreement between the local and remote 521 NFSv4 domain name services plus regular update data feeds, the 522 NFSv4 server local NFSv4 domain name service can be authoritative 523 for principal's in the remote NFSv4 domain. In this case, the 524 NFSv4 server makes a query to it's local NFSv4 domain name 525 service just as it does when servicing a local domain principal. 526 While this requires detailed knowledge of the remote NFSv4 527 domains name service, the authorization context information 528 presented to the NFSv4 server is in the same form as a query for 529 a local principal. 531 3. An authenticated direct query from the NFSv4 server to the 532 principal's NFSv4 domain authoritative name service. This 533 requires the NFSv4 server to have detailed knowledge of the 534 remote NFSv4 domain's authoritative name service and detailed 535 knowledge of the syntax of the resultant authorization context 536 information. 538 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 540 Revisiting the stand-alone (Section 4) NFSv4 domain deployment 541 examples, we note that due to the use of AUTH_SYS, neither 542 Section 4.1 nor Section 4.2 configurations are suitable for multi- 543 domain deployments. 545 The Section 4.3 configuration example can participate in a multi- 546 domain namespace deployment if: 548 o The NFSv4 domain name is unique across the namespace. 550 o All exported file systems are multi-domain capable. 552 o A secure method is used to resolve remote NFSv4 domain principals 553 authorization information from an authoritative source. 555 8. Security Considerations 557 This RFC discusses security throughout. All the security 558 considerations of the relevant protocols, such as NFSv4.0 [RFC7530], 559 NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP 560 [RFC4511], and others, apply. 562 Authentication and authorization across administrative domains 563 presents security considerations, most of which are treated 564 elsewhere, but we repeat some of them here: 566 o latency in propagation of revocation of authentication credentials 567 o latency in propagation of revocation of authorizations 569 o latency in propagation of granting of authorizations 571 o complications in establishing a foreign domain's users' complete 572 authorization context: only parts may be available to servers 574 o privacy considerations in a federated environment 576 Most of these are security considerations of the mechanisms used to 577 authenticate users to servers and servers to users, and of the 578 mechanisms used to evaluate a user's authorization context. We don't 579 treat them fully here, but implementors should study the protocols in 580 question to get a more complete set of security considerations. 582 Note that clients/users may also need to evaluate a server's 583 authorization context when using labeled security [I-D.NFSv4.2] 584 (e.g., is the server authorized to handle content at a given security 585 level, for the given compartments). Even when not using labeled 586 security, since there could be many realms (credential issuer) for a 587 given server, it's important to verify that the server a client is 588 talking to has a credential for the name the client has for the 589 server, and that that credential's issuer (i.e., its realm) is 590 allowed to issue it. Usually the service principle realm 591 authorization function is implemented by the security mechanism, but 592 the implementor should check this. 594 Implementors may be tempted to assume that realm (or "issuer") and 595 NFSv4 domain are roughly the same thing, but they are not. 596 Configuration and/or lookup protocols (such as LDAP) and associated 597 schemas are generally required in order to evaluate a user 598 principal's authorization context. In the simplest scheme a server 599 has access to a database mapping all known principal names to 600 usernames whose authorization context can be evaluated using 601 operating system interfaces that deal in usernames rather than 602 principal names. 604 9. Normative References 606 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 607 Internet File System (CIFS) Protocol", January 2013. 609 [I-D.NFSv4.2] 610 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 611 nfsv4-minorversion2-36 (Work In Progress), April 2015. 613 [I-D.rpcsec-gssv3] 614 Adamson, W. and N. Williams, "Remote Procedure Call (RPC) 615 Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-12 616 (Work In Progress), July 2015. 618 [I-D.sorce-krbwg-general-pac] 619 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 620 Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In 621 Progress awaiting merge with other document ), June 2011. 623 [I-D.zhu-pku2u] 624 Zhu, L., Altman, J., and N. Williams, "Public Key 625 Cryptography Based User-to-User Authentication - (PKU2U)", 626 draft-zhu-pku2u-09 (Work In Progress), November 2008. 628 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 629 in Kerberos Tickets for Access Control to Resources", 630 October 2002. 632 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 633 RFC 1034, November 1987. 635 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 636 Requirement Levels", RFC 2119, March 1997. 638 [RFC2203] Eisler, M. and J. Linn, "RPCSEC_GSS Protocol 639 Specification", RFC 2203, September 1997. 641 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 642 Information Service", RFC 2307, March 1998. 644 [RFC2743] Linn, J., "Generic Security Service Application Program 645 Interface Version 2, Update 1", RFC 2743, January 2000. 647 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 648 Version 5 Generic Security Service Application Program 649 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 650 2005. 652 [RFC4511] Sermersheim, Ed., J., "Lightweight Directory Access 653 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 655 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 656 System (NFS) Version 4 Minor Version 1 Protocol", RFC 657 5661, January 2010. 659 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 660 Naik, "Requirements for Federated File Systems", RFC 5716, 661 January 2010. 663 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 664 version 4 Protocol", RFC 7530, March 2015. 666 Appendix A. Acknowledgments 668 Andy Adamson would like to thank NetApp, Inc. for its funding of his 669 time on this project. 671 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 672 David Noveck for their review. 674 Authors' Addresses 676 William A. (Andy) Adamson 677 NetApp 679 Email: andros@netapp.com 681 Nicolas Williams 682 Cryptonector 684 Email: nico@cryptonector.com