Subject: CAP: AUTHENTICATE replies

From: Doug Royer <[email-masked]>
Date: Fri, 18 Aug 2000 20:05:26 -0700

What is the difference between:

  6.0 - Failed authentication.
  6.1 - Authorization identity refused.

---

What is the difference between:

6.2 - Sender aborted authentication, authentication exchange canceled.
6.5 - Authentication exchange canceled.

---

6.7 - Encryption required.

Could this be: "MUST use TLSSTART first" ?

---

6.9 - 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-confirmation that a one-time transition
      is acceptable.

What?
So if authentication fails, then is this supposed
to mean that only PLAIN-TEXT password is supported for
this user? If so, then ONLY if TLSSTART has been issued?
Then the CUA is supposed to retry using plain text?
How is a CS supposed to know to update any kind
of authentication information. The CS might not
be the authentication authority.

---

---

From: John Stracke <[email-masked]>
Date: Mon, 21 Aug 2000 11:03:47 -0400

Doug Royer wrote:

> this user?

I think it just means that the specified mechanism is not configured.  The
CUA could try other mechanisms before falling back to PLAIN-TEXT.

> If so, then ONLY if TLSSTART has been issued?

Not necessarily.  A good CUA would issue TLSSTART and fall back to
PLAIN-TEXT; a lazy one would fall back to PLAIN-TEXT and issue TLSSTART only
if it got a 6.7.

> be the authentication authority.

That is a good point.  I would suggest the text should be changed to say
that updating the backend is recommended where possible, but not required.
(It can't *really* be required by the protocol anyway, since the CUA can't
assume that the updated authentication information will still be there the
next time it comes along.) Another reasonable CS behavior might be to send
email to the admin saying that the user's DIGEST-MD5 (or whatever)
authentication info needs to be entered.  (Then again, that could be a
security risk if someone else can read that email.)

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"How quietly do you think we can nail these back|
[email-masked]|in?" --Calvin                                   |
\=================================================================/

---

From: "Paul B. Hill" <[email-masked]>
Date: Mon, 21 Aug 2000 11:11:53 -0400

>   6.1 - Authorization identity refused.

Authentication - who you are
Authorization - what you can do

I may be able to authenticate as Doug, but the server might not allow me to 
then assert an authorization identity of Frank. How the authorization 
identity is supported and enforced is implementation specific.

>6.5 - Authentication exchange canceled.

I assume that 6.2 indicates the client initiation the cancellation and 6.5 
indicates that the server initiated the cancellation. 6.5 would also 
indicate that the client and server cannot agree on mutually acceptable 
authentication mechanism.

>Could this be: "MUST use TLSSTART first" ?

No. Suppose you are using the SASL GSSAPI binding and the underlying 
mechanism is Kerberos 5. That mechanism might use DES or DES3. You don't 
want the overhead of encrpting the stream twice with two different systems. 
Nor do you want to start the channel with TLS and then later negotiate TLS off.

>be the authentication authority.

Doesn't sound like anything I wrote. I'll try to find the time to back over 
this section :)

Paul