RFC 2623

NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5

📅 published June 1999, from ietf

RFC 2623 ✨ NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5

Bestie, here's the title block 🎀 This one is RFC 2623, written by M. Eisler at Sun Microsystems, Inc. It's a Standards Track doc from the Network Working Group, dated June 1999 🌸. Its full title is "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5" 💅.

Status of This Memo 📜

Okay so this doc is an Internet standards track protocol for the Internet community 🦋. It also asks for discussion and suggestions for improvements, so bring your ideas! 💖 For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share it with everyone 🌈.

Copyright (C) The Internet Society (1999). All Rights Reserved. 🫶

Abstract 🌟

This memo clarifies a bunch of security issues in the NFS protocol, but only for Version 2 and Version 3 💅. Then it explains how NFS Version 2 and Version 3 use the RPCSEC_GSS security flavor protocol and Kerberos V5 🔐. It's written so people can build implementations that actually work together 🧚.

Table of Contents 🗂️

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   1.1.  Overview of RPC Security Architecture  . . . . . . . . . . . 3
   2.  Overview of NFS Security . . . . . . . . . . . . . . . . . . . 3
   2.1.  Port Monitoring  . . . . . . . . . . . . . . . . . . . . . . 3
   2.1.1.  MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 4
   2.2.  RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 4
   2.2.1.  AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.2.2.  AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5
   2.2.3.  RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 5
   2.3.  Authentication for NFS Procedures  . . . . . . . . . . . . . 6
   2.3.1.  NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6
   2.3.2.  NFS Procedures Used at Mount Time  . . . . . . . . . . . . 6
   2.4.  Binding Security Flavors to Exports  . . . . . . . . . . . . 7
   2.5.  Anonymous Mapping  . . . . . . . . . . . . . . . . . . . . . 7
   2.6.  Host-based Access Control  . . . . . . . . . . . . . . . . . 8
   2.7.  Security Flavor Negotiation  . . . . . . . . . . . . . . . . 8
   2.8.  Registering Flavors  . . . . . . . . . . . . . . . . . . . . 9
   3.  The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . .   9
   3.1.  Server Principal . . . . . . . . . . . . . . . . . . . . .   9
   3.2.  Negotiation  . . . . . . . . . . . . . . . . . . . . . . .   9
   3.3.  Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . .  10
   3.4.  Registering Pseudo Flavors and Mappings  . . . . . . . . .  11
   4.  The NFS Protocol over Kerberos V5  . . . . . . . . . . . . .  11
   4.1.  Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . .  12
   4.2.  The NFS Protocol over Kerberos V5 Pseudo Flavor
         Registration Entry . . . . . . . . . . . . . . . . . . . .  13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . .  14
   6.  IANA Considerations [RFC2434]  . . . . . . . . . . . . . . .  14
   6.1.  Pseudo Flavor Number . . . . . . . . . . . . . . . . . . .  14
   6.2.  String Name of Pseudo Flavor . . . . . . . . . . . . . . .  15
   6.2.1.  Name Space Size  . . . . . . . . . . . . . . . . . . . .  15
   6.2.2.  Delegation . . . . . . . . . . . . . . . . . . . . . . .  15
   6.2.3.  Outside Review . . . . . . . . . . . . . . . . . . . . .  15
   6.3.  GSS-API Mechanism OID  . . . . . . . . . . . . . . . . . .  15
   6.4.  GSS-API Mechanism Algorithm Values . . . . . . . . . . . .  15
   6.5.  RPCSEC_GSS Security Service  . . . . . . . . . . . . . . .  16
   References . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  18
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  19

1. Introduction 🦋

Okay so NFS is the thing that gives you transparent remote access to shared file systems across networks 💻✨. It's designed to be machine, operating system, network architecture, and security mechanism, and transport protocol independent 🌈. That independence comes from using ONC Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR) 🧚.

