rfc2222.txt

<VC++网络游戏建摸与实现>源代码

   S/Key authentication does not provide for any security layers.

   EXAMPLE: The following are two S/Key login scenarios in the IMAP4
   protocol.

     S: * OK IMAP4 Server
     C: A001 AUTHENTICATE SKEY
     S: +
     C: bW9yZ2Fu
     S: + OTUgUWE1ODMwOA==
     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
     S: A001 OK S/Key authentication successful





Myers                       Standards Track                    [Page 11]

RFC 2222                          SASL                      October 1997


     S: * OK IMAP4 Server
     C: A001 AUTHENTICATE SKEY
     S: +
     C: c21pdGg=
     S: + OTUgUWE1ODMwOA==
     C: BsAY3g4gBNo=
     S: A001 NO S/Key authentication failed

   The following is an S/Key login scenario in an IMAP4-like protocol
   which has an optional "initial response" argument to the AUTHENTICATE
   command.

     S: * OK IMAP4-Like Server
     C: A001 AUTHENTICATE SKEY bW9yZ2Fu
     S: + OTUgUWE1ODMwOA==
     C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
     S: A001 OK S/Key authentication successful

7.4.  External mechanism

   The mechanism name associated with external authentication is
   "EXTERNAL".

   The client sends an initial response with the authorization identity.

   The server uses information, external to SASL, to determine whether
   the client is authorized to authenticate as the authorization
   identity.  If the client is so authorized, the server indicates
   successful completion of the authentication exchange; otherwise the
   server indicates failure.

   The system providing this external information may be, for example,
   IPsec or TLS.

   If the client sends the empty string as the authorization identity
   (thus requesting the authorization identity be derived from the
   client's authentication credentials), the authorization identity is
   to be derived from authentication credentials which exist in the
   system which is providing the external authentication.












Myers                       Standards Track                    [Page 12]

RFC 2222                          SASL                      October 1997


8.    References

   [RFC 2060] Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 2060, December 1996.

   [RFC 2078] Linn, J., "Generic Security Service Application Program
              Interface, Version 2", RFC 2078, January 1997.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC
              Authors", RFC 2223, October 1997.

   [RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC
              1760, February 1995.

   [RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
              RFC 1700, October 1994.

9.    Security Considerations

   Security issues are discussed throughout this memo.

   The mechanisms that support integrity protection are designed such
   that the negotiation of the security layer and authorization identity
   is integrity protected.  When the client selects a security layer
   with at least integrity protection, this protects against an active
   attacker hijacking the connection and modifying the authentication
   exchange to negotiate a plaintext connection.

   When a server or client supports multiple authentication mechanisms,
   each of which has a different security strength, it is possible for
   an active attacker to cause a party to use the least secure mechanism
   supported.  To protect against this sort of attack, a client or
   server which supports mechanisms of different strengths should have a
   configurable minimum strength that it will use.  It is not sufficient
   for this minimum strength check to only be on the server, since an
   active attacker can change which mechanisms the client sees as being
   supported, causing the client to send authentication credentials for
   its weakest supported mechanism.










Myers                       Standards Track                    [Page 13]

RFC 2222                          SASL                      October 1997


   The client's selection of a SASL mechanism is done in the clear and
   may be modified by an active attacker.  It is important for any new
   SASL mechanisms to be designed such that an active attacker cannot
   obtain an authentication with weaker security properties by modifying
   the SASL mechanism name and/or the challenges and responses.

   Any protocol interactions prior to authentication are performed in
   the clear and may be modified by an active attacker.  In the case
   where a client selects integrity protection, it is important that any
   security-sensitive protocol negotiations be performed after
   authentication is complete.  Protocols should be designed such that
   negotiations performed prior to authentication should be either
   ignored or revalidated once authentication is complete.

10.   Author's Address

   John G. Myers
   Netscape Communications
   501 E. Middlefield Road
   Mail Stop MV-029
   Mountain View, CA 94043-4042

   EMail: [e-mail]




























Myers                       Standards Track                    [Page 14]

RFC 2222                          SASL                      October 1997


Appendix A. Relation of SASL to Transport Security

   Questions have been raised about the relationship between SASL and
   various services (such as IPsec and TLS) which provide a secured
   connection.

   Two of the key features of SASL are:

   1. The separation of the authorization identity from the identity in
      the client's credentials.  This permits agents such as proxy
      servers to authenticate using their own credentials, yet request
      the access privileges of the identity for which they are proxying.

   2. Upon successful completion of an authentication exchange, the
      server knows the authorization identity the client wishes to use.
      This allows servers to move to a "user is authenticated" state in
      the protocol.

   These features are extremely important to some application protocols,
   yet Transport Security services do not always provide them.  To
   define SASL mechanisms based on these services would be a very messy
   task, as the framing of these services would be redundant with the
   framing of SASL and some method of providing these important SASL
   features would have to be devised.

   Sometimes it is desired to enable within an existing connection the
   use of a security service which does not fit the SASL model.  (TLS is
   an example of such a service.)  This can be done by adding a command,
   for example "STARTTLS", to the protocol.  Such a command is outside
   the scope of SASL, and should be different from the command which
   starts a SASL authentication protocol exchange.

   In certain situations, it is reasonable to use SASL underneath one of
   these Transport Security services.  The transport service would
   secure the connection, either service would authenticate the client,
   and SASL would negotiate the authorization identity.  The SASL
   negotiation would be what moves the protocol from "unauthenticated"
   to "authenticated" state.  The "EXTERNAL" SASL mechanism is
   explicitly intended to handle the case where the transport service
   secures the connection and authenticates the client and SASL
   negotiates the authorization identity.

   When using SASL underneath a sufficiently strong Transport Security
   service, a SASL security layer would most likely be redundant.  The
   client and server would thus probably want to negotiate off the use
   of a SASL security layer.





Myers                       Standards Track                    [Page 15]

RFC 2222                          SASL                      October 1997


Full Copyright Statement

   Copyright (C) The Internet Society (1997).  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
   andand 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.
























Myers                       Standards Track                    [Page 16]