rfc2623.txt

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

      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.





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


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 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 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 that the considerations
   for RPC security flavors, as both are assigned from the same number
   space.  IANA is already responsible for the assigned 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.



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


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, and 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, 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 with the RPC flavor name space. The
   guidelines for delegation of the flavor name space are thus
   equivalent to guidelines for delegations 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



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


   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

   There are only three security services and they are enumerated and
   described in [RFC2203]. No guideline to IANA is necessary.

References

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

   [Sandberg]
             Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
             B. (1985). "Design and Implementation of the Sun Network
             Filesystem,"  Proceedings of the 1985 Summer USENIX
             Technical Conference.

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

   [RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
             Specification Version 2", RFC 1831, August 1995.
             http://www.ietf.org/rfc/rfc1831.txt

   [RFC1832] Srinivasan, R., "XDR: External Data Representation
             Standard", RFC 1832, August 1995.
             http://www.ietf.org/rfc/rfc1832.txt

   [Pawlowski]
             Pawlowski, B., Juszczak, C., Staubach, P., Smith, C.,
             Lebel, D. and D. Hitz, "NFS Version 3 Design and
             Implementation", Proceedings of the USENIX Summer 1994
             Technical Conference.

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

   [RFC2078] Linn, J., "Generic Security Service Application
             Program Interface, Version 2", RFC 2078, January 1997.
             http://www.ietf.org/rfc/rfc2078.txt




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


   [RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call
             Protocol Specification Version 2", RFC 1057, June 1988.
             This RFC is being referenced for its description of the
             AUTH_DH (AUTH_DES) RPC security flavor.
             http://www.ietf.org/rfc/rfc1057.txt

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
             http://www.ietf.org/rfc/rfc2119.txt

   [Callaghan]
             Callaghan, B., Singh, S. (1993). "The Autofs Automounter,"
             Proceedings of the 1993 Summer USENIX Technical Conference.

   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
             Mechanism", RFC 1964, June 1996.
             http://www.ietf.org/rfc/rfc1964.txt

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

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
             an IANA Considerations Section in RFCs", BCP 26, RFC
             2434, October 1998.
             http://www.ietf.org/rfc/rfc2434.txt

   [MIT]     Massachusetts Institute of Technology (1998). "Kerberos:
             The Network Authentication Protocol." The Web site for
             downloading MIT's implementation of Kerberos V5, including
             implementations of RFC 1510 and RFC 1964.
             http://web.mit.edu/kerberos/www/index.html

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.









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


Author's Address

   Address comments related to this memorandum to:

   [e-mail]

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

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






































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


14.  Full Copyright Statement

   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.




















Eisler                      Standards Track                    [Page 19]