SASL (was RE: ietf-nntp RFC977bis w.r.t. authentication)

[Chris Newman]

The SASL spec includes text which specificly says exactly what we have to
do to use it in NNTP.  I'm including the key part of RFC 2222 here so
everyone can read it.  Section 4 below lists the five things a SASL
profile has to specify. 

-----
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.

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.
 
   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.
 
   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.
-----

The above mentioned GSSAPI service registry is:

  <http://www.isi.edu/in-notes/iana/assignments/gssapi-service-names>

Currently registered SASL mechanisms are:

  <http://www.isi.edu/in-notes/iana/assignments/sasl-mechanisms>

There are about 6 more SASL mechanisms proposed in Internet drafts, plus
Microsoft has 3 proprietary ones which they haven't bothered to register
yet (I'm unsure why -- a spec is not required to register one).

		- Chris