rfc2755.txt

RFC 的详细文档！


RFC 2755            Security Negotiation for WebNFS         January 2000


    Client                                      Server
    ------                                      ------

        LOOKUP FH=0x0, 0x81 <sec-index> "path"
                        ----------->
                        <-----------
                            FH: length, status, {sec_1  sec_2 ... sec_n}

   where
      0x81 represents client's indication to negotiate security
      mechanisms with the server,

      path is either an ASCII string of slash separated components or
      0x80 and a native path,

      sec-index, one octet, contains the index into the array of
      security mechanisms the server uses to protect the specified path,

      status, one octet, 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,

      length (one octet for NFS v2 and four octets for NFS v3) describes
      the number of valid octets that follow,

      {sec_1 sec_2 ... sec_n} represents the array of security
      mechanisms.  As noted earlier, each security mechanism is
      represented by a four-octet integer.

   Here is an example showing the WebNFS security negotiation protocol
   with NFS v2.  In the example it is assumed the server shares /export
   with 10 security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the
   export, two SNEGO-MCL requests would be needed for the client to get
   the complete security information:

    LOOKUP FH=0x0, 0x81 0x01 "/export"
                        ----------->
                        <-----------
        0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}

    LOOKUP FH=0x0, 0x81 0x08 "/export"
                        ----------->
                        <-----------
        0x0c, 0x00, {0x3907 0x3908 0x3909}







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


   The order of the security mechanisms returned in an overloaded
   filehandle implies preferences, i.e., one is more recommended than
   those following it.  The ordering is the same as that returned by the
   MOUNT v3 protocol.

   The following shows a typical scenario which illustrates how the
   WebNFS security negotiation is accomplished in the course of
   accessing publicly shared filesystems.

   Normally, a WebNFS client first makes a regular multi-component
   LOOKUP request using the public filehandle to obtain the filehandle
   for the specified path.  Since the WebNFS client does not have any
   prior knowledge as to how the path is protected by the server the
   default security mechanism is used in this first multi-component
   LOOKUP.  If the default security mechanism does not meet server's
   requirements, the server replies with the AUTH_TOOWEAK RPC
   authentication error, indicating that the default security mechanism
   is not valid and the WebNFS client needs to use a stronger one.

   Upon receiving the AUTH_TOOWEAK error, to find out what security
   mechanisms are required to access the specified path the WebNFS
   client sends a SNEGO-qMCL request, using the default security
   mechanism.

   If the SNEGO-MCL request succeeds the server responds with the
   filehandle overloaded with the array of security mechanisms required
   for the specified path.  If the server does not support WebNFS
   security negotiation, the SNEGO-MCL request fails with NFSERR_IO for
   NFS v2 or NFS3ERR_IO for NFS v3 [RFC2055].

   Depending on the size of the array of security mechanisms, the WebNFS
   client may have to make more SNEGO-MCL requests to get the complete
   array.

   For successful SNEGO-MCL requests, the WebNFS client retrieves the
   array of security mechanisms from the overloaded filehandle, selects
   an appropriate one, and issues a regular multi-component LOOKUP using
   the selected security mechanism to acquire the filehandle.

   All subsequent NFS requests are then made using the selected security
   mechanism and the filehandle.

   The following depicts the scenario outlined above.  It is assumed
   that the server shares /export/home as follows:

        share -o sec=sec_1:sec_2:sec_3,public /export/home





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


   and AUTH_SYS is the client's default security mechanism and is not
   one of {sec_1, sec_2, sec_3}.

        Client                                          Server
        ------                                          ------

            LOOKUP FH=0x0, "/export/home"
                                     AUTH_SYS
                                    ----------->
                                    <-----------
                                                        AUTH_TOOWEAK

            LOOKUP FH=0x0, 0x81 0x01 "/export/home"
                                     AUTH_SYS
                                    ----------->
                                    <-----------
                     overloaded FH: length, status, {sec_1 sec_2 sec_3}

            LOOKUP FH=0x0, "/export/home"
                                        sec_n
                                    ----------->
                                    <-----------
                                                        FH = 0x01

            NFS request with FH=0x01
                                        sec_n
                                    ----------->
                                    <-----------
                                                        ...

   In the above scenario, the first request is a regular multi-component
   LOOKUP which fails with the AUTH_TOOWEAK error.  The client then
   issues a SNEGO-MCL request to get the security information.

   There are WebNFS implementations that allow the public filehandle to
   work with NFS protocol procedures other than LOOKUP.  For those
   WebNFS implementations, if the first request is not a regular multi-
   component LOOKUP and it fails with AUTH_TOOWEAK, the client should
   issue a SNEGO-MCL with

        0x81 0x01 "."

   as the path to get the security information.








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


5. Security Considerations

   The reader may note that no mandatory security mechanisms are
   specified in the protocol that the client must use in making SNEGO-
   MCL requests.  Normally, the client uses the default security
   mechanism configured on his system in the first SNEGO-MCL request.
   If the default security mechanism is not valid the server replies
   with the AUTH_TOOWEAK error. In this case the server does not return
   the array of security mechanisms to the client.  The client can then
   make another SNEGO-MCL request using a stronger security mechanism.
   This continues until the client hits a valid one or has exhausted all
   the supported security mechanisms.

6. References

   [RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol
             Specification", RFC 1094, March 1989.
             http://www.ietf.org/rfc/rfc1094.txt

   [RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version
             3 Protocol Specification", RFC 1813, June 1995.
             http://www.ietf.org/rfc/rfc1813.txt

   [RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054,
             October 1996.  http://www.ietf.org/rfc/rfc2054.txt

   [RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055,
             October 1996.  http://www.ietf.org/rfc/rfc2055.txt

   [RFC2203] Eisler, M., Chiu, A. and Ling, L., "RPCSEC_GSS Protocol
             Specification", RFC 2203, September 1997.
             http://www.ietf.org/rfc/rfc2203.txt

7. Acknowledgements

   This specification was extensively brainstormed and reviewed by the
   NFS group of Solaris Software Division.














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


8. Authors' Addresses

   Alex Chiu
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: [phone]
   EMail: [e-mail]


   Mike Eisler
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: [phone]
   EMail: [e-mail]


   Brent Callaghan
   Sun Microsystems, Inc.
   901 San Antonio Road
   Palo Alto, CA 94303

   Phone: [phone]
   EMail: [e-mail]
























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


9. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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 implementation 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
   developing 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.



















Chiu, et al.                 Informational                     [Page 12]