NFS Version 2 is specified in the Network File System Protocol Specification [RFC1094] 📖. You can read about the first implementation in [Sandberg] 🍓. NFS Version 3 is specified in the NFS Version 3 Protocol Specification [RFC1813] 💜. Some of the early implementations are described in [Pawlowski] ✨.

For the rest of this document, whenever it says "the NFS protocol," it means NFS Version 2 and Version 3, unless it says otherwise 🎀.

The RPC protocol is specified in the Remote Procedure Call Protocol Specification Version 2 [RFC1831] 🌸. The XDR protocol is specified in External Data Representation Standard [RFC1832] 🫶.

A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203] 🔥. It lets application protocols built on RPC reach security mechanisms that follow the GSS-API specification [RFC2078] 👑.

The goal of this doc is to clear up NFS security issues and to specify how the NFS protocol uses RPCSEC_GSS 💅. It also explains how NFS works over Kerberos V5, through RPCSEC_GSS 🔐.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🌈

1.1. Overview of RPC Security Architecture 🔐

Every RPC call has a slot for security parameters 🎀. The RPC spec calls these an authentication flavor [RFC1831]. What goes in that slot depends on the type of authentication the server and client are using 💖. A server can support several flavors at the same time, which is very main character energy 👑. Here are some of the better-known flavors:

  • The AUTH_NONE flavor provides null authentication 🫥. That just means no authentication information gets passed along.
  • The AUTH_SYS flavor gives you a UNIX-style user identifier, a group identifier, and an array of supplemental group identifiers with each call 🐧.
  • The AUTH_DH flavor (sometimes called AUTH_DES [RFC1057]) uses DES-encrypted authentication parameters 🔒. Those are based on a network-wide string name, and the session keys get exchanged with the Diffie-Hellman public key scheme 🦋.
  • The AUTH_KERB4 flavor also uses DES-encrypted authentication parameters, based on a network-wide string name 🌸. That name is a Kerberos Version 4 principal identifier, and session keys get exchanged through Kerberos Version 4 secret keys 🗝️.

NFS isn't limited to just this list of flavors ✨.

2. Overview of NFS Security 🛡️

2.1. Port Monitoring 🚪

Lots of NFS servers will want the client to send its NFS requests from UDP or TCP source ports with values < 1024 🙈. The idea is that binding to ports < 1024 is a privileged operation on the client, so the client is basically enforcing file access permissions on its own end 🧐. Except the idea falls apart, bestie 💀:

  • On lots of operating systems, there's no restriction on which user can bind to which port 😭.
  • Just because the client host enforces the privilege for binding to ports < 1024 doesn't mean a non-privileged user can't get that privilege anyway 🙃. Like, picture a single-user desktop running UNIX. The user might know the root password. And even if they don't, with physical access to the machine, root privileges are trivially acquired 💀.

In some rare cases, when the sysadmin can be certain the clients are trusted and under control (especially protected from physical attack), relying on trusted ports MAY be a reliable form of security 🫶.

In most cases though, privileged ports and port monitoring for security are at best an inconvenience to an attacker, and they SHOULD NOT be depended on 😤.

To keep things interoperable 🌈:

  • NFS clients SHOULD attempt to bind to ports < 1024. If they fail to bind (because the user doesn't have the privilege, or there's no free port < 1024), the NFS client MAY want to try the NFS operation over a port >= 1024 🦋.
  • NFS servers that implement port monitoring SHOULD provide a way to turn it off 🔌.
  • Whether port monitoring is on or off, NFS servers SHOULD NOT reject NFS requests to the NULL procedure (procedure number 0). See subsection 2.3.1, "NULL procedure", for the full explanation 🧚.

2.1.1. MOUNT Protocol 📂

All the port monitoring issues and recommendations apply to the MOUNT protocol too 💅.

2.2. RPC Security Flavors 🎀

The NFS server checks permissions by pulling the credentials out of the RPC security information in each remote request 👀. Each flavor packages its credentials differently 🍓.

2.2.1. AUTH_SYS 🐧

