rfc2755.txt

RFC 的详细文档！

Network Working Group                                             A. Chiu
Request for Comments: 2755                                      M. Eisler
Category: Informational                                      B. Callaghan
                                                         Sun Microsystems
                                                             January 2000


                    Security Negotiation for WebNFS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   This document describes a protocol for a WebNFS client [RFC2054] to
   negotiate the desired security mechanism with a WebNFS server
   [RFC2055] before the WebNFS client falls back to the MOUNT v3
   protocol [RFC1813].  This document is provided so that people can
   write compatible implementations.

Table of Contents

   1. Introduction ..............................................  2
   2. Security Negotiation Multi-component LOOKUP ...............  3
   3  Overloaded Filehandle .....................................  4
   3.1  Overloaded NFS Version 2 Filehandle .....................  5
   3.2  Overloaded NFS Version 3 Filehandle .....................  6
   4. WebNFS Security Negotiation ...............................  6
   5. Security Considerations ................................... 10
   6. References ................................................ 10
   7. Acknowledgements .......................................... 10
   8. Authors' Addresses ........................................ 11
   9. Full Copyright Statement .................................. 12











Chiu, et al.                 Informational                      [Page 1]

RFC 2755            Security Negotiation for WebNFS         January 2000


1. Introduction

   The MOUNT protocol is used by an NFS client to obtain the necessary
   filehandle for data access.  MOUNT versions 1 and 2 [RFC1094] return
   NFS version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns
   NFS version 3 filehandles.

   Among the existing versions of the MOUNT protocol, only the MOUNT v3
   provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security
   negotiation between an NFS v3 client and an NSF v3 server.  When this
   RPC procedure succeeds (MNT3_OK) the server returns to the client an
   array of security mechanisms it supports for the specified pathname,
   in addition to an NFS v3 filehandle.

   A security mechanism referred to in this document is a generalized
   security flavor which can be an RPC authentication flavor [RFC1831]
   or a security flavor referred to in the RPCSEC_GSS protocol
   [RFC2203]. A security mechanism is represented as a four-octet
   integer.

   No RPC procedures are available for security negotiation in versions
   1 or 2 of the MOUNT protocol.

   The NFS mount command provides a "sec=" option for an NFS client to
   specify the desired security mechanism to use for NFS transactions.
   If this mount option is not specified, the default action is to use
   the default security mechanism over NFS v2 mounts, or to negotiate a
   security mechanism via the MOUNTPROC3_MNT procedure of MOUNT v3 and
   use it over NFS v3 mounts.  In the latter, the client picks the first
   security mechanism in the array returned from the server that is also
   supported on the client.

   As specified in RFC 2054, a WebNFS client first assumes that the
   server supports WebNFS and uses the publsc filehandle as the initial
   filehandle for data access, eliminating the need for the MOUNT
   protocol.  The WebNFS client falls back to MOUNT if the server does
   not support WebNFS.

   Since a WebNFS client does not use MOUNT initially, the
   MOUNTPROC3_MNT procedure of MOUNT v3 is not available for security
   negotiation until the WebNFS client falls back to MOUNT.  A viable
   protocol needs to be devised for the WebNFS client to negotiate
   security mechanisms with the server in the absence of the
   MOUNTPROC3_MNT procedure.







Chiu, et al.                 Informational                      [Page 2]

RFC 2755            Security Negotiation for WebNFS         January 2000


   The WebNFS security negotiation protocol must meet the following
   requirements:

      - Must work seamlessly with NFS v2 and v3, and the WebNFS
         protocols

      - Must be backward compatible with servers that do not support
         this negotiation

      - Minimum number of network turnarounds (latency)

   This document describes the WebNFS security negotiation protocol
   developed by Sun Microsystems, Inc.  Terminology and definitions from
   RFCs 2054 and 2055 are used in this document.  The reader is expected
   to be familiar with them.

2. Security Negotiation Multi-component LOOKUP

   The goal of the WebNFS security negotiation is to allow a WebNFS
   client to identify a security mechanism which is used by the WebNFS
   server to protect a specified path and is also supported by the
   client.  The WebNFS client initiates the negotiation by sending the
   WebNFS server the path. The WebNFS server responds with the array of
   security mechanisms it uses to secure the specified path.  From the
   array of security mechanisms the WebNFS client selects the first one
   that it also supports.

   Without introducing a new WebNFS request, the WebNFS security
   negotiation is achieved by modifying the request and response of the
   existing multi-component LOOKUP (MCL) operation [RFC2055].  Note that
   the MCL operation is accomplished using the LOOKUP procedure
   (NFSPROC3_LOOKUP for NFS v3 and NFSPROC_LOOKUP for NFS v2).  This and
   the next sections describe how the MCL request and response are
   modified to facilitate WebNFS security negotiation.

   For ease of reference, the modified MCL request is henceforth
   referred to as SNEGO-MCL (security negotiation multi-component
   LOOKUP) request.

   A multi-component LOOKUP request [RFC2055] is composed of a public
   filehandle and a multi-component path:

        For Canonical Path:

                LOOKUP FH=0x0, "/a/b/c"






Chiu, et al.                 Informational                      [Page 3]

