idnits 2.17.1 draft-ietf-nfsv4-nfssec-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1999) is 9143 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1094 -- Possible downref: Non-RFC (?) normative reference: ref. 'Sandberg' ** Downref: Normative reference to an Informational RFC: RFC 1813 ** Obsolete normative reference: RFC 1831 (Obsoleted by RFC 5531) ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) -- Possible downref: Non-RFC (?) normative reference: ref. 'Pawlowski' ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) ** Downref: Normative reference to an Informational RFC: RFC 1057 -- Possible downref: Non-RFC (?) normative reference: ref. 'Callaghan' ** Downref: Normative reference to an Informational RFC: RFC 2054 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Duplicate reference: RFC1964, mentioned in 'MIT', was also mentioned in 'RFC1964'. Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eisler 3 Internet Draft Sun Microsystems, Inc. 4 Document: draft-ietf-nfsv4-nfssec-01.txt April 1999 6 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's 7 Use of RPCSEC_GSS and Kerberos V5 9 Status of this Memorandum 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Comments on this document should be sent to 31 "nfsv4-wg@sunroof.eng.sun.com", the NFS Version 4 Working Group 32 discussion list. 34 Abstract 36 This memorandum clarifies various security issues involving the NFS 37 protocol (Version 2 and Version 3 only) and then describes how the 38 Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS 39 security flavor protocol and Kerberos V5. This memorandum is 40 provided so that people can write compatible implementations. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3 46 2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 4 47 2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 4 48 2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 5 49 2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 5 50 2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5 52 2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 6 53 2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6 54 2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 7 56 2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7 57 2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 8 58 2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8 59 2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 9 60 2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9 61 3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 10 62 3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 10 63 3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 11 65 3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11 66 4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 12 67 4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12 68 4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor 69 Registration Entry . . . . . . . . . . . . . . . . . . . . 13 70 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations [RFC2434] . . . . . . . . . . . . . . . 15 72 6.1. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . 15 73 6.2. String Name of Pseudo Flavor . . . . . . . . . . . . . . . 15 74 6.2.1. Name Space Size . . . . . . . . . . . . . . . . . . . . 15 75 6.2.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.2.3. Outside Review . . . . . . . . . . . . . . . . . . . . . 16 77 6.3. GSS-API Mechanism OID . . . . . . . . . . . . . . . . . . 16 78 6.4. GSS-API Mechanism Algorithm Values . . . . . . . . . . . . 16 79 6.5. RPCSEC_GSS Security Service . . . . . . . . . . . . . . . 16 80 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 The NFS protocol provides transparent remote access to shared file 87 systems across networks. The NFS protocol is designed to be machine, 88 operating system, network architecture, and security mechanism, and 89 transport protocol independent. This independence is achieved through 90 the use of ONC Remote Procedure Call (RPC) primitives built on top of 91 an eXternal Data Representation (XDR). NFS protocol Version 2 is 92 specified in the Network File System Protocol Specification 93 [RFC1094]. A description of the initial implementation can be found 94 in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version 95 3 Protocol Specification [RFC1813]. A description of some initial 96 implementations can be found in [Pawlowski]. 98 For the remainder of this document, whenever it refers to the NFS 99 protocol, it means NFS Version 2 and Version 3, unless otherwise 100 stated. 102 The RPC protocol is specified in the Remote Procedure Call Protocol 103 Specification Version 2 [RFC1831]. The XDR protocol is specified in 104 External Data Representation Standard [RFC1832]. 106 A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203]. 107 This new flavor allows application protocols built on top of RPC to 108 access security mechanisms that adhere to the GSS-API specification 109 [RFC2078]. 111 The purpose of this document is to clarify NFS security issues and to 112 specify how the NFS protocol uses RPCSEC_GSS. This document will also 113 describe how NFS works over Kerberos V5, via RPCSEC_GSS. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 1.1. Overview of RPC Security Architecture 121 The RPC protocol includes a slot for security parameters (referred to 122 as an authentication flavor in the RPC specification [RFC1831]) on 123 every call. The contents of the security parameters are determined 124 by the type of authentication used by the server and client. A server 125 may support several different flavors of authentication at once. 126 Some of the better known flavors are summarized as follows: 128 * The AUTH_NONE flavor provides null authentication, that is, no 129 authentication information is passed. 131 * The AUTH_SYS flavor provides a UNIX-style user identifier, group 132 identifier, and an array of supplemental group identifiers with 133 each call. 135 * The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057]) flavor 136 provides DES-encrypted authentication parameters based on a 137 network-wide string name, with session keys exchanged via the 138 Diffie-Hellman public key scheme. 140 * The AUTH_KERB4 flavor provides DES encrypted authentication 141 parameters based on a network-wide string name (the name is a 142 Kerberos Version 4 principal identifier) with session keys 143 exchanged via Kerberos Version 4 secret keys. 145 The NFS protocol is not limited to the above list of security 146 flavors. 148 2. Overview of NFS Security 150 2.1. Port Monitoring 152 Many NFS servers will require that the client send its NFS requests 153 from UDP or TCP source ports with values < 1024. The theory is that 154 binding to ports < 1024 is a privileged operation on the client, and 155 so the client is enforcing file access permissions on its end. The 156 theory breaks down because: 158 * On many operating systems, there are no constraints on what port 159 what user can bind to. 161 * Just because the client host enforces the privilege on binding 162 to ports < 1024 does not necessarily mean that a non-privileged 163 user cannot gain access to the port binding privilege. For 164 example with a single-user desk-top host running a UNIX 165 operating system, the user may have knowledge of the root user 166 password. And even if he does not have that knowledge, with 167 physical access to the desk-top machine, root privileges are 168 trivially acquired. 170 In some rare cases, when the system administrator can be certain that 171 the clients are trusted and under control (in particular, protected 172 from physical attack), relying of trusted ports MAY be a reliable 173 form of security. 175 In most cases, the use of privileged ports and port monitoring for 176 security is at best an inconvenience to the attacker and SHOULD NOT 177 be depended on. 179 To maximize interoperability: 181 * NFS clients SHOULD attempt to bind to ports < 1024. In some 182 cases, if they fail to bind (because either the user does not 183 have the privilege to do so, or there is no free port < 1024), 184 the NFS client MAY wish to attempt the NFS operation over a port 185 >= 1024. 187 * NFS servers that implement port monitoring SHOULD provide a 188 method to turn it off. 190 * Whether port monitoring is enabled or not, NFS servers SHOULD 191 NOT reject NFS requests to the NULL procedure (procedure number 192 0). See subsection 2.3.1, "NULL procedure" for a complete 193 explanation. 195 2.1.1. MOUNT Protocol 197 The port monitoring issues and recommendations apply to the MOUNT 198 protocol as well. 200 2.2. RPC Security Flavors 202 The NFS server checks permissions by taking the credentials from the 203 RPC security information in each remote request. Each flavor packages 204 credentials differently. 206 2.2.1. AUTH_SYS 208 Using the AUTH_SYS flavor of authentication, the server gets the 209 client's effective user identifier, effective group identifier and 210 supplemental group identifiers on each call, and uses them to check 211 access. Using user identifiers and group identifiers implies that the 212 client and server either share the same identifier name space or do 213 local user and group identifier mapping. 215 For those sites that do not implement a consistent user identifier 216 and group identifier space, NFS implementations must agree on the 217 mapping of user and group identifiers between NFS clients and 218 servers. 220 2.2.2. AUTH_DH and AUTH_KERB4 222 The AUTH_DH and AUTH_KERB4 styles of security are based on a 223 network-wide name. They provide greater security through the use of 224 DES encryption and public keys in the case of AUTH_DH, and DES 225 encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4 226 case. Again, the server and client must agree on the identity of a 227 particular name on the network, but the name to identity mapping is 228 more operating system independent than the user identifier and group 229 identifier mapping in AUTH_SYS. Also, because the authentication 230 parameters are encrypted, a malicious user must know another user's 231 network password or private key to masquerade as that user. 232 Similarly, the server returns a verifier that is also encrypted so 233 that masquerading as a server requires knowing a network password. 235 2.2.3. RPCSEC_GSS 237 The RPCSEC_GSS style of security is based on a security-mechanism- 238 specific principal name. GSS-API mechanisms provide security through 239 the use of cryptography. The cryptographic protections are used in 240 the construction of the credential on calls, and in the verifiers on 241 replies. Optionally, cryptographic protections will be in the body of 242 the calls and replies. 244 Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, 245 and RPCSEC_GSS does not imply that the NFS protocol is limited to 246 using those five flavors. 248 2.3. Authentication for NFS Procedures 250 2.3.1. NULL Procedure 252 The NULL procedure is typically used by NFS clients to determine if 253 an NFS server is operating and responding to requests (in other 254 words, to "ping" the NFS server). Some NFS servers require that a 255 client using the NULL procedure: 257 * send the request from TCP or UDP port < 1024. There does not 258 seem to be any value in this because the NULL procedure is of 259 very low overhead and certainly no more overhead than the cost 260 of processing a NULL procedure and returning an authentication 261 error. Moreover, by sending back an authentication error, the 262 server has confirmed the information that the client was 263 interested in: is the server operating? 265 * be authenticated with a flavor stronger than AUTH_SYS. This is a 266 problem because the RPCSEC_GSS protocol uses NULL for control 267 messages. 269 NFS servers SHOULD: 271 * accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in 272 addition to other RPC security flavors, and 274 * NOT require that the source port be < 1024 on a NULL procedure 275 ping. 277 2.3.2. NFS Procedures Used at Mount Time 279 Certain NFS procedures are used at the time the NFS client mounts a 280 file system from the server. Some NFS server implementations will 281 not require authentication for these NFS procedures. For NFS 282 protocol Version 2, these procedures are GETATTR and STATFS. For 283 Version 3, the procedure is FSINFO. 285 The reason for not requiring authentication is described as follows. 286 When the NFS client mounts a NFS server's file system, the identity 287 of the caller on the client is typically an administrative entity (in 288 UNIX operating systems, this is usually the "root" user). It is 289 often the case that, for unattended operation in concert with an 290 automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS 291 credentials for the administrative entity associated with an 292 automounter are not available. If so, the NFS client will use 293 AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a 294 file system. While an attacker could exploit this implementation 295 artifact, the exposure is limited to gaining the attributes of a file 296 or a file system's characteristics. This OPTIONAL trade off favors 297 the opportunity for improved ease of use. 299 2.4. Binding Security Flavors to Exports 301 NFS servers MAY export file systems with specific security flavors 302 bound to the export. In the event a client uses a security flavor 303 that is not the one of the flavors the file system was exported with, 304 NFS server implementations MAY: 306 * reject the request with an error (either an NFS error or an RPC 307 level authentication error), or 309 * allow the request, but map the user's credentials to a user 310 other than the one the client intended. Typically the user that 311 is the result of this mapping is a user with limited access on 312 the system, such as user "nobody" on UNIX systems. 314 If a client uses AUTH_NONE, the server's options are the same as the 315 above, except that AUTH_NONE carries with it no user identity. In 316 order to allow the request, on many operating systems the server will 317 assign a user identity. Typically this assignment will be a user with 318 limited access on the system, such as user "nobody" on UNIX systems. 320 2.5. Anonymous Mapping 322 The following passage is excerpted verbatim from RFC 1813, section 323 4.4 "Permission Issues" (except that "may" has been changed to 324 "MAY"): 326 In most operating systems, a particular user (on UNIX, the uid 0) 327 has access to all files, no matter what permission and ownership 328 they have. This superuser permission MAY not be allowed on the 329 server, since anyone who can become superuser on their client 330 could gain access to all remote files. A UNIX server by default 331 maps uid 0 to a distinguished value (UID_NOBODY), as well as 332 mapping the groups list, before doing its access checking. A 333 server implementation MAY provide a mechanism to change this 334 mapping. This works except for NFS version 3 protocol root file 335 systems (required for diskless NFS version 3 protocol client 336 support), where superuser access cannot be avoided. Export 337 options are used, on the server, to restrict the set of clients 338 allowed superuser access. 340 The issues identified as applying to NFS protocol Version 3 in the 341 above passage also apply to Version 2. 343 2.6. Host-based Access Control 345 In some NFS server implementations, a host-based access control 346 method is used whereby file systems can be exported to lists of 347 clients. File systems may also be exported for read-only or read- 348 write access. Several of these implementations will check access 349 only at mount time, during the request for the file handle via the 350 MOUNT protocol handshake. The lack of authorization checking during 351 subsequent NFS requests has the following consequences: 353 * NFS servers are not able to repudiate access to the file system 354 by an NFS client after the client has mounted the file system. 356 * An attacker can circumvent the MOUNT server's access control to 357 gain access to a file system that the attacker is not authorized 358 for. The circumvention is accomplished by either stealing a file 359 handle (usually by snooping the network traffic between an 360 legitimate client and server) or guessing a file handle. For 361 this attack to succeed, the attacker must still be able 362 impersonate a user's credentials, which is simple for AUTH_SYS, 363 but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. 365 * WebNFS clients that use the public file handle lookup [RFC2054] 366 will not go through the MOUNT protocol to acquire initial file 367 handle of the NFS file system. Enforcing access control via the 368 MOUNT protocol is going to be a little use. Granted, some WebNFS 369 server implementations cope with this by limiting the use of the 370 public file handle to file systems exported to every client on 371 the Internet. 373 Thus, NFS server implementations SHOULD check the client's 374 authorization on each NFS request. 376 2.7. Security Flavor Negotiation 378 Any application protocol that supports multiple styles of security 379 will have the issue of negotiating the security method to be used. 380 NFS Version 2 had no support for security flavor negotiation. It was 381 up to the client to guess, or depend on prior knowledge. Often the 382 prior knowledge would be available in the form of security options 383 specified in a directory service used for the purpose of 384 automounting. 386 The MOUNT Version 3 protocol, associated with NFS Version 3, solves 387 the problem by having the response to the MNT procedure include a 388 list of flavors in the MNT procedure. Note that because some NFS 389 servers will export file systems to specific lists of clients, with 390 different access (read-only versus read-write), and with different 391 security flavors, it is possible a client might get back multiple 392 security flavors in the list returned in the MNT response. The use of 393 one flavor instead of another might imply read-only instead of read- 394 write access, or perhaps some other degradation of access. For this 395 reason, a NFS client SHOULD use the first flavor in the list that it 396 supports, on the assumption that the best access is provided by the 397 first flavor. NFS servers that support the ability to export file 398 systems with multiple security flavors SHOULD either present the best 399 accessing flavor first to the client, or leave the order under the 400 control of the system administrator. 402 2.8. Registering Flavors 404 When one develops a new RPC security flavor, iana@iana.org MUST be 405 contacted to get a unique flavor assignment. To simplify NFS client 406 and server administration, having a simple ASCII string name for the 407 flavor is useful. Currently, the following assignments exist: 409 flavor string name 411 AUTH_NONE none 412 AUTH_SYS sys 413 AUTH_DH dh 414 AUTH_KERB4 krb4 416 A string name for a new flavor SHOULD be assigned. String name 417 assignments can be registered by contacting iana@iana.org. 419 3. The NFS Protocol's Use of RPCSEC_GSS 421 3.1. Server Principal 423 When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API 424 via a GSS_C_NT_HOSTBASED_SERVICE name type. 425 GSS_C_NT_HOSTBASED_SERVICE names are of the form: 427 service@hostname 429 For NFS, the "service" element is 431 nfs 433 3.2. Negotiation 435 RPCSEC_GSS is a single security flavor over which different security 436 mechanisms can be multiplexed. Within a mechanism, GSS-API provides 437 for the support of multiple quality of protections (QOPs), which are 438 pairs of cryptographic algorithms. Each algorithm in the QOP consists 439 of an encryption algorithm for privacy and a checksum algorithm for 440 integrity. RPCSEC_GSS lets one protect the RPC request/response pair 441 with plain header authentication, message integrity, and message 442 privacy. Thus RPCSEC_GSS effectively supports M * Q * 3 different 443 styles of security, where M is the number of mechanisms supported, Q 444 is the average number of QOPs supported for each mechanism, and 3 445 enumerates authentication, integrity, and privacy. 447 Because RPCSEC_GSS encodes many styles of security, just adding 448 RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT 449 response is not going to be of much use to the NFS client. 451 The solution is the creation of a concept called "pseudo flavors." 452 Pseudo flavors are 32 bit integers that are allocated out of the same 453 number space as regular RPC security flavors like AUTH_NONE, 454 AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each 455 pseudo flavor will map to a specific triple of security mechanism, 456 quality of protection, and service. The service will be one of 457 authentication, integrity, and privacy. Note that integrity includes 458 authentication, and privacy includes integrity. RPCSEC_GSS uses 459 constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and 460 rpc_gss_svc_privacy, for authentication, integrity, and privacy 461 respectively. 463 Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will 464 instead return one or more pseudo flavors if the NFS server supports 465 RPCSEC_GSS and if the file system has been exported with one or more 466 triples. See section 4, "The NFS Protocol 467 over Kerberos V5" for an example of pseudo flavor to triple mapping. 469 3.3. Changing RPCSEC_GSS Parameters 471 Once an RPCSEC_GSS session or context has been set up (via the 472 RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of 473 RPCSEC_GSS), the NFS server MAY lock the 474 triple for the duration of the session. While RPCSEC_GSS allows for 475 the use of different QOPs and services on each message, it would be 476 expensive for the NFS server to re-consult its table of exported file 477 systems to see if the triple was allowed. Moreover, by the time the 478 NFS server's dispatch routine was reached, the typical RPC subsystem 479 would already have performed the appropriate GSS-API operation, 480 GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or 481 privacy services were selected. If the file system being accessed 482 were not exported with integrity or privacy, or with the particular 483 QOP used to perform the integrity or privacy service, then it would 484 be possible to execute a denial of service attack, whereby the 485 objective of the caller is to deny CPU service to legitimate users of 486 the NFS server's machine processors. 488 Thus, in general, clients SHOULD NOT assume that they will be 489 permitted to alter the triple once the data 490 exchange phase of RPCSEC_GSS has started. 492 3.4. Registering Pseudo Flavors and Mappings 494 Pseudo flavor numbers MUST be registered via same method as regular 495 RPC security flavor numbers via iana@iana.org. 497 Once the pseudo flavor number has been assigned, registrants SHOULD 498 register the mapping with iana@iana.org. The mapping registration 499 MUST contain: 501 * the pseudo flavor number, an ASCII string name for the flavor 502 (for example "none" has been assigned for AUTH_NONE), and 504 * the triple. As per the GSS- 505 API specification, the mechanism MUST be identified with a 506 unique ISO object identifier (OID). The reason why the second 507 component of the triple is not necessarily a QOP value is that 508 GSS-API allows mechanisms much latitude in the mapping of the 509 algorithm used in the default quality of protection (See 510 subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed 511 discussion). With some mechanisms, the second component of the 512 triple will be a QOP. Internally, on the NFS implementation, it 513 is expected that the triple would use a QOP for the second 514 component. 516 The mapping registration SHOULD also contain: 518 * A reference to an RFC describing how the NFS protocol MUST work 519 over the pseudo flavor(s), including the pseudo flavor 520 number(s), string name(s) for the flavor(s), and any other 521 issues, including how the registrant is interpreting the GSS-API 522 mechanism. 524 * A reference to the GSS-API mechanism used. 526 An example of a complete registration is provided in subsection 4.2, 527 "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry." 529 4. The NFS Protocol over Kerberos V5 531 The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS 532 security flavor. The GSS-API security mechanism for Kerberos V5 that 533 the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos 534 V5 GSS-API description [RFC1964]. 536 4.1. Issues with Kerberos V5 QOPs 538 The Kerberos V5 GSS-API description defines three algorithms for 539 integrity: 541 * DES MAC MD5 543 * MD2.5 545 * DES-MAC 547 RFC 1964 states that MD2.5 "may be significantly weaker than DES MAC 548 MD5." RFC 1964 also states that DES-MAC "may not be present in all 549 implementations." 551 Thus the description of operation of NFS clients and servers over 552 Kerberos V5 is limited to the DES MAC MD5 integrity algorithm. 554 NFS clients and servers operating over Kerberos V5 MUST support the 555 DES MAC MD5 integrity algorithm. RFC 1964 lists a single algorithm 556 for privacy: 56 bit DES. NFS clients and servers SHOULD support the 557 56 bit DES privacy algorithm. 559 GSS-API has the concept of a default QOP of zero which means 560 different integrity and privacy algorithms to different GSS-API 561 mechanisms. In Kerberos V5, the default QOP of zero means to use the 562 56 bit DES algorithm (when doing a GSS_Wrap() operation with the 563 conf_req_flag set to 1). 565 For Kerberos V5, the default QOP of zero means different integrity 566 algorithms to different implementations of Kerberos V5. Furthermore, 567 during the processing of a token in GSS_Unwrap(), and 568 GSS_VerifyMIC(), at least one reference implementation of the 569 Kerberos V5 GSS-API mechanism [MIT], always returns a QOP of zero, 570 regardless of integrity algorithm encoded in the token. For such 571 implementations, it means that the caller of GSS_Unwrap() and 572 GSS_VerifyMIC() cannot know the actual integrity algorithm used. 573 Given that each integrity algorithm has a different degree of 574 security, this situation may not be acceptable to the user of GSS- 575 API. An implementation of Kerberos V5 under GSS-API for use under NFS 576 MUST NOT do this. 578 For the purposes of NFS, as a simplification, some Kerberos V5 GSS- 579 API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity, 580 and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES 581 MAC MD5 integrity that is specified to QOP 0. 583 4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry 585 Here are the pseudo flavor mappings for the NFS protocol using 586 Kerberos V5 security: 588 columns: 590 1 == number of pseudo flavor 591 2 == name of pseudo flavor 592 3 == mechanism's OID 593 4 == mechanism's algorithm(s) 594 5 == RPCSEC_GSS service 596 1 2 3 4 5 597 ----------------------------------------------------------------------- 598 390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none 599 390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity 600 390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy 601 for integrity, 602 and 56 bit DES 603 for privacy. 605 An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that 606 maps the default QOP to DES MAC MD5 (and vice versa), would implement 607 a mapping of: 609 columns: 611 1 == number of pseudo flavor 612 2 == name of pseudo flavor 613 3 == mechanism's OID 614 4 == QOP 615 5 == RPCSEC_GSS service 617 1 2 3 4 5 618 ----------------------------------------------------------- 619 390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none 620 390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity 621 390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy 623 The reference for the GSS-API mechanism with the above OID is 624 [RFC1964]. 626 The reference for how the NFS protocol MUST work over Kerberos V5 is 627 this document. 629 5. Security Considerations 631 Version 3 of the MOUNT protocol is used to negotiate the security 632 flavor to be used by the NFS Version 3 client. If the NFS client uses 633 a weak security flavor like AUTH_SYS to query a Version 3 MOUNT 634 server, then the following attacks are possible by an attacker in the 635 middle: 637 * The attacker in the middle can coax the NFS client into using a 638 weaker form of security than what the real NFS server requires. 639 However, once the NFS client selects a security flavor when it 640 sends a request to real NFS server, if the flavor is 641 unacceptable, the NFS client's NFS request will be rejected. So 642 at worst, a denial of service attack is possible. In theory, the 643 NFS client could contact the MOUNT server using a stronger 644 security flavor, but this would require that the client know in 645 advance what security flavors the MOUNT server supports. 647 * If the client and server support a common set of security 648 flavors, such that the client considers one preferable to the 649 other (for example, one might have privacy and other not), 650 unless the client uses a strong security flavor in the MOUNT 651 protocol query, an attacker in the middle could cause the client 652 to use the weaker form of security. Again, a client could 653 contact the MOUNT server using a stronger form of security. 655 6. IANA Considerations [RFC2434] 657 This memorandum describes how NFS Version 2 and Version 3 work over 658 RPC's RPCSEC_GSS security flavor. This memorandum requires that 659 triples of { GSS-API mechanism OID, GSS-API mechanism algorithm, 660 RPCSEC_GSS security service } be mapped to a unique RPC security 661 flavor number, which is a pseudo flavor that does not appear in an 662 RPC protocol header. This memorandum also encourages that an ASCII 663 string name be registered with the triple. 665 Thus there are five different kinds of objects to consider guidelines 666 for. 668 6.1. Pseudo Flavor Number 670 The considerations of assignment, allocation, and delegation of 671 pseudo flavor numbers are no different than that the considerations 672 for RPC security flavors, as both are assigned from the same number 673 space. IANA is already responsible for the assigned of RPC security 674 flavors, and because this memorandum does not specify the RPC 675 protocol [RFC1831], it is beyond the scope of this memorandum to 676 guide IANA in the assignment of flavor numbers. 678 6.2. String Name of Pseudo Flavor 680 This memorandum introduces the concept of a string name to be 681 associated with the RPC pseudo flavor number, and so it is within the 682 scope of this memorandum to provide guidance to IANA. 684 6.2.1. Name Space Size 686 There are no limits placed on the length of the unique string name by 687 this memorandum, so the size of the name space is infinite. However, 688 IANA may want to prevent the hoarding or reservation of names. The 689 simplest way to do this is by requiring the registrant to provide the 690 GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS 691 security service, and flavor number, with the request for a flavor 692 name. If the registrant does not have a flavor number, then 693 guidelines for flavor number assignments will indirectly limit the 694 assignment of flavor names. 696 6.2.2. Delegation 698 The simplest way to handle delegation is to delegate portions of the 699 RPC security flavor number space with the RPC flavor name space. The 700 guidelines for delegation of the flavor name space are thus 701 equivalent to guidelines for delegations of the flavor number space. 703 6.2.3. Outside Review 705 Because string names can be trademarks, IANA may want to seek legal 706 counsel to review a proposed pseudo flavor name. Other than that, no 707 outside review is necessary. 709 6.3. GSS-API Mechanism OID 711 This memorandum assumes that the mechanism OID associated with the 712 pseudo flavor has already been allocated. OIDs are allocated by the 713 International Standards Organization and the International 714 Telecommunication Union. Both organizations have delegated assignment 715 authority for subsets of the OID number space to other organizations. 716 Presumably, IANA has received authority to assign OIDs to GSS-API 717 mechanisms. Because this memorandum does not specify the GSS-API 718 protocol (see [RFC2078]) it is beyond the scope of this memorandum to 719 guide IANA in the assignment of GSS-API mechanism OIDs. 721 6.4. GSS-API Mechanism Algorithm Values 723 This memorandum assumes that the algorithm value for a given GSS-API 724 mechanism has already been allocated. Algorithm values are controlled 725 by the owner of the GSS-API mechanism, though the owner may delegate 726 assignment of algorithm values to a body such as IANA. Because this 727 memorandum does not specify GSS-API mechanisms, such as [RFC1964], it 728 is beyond the scope of this memorandum to guide IANA in the 729 assignment of a mechanism's algorithm value(s). 731 6.5. RPCSEC_GSS Security Service 733 There are only three security services and they are enumerated and 734 described in [RFC2203]. No guideline to IANA is necessary. 736 References 738 [RFC1094] Sun Microsystems, Inc. (1989). "NFS: Network File System 739 Protocol specification," RFC 1094. 740 http://www.ietf.org/rfc/rfc1094.txt 742 [Sandberg] 743 Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, 744 B. (1985). "Design and Implementation of the Sun Network 745 Filesystem," Proceedings of the 1985 Summer USENIX 746 Technical Conference. 748 [RFC1813] Callaghan, B., Pawlowski, B., Staubach, P. (1995). "NFS 749 Version 3 Protocol Specification," RFC 1813. 750 http://www.ietf.org/rfc/rfc1813.txt 752 [RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol 753 Specification Version 2," RFC 1831. 754 http://www.ietf.org/rfc/rfc1831.txt 756 [RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation 757 Standard," RFC 1832. 758 http://www.ietf.org/rfc/rfc1832.txt 760 [Pawlowski] 761 Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., 762 Lebel, D., Hitz, D. (1994). "NFS Version 3 Design and 763 Implementation," Proceedings of the USENIX Summer 1994 764 Technical Conference. 766 [RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol 767 Specification," RFC 2203. 768 http://www.ietf.org/rfc/rfc2203.txt 770 [RFC2078] Linn, J. (1997). "Generic Security Service Application 771 Program Interface, Version 2," RFC 2078. 772 http://www.ietf.org/rfc/rfc2078.txt 774 [RFC1057] Sun Microsystems, Inc. "RPC: Remote Procedure Call Protocol 775 Specification Version 2," RFC 1057. This RFC is being 776 referenced for its description of the AUTH_DH (AUTH_DES) 777 RPC security flavor. 778 http://www.ietf.org/rfc/rfc1057.txt 780 [RFC2119] Bradner, S. (1997). "Key words for use in RFCs to Indicate 781 Requirement Levels," RFC 2119. 782 http://www.ietf.org/rfc/rfc2119.txt 784 [Callaghan] 785 Callaghan, B., Singh, S. (1993). "The Autofs Automounter," 786 Proceedings of the 1993 Summer USENIX Technical Conference. 788 [RFC1964] Linn, J. (1996). "The Kerberos Version 5 GSS-API 789 Mechanism," RFC 1964. 790 http://www.ietf.org/rfc/rfc1964.txt 792 [RFC2054] Callaghan, B. (1996). "WebNFS Client Specification," RFC 793 2054. 794 http://www.ietf.org/rfc/rfc2054.txt 796 [RFC2434] Narten, T., Alvestrand, H. (1998). "Guidelines for Writing 797 an IANA Considerations Section in RFCs," RFC 2424. 798 http://www.ietf.org/rfc/rfc2434.txt 800 [MIT] Massachusetts Institute of Technology (1998). "Kerberos: 801 The Network Authentication Protocol." The Web site for 802 downloading MIT's implementation of Kerberos V5, including 803 implementations of RFC 1510 and RFC 1964. 804 http://web.mit.edu/kerberos/www/index.html 806 Acknowledgments 808 The author thanks: 810 * Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve 811 Nahm, Joyce Reynolds, and David Robinson for their review 812 comments. 814 * John Linn, for his explanation of QOP handling in RFC 1964. 816 Author's Address 818 Address comments related to this memorandum to: 820 nfsv4-wg@sunroof.eng.sun.com 822 Mike Eisler 823 Sun Microsystems, Inc. 824 5565 Wilson Road 825 Colorado Springs, CO 80919 827 Phone: 1-719-599-9026 828 E-mail: mre@eng.sun.com