With the AUTH_SYS flavor, the server gets the client's effective user identifier, effective group identifier, and supplemental group identifiers on every call 💖. It uses those to check access. Using user and group identifiers means the client and server either share the same identifier name space, or they do local user and group identifier mapping 🗺️.

For sites that don't have a consistent user and group identifier space, NFS implementations must agree on how user and group identifiers get mapped between NFS clients and servers 🫶.

2.2.2. AUTH_DH and AUTH_KERB4 🔐

AUTH_DH and AUTH_KERB4 are both based on a network-wide name ✨. They're more secure because they use DES encryption, plus public keys for AUTH_DH and Kerberos secret keys (and tickets) for AUTH_KERB4 👑. With both, the server and client have to agree on who a particular name on the network is 🧚. But mapping names to identities is less tied to the operating system than mapping user and group identifiers is in AUTH_SYS 🌈. Also, since the authentication parameters are encrypted, a malicious user must know another user's network password or private key to pretend to be that user 😈. The server sends back a verifier that's encrypted too, so pretending to be the server means knowing a network password 🔒.

2.2.3. RPCSEC_GSS 🔥

RPCSEC_GSS is based on a security-mechanism-specific principal name 🦋. GSS-API mechanisms provide security through cryptography 🔐. Those cryptographic protections get used to build the credential on calls, and the verifiers on replies 💅. Optionally, cryptographic protections can also go in the body of the calls and replies 🌸.

Heads up: talking about AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS does not mean NFS is limited to those five flavors 🌈. It just means that's what we're covering here ✨.

2.3. Authentication for NFS Procedures 🔑

2.3.1. NULL Procedure 🏓

okay so the NULL procedure is basically how NFS clients go "hey, you alive?" 💖 They use it to "ping" the NFS server and check that it's operating and answering requests. Some NFS servers are kinda picky tho and want a client using NULL to:

  • send the request from TCP or UDP port < 1024. ngl there doesn't seem to be much point 🙄. NULL is super low overhead, and it costs no more than processing a NULL call and sending back an authentication error. Plus, by sending back that auth error, the server has already answered the client's question: is the server operating? 🤷‍♀️
  • be authenticated with a flavor stronger than AUTH_SYS. This is a whole mess 💀 because the RPCSEC_GSS protocol uses NULL for control messages.

NFS servers SHOULD:

  • accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in addition to other RPC security flavors, and
  • NOT require that the source port be < 1024 on a NULL procedure ping.

2.3.2. NFS Procedures Used at Mount Time 🧚

certain NFS procedures run at the moment a client mounts a file system from the server. Some server implementations won't ask for authentication on these, which is lowkey iconic for ease of use ✨. For NFS protocol Version 2, the procedures are GETATTR and STATFS. For Version 3, it's just FSINFO.

so why skip auth? When an NFS client mounts a server's file system, the caller on the client is usually an administrative entity (on UNIX this is typically the "root" user 👑). With unattended operation alongside an automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS credentials for that admin entity are often not available. If that's the case, the NFS client will use AUTH_NONE or AUTH_SYS for the initial NFS operations it uses to mount the file system. An attacker could exploit this implementation artifact, but the exposure is limited to gaining the attributes of a file or a file system's characteristics. This OPTIONAL trade-off favors the opportunity for improved ease of use 🫶.

2.4. Binding Security Flavors to Exports 🎀

NFS servers MAY export file systems with specific security flavors bound to the export. If a client uses a security flavor that isn't one of the flavors the file system was exported with, NFS server implementations MAY:

  • reject the request with an error (either an NFS error or an RPC level authentication error), or
  • allow the request, but map the user's credentials to a user other than the one the client intended. This is usually a user with limited access on the system, like user "nobody" on UNIX systems 🫣.

If a client uses AUTH_NONE, the server's options are the same as above, except that AUTH_NONE carries no user identity with it. To allow the request anyway, many operating systems will assign a user identity. This is typically a user with limited access on the system, such as user "nobody" on UNIX systems.

2.5. Anonymous Mapping 🌸

