proposed revised AUTHENTICATE command section

["Paul B. Hill" <pbh@xxxxxxx>]

Hi,

I'd like to revise the AUTHENTICATE command to the version that I have 
included below. This version eliminates the earlier text that seemed to be 
a splice of two different sentences that talked about Digest-MD5, DES, and 
3DES. It also eliminates other SASL mechanism specific text that did not 
belong in this section.

-------------------------

7.1.3.	AUTHENTICATE Command
   Arguments:  <SASL mechanism name> [<initial data>]
   Data:       continuation data may be requested
   Result:

	    2.0	-   Authenticate completed, now	in  authenticated
		    state.
	    6.0	-   Failed authentication.
	    6.1	-   Authorization identity refused.
	    6.2	-   Sender aborted authentication, authentication
		    exchange cancelled.
	    6.3	-   Unsupported	Authentication Mechanism.
	    6.x	-   Temporary failure  (back  end  authentication
		    server down).
	    6.x	-   Authentication exchange cancelled.
	    6.x	-   Authentication mechanism too weak.
	    6.x	-   Encryption required.
	    6.x	-   Pass  phrase  expired.   The  pass phrase was
		    correct but	expired.  The user will	 have  to
		    contact  a pass phrase change server prior to
		    authenticating.
	    6.x	-   The	user is	valid but  the	server	does  not
		    have  an entry in the authentication database
		    for	the requested  mechanism  (e.g.,  DIGEST-
		    MD5).  If the user successfully authenticates
		    using a plain text password,  then	the  back
		    end	 back  end  entry  will	be updated.  Note
		    that if the	client chooses to  fall	 back  to
		    plain  text	password authentication	it should
		    enable an encryption layer or  get	user-con-
		    firmation  that  a one-time	transition is ac-
		    ceptable.
	    6.x	-   User account disabled. The user will have  to
		    contact  the  system administrator to get the
		    account re-enabled.
	    9.1	-   Unexpected command.

   The capabilities of the CS in the authenticated state are reported in
   the response from the CS. These may be different than the capabilities
   in the Connected, but unauthenticated state.

   The AUTHENTICATE command is used by the CUA to identify the user to the
   CS. CAP supports a number of authentication methods, the [SASL] 
specification
   for authentication is the preferred method.

   If STARTTLS is negotiated prior to the AUTHENTICATE command, the client 
MUST
   discard all information about the CS capabilities fetched prior to the TLS
   negotiation.  In particular, the value of supported SASL Mechanisms MAY 
be different
   after TLS has been negotiated.

   If a SASL security layer is negotiated, the client MUST discard all
   information about the CS capabilities fetched prior to SASL.  In 
particular, if
   the client is configured to support multiple SASL mechanisms, it SHOULD
   fetch supported SASL Mechanisms both before and after the SASL security
   layer is negotiated and verify that the value has not changed after the
   SASL security layer was negotiated.  This detects active attacks which
   remove supported SASL mechanisms from the supported SASL Mechanisms list.

   <initial data> is an optional parameter which can be used for mechanisms
   which require an initial response from the CUA.

   The AUTHENTICATE command is followed by an authentication protocol
   exchange, in the form of a series of CS challenges and CUA responses, per
   the relevant RFC that describes the specific SASL mechanism being used.

   Cancelling the authentication process during its negotiation is 
implementation
   specific and not within scope of the CAP specification.

   If a security layer was negotiated it comes into effect for the CS
   starting with the first octet transmitted after the CRLF which follows
   the 2.0 reply code, and for the CUA starting with the first octet after
   the CRLF of its last response in the authentication exchange. Encrypted
   data is transmitted as described in [SASL].

   The service name specified by this protocol's profile of SASL is "cap".
   [Note: this must be registered with IANA, has anyone done this yet?]

   The result of the AUTHENTICATE command includes data indicating the
   identity which has been assigned to the session, derived from the
   supplied authentication credentials, and/or authorization identifier.
   A CAP session does not have an identity until the CUA has issued the
   "AUTHENTICATE" command.

   The CUA may not issue the "AUTHENTICATE" command multiple times, even if
   the first attempt was aborted. If a CUA attempts to do this the CS must
   terminate the session.

   Data returned in response to a successful login is:

   The following examples illustrate the various possibilities for an
   authentication protocol exchange.

   Here are examples of a successful authentication:

   C: AUTHENTICATE KERBEROS_V4
   S: AmFYig==
   C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
   S: or//EoAADZI=
   C: DiAF5A4gA+oOIALuBkAAmw==
   S: 2.0
   S: .
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit

   S:
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/CAPserver//EN
   S: VERSION:2.1
   S: IDENTITY=bill@xxxxxxxxxxx
   S: CAPVERSION=1.0
   S: ITIPVERSION=1.0
   S: AUTH=KERBEROS_V4
   S: AUTH=DIGEST_MD5
   S: CAR=CAR-FULL-1
   S: MINDATE=19700101T000000Z
   S: MAXDATE=20370201T000000Z
   S: END:VCALENDAR
   S: .

   This example shows a failed authentication:

   C: AUTHENTICATE KERBEROS_V4
   S: AmFYig==
   C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
   S: .
   S: 6.0
   S: .
   S: .