Subject: Re: [OAUTH-WG] Authentication-Info Header

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 20 Jan 2010 11:17:58 -0700

Any comments? Suggestions?

EHL

On 12/4/09 9:19 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

The Authentication-Info header should be added to draft-ietf-httpbis-p7-auth to provide a complete list of all the defined authentication headers. It should generalize the definition to make it useful for new authentication schemes:

   The Authentication-Info header is used by the server to communicate
   some information regarding the successful authentication in the response.
   The Authentication-Info header is allowed in the trailer of an HTTP
   message transferred via chunked transfer-coding.

     Authentication-Info = "Authentication-Info" ":" OWS Authentication-Info-v
     Authentication-Info-v = 1#auth-param

And should probably (finally) define Proxy-Authentication-Info which is only mentioned in passing in 2617.

It is also not clear if the Authentication-Info header can (or is appropriate) together with a new WWW-Authenticate challenge.

---

Also, for OAuth, we are looking for a place to provide authentication error information. The current definition of Authentication-Info limits it use to successful authentications. While I can certainly argue that an error is "some information regarding the successful authentication", (i.e. that it was not), it seems to violate the spirit of the text.

I am not aware of other authentication schemes using this header than Digest, and since Digest limits the allowed values, extending this header field to mean *any* status information (not just successful) should not break or change any existing implementation.

If the definition remains the same, we will need to decide between minting a new header Authentication-Error (and corresponding Proxy-Authentication-Error), or find a way to stick the error information together with a new challenge or as masked as new challenge. I am not excited about the latter option, especially given the possibility of multiple challenges in a single header.

EHL

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Jan 2010 21:33:29 +0000

> Any comments? Suggestions?

Hi Eran,
Speaking as an individual contributor:

>     The Authentication-Info header should be added to
>     draft-ietf-httpbis-p7-auth to provide a complete list of all the
>     defined authentication headers.
>
Yes.

>     It should generalize the definition to make it useful for new
>     authentication schemes:
>
As long as this is consistent with existing usage (I don't remember of 
the top of my head how Negotiate works and whether it is using this 
header field).

>     And should probably (finally) define Proxy-Authentication-Info
>     which is only mentioned in passing in 2617.
>
Yes.

>     It is also not clear if the Authentication-Info header can (or is
>     appropriate) together with a new WWW-Authenticate challenge.
>
Sure. I am not sure I can provide an opinion on this, as I am not an 
implementor.

>     ---
>
>     Also, for OAuth, we are looking for a place to provide
>     authentication error information. The current definition of
>     Authentication-Info limits it use to successful authentications.
>     While I can certainly argue that an error is "some information
>     regarding the successful authentication", (i.e. that it was not),
>     it seems to violate the spirit of the text.
>
>     I am not aware of other authentication schemes using this header
>     than Digest, and since Digest limits the allowed values, extending
>     this header field to mean *any* status information (not just
>     successful) should not break or change any existing implementation.
>
>     If the definition remains the same, we will need to decide between
>     minting a new header Authentication-Error (and corresponding
>     Proxy-Authentication-Error), or find a way to stick the error
>     information together with a new challenge or as masked as new
>     challenge. I am not excited about the latter option, especially
>     given the possibility of multiple challenges in a single header.
>
>     EHL
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 10:22:52 +0100

> Any comments? Suggestions?

Sorry for the delay. It was on my TODO list, but that list got too long.

>     defined authentication headers. It should generalize the definition
>     to make it useful for new authentication schemes:
> ...

As far as I can tell, Authentication-Info in RFC 2617 specific for 
Digest. If that's correct, it doesn't belong into HTTPbis P7.

It may be a good idea to generalize it (I have no opinion on that), but 
it would still need to be specified in a spec other than HTTPbis.

Best regards, Julian

---

From: Yutaka Oiwa <[email-masked]>
Date: Thu, 21 Jan 2010 20:41:45 +0900

>     successful) should not break or change any existing implementation.

We use the Authentication-Info: header in our proposed authentication
scheme (Mutual), and it will be good to have a common syntax for several
authentication schemes.
# We realized, during our implementation, that some implementations prefer to
# have a common syntax for each HTTP header, even when its meaning
# depends on some other values in headers (e.g. on authentication
# schemes).  These use generic lexer-parser to parse such headers first into
# key-value pairs before interpretation.

As Julian says that it is out of current HTTPbis spec,
if you are going to generalize it somewhere (e.g. OAuth WG),
I will join the discussion there.

>     regarding the successful authentication", (i.e. that it was not), it
>     seems to violate the spirit of the text.
>

Sorry for my laziness, but could you please give me a little-bit
detail (or a pointer to that) what will be the possible payload on that
[may be in oauth WG ML]?
In our proposal, a field in WWW-Authenticate was sufficient for carrying an
error information (ours has a 1-bit flag in WWW-Authenticate to distinguish
between password mismatch and key expiration, on which client behavior differs).
I'm interested if we also have a similar need which is not realized now.

-- 
Yutaka OIWA, Ph.D.                                       Research Scientist
                            Research Center for Information Security (RCIS)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]