The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):

In most operating systems, a particular user (on UNIX, the uid 0) has access to all files, no matter what permission and ownership they have. This superuser permission MAY not be allowed on the server, since anyone who can become superuser on their client could gain access to all remote files. A UNIX server by default maps uid 0 to a distinguished value (UID_NOBODY), as well as mapping the groups list, before doing its access checking. A server implementation MAY provide a mechanism to change this mapping. This works except for NFS version 3 protocol root file systems (required for diskless NFS version 3 protocol client support), where superuser access cannot be avoided. Export options are used, on the server, to restrict the set of clients allowed superuser access.

the issues identified as applying to NFS protocol Version 3 in the passage above also apply to Version 2 🙌.

2.6. Host-based Access Control 🔐

in some NFS server implementations, a host-based access control method is used, where file systems can be exported to lists of clients. File systems may also be exported for read-only or read-write access. Several of these implementations only check access at mount time, during the request for the file handle via the MOUNT protocol handshake. Not checking authorization on later NFS requests causes these consequences:

  • NFS servers are not able to repudiate access to the file system by an NFS client after the client has mounted the file system.
  • An attacker can get around the MOUNT server's access control to reach a file system they aren't authorized for 😱. They do this by either stealing a file handle (usually by snooping the network traffic between a legitimate client and server) or by guessing one. For this attack to work, the attacker must still be able to impersonate a user's credentials. That's simple for AUTH_SYS, but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
  • WebNFS clients that use the public file handle lookup [RFC2054] won't go through the MOUNT protocol to get the initial file handle for the NFS file system. So enforcing access control via the MOUNT protocol is going to be pretty pointless 🙃. To be fair, some WebNFS server implementations cope with this by limiting the use of the public file handle to file systems exported to every client on the Internet.

Thus, NFS server implementations SHOULD check the client's authorization on each NFS request. no skipping this one bestie 💅.

2.7. Security Flavor Negotiation 🦋

any application protocol that supports multiple styles of security has to deal with negotiating which security method gets used. NFS Version 2 had no support for security flavor negotiation at all, so it was up to the client to guess or rely on prior knowledge 🥲. Often that prior knowledge came from security options in a directory service used for automounting.

The MOUNT Version 3 protocol, which goes with NFS Version 3, solves this by having the response to the MNT procedure include a list of flavors. Here's the catch: because some NFS servers export file systems to specific lists of clients, with different access (read-only versus read-write) and different security flavors, a client might get back multiple security flavors in that list. Using one flavor instead of another might imply read-only instead of read-write access, or some other degradation of access. For that reason, an NFS client SHOULD use the first flavor in the list that it supports, on the assumption that the best access is provided by the first flavor 👑. NFS servers that can export file systems with multiple security flavors SHOULD either present the best accessing flavor first to the client, or leave the order under the control of the system administrator.

2.8. Registering Flavors 📝

when someone develops a new RPC security flavor, iana@iana.org MUST be contacted to get a unique flavor assignment. Having a simple ASCII string name for the flavor makes NFS client and server administration way easier 🫶. Right now, these assignments exist:

flavor       string name

AUTH_NONE    none
AUTH_SYS     sys
AUTH_DH      dh
AUTH_KERB4   krb4

A string name for a new flavor SHOULD be assigned. String name assignments can be registered by contacting iana@iana.org.

3. The NFS Protocol's Use of RPCSEC_GSS 🔥

3.1. Server Principal 🧚‍♀️

when using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names look like this:

service@hostname

For NFS, the "service" element is:

nfs

3.2. Negotiation 🌈

okay this one is a lot but it's so good 🤌. RPCSEC_GSS is a single security flavor that can multiplex different security mechanisms. Within a mechanism, GSS-API supports multiple quality of protections (QOPs), which are pairs of cryptographic algorithms. Each algorithm in the QOP is made of an encryption algorithm for privacy and a checksum algorithm for integrity. RPCSEC_GSS lets you protect the RPC request/response pair with plain header authentication, message integrity, and message privacy. So RPCSEC_GSS effectively supports M * Q * 3 different styles of security, where M is the number of mechanisms supported, Q is the average number of QOPs supported for each mechanism, and 3 enumerates authentication, integrity, and privacy 😳.

