idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-03.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 7, 2015) is 3184 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) == Unused Reference: 'I-D.rpcsec-gssv3' is defined on line 587, but no explicit reference was found in the text -- 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 (~~), 3 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 8, 2016 Cryptonector 6 August 7, 2015 8 Multiple NFSv4 Domain Namespace Deployment Guidelines 9 draft-ietf-nfsv4-multi-domain-fs-reqs-03 11 Abstract 13 This document describes administrative constraints to the deployment 14 of the NFSv4 protocols required for the construction of an NFSv4 file 15 system namespace supporting the use of multiple NFSv4 domains and 16 utilizing multi-domain capable file systems. Also described are 17 administrative constraints to name resolution and security services 18 appropriate to such a system. Such a namespace is a suitable way to 19 enable a Federated File System supporting the use of multiple NFSv4 20 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 8, 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. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . . . 5 65 4. Stand-alone NFSv4 Domain Deployment Examples . . . . . . . . 5 66 4.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . . 6 67 4.2. AUTH_SYS with name@domain . . . . . . . . . . . . . . . . . 6 68 4.3. RPCSEC_GSS with name@domain . . . . . . . . . . . . . . . . 7 69 5. Multi-domain Constraints to the NFSv4 Protocol . . . . . . . 7 70 5.1. Name@domain Constraints . . . . . . . . . . . . . . . . . . 7 71 5.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . . . 8 72 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 8 73 5.2. RPC Security Constraints . . . . . . . . . . . . . . . . . 9 74 5.2.1. NFSv4 Domain and Security Services . . . . . . . . . . . 10 75 6. Resolving Multi-domain Authorization Information . . . . . . 10 76 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 An NFSv4 domain is defined as a set of users, groups and computers 85 running NFSv4 protocols (NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and 86 NFSv4.2 [I-D.NFSv4.2] as of this writing) identified by an NFSv4 87 domain name. 89 The Federated File System (FedFS) [RFC5716] describes the 90 requirements and administrative tools to construct a uniform NFSv4 91 file server based namespace that is capable of spanning a whole 92 enterprise and that is easy to manage. 94 The FedFS is the standardized method of constructing and 95 administrating an enterprise wide NFSv4 filesystem, and so is 96 referenced in this document. The issues with multiple NFSv4 domain 97 file systems described in this document apply to all multiple NFSv4 98 domain file systems, be they run as a FedFS or not. 100 Stand-alone NFSv4 domains can be run in many ways. While a FedFS can 101 be run within all stand-alone NFSv4 domain configurations some of 102 these configurations (Section 4) are not compatible with joining a 103 multiple NFSv4 domain FedFS namespace. 105 Multi NFSv4 domain file systems require support for global identities 106 in name services, security services, and in the exporting of on-disk 107 local identity representation. Many of the stand-alone NFSv4 domain 108 deployments do not provide full support for global identities. 110 This document describes administrative constraints to the deployment 111 of the NFSv4 protocols required for the construction of an NFSv4 file 112 system namespace supporting the use of multiple NFSv4 domains and 113 utilizing multi-domain capable file systems. Also described are 114 administrative constraints to name resolution and security services 115 appropriate to such a system. Such a namespace is a suitable way to 116 enable a Federated File System supporting the use of multiple NFSv4 117 domains. 119 2. Terminology 121 Name Service: provides the mapping between {NFSv4 domain, group or 122 user name} and {NFSv4 domain, local ID}, as well as the mapping 123 between {security principal} and {NFSv4 domain, local ID} via 124 lookups. Can be applied to local or remote domains. Often 125 provided by a Directory Service such as LDAP. 127 Name Service Switch (nsswitch): a facility in provides a variety 128 of sources for common configuration databases and name resolution 129 mechanisms. 131 Domain: This term is used in multiple contexts where it has 132 different meanings. Here we provide specific definitions used in 133 this document. 135 DNS domain: a set of computers, services, or any internet 136 resource identified by an DNS domain name [RFC1034]. 138 Security realm or domain: a set of configured security 139 providers, users, groups, security roles, and security policies 140 running a single security protocol and administered by a single 141 entity, for example a Kerberos realm. 143 NFSv4 domain: a set of users, groups, and computers running 144 NFSv4 protocols identified by a unique NFSv4 domain name. See 145 [RFC5661] Section 5.9 "Interpreting owner and owner_group". 147 Multi-domain: In this document this always refers to multiple 148 NFSv4 domains. 150 FedFS domain: A file namespace that can cross multiple shares 151 on multiple file servers using file-access protocols such as 152 NFSv4. A FedFS domain is typically a single administrative 153 entity, and has a name that is similar to a DNS domain name. 154 Also known as a Federation. 156 Administrative domain: a set of users, groups, computers, and 157 services administered by a single entity. Can include multiple 158 DNS domains, NFSv4 domains, security domains, and FedFS 159 domains. 161 Local representation of identity: an object such as a uidNumber 162 (UID) or gidNumber (GID) [RFC2307], a Windows Security Identifier 163 (SID) [CIFS], or other such representation of a user or a group of 164 users on-disk in a file system. 166 Global identity: An on-the-wire globally unique form of identity 167 that can be mapped to a local representation. For example, the 168 NFSv4 name@domain or the Kerberos principal@REALM. 170 Multi-domain capable filesystem: A local filesystem that uses a 171 local ID form that can represent identities from both local and 172 remote domains. For example, an SSID based local ID form where 173 the SSID contains both a domain and a user or group component. 175 Principal: an RPCSEC_GSS authentication identity. Usually, but 176 not always, a user; rarely, if ever, a group; sometimes a host or 177 server. 179 Authorization Context: A collection of information about a 180 principal such as username, userID, group membership, etcetera 181 used in authorization decisions. 183 Stringified UID or GID: NFSv4 owner and group strings that consist 184 of decimal numeric values with no leading zeros, and which do not 185 contain an '@' sign. See Section 5.9 "Interpreting owner and 186 owner_group" [RFC5661]. 188 3. NFSv4 Server Identity Mapping 190 NFSv4 servers deal with two kinds of identities: authentication 191 identities (referred to here as "principals") and authorization 192 identities ("users" and "groups" of users). NFSv4 supports multiple 193 authentication methods, each authenticating an "initiator principal" 194 (typically representing a user) to an "acceptor principal" (always 195 corresponding to the NFSv4 server). NFSv4 does not prescribe how to 196 represent authorization identities on file systems. All file access 197 decisions constitute "authorization" and are made by NFSv4 servers 198 using authorization context information and file metadata related to 199 authorization, such as a file's access control list (ACL). 201 NFSv4 servers therefore must perform two kinds of mappings: 203 1. Auth-to-authz: A mapping between the authentication identity and 204 the authorization context information. 206 2. Wire-to-disk: A mapping between the on-the-wire authorization 207 identity representation and the on-disk authorization identity 208 representation. 210 A Name Service such as LDAP often provides these mappings. 212 Many aspects of these mappings are entirely implementation specific, 213 but some require multi-domain capable name resolution and security 214 services in order to interoperate in a multiple NFSv4 domain file 215 system. 217 NFSv4 servers use these mappings for: 219 1. File access: Both the auth-to-authz and the wire-to-disk mappings 220 may be required for file access decisions. 222 2. Meta-data setting and listing: The auth-to-authz mapping is 223 usually required to service file metadata setting or listing 224 requests (such as ACL or unix permission setting or listing) as 225 NFSv4 uses the name@domain on-the-wire identity representation 226 which usually differs from the exported on-disk identity 227 representation. 229 4. Stand-alone NFSv4 Domain Deployment Examples 231 In order to service as many environments as possible, the NFSv4 232 protocol is designed to allow administrators freedom to configure 233 their NFSv4 domains as they please. 235 Stand-alone NFSv4 domains can be run in many ways. Here we list some 236 stand-alone NFSv4 domain deployment examples focusing on the NFSv4 237 server's use of name service mappings (Section 3) and security 238 services deployment to demonstrate the need for some multiple NFSv4 239 domain constraints to the NFSv4 protocol, name service configuration, 240 and security service choices. 242 Because all on-disk identities participating in a stand-alone NFSv4 243 domain belong to the same NFSv4 domain, stand-alone NFSv4 domain 244 deployments have no requirement for exporting multi-domain capable 245 file systems. 247 These examples are for a NFSv4 server exporting a POSIX UID/GID based 248 file system, a typical deployment. These examples are listed in the 249 order of increasing NFSv4 administrative complexity. 251 4.1. AUTH_SYS with Stringified UID/GID 253 This example is the closest NFSv4 gets to being run as NFSv3. 255 File access: The AUTH_SYS RPC credential provides a UID as the 256 authentication identity, and a list of GIDs as authorization context 257 information. File access decisions require no name service 258 interaction as the on-the-wire and on-disk representation are the 259 same and the auth-to-authz UID and GID authorization context 260 information is provided in the RPC credential. 262 Meta-data setting and listing: When the NFSv4 clients and servers 263 implement a stringified UID/GID scheme, where a stringified UID or 264 GID is used for the NFSv4 name@domain on-the-wire identity, then a 265 name service is not required for file metadata listing as the UID or 266 GID can be constructed from the stringified form on the fly by the 267 server. 269 4.2. AUTH_SYS with name@domain 271 The next level of complexity is to not use a stringified UID/GID 272 scheme for file metadata listing. 274 File access: This is the same as in Section 4.1. 276 Meta-data setting and listing: The NFSv4 server will need to use a 277 name service for the wire-to-disk mappings to map between the on-the- 278 wire name@domain syntax and the on-disk UID/GID representation. 279 Often, the NFSv4 server will use the nsswitch interface for these 280 mappings. A typical use of the nsswitch name service interface uses 281 no domain component, just the uid attribute [RFC2307] (or login name) 282 as the name component. This is no issue in a stand-alone NFSv4 283 domain deployment as the NFSv4 domain is known to the NFSv4 server 284 and can combined with the login name to form the name@domain syntax 285 after the return of the name service call. 287 4.3. RPCSEC_GSS with name@domain 289 RPCSEC_GSS uses GSS-API [RFC2743] security mechanisms to securely 290 authenticate users to servers. The most common mechanism is Kerberos 291 [RFC4121]. 293 This final example adds the complexity of RPCSEC_GSS with the 294 Kerberos 5 GSS security mechanism. 296 File Access: The forms of GSS principal names are mechanism-specific. 297 For Kerberos these are of the form principal@REALM. Sometimes 298 authorization context information is delivered with authentication, 299 but this cannot be counted on. Authorization context information 300 delivered with authentication has timely update considerations (i.e., 301 generally it's not possible to get a timely update). File access 302 decisions therefore require a wire-to-disk mapping of the GSS 303 principal to a UID, and an auth-to-authz mapping to obtain the list 304 of GIDs as the authorization context. 306 Implementations must never blindly drop a Kerberos REALM name from a 307 Kerberos principal name to obtain a POSIX username, but they may be 308 configured to do so for specific REALMs. 310 Meta-data setting and listing: This is the same as in Section 4.2. 312 5. Multi-domain Constraints to the NFSv4 Protocol 314 Joining NFSv4 domains under a single file namespace imposes slightly 315 on the NFSv4 administration freedom. Here we describe the required 316 constraints. 318 5.1. Name@domain Constraints 320 NFSv4 uses a syntax of the form "name@domain" as the on wire 321 representation of the "who" field of an NFSv4 access control entry 322 (ACE) for users and groups. This design provides a level of 323 indirection that allows NFSv4 clients and servers with different 324 internal representations of authorization identity to interoperate 325 even when referring to authorization identities from different NFSv4 326 domains. 328 Multiple NFSv4 domain capable sites need to meet the following 329 requirements in order to ensure that NFSv4 clients and servers can 330 map between name@domain and internal representations reliably. While 331 some of these constraints are basic assumptions in NFSv4.0 [RFC7530] 332 and NFSv4.1 [RFC5661], they need to be clearly stated for the 333 multiple NFSv4 domain case. 335 o The NFSv4 domain portion of name@domain MUST be unique within the 336 multiple NFSv4 domain namespace. See [RFC5661] section 5.9 337 "Interpreting owner and owner_group" for a discussion on NFSv4 338 domain configuration. 340 o The name portion of name@domain MUST be unique within the 341 specified NFSv4 domain. 343 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 344 in a multiple NFSv4 domain file system. This means that multi- 345 domain-capable servers MUST reject requests that use stringified UID/ 346 GIDs. 348 5.1.1. NFSv4 Domain and DNS Services 350 Here we address the relationship between NFSv4 domain name and DNS 351 domain name in a multiple NFSv4 domain deployment. 353 The definition of an NFSv4 domain name needs clarification to work in 354 a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661] 355 loosely defines the NFSv4 domain name as a DNS domain name. This 356 loose definition for the NFSv4 domain is a good one, as DNS domain 357 names are globally unique. As noted above in Section 5.1, any choice 358 of NFSv4 domain name can work within a stand-alone NFSv4 domain 359 deployment whereas the NFSv4 domain is required to be unique in a 360 multiple NFSv4 domain deployment. 362 A typical configuration is that there is a single NFSv4 domain that 363 is served by a single DNS domain. In this case the NFSv4 domain name 364 can be the same as the DNS domain name. 366 An NFSv4 domain can span multiple DNS domains. In this case, one of 367 the DNS domain names can be chosen as the NFSv4 domain name. 369 Multiple NFSv4 domains can also share a DNS domain. In this case, 370 only one of the NFSv4 domains can use the DNS domain name, the other 371 NFSv4 domains must choose another unique NFSv4 domain name. 373 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 375 As noted above in Section 5.1, each name@domain is unique across the 376 multiple NFSv4 domain namespace, and maps to a local representation 377 of ID in each NFSv4 domain. This means that each NFSv4 domain has a 378 single name resolution service exporting the NFSv4 domain local ID 379 namespace. 381 An NFSv4 domain administrator that wants to give NFSv4 local file 382 access to a remote user from a remote NFSv4 domain needs to create a 383 local ID for the remote user which can then be assigned on-disk and 384 used for local access decisions. Since the local ID for the remote 385 user must be able to be mapped to a name@remote-domain, only multi- 386 domain capable file systems can be exported in a multiple NFSv4 387 domain namespace. 389 We note that many file systems exported by NFSv4 use POSIX UID and 390 GIDs as a local ID form and as this local ID form has no domain 391 component, these file systems are not domain aware and can not easily 392 participate in a multiple NFSv4 domain namespace. There are ways to 393 overcome this deficiency, but these practices are beyond the scope of 394 this document. 396 5.2. RPC Security Constraints 398 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 400 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 401 (This requirement to implement is not a requirement 402 to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, 403 MAY be implemented as well. 405 The underlying RPCSEC_GSS security mechanism used in a multiple NFSv4 406 domain namespace is REQUIRED to employ a method of cross NFSv4 domain 407 trust so that a principal from a security service in one NFSv4 domain 408 can be authenticated in another NFSv4 domain that uses a security 409 service with the same security mechanism. Kerberos, and PKU2U 410 [I-D.zhu-pku2u] are examples of such security services. 412 The AUTH_NONE security flavor can be useful in a multiple NFSv4 413 domain namespace to grant universal access to public data without any 414 credentials. 416 The AUTH_SYS security flavor uses a host-based authentication model 417 where the weakly authenticated host (the NFSv4 client) asserts the 418 user's authorization identities using small integers, uidNumber, and 419 gidNumber [RFC2307], as user and group identity representations. 420 Because this authorization ID representation has no domain component, 421 AUTH_SYS can only be used in a namespace where all NFSv4 clients and 422 servers share an [RFC2307] name service. A shared name service is 423 required because uidNumbers and gidNumbers are passed in the RPC 424 credential; there is no negotiation of namespace in AUTH_SYS. 426 Collisions can occur if multiple name services are used, so AUTH_SYS 427 MUST NOT be used in a multiple NFSv4 domain file system. 429 While the AUTH_SYS security mechanism can not be used (indeed, 430 AUTH_SYS is obsolete and of limited use for all of NFS), RPCSEC_GSSv3 431 can completely replace all uses of AUTH_SYS in a multiple NFSv4 432 domain file system. Like AUTH_SYS, and unlike RPCSEC_GSSv1/2, 433 RPCSEC_GSSv3 allows the client to assert and contribute knowledge of 434 the user process' authorization context. 436 5.2.1. NFSv4 Domain and Security Services 438 As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 439 domain security services are RPCSEC_GSS based with the Kerberos 5 440 security mechanism being the most commonly (and as of this writing, 441 the only) deployed service. 443 A single Kerberos 5 security service per NFSv4 domain with the upper 444 case NFSv4 domain name as the Kerberos 5 REALM name is a common 445 deployment. 447 Multiple security services per NFSv4 domain is allowed, and brings 448 the issue of mapping multiple Kerberos 5 principal@REALMs to the same 449 local ID. Methods of achieving this are beyond the scope of this 450 document. 452 6. Resolving Multi-domain Authorization Information 454 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 455 server, after authenticating the principal, the server must obtain in 456 a secure manner the principal's authorization context information 457 from an authoritative source such as the name service in the 458 principal's NFSv4 domain. 460 In the stand-alone NFSv4 domain case where the principal is seeking 461 access to files on an NFSv4 server in the principal's home NFSv4 462 domain, the server administrator has knowledge of the local policies 463 and methods for obtaining the principal's authorization information 464 and the mappings to local representation of identity from an 465 authoritative source. E.g., the administrator can configure secure 466 access to the local NFSv4 domain name service. 468 In the multiple NFSv4 domain case where a principal is seeking access 469 to files on an NFSv4 server not in the principal's home NFSv4 domain, 470 the NFSv4 server may be required to contact the remote name service 471 in the principals NFSv4 domain. In this case there is no assumption 472 of: 474 o Remote name service configuration knowledge 476 o The syntax of the remote authorization context information 477 presented to the NFSv4 server by the remote name service for 478 mapping to a local representation. 480 There are several methods the NFSv4 server can use to obtain the 481 NFSv4 domain authoritative authorization information for a remote 482 principal from an authoritative source. While any detail is beyond 483 the scope of this document, some general methods are listed here. 485 1. A mechanism specific GSS-API authorization payload containing 486 credential authorization data such as a "privilege attribute 487 certificate" (PAC) [PAC] or a "general PAD" (PAD) 488 [I-D.sorce-krbwg-general-pac]. This is the preferred method as 489 the payload is delivered as part of GSS-API authentication, 490 avoids requiring any knowledge of the remote authoritative 491 service configuration, and its syntax is well known. 493 2. When there is a security agreement between the local and remote 494 NFSv4 domain name services plus regular update data feeds, the 495 NFSv4 server local NFSv4 domain name service can be authoritative 496 for principal's in the remote NFSv4 domain. In this case, the 497 NFSv4 server makes a query to it's local NFSv4 domain name 498 service just as it does when servicing a local domain principal. 499 While this requires detailed knowledge of the remote NFSv4 500 domains name service, the authorization context information 501 presented to the NFSv4 server is in the same form as a query for 502 a local principal. 504 3. An authenticated direct query from the NFSv4 server to the 505 principal's NFSv4 domain authoritative name service. This 506 requires the NFSv4 server to have detailed knowledge of the 507 remote NFSv4 domain's authoritative name service and detailed 508 knowledge of the syntax of the resultant authorization context 509 information. 511 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 513 Revisiting the stand-alone (Section 4) NFSv4 domain deployment 514 examples, we note that due to the use of AUTH_SYS, neither 515 Section 4.1 nor Section 4.2 configurations are suitable for multiple 516 NFSv4 domain deployments. 518 The Section 4.3 configuration example can participate in a multiple 519 NFSv4 domain namespace deployment if: 521 o The NFSv4 domain name is unique across the namespace. 523 o All exported file systems are multi-domain capable. 525 o A secure method is used to resolve remote NFSv4 domain principals 526 authorization information from an authoritative source. 528 8. Security Considerations 530 This RFC discusses security throughout. All the security 531 considerations of the relevant protocols, such as NFSv4.0 [RFC7530], 532 NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP 533 [RFC4511], and others, apply. 535 Authentication and authorization across administrative domains 536 presents security considerations, most of which are treated 537 elsewhere, but we repeat some of them here: 539 o latency in propagation of revocation of authentication credentials 541 o latency in propagation of revocation of authorizations 543 o latency in propagation of granting of authorizations 545 o complications in establishing a foreign domain's users' complete 546 authorization context: only parts may be available to servers 548 o privacy considerations in a federated environment 550 Most of these are security considerations of the mechanisms used to 551 authenticate users to servers and servers to users, and of the 552 mechanisms used to evaluate a user's authorization context. We don't 553 treat them fully here, but implementors should study the protocols in 554 question to get a more complete set of security considerations. 556 Note that clients/users may also need to evaluate a server's 557 authorization context when using labeled security (e.g., is the 558 server authorized to handle content at a given security level, for 559 the given compartments). Even when not using labeled security, since 560 there could be many realms (credential issuer) for a given server, 561 it's important to verify that the server a client is talking to has a 562 credential for the name the client has for the server, and that that 563 credential's issuer (i.e., its realm) is allowed to issue it. 564 Usually the service principle realm authorization function is 565 implemented by the security mechanism, but the implementor should 566 check this. 568 Implementors may be tempted to assume that realm (or "issuer") and 569 NFSv4 domain are roughly the same thing, but they are not. 570 Configuration and/or lookup protocols (such as LDAP) and associated 571 schemas are generally required in order to evaluate a user 572 principal's authorization context. In the simplest scheme a server 573 has access to a database mapping all known principal names to 574 usernames whose authorization context can be evaluated using 575 operating system interfaces that deal in usernames rather than 576 principal names. 578 9. Normative References 580 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 581 Internet File System (CIFS) Protocol", January 2013. 583 [I-D.NFSv4.2] 584 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 585 nfsv4-minorversion2-36 (Work In Progress), April 2015. 587 [I-D.rpcsec-gssv3] 588 Adamson, W. and N. Williams, "Remote Procedure Call (RPC) 589 Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-12 590 (Work In Progress), July 2015. 592 [I-D.sorce-krbwg-general-pac] 593 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 594 Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In 595 Progress awaiting merge with other document ), June 2011. 597 [I-D.zhu-pku2u] 598 Zhu, L., Altman, J., and N. Williams, "Public Key 599 Cryptography Based User-to-User Authentication - (PKU2U)", 600 draft-zhu-pku2u-09 (Work In Progress), November 2008. 602 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 603 in Kerberos Tickets for Access Control to Resources", 604 October 2002. 606 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 607 RFC 1034, November 1987. 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", RFC 2119, March 1997. 612 [RFC2203] Eisler, M. and J. Linn, "RPCSEC_GSS Protocol 613 Specification", RFC 2203, September 1997. 615 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 616 Information Service", RFC 2307, March 1998. 618 [RFC2743] Linn, J., "Generic Security Service Application Program 619 Interface Version 2, Update 1", RFC 2743, January 2000. 621 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 622 Version 5 Generic Security Service Application Program 623 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 624 2005. 626 [RFC4511] Sermersheim, Ed., J., "Lightweight Directory Access 627 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 629 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 630 System (NFS) Version 4 Minor Version 1 Protocol", RFC 631 5661, January 2010. 633 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 634 Naik, "Requirements for Federated File Systems", RFC 5716, 635 January 2010. 637 [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS) 638 version 4 Protocol", RFC 7530, March 2015. 640 Appendix A. Acknowledgments 642 Andy Adamson would like to thank NetApp, Inc. for its funding of his 643 time on this project. 645 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 646 David Noveck for their review. 648 Authors' Addresses 650 William A. (Andy) Adamson 651 NetApp 653 Email: andros@netapp.com 655 Nicolas Williams 656 Cryptonector 658 Email: nico@cryptonector.com