rfc2623.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          M. Eisler
Request for Comments: 2623                        Sun Microsystems, Inc.
Category: Standards Track                                      June 1999


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

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memorandum clarifies various security issues involving the NFS
   protocol (Version 2 and Version 3 only) and then describes how the
   Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS
   security flavor protocol and Kerberos V5.  This memorandum is
   provided so that people can write compatible implementations.

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



Eisler                      Standards Track                     [Page 1]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


   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

   The NFS protocol provides transparent remote access to shared file
   systems across networks. The NFS protocol is designed to be machine,
   operating system, network architecture, and security mechanism, and
   transport protocol independent. This independence is achieved through
   the use of ONC Remote Procedure Call (RPC) primitives built on top of
   an eXternal Data Representation (XDR).  NFS protocol Version 2 is
   specified in the Network File System Protocol Specification
   [RFC1094]. A description of the initial implementation can be found
   in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version
   3 Protocol Specification [RFC1813]. A description of some initial
   implementations can be found in [Pawlowski].

   For the remainder of this document, whenever it refers to the NFS
   protocol, it means NFS Version 2 and Version 3, unless otherwise
   stated.

   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].
   This new flavor allows application protocols built on top of RPC to
   access security mechanisms that adhere to the GSS-API specification



Eisler                      Standards Track                     [Page 2]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


   [RFC2078].

   The purpose of this document is to clarify NFS security issues and to
   specify how the NFS protocol uses RPCSEC_GSS. This document will also
   describe how NFS works over Kerberos V5, via 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

   The RPC protocol includes a slot for security parameters (referred to
   as an authentication flavor in the RPC specification [RFC1831]) on
   every call.  The contents of the security parameters are determined
   by the type of authentication used by the server and client. A server
   may support several different flavors of authentication at once.
   Some of the better known flavors are summarized as follows:

   *    The AUTH_NONE flavor provides null authentication, that is, no
        authentication information is passed.

   *    The AUTH_SYS flavor provides a UNIX-style user identifier, group
        identifier, and an array of supplemental group identifiers with
        each call.

   *    The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057]) flavor
        provides DES-encrypted authentication parameters based on a
        network-wide string name, with session keys exchanged via the
        Diffie-Hellman public key scheme.

   *    The AUTH_KERB4 flavor provides DES encrypted authentication
        parameters based on a network-wide string name (the name is a
        Kerberos Version 4 principal identifier) with session keys
        exchanged via Kerberos Version 4 secret keys.

   The NFS protocol is not limited to the above list of security
   flavors.

2.  Overview of NFS Security

2.1.  Port Monitoring

   Many NFS servers will require that the client send its NFS requests
   from UDP or TCP source ports with values < 1024. The theory is that
   binding to ports < 1024 is a privileged operation on the client, and
   so the client is enforcing file access permissions on its end. The
   theory breaks down because:



Eisler                      Standards Track                     [Page 3]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


   *    On many operating systems, there are no constraints on what port
        what user can bind to.

   *    Just because the client host enforces the privilege on binding
        to ports < 1024 does not necessarily mean that a non-privileged
        user cannot gain access to the port binding privilege. For
        example with a single-user desk-top host running a UNIX
        operating system, the user may have knowledge of the root user
        password. And even if he does not have that knowledge, with
        physical access to the desk-top machine, root privileges are
        trivially acquired.

   In some rare cases, when the system administrator can be certain that
   the clients are trusted and under control (in particular, protected
   from physical attack), relying of trusted ports MAY be a reliable
   form of security.

   In most cases, the use of privileged ports and port monitoring for
   security is at best an inconvenience to the attacker and SHOULD NOT
   be depended on.

   To maximize interoperability:

   *    NFS clients SHOULD attempt to bind to ports < 1024. In some
        cases, if they fail to bind (because either the user does not
        have the privilege to do so, or there is no free port < 1024),
        the NFS client MAY wish to attempt the NFS operation over a port
        >= 1024.

   *    NFS servers that implement port monitoring SHOULD provide a
        method to turn it off.

   *    Whether port monitoring is enabled or not, NFS servers SHOULD
        NOT reject NFS requests to the NULL procedure (procedure number
        0). See subsection 2.3.1, "NULL procedure" for a complete
        explanation.