Because RPCSEC_GSS encodes so many styles of security, just adding RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT response isn't going to be much use to the NFS client 🙈.

The solution is a concept called "pseudo flavors." Pseudo flavors are 32 bit integers allocated out of the same number space as regular RPC security flavors like AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each pseudo flavor maps to a specific triple of security mechanism, quality of protection, and service. The service is one of authentication, integrity, and privacy. Note that integrity includes authentication, and privacy includes integrity ✨. RPCSEC_GSS uses the constants rpc_gss_svc_none, rpc_gss_svc_integrity, and rpc_gss_svc_privacy for authentication, integrity, and privacy respectively.

So instead of returning RPCSEC_GSS, a MOUNT Version 3 server will return one or more pseudo flavors if the NFS server supports RPCSEC_GSS and the file system has been exported with one or more <mechanism, QOP, service> triples. See section 4, "The NFS Protocol over Kerberos V5" for an example of pseudo flavor to triple mapping 🦋.

3.3. Changing RPCSEC_GSS Parameters ✨

okay so once an RPCSEC_GSS session or context is set up (through the RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of RPCSEC_GSS 💖), the NFS server MAY lock the <mechanism, QOP, service> triple for the whole session. RPCSEC_GSS lets every message use a different QOP and service, but it would be super expensive for the NFS server to keep re-checking its table of exported file systems to see if the triple is allowed. 🙈 And by the time the dispatch routine is reached, the typical RPC subsystem has already run the GSS-API operation (GSS_VerifyMIC() or GSS_Unwrap(), if the integrity or privacy services were picked). If the file system being accessed wasn't exported with integrity or privacy, or with the particular QOP used for that service, then someone could pull off a denial of service attack, where the caller's whole goal is to hog CPU service away from the legitimate users of the NFS server's machine processors. 💀

Thus, in general, clients SHOULD NOT assume they'll be allowed to alter the <mechanism, QOP, service> triple once the data exchange phase of RPCSEC_GSS has started. 🫶

3.4. Registering Pseudo Flavors and Mappings 🦋

Pseudo flavor numbers MUST be registered via the same method as regular RPC security flavor numbers, through iana@iana.org. 📮

Once the pseudo flavor number has been assigned, registrants SHOULD register the mapping with iana@iana.org. The mapping registration MUST contain:

  • the pseudo flavor number, an ASCII string name for the flavor (for example "none" has been assigned for AUTH_NONE), and
  • the <mechanism, algorithm(s), service> triple. As per the GSS-API specification, the mechanism MUST be identified with a unique ISO object identifier (OID). The reason the second component of the triple isn't necessarily a QOP value is that GSS-API gives mechanisms a lot of latitude in mapping the algorithm used in the default quality of protection. (See subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed discussion.) With some mechanisms, the second component of the triple will be a QOP. Internally, on the NFS implementation, it is expected that the triple would use a QOP for the second component. 🧚

The mapping registration SHOULD also contain:

  • A reference to an RFC describing how the NFS protocol works over the pseudo flavor(s), including the pseudo flavor number(s), string name(s) for the flavor(s), and any other issues, including how the registrant is interpreting the GSS-API mechanism.
  • A reference to the GSS-API mechanism used.

An example of a complete registration is provided in subsection 4.2, "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry." ✨

4. The NFS Protocol over Kerberos V5 🌸

The NFS protocol uses Kerberos V5 security with the RPCSEC_GSS security flavor. The GSS-API security mechanism for Kerberos V5 that the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos V5 GSS-API description [RFC1964]. 👑

4.1. Issues with Kerberos V5 QOPs 💅

The Kerberos V5 GSS-API description defines three algorithms for integrity:

  • DES MAC MD5
  • MD2.5
  • DES-MAC

