idnits 2.17.1 draft-ietf-nfsv4-multi-domain-fs-reqs-01.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 (January 23, 2015) is 3379 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 (-35) exists of draft-ietf-nfsv4-rfc3530bis-25 -- 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: July 27, 2015 Cryptonector 6 January 23, 2015 8 Multiple NFSv4 Domain Namespace Deployment Guidelines 9 draft-ietf-nfsv4-multi-domain-fs-reqs-01 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 July 27, 2015. 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 . . . . . . . . . . . . . . . . 4 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 9 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 . . . . . . . . . . . . . . . . . . . . 12 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 An NFSv4 domain is defined as a set of users, groups and computers 85 running NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661] 86 (hereafter referred to as NFSv4) protocols 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 Domain: This term is used in multiple contexts where it has 128 different meanings. Here we provide specific definitions used in 129 this document. 131 DNS domain: a set of computers, services, or any internet 132 resource identified by an DNS domain name [RFC1034]. 134 Security realm or domain: a set of configured security 135 providers, users, groups, security roles, and security policies 136 running a single security protocol and administered by a single 137 entity, for example a Kerberos realm. 139 NFSv4 domain: a set of users, groups, and computers running 140 NFSv4 protocols identified by a unique NFSv4 domain name. See 141 [RFC5661] Section 5.9 "Interpreting owner and owner_group". 143 Multi-domain: In this document this always refers to multiple 144 NFSv4 domains. 146 FedFS domain: A file namespace that can cross multiple shares 147 on multiple file servers using file-access protocols such as 148 NFSv4. A FedFS domain is typically a single administrative 149 entity, and has a name that is similar to a DNS domain name. 150 Also known as a Federation. 152 Administrative domain: a set of users, groups, computers, and 153 services administered by a single entity. Can include multiple 154 DNS domains, NFSv4 domains, security domains, and FedFS 155 domains. 157 Local representation of identity: an object such as a uidNumber 158 (UID) or gidNumber (GID) [RFC2307], a Windows Security Identifier 159 (SID) [CIFS], or other such representation of a user or a group of 160 users on-disk in a file system. 162 Global identity: An on-the-wire globally unique form of identity 163 that can be mapped to a local representation. For example, the 164 NFSv4 name@domain or the Kerberos principal@REALM. 166 Multi-domain capable filesystem: A local filesystem that uses a 167 local ID form that can represent identities from both local and 168 remote domains. For example, an SSID based local ID form where 169 the SSID contains both a domain and a user or group component. 171 Principal: an RPCSEC_GSS authentication identity. Usually, but 172 not always, a user; rarely, if ever, a group; sometimes a host or 173 server. 175 Authorization Context: A collection of information about a 176 principal such as username, userID, group membership, etcetera 177 used in authorization decisions. 179 Stringified UID or GID: NFSv4 owner and group strings that consist 180 of decimal numeric values with no leading zeros, and which do not 181 contain an '@' sign. See Section 5.9 "Interpreting owner and 182 owner_group" [RFC5661]. 184 3. NFSv4 Server Identity Mapping 186 NFSv4 servers deal with two kinds of identities: authentication 187 identities (referred to here as "principals") and authorization 188 identities ("users" and "groups" of users). NFSv4 supports multiple 189 authentication methods, each authenticating an "initiator principal" 190 (typically representing a user) to an "acceptor principal" (always 191 corresponding to the NFSv4 server). NFSv4 does not prescribe how to 192 represent authorization identities on file systems. All file access 193 decisions constitute "authorization" and are made by NFSv4 servers 194 using authorization context information and file metadata related to 195 authorization, such as a file's access control list (ACL). 197 NFSv4 servers therefore must perform two kinds of mappings: 199 1. Auth-to-authz: A mapping between the authentication identity and 200 the authorization context information. 202 2. Wire-to-disk: A mapping between the on-the-wire authorization 203 identity representation and the on-disk authorization identity 204 representation. 206 A Name Service such as LDAP often provides these mappings. 208 Many aspects of these mappings are entirely implementation specific, 209 but some require multi-domain capable name resolution and security 210 services in order to interoperate in a multiple NFSv4 domain file 211 system. 213 NFSv4 servers use these mappings for: 215 1. File access: Both the auth-to-authz and the wire-to-disk mappings 216 may be required for file access decisions. 218 2. Meta-data setting and listing: The auth-to-authz mapping is 219 usually required to service file metadata setting or listing 220 requests (such as ACL or unix permission setting or listing) as 221 NFSv4 uses the name@domain on-the-wire identity representation 222 which usually differs from the exported on-disk identity 223 representation. 225 4. Stand-alone NFSv4 Domain Deployment Examples 227 In order to service as many environments as possible, the NFSv4 228 protocol is designed to allow administrators freedom to configure 229 their NFSv4 domains as they please. 231 Stand-alone NFSv4 domains can be run in many ways. Here we list some 232 stand-alone NFSv4 domain deployment examples focusing on the NFSv4 233 server's use of name service mappings (Section 3) and security 234 services deployment to demonstrate the need for some multiple NFSv4 235 domain constraints to the NFSv4 protocol, name service configuration, 236 and security service choices. 238 Because all on-disk identities participating in a stand-alone NFSv4 239 domain belong to the same NFSv4 domain, stand-alone NFSv4 domain 240 deployments have no requirement for exporting multi-domain capable 241 file systems. 243 These examples are for a NFSv4 server exporting a 32bit UID/GID based 244 file system, a typical deployment. These examples are listed in the 245 order of increasing NFSv4 administrative complexity. 247 4.1. AUTH_SYS with Stringified UID/GID 249 This example is the closest NFSv4 gets to being run as NFSv3. 251 File access: The AUTH_SYS RPC credential provides a UID as the 252 authentication identity, and a list of GIDs as authorization context 253 information. File access decisions require no name service 254 interaction as the on-the-wire and on-disk representation are the 255 same and the auth-to-authz UID and GID authorization context 256 information is provided in the RPC credential. 258 Meta-data setting and listing: When the NFSv4 clients and servers 259 implement a stringified UID/GID scheme, where a stringified UID or 260 GID is used for the NFSv4 name@domain on-the-wire identity, then a 261 name service is not required for file metadata listing as the UID or 262 GID can be constructed from the stringified form on the fly by the 263 server. 265 4.2. AUTH_SYS with name@domain 267 The next level of complexity is to not use a stringified UID/GID 268 scheme for file metadata listing. 270 File access: This is the same as in Section 4.1. 272 Meta-data setting and listing: The NFSv4 server will need to use a 273 name service for the wire-to-disk mappings to map between the on-the- 274 wire name@domain syntax and the on-disk UID/GID representation. 275 Often, the NFSv4 server will use the nsswitch interface for these 276 mappings. A typical use of the nsswitch name service interface uses 277 no domain component, just the uid attribute [RFC2307] (or login name) 278 as the name component. This is no issue in a stand-alone NFSv4 279 domain deployment as the NFSv4 domain is known to the NFSv4 server 280 and can combined with the login name to form the name@domain syntax 281 after the return of the name service call. 283 4.3. RPCSEC_GSS with name@domain 285 This final example adds the complexity of RPCSEC_GSS with the 286 Kerberos 5 GSS security mechanism. 288 File Access: The RPCSEC_GSS Kerberos credential provides a 289 principal@REALM name as the authentication identity, and (as of this 290 writing) no authorization context information. File access decisions 291 therefore require a wire-to-disk mapping of the principal@REALM to a 292 UID, and an auth-to-authz mapping to obtain the list of GIDs as the 293 authorization context. 295 Deployments can use the nsswitch name service interface for the 296 principal@REALM to UID mapping by stripping off the REALM portion. 297 This requires that the principal portion of the principal@REALM 298 matches the uid attribute [RFC2307] (or login name) of the user. 300 Meta-data setting and listing: This is the same as in Section 4.2. 302 5. Multi-domain Constraints to the NFSv4 Protocol 304 Joining NFSv4 domains under a single file namespace imposes slightly 305 on the NFSv4 administration freedom. Here we describe the required 306 constraints. 308 5.1. Name@domain Constraints 310 NFSv4 uses a syntax of the form "name@domain" as the on wire 311 representation of the "who" field of an NFSv4 access control entry 312 (ACE) for users and groups. This design provides a level of 313 indirection that allows NFSv4 clients and servers with different 314 internal representations of authorization identity to interoperate 315 even when referring to authorization identities from different NFSv4 316 domains. 318 Multiple NFSv4 domain capable sites need to meet the following 319 requirements in order to ensure that NFSv4 clients and servers can 320 map between name@domain and internal representations reliably. While 321 some of these constraints are basic assumptions in NFSv4.0 322 [I-D.ietf-nfsv4-rfc3530bis] and NFSv4.1 [RFC5661], they need to be 323 clearly stated for the multiple NFSv4 domain case. 325 o The NFSv4 domain portion of name@domain MUST be unique within the 326 multiple NFSv4 domain namespace. See [RFC5661] section 5.9 327 "Interpreting owner and owner_group" for a discussion on NFSv4 328 domain configuration. 330 o The name portion of name@domain MUST be unique within the 331 specified NFSv4 domain. 333 o Every local representation of a user and of a group MUST have a 334 canonical name@domain, and it must be possible to return the 335 canonical name@domain for any identity stored on disk, at least 336 when required infrastructure servers (such as name services) are 337 online. 339 Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used 340 in a multiple NFSv4 domain file system. 342 Note that for stand-alone NFSv4 domains it does not matter if the 343 choice of the NFSv4 domain name is replicated by another stand-alone 344 NFSv4 domain deployment. Indeed, if a stringified UID/GID scheme is 345 used, or just UNIX mode bits are used (NFSv4 ACLs are not set or 346 listed) and the simple nsswitch interface that strips the @domain and 347 the @REALM is used, then the domain portion of name@domain can be 348 ignored, and even be different for each client and server in the 349 domain. 351 5.1.1. NFSv4 Domain and DNS Services 353 Here we address the relationship between NFSv4 domain name and DNS 354 domain name in a multiple NFSv4 domain deployment. 356 The definition of an NFSv4 domain name needs clarification to work in 357 a multiple NFSv4 domain file system namespace. Section 5.9 [RFC5661] 358 loosely defines the NFSv4 domain name as a DNS domain name. This 359 loose definition for the NFSv4 domain is a good one, as DNS domain 360 names are globally unique. As noted above in Section 5.1, any choice 361 of NFSv4 domain name can work within a stand-alone NFSv4 domain 362 deployment whereas the NFSv4 domain is required to be unique in a 363 multiple NFSv4 domain deployment. 365 A typical configuration is that there is a single NFSv4 domain that 366 is served by a single DNS domain. In this case the NFSv4 domain name 367 can be the same as the DNS domain name. 369 An NFSv4 domain can span multiple DNS domains. In this case, one of 370 the DNS domain names can be chosen as the NFSv4 domain name. 372 Multiple NFSv4 domains can also share a DNS domain. In this case, 373 only one of the NFSv4 domains can use the DNS domain name, the other 374 NFSv4 domains must choose another unique NFSv4 domain name. 376 5.1.2. NFSv4 Domain, Name Service, and Domain Aware File Systems 378 As noted above in Section 5.1, each name@domain is unique across the 379 multiple NFSv4 domain namespace, and maps to a local representation 380 of ID in each NFSv4 domain. This means that each NFSv4 domain has a 381 single name resolution service exporting the NFSv4 domain local ID 382 namespace. 384 An NFSv4 domain administrator that wants to give NFSv4 local file 385 access to a remote user from a remote NFSv4 domain needs to create a 386 local ID for the remote user which can then be assigned on-disk and 387 used for local access decisions. Since the local ID for the remote 388 user must be able to be mapped to a name@remote-domain, only multi- 389 domain capable file systems can be exported in a multiple NFSv4 390 domain namespace. 392 We note that many file systems exported by NFSv4 use 32 bit POSIX UID 393 and GIDs as a local ID form and as this local ID form has no domain 394 component, these file systems are not domain aware and can not 395 participate in a multiple NFSv4 domain namespace. There are ways to 396 overcome this deficiency, but these practices are beyond the scope of 397 this document. 399 5.2. RPC Security Constraints 401 As described in [RFC5661] section 2.2.1.1 "RPC Security Flavors": 403 NFSv4.1 clients and servers MUST implement RPCSEC_GSS. 404 (This requirement to implement is not a requirement 405 to use.) Other flavors, such as AUTH_NONE, and AUTH_SYS, 406 MAY be implemented as well. 408 The underlying RPCSEC_GSS security mechanism used in a multiple NFSv4 409 domain namespace is REQUIRED to employ a method of cross NFSv4 domain 410 trust so that a principal from a security service in one NFSv4 domain 411 can be authenticated in another NFSv4 domain that uses a security 412 service with the same security mechanism. Kerberos, and PKU2U 413 [I-D.zhu-pku2u] are examples of such security services. 415 The AUTH_NONE security flavor can be useful in a multiple NFSv4 416 domain namespace to grant universal access to public data without any 417 credentials. 419 The AUTH_SYS security flavor uses a host-based authentication model 420 where the weakly authenticated host (the NFSv4 client) asserts the 421 user's authorization identities using small integers, uidNumber, and 422 gidNumber [RFC2307], as user and group identity representations. 423 Because this authorization ID representation has no domain component, 424 AUTH_SYS can only be used in a namespace where all NFSv4 clients and 425 servers share an [RFC2307] name service. A shared name service is 426 required because uidNumbers and gidNumbers are passed in the RPC 427 credential; there is no negotiation of namespace in AUTH_SYS. 428 Collisions can occur if multiple name services are used, so AUTH_SYS 429 MUST NOT be used in a multiple NFSv4 domain file system. 431 5.2.1. NFSv4 Domain and Security Services 433 As noted above in Section 5.2, caveat AUTH_NULL, multiple NFSv4 434 domain security services are RPCSEC_GSS based with the Kerberos 5 435 security mechanism being the most commonly (and as of this writing, 436 the only) deployed service. 438 A single Kerberos 5 security service per NFSv4 domain with the upper 439 case NFSv4 domain name as the Kerberos 5 REALM name is a common 440 deployment. 442 Multiple security services per NFSv4 domain is allowed, and brings 443 the issue of mapping multiple Kerberos 5 principal@REALMs to the same 444 local ID. Methods of achieving this are beyond the scope of this 445 document. 447 6. Resolving Multi-domain Authorization Information 449 When an RPCSEC_GSS principal is seeking access to files on an NFSv4 450 server, after authenticating the principal, the server must obtain in 451 a secure manner the principal's authorization context information 452 from an authoritative source such as the name service in the 453 principal's NFSv4 domain. 455 In the stand-alone NFSv4 domain case where the principal is seeking 456 access to files on an NFSv4 server in the principal's home NFSv4 457 domain, the server administrator has knowledge of the local policies 458 and methods for obtaining the principal's authorization information 459 and the mappings to local representation of identity from an 460 authoritative source. E.g., the administrator can configure secure 461 access to the local NFSv4 domain name service. 463 In the multiple NFSv4 domain case where a principal is seeking access 464 to files on an NFSv4 server not in the principal's home NFSv4 domain, 465 the server is REQUIRED to obtain in a secure manner the principal's 466 authorization context information from an authoritative source. In 467 this case there is no assumption of: 469 o Remote name service configuration knowledge 470 o The syntax of the remote authorization context information 471 presented to the NFSv4 server by the remote name service for 472 mapping to a local representation. 474 There are several methods the NFSv4 server can use to obtain the 475 NFSv4 domain authoritative authorization information for a remote 476 principal from an authoritative source. While any detail is beyond 477 the scope of this document, some general methods are listed here. 479 1. A mechanism specific GSS-API authorization payload containing 480 credential authorization data such as a "privilege attribute 481 certificate" (PAC) [PAC] or a "general PAD" (PAD) 482 [I-D.sorce-krbwg-general-pac]. This is the preferred method as 483 the payload is delivered as part of GSS-API authentication, 484 avoids requiring any knowledge of the remote authoritative 485 service configuration, and its syntax is well known. 487 2. When there is a security agreement between the local and remote 488 NFSv4 domain name services plus regular update data feeds, the 489 NFSv4 server local NFSv4 domain name service can be authoritative 490 for principal's in the remote NFSv4 domain. In this case, the 491 NFSv4 server makes a query to it's local NFSv4 domain name 492 service just as it does when servicing a local domain principal. 493 While this requires detailed knowledge of the remote NFSv4 494 domains name service, the authorization context information 495 presented to the NFSv4 server is in the same form as a query for 496 a local principal. 498 3. An authenticated direct query from the NFSv4 server to the 499 principal's NFSv4 domain authoritative name service. This 500 requires the NFSv4 server to have detailed knowledge of the 501 remote NFSv4 domain's authoritative name service and detailed 502 knowledge of the syntax of the resultant authorization context 503 information. 505 7. Stand-alone Examples and Multiple NFSv4 Domain Namespaces 507 Revisiting the stand-alone (Section 4) NFSv4 domain deployment 508 examples, we note that due to the use of AUTH_SYS, neither 509 Section 4.1 nor Section 4.2 configurations are suitable for multiple 510 NFSv4 domain deployments. 512 The Section 4.3 configuration example can participate in a multiple 513 NFSv4 domain namespace deployment if: 515 o The NFSv4 domain name is unique across the namespace. 517 o All exported file systems are multi-domain capable. 519 o A secure method is used to resolve remote NFSv4 domain principals 520 authorization information from an authoritative source. 522 8. Security Considerations 524 There are no security considerations introduced by this document 525 beyond those described in NFSv4.0 [I-D.ietf-nfsv4-rfc3530bis] and 526 NFSv4.1 [RFC5661]. 528 9. Normative References 530 [CIFS] Microsoft Corporation, "[MS-CIFS] -- v20130118 Common 531 Internet File System (CIFS) Protocol", January 2013. 533 [I-D.ietf-nfsv4-rfc3530bis] 534 Haynes, T. and D. Noveck, "Network File System (NFS) 535 version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-25 (Work 536 In Progress), February 2013. 538 [I-D.sorce-krbwg-general-pac] 539 Sorce, S., Yu, T., and T. Hardjono, "A Generalized PAC for 540 Kerberos V5", draft-ietf-krb-wg-general-pac-02 (Work In 541 Progress awaiting merge with other document ), June 2011. 543 [I-D.zhu-pku2u] 544 Zhu, L., Altman, J., and N. Williams, "Public Key 545 Cryptography Based User-to-User Authentication - (PKU2U)", 546 draft-zhu-pku2u-09 (Work In Progress), November 2008. 548 [PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data 549 in Kerberos Tickets for Access Control to Resources", 550 October 2002. 552 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 553 RFC 1034, November 1987. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", RFC 2119, March 1997. 558 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 559 Information Service", RFC 2307, March 1998. 561 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 562 System (NFS) Version 4 Minor Version 1 Protocol", RFC 563 5661, January 2010. 565 [RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. 566 Naik, "Requirements for Federated File Systems", RFC 5716, 567 January 2010. 569 Appendix A. Acknowledgments 571 Andy Adamson would like to thank NetApp, Inc. for its funding of his 572 time on this project. 574 We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and 575 David Noveck for their review. 577 Authors' Addresses 579 William A. (Andy) Adamson 580 NetApp 582 Email: andros@netapp.com 584 Nicolas Williams 585 Cryptonector 587 Email: nico@cryptonector.com