rfc2222.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           J. Myers
Request for Comments: 2222                       Netscape Communications
Category: Standards Track                                   October 1997


            Simple Authentication and Security Layer (SASL)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Table of Contents

   1.    Abstract ..............................................    2
   2.    Organization of this Document .........................    2
   2.1.  How to Read This Document .............................    2
   2.2.  Conventions Used in this Document .....................    2
   2.3.  Examples ..............................................    3
   3.    Introduction and Overview .............................    3
   4.    Profiling requirements ................................    4
   5.    Specific issues .......................................    5
   5.1.  Client sends data first ...............................    5
   5.2.  Server returns success with additional data ...........    5
   5.3.  Multiple authentications ..............................    5
   6.    Registration procedures ...............................    6
   6.1.  Comments on SASL mechanism registrations ..............    6
   6.2.  Location of Registered SASL Mechanism List ............    6
   6.3.  Change Control ........................................    7
   6.4.  Registration Template .................................    7
   7.    Mechanism definitions .................................    8
   7.1.  Kerberos version 4 mechanism ..........................    8
   7.2.  GSSAPI mechanism ......................................    9
   7.2.1 Client side of authentication protocol exchange .......    9
   7.2.2 Server side of authentication protocol exchange .......   10
   7.2.3 Security layer ........................................   11
   7.3.  S/Key mechanism .......................................   11
   7.4.  External mechanism ....................................   12
   8.    References ............................................   13
   9.    Security Considerations ...............................   13
   10.   Author's Address ......................................   14



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


   Appendix A. Relation of SASL to Transport Security ..........   15
   Full Copyright Statement ....................................   16

1.    Abstract

   This document describes a method for adding authentication support to
   connection-based protocols.  To use this specification, a protocol
   includes a command for identifying and authenticating a user to a
   server and for optionally negotiating protection of subsequent
   protocol interactions.  If its use is negotiated, a security layer is
   inserted between the protocol and the connection.  This document
   describes how a protocol specifies such a command, defines several
   mechanisms for use by the command, and defines the protocol used for
   carrying a negotiated security layer over the connection.

2.    Organization of this Document

2.1.  How to Read This Document

   This document is written to serve two different audiences, protocol
   designers using this specification to support authentication in their
   protocol, and implementors of clients or servers for those protocols
   using this specification.

   The sections "Introduction and Overview", "Profiling requirements",
   and "Security Considerations" cover issues that protocol designers
   need to understand and address in profiling this specification for
   use in a specific protocol.

   Implementors of a protocol using this specification need the
   protocol-specific profiling information in addition to the
   information in this document.

2.2.  Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in "Key words for
   use in RFCs to Indicate Requirement Levels" [RFC 2119].










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


2.3.  Examples

   Examples in this document are for the IMAP profile [RFC 2060] of this
   specification.  The base64 encoding of challenges and responses, as
   well as the "+ " preceding the responses are part of the IMAP4
   profile, not part of the SASL specification itself.

3.    Introduction and Overview

   The Simple Authentication and Security Layer (SASL) is a method for
   adding authentication support to connection-based protocols.  To use
   this specification, a protocol includes a command for identifying and
   authenticating a user to a server and for optionally negotiating a
   security layer for subsequent protocol interactions.

   The command has a required argument identifying a SASL mechanism.
   SASL mechanisms are named by strings, from 1 to 20 characters in
   length, consisting of upper-case letters, digits, hyphens, and/or
   underscores.  SASL mechanism names must be registered with the IANA.
   Procedures for registering new SASL mechanisms are given in the
   section "Registration procedures"

   If a server supports the requested mechanism, it initiates an
   authentication protocol exchange.  This consists of a series of
   server challenges and client responses that are specific to the
   requested mechanism.  The challenges and responses are defined by the
   mechanisms as binary tokens of arbitrary length.  The protocol's
   profile then specifies how these binary tokens are then encoded for
   transfer over the connection.

   After receiving the authentication command or any client response, a
   server may issue a challenge, indicate failure, or indicate
   completion.  The protocol's profile specifies how the server
   indicates which of the above it is doing.

   After receiving a challenge, a client may issue a response or abort
   the exchange.  The protocol's profile specifies how the client
   indicates which of the above it is doing.

   During the authentication protocol exchange, the mechanism performs
   authentication, transmits an authorization identity (frequently known
   as a userid) from the client to server, and negotiates the use of a
   mechanism-specific security layer.  If the use of a security layer is
   agreed upon, then the mechanism must also define or negotiate the
   maximum cipher-text buffer size that each side is able to receive.






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


   The transmitted authorization identity may be different than the
   identity in the client's authentication 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.  With any mechanism, transmitting an
   authorization identity of the empty string directs the server to
   derive an authorization identity from the client's authentication
   credentials.

   If use of a security layer is negotiated, it is applied to all
   subsequent data sent over the connection.  The security layer takes
   effect immediately following the last response of the authentication
   exchange for data sent by the client and the completion indication
   for data sent by the server.  Once the security layer is in effect,
   the protocol stream is processed by the security layer into buffers
   of cipher-text.  Each buffer is transferred over the connection as a
   stream of octets prepended with a four octet field in network byte
   order that represents the length of the following buffer.  The length
   of the cipher-text buffer must be no larger than the maximum size
   that was defined or negotiated by the other side.