RFC 1964 states that MD2.5 "may be significantly weaker than DES MAC MD5." RFC 1964 also states that DES-MAC "may not be present in all implementations." 🙈

Thus the description of how NFS clients and servers operate over Kerberos V5 is limited to the DES MAC MD5 integrity algorithm.

NFS clients and servers operating over Kerberos V5 MUST support the DES MAC MD5 integrity algorithm. RFC 1964 lists a single algorithm for privacy: 56 bit DES. NFS clients and servers SHOULD support the 56 bit DES privacy algorithm. 🔐

GSS-API has this concept of a default QOP of zero, which means different integrity and privacy algorithms for different GSS-API mechanisms. In Kerberos V5, the default QOP of zero means to use the 56 bit DES algorithm (when doing a GSS_Wrap() operation with the conf_req_flag set to 1). 🧁

For Kerberos V5, the default QOP of zero means different integrity algorithms for different implementations of Kerberos V5. Furthermore, during the processing of a token in GSS_Unwrap() and GSS_VerifyMIC(), at least one reference implementation of the Kerberos V5 GSS-API mechanism [MIT] always returns a QOP of zero, regardless of the integrity algorithm encoded in the token. For such implementations, it means the caller of GSS_Unwrap() and GSS_VerifyMIC() cannot know the actual integrity algorithm used. Given that each integrity algorithm has a different degree of security, this situation may not be acceptable to the user of GSS-API. An implementation of Kerberos V5 under GSS-API for use under NFS MUST NOT do this. 🚫

For the purposes of NFS, as a simplification, some Kerberos V5 GSS-API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity, and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES MAC MD5 integrity that is specified to QOP 0. ✨

4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry 🎀

Here are the pseudo flavor mappings for the NFS protocol using Kerberos V5 security:

 columns:

 1 == number of pseudo flavor
 2 == name of pseudo flavor
 3 == mechanism's OID
 4 == mechanism's algorithm(s)
 5 == RPCSEC_GSS service

 1      2     3                    4              5
 -----------------------------------------------------------------------
 390003 krb5  1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_none
 390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_integrity
 390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5    rpc_gss_svc_privacy
                                   for integrity,
                                   and 56 bit DES
                                   for privacy.

An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that maps the default QOP to DES MAC MD5 (and vice versa) would implement a mapping of:

      columns:

      1 == number of pseudo flavor
      2 == name of pseudo flavor
      3 == mechanism's OID
      4 == QOP
      5 == RPCSEC_GSS service

      1      2     3                     4  5
      -----------------------------------------------------------
      390003 krb5  1.2.840.113554.1.2.2  0  rpc_gss_svc_none
      390004 krb5i 1.2.840.113554.1.2.2  0  rpc_gss_svc_integrity
      390005 krb5p 1.2.840.113554.1.2.2  0  rpc_gss_svc_privacy

The reference for the GSS-API mechanism with the above OID is [RFC1964]. 📚

The reference for how the NFS protocol MUST work over Kerberos V5 is this document. 💜

5. Security Considerations 💀

Version 3 of the MOUNT protocol is used to negotiate the security flavor to be used by the NFS Version 3 client. If the NFS client uses a weak security flavor like AUTH_SYS to query a Version 3 MOUNT server, then the following attacks are possible by an attacker in the middle:

  • The attacker in the middle can coax the NFS client into using a weaker form of security than what the real NFS server requires. However, once the NFS client selects a security flavor when it sends a request to the real NFS server, if the flavor is unacceptable, the NFS client's NFS request will be rejected. So at worst, a denial of service attack is possible. In theory, the NFS client could contact the MOUNT server using a stronger security flavor, but this would require that the client know in advance what security flavors the MOUNT server supports. 😱
  • If the client and server support a common set of security flavors, such that the client considers one preferable to the other (for example, one might have privacy and the other not), unless the client uses a strong security flavor in the MOUNT protocol query, an attacker in the middle could cause the client to use the weaker form of security. Again, a client could contact the MOUNT server using a stronger form of security. 🚨

