Subject: proposed revised AUTHENTICATE command section

From: "Paul B. Hill" <[email-masked]>
Date: Wed, 08 Mar 2000 15:36:33 -0500

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=[email-masked]
    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: .