4.    Profiling requirements

   In order to use this specification, a protocol definition must supply
   the following information:

   1. A service name, to be selected from the IANA registry of "service"
      elements for the GSSAPI host-based service name form [RFC 2078].

   2. A definition of the command to initiate the authentication
      protocol exchange.  This command must have as a parameter the
      mechanism name being selected by the client.

      The command SHOULD have an optional parameter giving an initial
      response.  This optional parameter allows the client to avoid a
      round trip when using a mechanism which is defined to have the
      client send data first.  When this initial response is sent by the
      client and the selected mechanism is defined to have the server
      start with an initial challenge, the command fails.  See section
      5.1 of this document for further information.

   3. A definition of the method by which the authentication protocol
      exchange is carried out, including how the challenges and
      responses are encoded, how the server indicates completion or
      failure of the exchange, how the client aborts an exchange, and
      how the exchange method interacts with any line length limits in
      the protocol.




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


   4. Identification of the octet where any negotiated security layer
      starts to take effect, in both directions.

   5. A specification of how the authorization identity passed from the
      client to the server is to be interpreted.

5.    Specific issues

5.1.  Client sends data first

   Some mechanisms specify that the first data sent in the
   authentication protocol exchange is from the client to the server.

   If a protocol's profile permits the command which initiates an
   authentication protocol exchange to contain an initial client
   response, this parameter SHOULD be used with such mechanisms.

   If the initial client response parameter is not given, or if a
   protocol's profile does not permit the command which initiates an
   authentication protocol exchange to contain an initial client
   response, then the server issues a challenge with no data.  The
   client's response to this challenge is then used as the initial
   client response.  (The server then proceeds to send the next
   challenge, indicates completion, or indicates failure.)

5.2.  Server returns success with additional data

   Some mechanisms may specify that server challenge data be sent to the
   client along with an indication of successful completion of the
   exchange.  This data would, for example, authenticate the server to
   the client.

   If a protocol's profile does not permit this server challenge to be
   returned with a success indication, then the server issues the server
   challenge without an indication of successful completion.  The client
   then responds with no data.  After receiving this empty response, the
   server then indicates successful completion.

5.3.  Multiple authentications

   Unless otherwise stated by the protocol's profile, only one
   successful SASL negotiation may occur in a protocol session.  In this
   case, once an authentication protocol exchange has successfully
   completed, further attempts to initiate an authentication protocol
   exchange fail.






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


   In the case that a profile explicitly permits multiple successful
   SASL negotiations to occur, then in no case may multiple security
   layers be simultaneously in effect.  If a security layer is in effect
   and a subsequent SASL negotiation selects no security layer, the
   original security layer remains in effect.  If a security layer is in
   effect and a subsequent SASL negotiation selects a second security
   layer, then the second security layer replaces the first.

6.    Registration procedures

   Registration of a SASL mechanism is done by filling in the template
   in section 6.4 and sending it in to [e-mail].  IANA has the right
   to reject obviously bogus registrations, but will perform no review
   of clams made in the registration form.