6. IANA Considerations [RFC2434] 🧚

This memorandum describes how NFS Version 2 and Version 3 work over RPC's RPCSEC_GSS security flavor. This memorandum requires that triples of { GSS-API mechanism OID, GSS-API mechanism algorithm, RPCSEC_GSS security service } be mapped to a unique RPC security flavor number, which is a pseudo flavor that does not appear in an RPC protocol header. This memorandum also encourages that an ASCII string name be registered with the triple. 🎀

Thus there are five different kinds of objects to consider guidelines for. 🌈

6.1. Pseudo Flavor Number 🔢

The considerations of assignment, allocation, and delegation of pseudo flavor numbers are no different than the considerations for RPC security flavors, as both are assigned from the same number space. IANA is already responsible for the assignment of RPC security flavors, and because this memorandum does not specify the RPC protocol [RFC1831], it is beyond the scope of this memorandum to guide IANA in the assignment of flavor numbers. 🙌

6.2. String Name of Pseudo Flavor 🏷️

This memorandum introduces the concept of a string name to be associated with the RPC pseudo flavor number, so it is within the scope of this memorandum to provide guidance to IANA. ✨

6.2.1. Name Space Size 📏

There are no limits placed on the length of the unique string name by this memorandum, so the size of the name space is infinite. However, IANA may want to prevent the hoarding or reservation of names. The simplest way to do this is by requiring the registrant to provide the GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS security service, and flavor number, along with the request for a flavor name. If the registrant does not have a flavor number, then guidelines for flavor number assignments will indirectly limit the assignment of flavor names. 🫣

6.2.2. Delegation 🤝

The simplest way to handle delegation is to delegate portions of the RPC security flavor number space along with the RPC flavor name space. The guidelines for delegation of the flavor name space are thus equivalent to the guidelines for delegation of the flavor number space. 💅

6.2.3. Outside Review ⚖️

Because string names can be trademarks, IANA may want to seek legal counsel to review a proposed pseudo flavor name. Other than that, no outside review is necessary. 👀

6.3. GSS-API Mechanism OID 🔑

This memorandum assumes that the mechanism OID associated with the pseudo flavor has already been allocated. OIDs are allocated by the International Standards Organization and the International Telecommunication Union. Both organizations have delegated assignment authority for subsets of the OID number space to other organizations. Presumably, IANA has received authority to assign OIDs to GSS-API mechanisms. Because this memorandum does not specify the GSS-API protocol (see [RFC2078]), it is beyond the scope of this memorandum to guide IANA in the assignment of GSS-API mechanism OIDs. 🦋

6.4. GSS-API Mechanism Algorithm Values 🧮

This memorandum assumes that the algorithm value for a given GSS-API mechanism has already been allocated. Algorithm values are controlled by the owner of the GSS-API mechanism, though the owner may delegate assignment of algorithm values to a body such as IANA. Because this memorandum does not specify GSS-API mechanisms, such as [RFC1964], it is beyond the scope of this memorandum to guide IANA in the assignment of a mechanism's algorithm value(s). 🌸

6.5. RPCSEC_GSS Security Service

okay so there are only three security services for RPCSEC_GSS 💅, and they're enumerated and described in [RFC2203]. IANA doesn't need any guidelines for this one 🫶

References

Acknowledgments

The author thanks:

  • Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve Nahm, Joyce Reynolds, and David Robinson for their review comments.
  • John Linn, for his explanation of QOP handling in RFC 1964.

Author's Address

Address comments related to this memorandum to:

nfsv4-wg@sunroof.eng.sun.com

Mike Eisler
Sun Microsystems, Inc.
5565 Wilson Road
Colorado Springs, CO 80919

Phone: 1-719-599-9026
EMail: mre@eng.sun.com

Okay, the legal stuff matters, so this part stays word-for-word 🎀

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of eveloping Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from