2.1.1.  MOUNT Protocol

   The port monitoring issues and recommendations apply to the MOUNT
   protocol as well.

2.2.  RPC Security Flavors

   The NFS server checks permissions by taking the credentials from the
   RPC security information in each remote request. Each flavor packages
   credentials differently.




Eisler                      Standards Track                     [Page 4]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


2.2.1.  AUTH_SYS

   Using the AUTH_SYS flavor of authentication, the server gets the
   client's effective user identifier, effective group identifier and
   supplemental group identifiers on each call, and uses them to check
   access. Using user identifiers and group identifiers implies that the
   client and server either share the same identifier name space or do
   local user and group identifier mapping.

   For those sites that do not implement a consistent user identifier
   and group identifier space, NFS implementations must agree on the
   mapping of user and group identifiers between NFS clients and
   servers.

2.2.2.  AUTH_DH and AUTH_KERB4

   The AUTH_DH and AUTH_KERB4 styles of security are based on a
   network-wide name. They provide greater security through the use of
   DES encryption and public keys in the case of AUTH_DH, and DES
   encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4
   case. Again, the server and client must agree on the identity of a
   particular name on the network, but the name to identity mapping is
   more operating system independent than the user identifier and group
   identifier mapping in AUTH_SYS. Also, because the authentication
   parameters are encrypted, a malicious user must know another user's
   network password or private key to masquerade as that user.
   Similarly, the server returns a verifier that is also encrypted so
   that masquerading as a server requires knowing a network password.

2.2.3.  RPCSEC_GSS

   The RPCSEC_GSS style of security is based on a security-mechanism-
   specific principal name. GSS-API mechanisms provide security through
   the use of cryptography. The cryptographic protections are used in
   the construction of the credential on calls, and in the verifiers on
   replies. Optionally, cryptographic protections will be in the body of
   the calls and replies.

   Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4,
   and RPCSEC_GSS does not imply that the NFS protocol is limited to
   using those five flavors.










Eisler                      Standards Track                     [Page 5]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


2.3.  Authentication for NFS Procedures

2.3.1.  NULL Procedure

   The NULL procedure is typically used by NFS clients to determine if
   an NFS server is operating and responding to requests (in other
   words, to "ping" the NFS server). Some NFS servers require that a
   client using the NULL procedure:

   *    send the request from TCP or UDP port < 1024.  There does not
        seem to be any value in this because the NULL procedure is of
        very low overhead and certainly no more overhead than the cost
        of processing a NULL procedure and returning an authentication
        error. Moreover, by sending back an authentication error, the
        server has confirmed the information that the client was
        interested in: is the server operating?

   *    be authenticated with a flavor stronger than AUTH_SYS. This is a
        problem 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 are used at the time the NFS client mounts a
   file system from the server.  Some NFS server implementations will
   not require authentication for these NFS procedures.  For NFS
   protocol Version 2, these procedures are GETATTR and STATFS. For
   Version 3, the procedure is FSINFO.

   The reason for not requiring authentication is described as follows.
   When the NFS client mounts a NFS server's file system, the identity
   of the caller on the client is typically an administrative entity (in
   UNIX operating systems, this is usually the "root" user).  It is
   often the case that, for unattended operation in concert with an
   automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS
   credentials for the administrative entity associated with an
   automounter are not available. If so, the NFS client will use
   AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a
   file system.  While an attacker could exploit this implementation
   artifact, the exposure is limited to gaining the attributes of a file



Eisler                      Standards Track                     [Page 6]

RFC 2623       NFS Security, RPCSEC_GSS, and Kerberos V5       June 1999


   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.  In the event a client uses a security flavor
   that is not the 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