RFC 2755            Security Negotiation for WebNFS         January 2000


        For Native Path:

                LOOKUP FH=0x0, 0x80 "a:b:c"

   A multi-component path is either an ASCII string of slash separated
   components or a 0x80 character followed by a native path.  Note that
   a multi-component LOOKUP implies the use of the public filehandle in
   the LOOKUP.

   Similar to the MCL request, a SNEGO-MCL request consists of a public
   filehandle and a pathname.  However, the pathname is uniquely
   composed, as described below, to distinguish it from other pathnames.

   The pathname used in a SNEGO-MCL is the regular WebNFS multi-
   component path prefixed with two octets.  The first prefixed octet is
   the 0x81 non-ascii character, similar to the 0x80 non-ascii character
   for the native paths.  This octet represents client's indication to
   negotiate security mechanisms.  It is followed by the security index
   octet which stores the current value of the index into the array of
   security mechanisms to be returned from the server.  The security
   index always starts with one and gets incremented as negotiation
   continues.  It is then followed by the pathname, either an ASCII
   string of slash separated canonical components or 0x80 and a native
   path.

   A security negotiation multi-component LOOKUP request looks like
   this:

        For Canonical Path:

                LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"

        For Native Path:

                LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"

   In the next section we will see how the MCL response is modified for
   WebNFS security negotiation.

3. Overloaded Filehandle

   As described in RFC2054, if a multi-component LOOKUP request
   succeeds, the server responds with a valid filehandle:

        LOOKUP FH=0x0, "a/b/c"
                        ----------->
                        <-----------
                                       FH=0x3



Chiu, et al.                 Informational                      [Page 4]

RFC 2755            Security Negotiation for WebNFS         January 2000


   NFS filehandles are used to uniquely identify a particular file or
   directory on the server and are opaque to the client.  The client
   neither examines a filehandle nor has any knowledge of its contents.
   Thus, filehandles make an ideal repository for the server to return
   the array of security mechanisms to the client in response to a
   SNEGO-MCL request.

   To a successful SNEGO-MCL request the server responds, in place of
   the filehandle, with an array of integers that represents the valid
   security mechanisms the client must use to access the given path. A
   length field is introduced to store the size (in octets) of the array
   of integers.

   As the filehandles are limited in size (32 octets for NFS v2 and up
   to 64 octets for NFS v3), it can happen that there are more security
   mechanisms than the filehandles can accommodate.  To circumvent this
   problem, a one-octet status field is introduced which indicates
   whether there are more security mechanisms (1 means yes, 0 means no)
   that require the client to perform another SNEGO-MCL to get them.

   To summarize, the response to a SNEGO-MCL request contains, in place
   of the filehandle, the length field, the status field, and the array
   of security mechanisms:

        FH: length, status, {sec_1  sec_2 ... sec_n}

   The next two sub-sections describe how NFS v2 and v3 filehandles are
   "overloaded" to carry the length and status fields and the array of
   security mechanisms.

3.1 Overloaded NFS Version 2 Filehandle

   A regular NFS v2 filehandle is defined in RFC1094 as an opaque value
   occupying 32 octets:

     1   2   3   4                                                32
   +---+---+---+---+---+---+---+---+     +---+---+---+---+---+---+---+
   |   |   |   |   |   |   |   |   | ... |   |   |   |   |   |   |   |
   +---+---+---+---+---+---+---+---+     +---+---+---+---+---+---+---+

   An overloaded NFS v2 filehandle looks like this:

     1   2   3   4   5           8                                  32
   +---+---+---+---+---+---+---+---+     +---+---+---+---+     +---+---+
   | l | s |   |   |     sec_1     | ... |     sec_n     | ... |   |   |
   +---+---+---+---+---+---+---+---+     +---+---+---+---+     +---+---+





Chiu, et al.                 Informational                      [Page 5]

RFC 2755            Security Negotiation for WebNFS         January 2000


   Note that the first four octets of an overloaded NFS v2 filehandle
   contain the length octet, the status octet, and two padded octets to
   make them XDR four-octet aligned.  The length octet l = 4 * n, where
   n is the number of security mechanisms sent in the current overloaded
   filehandle.  Apparently, an overloaded NFS v2 filehandle can carry up
   to seven security mechanisms.

3.2 Overloaded NFS Version 3 Filehandle

   A regular NFS v3 filehandle is defined in RFC1813 as a variable
   length opaque value occupying up to 64 octets.  The length of the
   filehandle is indicated by an integer value contained in a four octet
   value which describes the number of valid octets that follow:

  1           4
+---+---+---+---+
|      len      |
+---+---+---+---+

  1           4                                              up to 64
+---+---+---+---+---+---+---+---+---+---+---+---+     +---+---+---+---+
|   |   |   |   |   |   |   |   |   |   |   |   | ... |   |   |   |   |
+---+---+---+---+---+---+---+---+---+---+---+---+     +---+---+---+---+

An overloaded NFS v3 filehandle looks like the following:

  1           4
+---+---+---+---+
|      len      |
+---+---+---+---+

  1           4   5           8
+---+---+---+---+---+---+---+---+     +---+---+---+---+
| s |   |   |   |     sec_1     | ... |     sec_n     |
+---+---+---+---+---+---+---+---+     +---+---+---+---+

   Here, len = 4 * (n+1).  Again, n is the number of security mechanisms
   contained in the current overloaded filehandle.  Three octets are
   padded after the status octet to meet the XDR four-octet alignment
   requirement.  An overloaded NFS v3 filehandle can carry up to fifteen
   security mechanisms.

4. WebNFS Security Negotiation

   With the SNEGO-MCL request and the overloaded NFS v2 and v3
   filehandles defined above, the following diagram depicts the WebNFS
   security negotiation protocol:




Chiu, et al.                 Informational                      [Page 6]