idnits 2.17.1 draft-ietf-nfsv4-nfssec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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.) ** 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 (January 1999) is 9205 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) == Missing Reference: 'RFC 1964' is mentioned on line 522, but not defined == Unused Reference: 'RFC1964' is defined on line 695, but no explicit reference was found in the text ** 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 -- Duplicate reference: RFC1964, mentioned in 'MIT', was also mentioned in 'RFC1964'. Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Eisler 2 Internet Draft January 1999 3 Document: draft-ietf-nfsv4-nfssec-03.txt 5 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's 6 Use of RPCSEC_GSS and Kerberos V5 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Comments on this document should be sent to 27 "nfsv4-wg@sunroof.eng.sun.com", the NFS Version 4 Working Group 28 discussion list. 30 Abstract 32 This memorandum clarifies various security issues involving the NFS 33 protocol (Version 2 and Version 3 only) and then describes how the 34 Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS 35 security flavor protocol and Kerberos V5. This memorandum is 36 provided so that people can write compatible implementations. 38 Table of Contents 40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 41 1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3 42 2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 4 43 2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 4 44 2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 5 45 2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 5 46 2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5 47 2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5 48 2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 6 49 2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6 50 2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6 51 2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 7 52 2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7 53 2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 8 54 2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8 55 2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 9 56 2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9 57 3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 10 58 3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 10 59 3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 10 60 3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 11 61 3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11 62 4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 12 63 4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12 64 4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor 65 Registration Entry . . . . . . . . . . . . . . . . . . . . 13 66 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 67 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 The NFS protocol provides transparent remote access to shared file 74 systems across networks. The NFS protocol is designed to be machine, 75 operating system, network architecture, and security mechanism, and 76 transport protocol independent. This independence is achieved through 77 the use of Remote Procedure Call (RPC) primitives built on top of an 78 eXternal Data Representation (XDR). NFS protocol Version 2 is 79 specified in the Network File System Protocol Specification 80 [RFC1094]. A description of the initial implementation can be found 81 in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version 82 3 Protocol Specification [RFC1813]. A description of some initial 83 implementations can be found in [Pawlowski]. 85 For the remainder of this document, whenever it refers to the NFS 86 protocol, it means NFS Version 2 and Version 3, unless otherwise 87 stated. 89 The RPC protocol is specified in the Remote Procedure Call Protocol 90 Specification Version 2 [RFC1831]. The XDR protocol is specified in 91 External Data Representation Standard [RFC1832]. 93 A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203]. 94 This new flavor allows application protocols built on top of RPC to 95 access security mechanisms that adhere to the GSS-API specification 96 [RFC2078]. 98 The purpose of this document is to clarify NFS security issues and to 99 specify how the NFS protocol uses RPCSEC_GSS. This document will also 100 describe how NFS works over Kerberos V5, via RPCSEC_GSS. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.1. Overview of RPC Security Architecture 108 The RPC protocol includes a slot for security parameters (referred to 109 as an authentication flavor in the RPC specification [RFC1831]) on 110 every call. The contents of the security parameters are determined 111 by the type of authentication used by the server and client. A server 112 may support several different flavors of authentication at once. 113 Some of the better known flavors are summarized as follows: 115 * The AUTH_NONE flavor provides null authentication, that is, no 116 authentication information is passed. 118 * The AUTH_SYS flavor provides a UNIX-style user identifier, group 119 identifier, and an array of supplemental group identifiers with 120 each call. 122 * The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057]) flavor 123 provides DES-encrypted authentication parameters based on a 124 network-wide string name, with session keys exchanged via the 125 Diffie-Hellman public key scheme. 127 * The AUTH_KERB4 flavor provides DES encrypted authentication 128 parameters based on a network-wide string name (the name is a 129 Kerberos Version 4 principal identifier) with session keys 130 exchanged via Kerberos Version 4 secret keys. 132 The NFS protocol is not limited to the above list of security 133 flavors. 135 2. Overview of NFS Security 137 2.1. Port Monitoring 139 Many NFS servers will require that the client send its NFS requests 140 from UDP or TCP source ports with values < 1024. The theory is that 141 binding to ports < 1024 is a privileged operation on the client, and 142 so the client is enforcing file access permissions on its end. The 143 theory breaks down because: 145 * On many operating systems, there are no constraints on what port 146 what user can bind to. 148 * Just because the client host enforces the privilege on binding 149 to ports < 1024 does not necessarily mean that a non-privileged 150 user cannot gain access to the port binding privilege. For 151 example with a single-user desk-top host running a UNIX 152 operating system, the user may have knowledge of the root user 153 password. And even if he does not have that knowledge, with 154 physical access to the desk-top machine, root privileges are 155 trivially acquired. 157 In some rare cases, when the system administrator can be certain that 158 the clients are trusted and under control (in particular, protected 159 from physical attack), relying of trusted ports MAY be a reliable 160 form of security. 162 In most cases, the use of privileged ports and port monitoring for 163 security is at best an inconvenience to the attacker and SHOULD NOT 164 be depended on. 166 To maximize interoperability: 168 * NFS clients SHOULD attempt to bind to ports < 1024. In some 169 cases, if they fail to bind (because either the user does not 170 have the privilege to do so, or there is no free port < 1024), 171 the NFS client MAY wish to attempt the NFS operation over a port 172 >= 1024. 174 * NFS servers that implement port monitoring SHOULD provide a 175 method to turn it off. 177 * Whether port monitoring is enabled or not, NFS servers SHOULD 178 NOT reject NFS requests to the NULL procedure (procedure number 179 0). See subsection 2.3.1, "NULL procedure" for a complete 180 explanation. 182 2.1.1. MOUNT Protocol 184 The port monitoring issues and recommendations apply to the MOUNT 185 protocol as well. 187 2.2. RPC Security Flavors 189 The NFS server checks permissions by taking the credentials from the 190 RPC security information in each remote request. Each flavor packages 191 credentials differently. 193 2.2.1. AUTH_SYS 195 Using the AUTH_SYS flavor of authentication, the server gets the 196 client's effective user identifier, effective group identifier and 197 supplemental group identifiers on each call, and uses them to check 198 access. Using user identifiers and group identifiers implies that the 199 client and server either share the same identifier name space or do 200 local user and group identifier mapping. 202 For those sites that do not implement a consistent user identifier 203 and group identifier space, NFS implementations must agree on the 204 mapping of user and group identifiers between NFS clients and 205 servers. 207 2.2.2. AUTH_DH and AUTH_KERB4 209 The AUTH_DH and AUTH_KERB4 styles of security are based on a 210 network-wide name. They provide greater security through the use of 211 DES encryption and public keys in the case of AUTH_DH, and DES 212 encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4 213 case. Again, the server and client must agree on the identity of a 214 particular name on the network, but the name to identity mapping is 215 more operating system independent than the user identifier and group 216 identifier mapping in AUTH_SYS. Also, because the authentication 217 parameters are encrypted, a malicious user must know another user's 218 network password or private key to masquerade as that user. 219 Similarly, the server returns a verifier that is also encrypted so 220 that masquerading as a server requires knowing a network password. 222 2.2.3. RPCSEC_GSS 224 The RPCSEC_GSS style of security is based on a security-mechanism- 225 specific principal name. GSS-API mechanisms provide security through 226 the use of cryptography. The cryptographic protections are used in 227 the construction of the credential on calls, and in the verifiers on 228 replies. Optionally, cryptographic protections will be in the body of 229 the calls and replies. 231 Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, 232 and RPCSEC_GSS does not imply that the NFS protocol is limited to 233 using those five flavors. 235 2.3. Authentication for NFS Procedures 237 2.3.1. NULL Procedure 239 The NULL procedure is typically used by NFS clients to determine if 240 an NFS server is operating and responding to requests (in other 241 words, to "ping" the NFS server). Some NFS servers require that a 242 client using the NULL procedure: 244 * send the request from TCP or UDP port < 1024. There does not 245 seem to be any value in this because the NULL procedure is of 246 very low overhead and certainly no more overhead than the cost 247 of processing a NULL procedure and returning an authentication 248 error. Moreover, by sending back an authentication error, the 249 server has confirmed the information that the client was 250 interested in: is the server operating? 252 * be authenticated with a flavor stronger than AUTH_SYS. This is a 253 problem because the RPCSEC_GSS protocol uses NULL for control 254 messages. 256 NFS servers SHOULD: 258 * accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in 259 addition to other RPC security flavors, and 261 * NOT require that the source port be < 1024 on a NULL procedure 262 ping. 264 2.3.2. NFS Procedures Used at Mount Time 266 Certain NFS procedures are used at the time the NFS client mounts a 267 file system from the server. Some NFS server implementations will 268 not require authentication for these NFS procedures. For NFS 269 protocol Version 2, these procedures are GETATTR and STATFS. For 270 Version 3, the procedure is FSINFO. 272 The reason for not requiring authentication is described as follows. 273 When the NFS client mounts a NFS server's file system, the identity 274 of the caller on the client is typically an administrative entity (in 275 UNIX operating systems, this is usually the "root" user). It is 276 often the case that, for unattended operation in concert with an 277 automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS 278 credentials for the administrative entity associated with an 279 automounter are not available. If so, the NFS client will use 280 AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a 281 file system. While an attacker could exploit this implementation 282 artifact, the exposure is limited to gaining the attributes of a file 283 or a file system's characteristics. This OPTIONAL trade off favors 284 the opportunity for improved ease of use. 286 2.4. Binding Security Flavors to Exports 288 NFS servers MAY export file systems with specific security flavors 289 bound to the export. In the event a client uses a security flavor 290 that is not the one of the flavors the file system was exported with, 291 NFS server implementations MAY: 293 * reject the request with an error (either an NFS error or an RPC 294 level authentication error), or 296 * allow the request, but map the user's credentials to a user 297 other than the one the client intended. Typically the user that 298 is the result of this mapping is a user with limited access on 299 the system, such as user "nobody" on UNIX systems. 301 If a client uses AUTH_NONE, the server's options are the same as the 302 above, except that AUTH_NONE carries with it no user identity. In 303 order to allow the request, on many operating systems the server will 304 assign a user identity. Typically this assignment will be a user with 305 limited access on the system, such as user "nobody" on UNIX systems. 307 2.5. Anonymous Mapping 309 The following passage is excerpted verbatim from RFC 1813, section 310 4.4 "Permission Issues" (except that "may" has been changed to 311 "MAY"): 313 In most operating systems, a particular user (on UNIX, the uid 0) 314 has access to all files, no matter what permission and ownership 315 they have. This superuser permission MAY not be allowed on the 316 server, since anyone who can become superuser on their client 317 could gain access to all remote files. A UNIX server by default 318 maps uid 0 to a distinguished value (UID_NOBODY), as well as 319 mapping the groups list, before doing its access checking. A 320 server implementation MAY provide a mechanism to change this 321 mapping. This works except for NFS version 3 protocol root file 322 systems (required for diskless NFS version 3 protocol client 323 support), where superuser access cannot be avoided. Export 324 options are used, on the server, to restrict the set of clients 325 allowed superuser access. 327 The issues identified as applying to NFS protocol Version 3 in the 328 above passage also apply to Version 2. 330 2.6. Host-based Access Control 332 In some NFS server implementations, a host-based access control 333 method is used whereby file systems can be exported to lists of 334 clients. File systems may also be exported for read-only or read- 335 write access. Several of these implementations will check access 336 only at mount time, during the request for the file handle via the 337 MOUNT protocol handshake. The lack of authorization checking during 338 subsequent NFS requests has the following consequences: 340 * NFS servers are not able to repudiate access to the file system 341 by an NFS client after the client has mounted the file system. 343 * An attacker can circumvent the MOUNT server's access control to 344 gain access to a file system that the attacker is not authorized 345 for. The circumvention is accomplished by either stealing a file 346 handle (usually by snooping the network traffic between an 347 legitimate client and server) or guessing a file handle. For 348 this attack to succeed, the attacker must still be able 349 impersonate a user's credentials, which is simple for AUTH_SYS, 350 but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. 352 * WebNFS clients that use the public file handle lookup [RFC2054] 353 will not go through the MOUNT protocol to acquire initial file 354 handle of the NFS file system. Enforcing access control via the 355 MOUNT protocol is going to be a little use. Granted, some WebNFS 356 server implementations cope with this by limiting the use of the 357 public file handle to file systems exported to every client on 358 the Internet. 360 Thus, NFS server implementations SHOULD check the client's 361 authorization on each NFS request. 363 2.7. Security Flavor Negotiation 365 Any application protocol that supports multiple styles of security 366 will have the issue of negotiating the security method to be used. 367 NFS Version 2 had no support for security flavor negotiation. It was 368 up to the client to guess, or depend on prior knowledge. Often the 369 prior knowledge would be available in the form of security options 370 specified in a directory service used for the purpose of 371 automounting. 373 The MOUNT Version 3 protocol, associated with NFS Version 3, solves 374 the problem by having the response to the MNT procedure include a 375 list of flavors in the MNT procedure. Note that because some NFS 376 servers will export file systems to specific lists of clients, with 377 different access (read-only versus read-write), and with different 378 security flavors, it is possible a client might get back multiple 379 security flavors in the list returned in the MNT response. The use of 380 one flavor instead of another might imply read-only instead of read- 381 write access, or perhaps some other degradation of access. For this 382 reason, a NFS client SHOULD use the first flavor in the list that it 383 supports, on the assumption that the best access is provided by the 384 first flavor. NFS servers that support the ability to export file 385 systems with multiple security flavors SHOULD either present the best 386 accessing flavor first to the client, or leave the order under the 387 control of the system administrator. 389 2.8. Registering Flavors 391 When one develops a new RPC security flavor, iana@isi.edu MUST be 392 contacted to get a unique flavor assignment. To simplify NFS client 393 and server administration, having a simple ASCII string name for the 394 flavor is useful. Currently, the following assignments exist: 396 flavor string name 398 AUTH_NONE none 399 AUTH_SYS sys 400 AUTH_DH dh 401 AUTH_KERB4 krb4 403 A string name for a new flavor SHOULD be assigned. String name 404 assignments can be registered by contacting nfs-ana@sun.com. In the 405 future, this function may be transferred to iana@isi.edu. 407 3. The NFS Protocol's Use of RPCSEC_GSS 409 3.1. Server Principal 411 When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API 412 via a GSS_C_NT_HOSTBASED_SERVICE name type. 413 GSS_C_NT_HOSTBASED_SERVICE names are of the form: 415 service@hostname 417 For NFS, the "service" element is 419 nfs 421 3.2. Negotiation 423 RPCSEC_GSS is a single security flavor over which different security 424 mechanisms can be multiplexed. Within a mechanism, GSS-API provides 425 for the support of multiple quality of protections (QOPs), which are 426 pairs of cryptographic algorithms. Each algorithm in the QOP consists 427 of an encryption algorithm for privacy and a checksum algorithm for 428 integrity. RPCSEC_GSS lets one protect the RPC request/response pair 429 with plain header authentication, message integrity, and message 430 privacy. Thus RPCSEC_GSS effectively supports M * Q * 3 different 431 styles of security, where M is the number of mechanisms supported, Q 432 is the average number of QOPs supported for each mechanism, and 3 433 enumerates authentication, integrity, and privacy. 435 Because RPCSEC_GSS encodes many styles of security, just adding 436 RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT 437 response is not going to be of much use to the NFS client. 439 The solution is the creation of a concept called "pseudo flavors." 440 Pseudo flavors are 32 bit integers that are allocated out of the same 441 number space as regular RPC security flavors like AUTH_NONE, 442 AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each 443 pseudo flavor will map to a specific triple of security mechanism, 444 quality of protection, and service. The service will be one of 445 authentication, integrity, and privacy. Note that integrity includes 446 authentication, and privacy includes integrity. RPCSEC_GSS uses 447 constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and 448 rpc_gss_svc_privacy, for authentication, integrity, and privacy 449 respectively. 451 Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will 452 instead return one or more pseudo flavors if the NFS server supports 453 RPCSEC_GSS and if the file system has been exported with one or more 454 triples. See section 4, "The NFS Protocol 455 over Kerberos V5" for an example of pseudo flavor to triple mapping. 457 3.3. Changing RPCSEC_GSS Parameters 459 Once an RPCSEC_GSS session or context has been set up (via the 460 RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of 461 RPCSEC_GSS), the NFS server MAY lock the 462 triple for the duration of the session. While RPCSEC_GSS allows for 463 the use of different QOPs and services on each message, it would be 464 expensive for the NFS server to re-consult its table of exported file 465 systems to see if the triple was allowed. Moreover, by the time the 466 NFS server's dispatch routine was reached, the typical RPC subsystem 467 would already have performed the appropriate GSS-API operation, 468 GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or 469 privacy services were selected. If the file system being accessed 470 were not exported with integrity or privacy, or with the particular 471 QOP used to perform the integrity or privacy service, then it would 472 be possible to execute a denial of service attack, whereby the 473 objective of the caller is to deny CPU service to legitimate users of 474 the NFS server's machine processors. 476 Thus, in general, clients SHOULD NOT assume that they will be 477 permitted to alter the triple once the data 478 exchange phase of RPCSEC_GSS has started. 480 3.4. Registering Pseudo Flavors and Mappings 482 Pseudo flavor numbers MUST be registered via same method as regular 483 RPC security flavor numbers via iana@isi.edu. 485 Once the pseudo flavor number has been assigned, registrants SHOULD 486 register the mapping with nfs-ana@sun.com. The mapping registration 487 MUST contain: 489 * the pseudo flavor number, an ASCII string name for the flavor 490 (for example "none" has been assigned for AUTH_NONE), and 492 * the triple. As per the GSS- 493 API specification, the mechanism MUST be identified with a 494 unique ISO object identifier (OID). The reason why the second 495 component of the triple is not necessarily a QOP value is that 496 GSS-API allows mechanisms much latitude in the mapping of the 497 algorithm used in the default quality of protection (See 498 subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed 499 discussion). With some mechanisms, the second component of the 500 triple will be a QOP. Internally, on the NFS implementation, it 501 is expected that the triple would use a QOP for the second 502 component. 504 The mapping registration SHOULD also contain: 506 * A reference to an RFC (typically an Informational RFC) 507 describing how the NFS protocol MUST work over the pseudo 508 flavor(s), including the pseudo flavor number(s), string name(s) 509 for the flavor(s), and any other issues, including how the 510 registrant is interpreting the GSS-API mechanism. 512 * A reference to the GSS-API mechanism used. 514 An example of a complete registration is provided in subsection 4.2, 515 "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry." 517 4. The NFS Protocol over Kerberos V5 519 The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS 520 security flavor. The GSS-API security mechanism for Kerberos V5 that 521 the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos 522 V5 GSS-API description [RFC 1964]. 524 4.1. Issues with Kerberos V5 QOPs 526 The Kerberos V5 GSS-API description defines three algorithms for 527 integrity: 529 * DES MAC MD5 531 * MD2.5 533 * DES-MAC 535 RFC 1964 states that MD2.5 "may be significantly weaker than DES MAC 536 MD5." RFC 1964 also states that DES-MAC "may not be present in all 537 implementations." 539 Thus the description of operation of NFS clients and servers over 540 Kerberos V5 is limited to the DES MAC MD5 integrity algorithm. 542 NFS clients and servers operating over Kerberos V5 MUST support the 543 DES MAC MD5 integrity algorithm. RFC 1964 lists a single algorithm 544 for privacy: 56 bit DES. NFS clients and servers SHOULD support the 545 56 bit DES privacy algorithm. 547 GSS-API has the concept of a default QOP of zero which means 548 different integrity and privacy algorithms to different GSS-API 549 mechanisms. In Kerberos V5, the default QOP of zero means to use the 550 56 bit DES algorithm (when doing a GSS_Wrap() operation with the 551 conf_req_flag set to 1). 553 For Kerberos V5, the default QOP of zero means different integrity 554 algorithms to different implementations of Kerberos V5. Furthermore, 555 during the processing of a token in GSS_Unwrap(), and 556 GSS_VerifyMIC(), at least one reference implementation of the 557 Kerberos V5 GSS-API mechanism [MIT], always returns a QOP of zero, 558 regardless of integrity algorithm encoded in the token. For such 559 implementations, it means that the caller of GSS_Unwrap() and 560 GSS_VerifyMIC() cannot know the actual integrity algorithm used. 561 Given that each integrity algorithm has a different degree of 562 security, this situation may not be acceptable to the user of GSS- 563 API. An implementation of Kerberos V5 under GSS-API for use under NFS 564 MUST NOT do this. 566 For the purposes of NFS, as a simplification, some Kerberos V5 GSS- 567 API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity, 568 and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES 569 MAC MD5 integrity that is specified to QOP 0. 571 4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry 573 Here are the pseudo flavor mappings for the NFS protocol using 574 Kerberos V5 security: 576 columns: 578 1 == number of pseudo flavor 579 2 == name of pseudo flavor 580 3 == mechanism's OID 581 4 == mechanism's algorithm(s) 582 5 == RPCSEC_GSS service 584 1 2 3 4 5 585 ----------------------------------------------------------------------- 586 390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none 587 390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity 588 390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy 589 for integrity, 590 and 56 bit DES 591 for privacy. 593 An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that 594 maps the default QOP to DES MAC MD5 (and vice versa), would implement 595 a mapping of: 597 columns: 599 1 == number of pseudo flavor 600 2 == name of pseudo flavor 601 3 == mechanism's OID 602 4 == QOP 603 5 == RPCSEC_GSS service 605 1 2 3 4 5 606 ----------------------------------------------------------- 607 390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none 608 390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity 609 390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy 611 The reference for the GSS-API mechanism with the above OID is RFC 612 1964. 614 The reference for how the NFS protocol MUST work over Kerberos V5 is 615 this document. 617 5. Security Considerations 619 Version 3 of the MOUNT protocol is used to negotiate the security 620 flavor to be used by the NFS Version 3 client. If the NFS client uses 621 a weak security flavor like AUTH_SYS to query a Version 3 MOUNT 622 server, then the following attacks are possible by an attacker in the 623 middle: 625 * The attacker in the middle can coax the NFS client into using a 626 weaker form of security than what the real NFS server requires. 627 However, once the NFS client selects a security flavor when it 628 sends a request to real NFS server, if the flavor is 629 unacceptable, the NFS client's NFS request will be rejected. So 630 at worst, a denial of service attack is possible. In theory, the 631 NFS client could contact the MOUNT server using a stronger 632 security flavor, but this would require that the client know in 633 advance what security flavors the MOUNT server supports. 635 * If the client and server support a common set of security 636 flavors, such that the client considers one preferable to the 637 other (for example, one might have privacy and other not), 638 unless the client uses a strong security flavor in the MOUNT 639 protocol query, an attacker in the middle could cause the client 640 to use the weaker form of security. Again, a client could 641 contact the MOUNT server using a stronger form of security. 643 References 645 [RFC1094] Sun Microsystems, Inc. (1989). "NFS: Network File System 646 Protocol specification," RFC 1094. 647 http://info.internet.isi.edu/in-notes/rfc/files/rfc1094.txt 649 [Sandberg] 650 Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, 651 B.. (1985). "Design and Implementation of the Sun Network 652 Filesystem," Proceedings of the 1985 Summer USENIX 653 Technical Conference. 655 [RFC1813] Callaghan, B., Pawlowski, B., Staubach, P. (1995). "NFS 656 Version 3 Protocol Specification," RFC 1813. 657 http://info.internet.isi.edu/in-notes/rfc/files/rfc1813.txt 659 [RFC1831] Srinivasan, R. (1995). "RPC: Remote Procedure Call Protocol 660 Specification Version 2," RFC 1831. 661 http://info.internet.isi.edu/in-notes/rfc/files/rfc1831.txt 663 [RFC1832] Srinivasan, R. (1995). "XDR: External Data Representation 664 Standard," RFC 1832. 665 http://info.internet.isi.edu/in-notes/rfc/files/rfc1832.txt 667 [Pawlowski] 668 Pawlowski, B., Juszczak, C., Staubach, P., Smith, C., 669 Lebel, D., Hitz, D. (1994). "NFS Version 3 Design and 670 Implementation," Proceedings of the USENIX Summer 1994 671 Technical Conference. 673 [RFC2203] Eisler, M., Chiu, A., Ling L. (1997). "RPCSEC_GSS Protocol 674 Specification," RFC 2203. 675 http://info.internet.isi.edu/in-notes/rfc/files/rfc2203.txt 677 [RFC2078] Linn, J. (1997). "Generic Security Service Application 678 Program Interface, Version 2," RFC 2078. 679 http://info.internet.isi.edu/in-notes/rfc/files/rfc2078.txt 681 [RFC1057] Sun Microsystems, Inc. "RPC: Remote Procedure Call Protocol 682 Specification Version 2," RFC 1057. This RFC is being 683 referenced for its description of the AUTH_DH (AUTH_DES) 684 RPC security flavor. 685 http://info.internet.isi.edu/in-notes/rfc/files/rfc1057.txt 687 [RFC2119] Bradner, S. (1997). "Key words for use in RFCs to Indicate 688 Requirement Levels," RFC 2119. 689 http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt 691 [Callaghan] 692 Callaghan, B., Singh, S. (1993). "The Autofs Automounter," 693 Proceedings of the 1993 Summer USENIX Technical Conference. 695 [RFC1964] Linn, J. (1996). "The Kerberos Version 5 GSS-API 696 Mechanism," RFC 1964. 697 http://info.internet.isi.edu/in-notes/rfc/files/rfc1964.txt 699 [RFC2054] Callaghan, B. (1996). "WebNFS Client Specification," RFC 700 2054. 701 http://info.internet.isi.edu/in-notes/rfc/files/rfc2054.txt 703 [MIT] Massachusetts Institute of Technology (1998). "Kerberos: 704 The Network Authentication Protocol." The Web site for 705 downloading MIT's implementation of Kerberos V5, including 706 implementations of RFC 1510 and RFC 1964. 707 http://web.mit.edu/kerberos/www/index.html 709 Acknowledgments 711 The author thanks: 713 * Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve 714 Nahm, and David Robinson for their review comments. 716 * John Linn, for his explanation of QOP handling in RFC 1964. 718 Author's Address 720 Address comments related to this memorandum to: 722 nfsv4-wg@sunroof.eng.sun.com 724 Mike Eisler 725 Sun Microsystems, Inc. 726 5565 Wilson Road 727 Colorado Springs, CO 80919 729 Phone: 1-719-599-9026 730 E-mail: mre@eng.sun.com