rfc2623.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,068 行 · 第 1/3 页

        other than the one the client intended. Typically the user that
        is the result of this mapping is a user with limited access on
        the system, such as user "nobody" on UNIX systems.

   If a client uses AUTH_NONE, the server's options are the same as the
   above, except that AUTH_NONE carries with it no user identity. In
   order to allow the request, on many operating systems the server will
   assign a user identity. Typically this assignment will be 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
   above passage also apply to Version 2.





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


2.6.  Host-based Access Control

   In some NFS server implementations, a host-based access control
   method is used whereby 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 will check access
   only at mount time, during the request for the file handle via the
   MOUNT protocol handshake.  The lack of authorization checking during
   subsequent NFS requests has the following 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 circumvent the MOUNT server's access control to
        gain access to a file system that the attacker is not authorized
        for. The circumvention is accomplished by either stealing a file
        handle (usually by snooping the network traffic between an
        legitimate client and server) or guessing a file handle.  For
        this attack to succeed, the attacker must still be able
        impersonate a user's credentials, which is simple for AUTH_SYS,
        but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.

   *    WebNFS clients that use the public file handle lookup [RFC2054]
        will not go through the MOUNT protocol to acquire initial file
        handle of the NFS file system. Enforcing access control via the
        MOUNT protocol is going to be a little use. Granted, 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.

2.7.  Security Flavor Negotiation

   Any application protocol that supports multiple styles of security
   will have the issue of negotiating the security method to be used.
   NFS Version 2 had no support for security flavor negotiation.  It was
   up to the client to guess, or depend on prior knowledge.  Often the
   prior knowledge would be available in the form of security options
   specified in a directory service used for the purpose of
   automounting.

   The MOUNT Version 3 protocol, associated with NFS Version 3, solves
   the problem by having the response to the MNT procedure include a
   list of flavors in the MNT procedure. Note that because some NFS
   servers will export file systems to specific lists of clients, with
   different access (read-only versus read-write), and with different



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


   security flavors, it is possible a client might get back multiple
   security flavors in the list returned in the MNT response. The use of
   one flavor instead of another might imply read-only instead of read-
   write access, or perhaps some other degradation of access. For this
   reason, a 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 support the ability to 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 one develops a new RPC security flavor, [e-mail] MUST be
   contacted to get a unique flavor assignment. To simplify NFS client
   and server administration, having a simple ASCII string name for the
   flavor is useful. Currently, the following 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 [e-mail].

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 are of the form:

        service@hostname

   For NFS, the "service" element is

        nfs

3.2.  Negotiation

   RPCSEC_GSS is a single security flavor over which different security
   mechanisms can be multiplexed. Within a mechanism, GSS-API provides
   for the support of multiple quality of protections (QOPs), which are
   pairs of cryptographic algorithms. Each algorithm in the QOP consists



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


   of an encryption algorithm for privacy and a checksum algorithm for
   integrity.  RPCSEC_GSS lets one protect the RPC request/response pair
   with plain header authentication, message integrity, and message
   privacy.  Thus 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 many styles of security, just adding
   RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT
   response is not going to be of much use to the NFS client.

   The solution is the creation of a concept called "pseudo flavors."
   Pseudo flavors are 32 bit integers that are 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 will map to a specific triple of security mechanism,
   quality of protection, and service. The service will be one of
   authentication, integrity, and privacy. Note that integrity includes
   authentication, and privacy includes integrity. RPCSEC_GSS uses
   constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and
   rpc_gss_svc_privacy, for authentication, integrity, and privacy
   respectively.

   Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will
   instead return one or more pseudo flavors if the NFS server supports
   RPCSEC_GSS and if 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

   Once an RPCSEC_GSS session or context has been set up (via 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 duration of the session.  While RPCSEC_GSS allows for
   the use of different QOPs and services on each message, it would be
   expensive for the NFS server to re-consult its table of exported file
   systems to see if the triple was allowed. Moreover, by the time the
   NFS server's dispatch routine was reached, the typical RPC subsystem
   would already have performed the appropriate GSS-API operation,
   GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or
   privacy services were selected. If the file system being accessed
   were not exported with integrity or privacy, or with the particular
   QOP used to perform the integrity or privacy service, then it would
   be possible to execute a denial of service attack, whereby the
   objective of the caller is to deny CPU service to legitimate users of
   the NFS server's machine processors.



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


   Thus, in general, clients SHOULD NOT assume that they will be
   permitted 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 same method as regular
   RPC security flavor numbers via [e-mail].

   Once the pseudo flavor number has been assigned, registrants SHOULD
   register the mapping with [e-mail]. 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 why the second
        component of the triple is not necessarily a QOP value is that
        GSS-API allows mechanisms much latitude in the mapping of 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 using 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].




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


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 operation of NFS clients and servers 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 the concept of a default QOP of zero which means
   different integrity and privacy algorithms to 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 to 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 integrity algorithm encoded in the token.  For such
   implementations, it means that 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.





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


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