Subject: Working Group Last Call: draft-ietf-httpbis-auth-info

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Feb 2015 09:59:19 +1100

Everyone,

Julian believes (with his editor hat on) that this is ready. As discussed, this is a simple document to pull the Authentication-Info and Proxy-Authentication-Info header fields out of 2617, so that they’re not associated with a particular authentication scheme (thereby avoiding lots of scheme-specific headers).

Therefore, this is the announcement of WGLC for: 
 https://tools.ietf.org/html/draft-ietf-httpbis-auth-info-02

Please review the document carefully, and comment on this list.

WGLC will end on 25 February.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 11 Feb 2015 01:36:26 +0100

* Mark Nottingham wrote:
>Julian believes (with his editor hat on) that this is ready. As 
>discussed, this is a simple document to pull the Authentication-Info and 
>Proxy-Authentication-Info header fields out of 2617, so that they’re not 
>associated with a particular authentication scheme (thereby avoiding 
>lots of scheme-specific headers).
>

This revision does not address my previous comments. It basically just
contains the idea that the `Authentication-Info` header could possibly
be used for other purposes than what it has already been defined for.
Without further information it is an entirely redundant level of indi-
rection for hypothetical future specifications and should not be pub-
lished.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Feb 2015 14:37:27 +1300

> Please review the document carefully, and comment on this list.

Section 3 paragraph 3 says "
 Intermediaries are not allowed to modify the field value in any way.
"

RFC 7235 uses wording in the form:
  A proxy forwarding ... MUST NOT modify ...

I believe the Authentication-Info should share both normative MUST NOT,
and term "proxy" instead of intermediary. Since there are legitimate
cases where gateways and/or other intermediaries may need to change it
per the relevant auth scheme.

Section 4 uses the term "proxy authentication" referencing RFC 7235.

In RFC 7235 there is no definition, and only a vague implied explanation
of that term via explaining what the 407 status means.

I believe the text in section 4 should be re-written to match the
per-header descriptions found in RFC 7235 sectio 4.3/4.3 paragraph 2.
With mention specifically about how it differs from Authentication-Info
by being hop-by-hop.

Under security considerations I believe it would be good to mention that
recipients of the Authentication-Info header in any response should
(ought to or SHOULD?) treat the transaction as if it were authenticated
even if the RFC7235 headers are not present.
 Some of the use-cases I see for this header include out-of-band
authentication. If the server is treating the reply as authenticated it
may inadvertently include private information in the payload or other
headers.

Also, Yutaka brought up the issue of association between selected scheme
and Authentication-Info contents. I believe this document is the right
place to reserve a parameter scheme= which takes the auth-scheme as its
value for the purpose in the same way RFC 7235 reserves the realm=
parameter for use across schemes.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 09:43:28 +0100

> and term "proxy" instead of intermediary. Since there are legitimate

Right now the spec doesn't use any RFC 2119 terms, so if we do this, 
we'd need to apply it in more places.

> per the relevant auth scheme.

Can you give an example?

In any case, I agree that this ought to be consistent with RFC7235.

> of that term via explaining what the 407 status means.

That's a problem of RFC 7235. This spec would be the wrong place to 
address this.

I think proposed text for rfc7235bis would be great.

> per-header descriptions found in RFC 7235 sectio 4.3/4.3 paragraph 2.

Not sure how that would improve things.

> With mention specifically about how it differs from Authentication-Info

Hmm, why is it hop-by-hop?

> even if the RFC7235 headers are not present.

Why?

(Remember that the intent of the spec was simply to extract the 
definition from RFC 2617; so if we make additional changes they need to 
be, well, understood)

> parameter for use across schemes.

That was already answered. There can only be one authentication 
happening at a single time (plus one proxy authentication).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 09:54:52 +0100

> This revision does not address my previous comments. It basically just

I see one email that I did not reply to in 
<https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0355.html>, where 
you say:

"A possible starting point would be to explain whether, how, and why it
is better to use an authentication scheme independent header to specify
authentication scheme specific parameters. If it's pretty much always
better to use `Authentication-Info` then there probably should be some
SHOULD-level requirement to use it somewhere."

I think it's evident why it's better: you don't need to define a new 
header field. Is this worth calling out?

Also, just because it's better doesn't necessarily imply that there is a 
requirement to use it in new schemes. At least, there was no such 
requirement before.

> be used for other purposes than what it has already been defined for.

It has been defined for DIGEST previously. The only change is a 
clarification that other schemes can use it as well, and we have two 
authors of new schemes who intend to use it.

> rection for hypothetical future specifications and should not be pub-

Well, I disagree. We have three specifications that want to use this 
header field, one of which is in WGLC over in HTTPAuth.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Feb 2015 23:10:17 +1300

On 11/02/2015 9:43 p.m., Julian Reschke wrote:
>>> discussed, this is a simple document to pull the Authentication-Info
>>> and Proxy-Authentication-Info header fields out of 2617, so that
>>> they’re not associated with a particular authentication scheme
>>> (thereby avoiding lots of scheme-specific headers).
>>>

1) A gateway which is itself the client doing the authentication to the
origin needs the ability to strip the header it caused to exist.

2) An ESI gateway transforming the payload from multiple transactions,
only some of which are authenticated, or authenticated using different
schemes. Needs the ability to filter which (if any) the client gets
delivered.

> Hmm, why is it hop-by-hop?

First Proxy-Auth* are explicitly hop-by-hop. This not being so violates
the principle of least surprise.

It would leak the proxies network credentials related data to the client.

With result such as; In a proxy chain of A<-B<-C<-D<-E with different
authentications happening in the hop D->C and the hop C->B.  If the
header was treated as end-to-end D would be participating in the B->C
authentication.

> definition from RFC 2617; so if we make additional changes they need to

Information leak vulnerabilities.

"ought to" is fine with me if you really want to stick with the
non-normative.

> happening at a single time (plus one proxy authentication).

Except in the case above where the D header leaks to B because the C
implementer did not treat it as hop-by-hop. But the spec does not
(currently) say anything about it being different from
Authentication-Info which is end-to-end ... so they were able to
compliantly choose that nasty interpretation.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 11:45:15 +0100

On 2015-02-11 11:10, Amos Jeffries wrote:
> ...
> ...

Understood, but that doesn't make it hop-by-hop, but something in 
between, right?

> Information leak vulnerabilities.

Yes, but why would you send Authentication-Info in a response when 
Authenticate was not present in the request?

> compliantly choose that nasty interpretation.

Again, we need to find the right terminology here.

As far as I understand proxy auth, it's neither end-to-end (UA to origin 
server) nor hop-by-hop. I do agree that the description of proxy 
authentication is weak in 7235, but by all means let's fix it over 
there, not here.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 12 Feb 2015 09:57:28 +1300

> Understood, but that doesn't make it hop-by-hop, but something in

Technically yes. I dont think we need to fix that though. The well
RFC7235 is clear for the proxy-auth headers that each recipient has to
make an explicit choice with them whether to relay, change, or remove
(default).
Since this header is supposed to be a part of the same framework there
should be no issue with clearly giving it the same property. Just as
long as it *is* clear, and not just implied like right now.

> Authenticate was not present in the request?

If the auth is out-of-band. In the web form payload for example, or TLS
based certificate authentication. This header would make a good binding
between them and HTTP.

> authentication is weak in 7235, but by all means let's fix it over

Which is why I suggested using the RFC 7235 wording. It may not be using
the term hop-by-hop, but its clear about the properties involved and why.

I dont find the description in RFC 7235 weak. It just does not use a
term to label the situation where multiple proxy recipients use
identical credentials.

Amos

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 12 Feb 2015 10:47:24 +0900

> based certificate authentication. This header would make a good binding

I strongly believe that this header MUST NOT be used for such a purpose.
Use of Authentication-Info: header should be limited to RFC-7235 in-band
authentications.
Out-of-band authentication can co-exist with RFC-7235-style
in-band authentication, and re-use of the headers for out-of-band
authentication will immediately cause conflicts.

There is several good reasons to bind out-of-band authentication and
HTTP, and there can be two solutions:

1) define an in-band WWW-Authenticate authentication scheme,
    using outcome of out-of-band authentication for
    in-band authorization.  Authentication-info: header can be used
    as a part of latter.

    OAuth is one of such an example.
    Or, we can simply define an tunnel in-band authentication scheme like

    WWW-Authenticate: OutOfBand medium=TLS-client-cert
    Authorization: OutOfBand medium=TLS-client-cert channel-binding=......

2) if there is a need for light-weight solution, we can define a new
    header for a specific purpose.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Feb 2015 14:53:31 +0100

> based certificate authentication. This header would make a good binding

AFAIU, for TLS cert based auth, this is a problem in HTTP/2 anyway (due 
to renegotiation); see 
<https://tools.ietf.org/html/draft-thomson-httpbis-cant-01>.

Best regards, Julian

---

From: Hervé Ruellan <[email-masked]>
Date: Wed, 18 Feb 2015 13:37:37 +0100

I think the purpose of the headers should be made more consistent across 
the document.
In the Introduction, they are used to "return additional information 
during or after authentication", while in 3, the Authentication-Info 
header is used to "communicate additional information regarding the 
successful authentication".

DIGEST use it in an optional manner, to convey additional information 
after a successful authentication.
Scram is using it in a mandatory manner, to finalize the authentication, 
by conveying information for authenticating the server.

I think that Authentication-Info should be used by the server once the 
client is authenticated (i.e. the status code is not 401), to either 
convey additional information or finalize the authentication.

I created a pull request in this direction:
https://github.com/httpwg/http-extensions/pull/47

Hervé.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Feb 2015 15:15:08 +1100

Now <https://github.com/httpwg/http-extensions/issues/49>.

Cheers,

> On 18 Feb 2015, at 11:37 pm, Hervé Ruellan <[email-masked]> wrote:
> 
> I think the purpose of the headers should be made more consistent across the document.
> In the Introduction, they are used to "return additional information during or after authentication", while in 3, the Authentication-Info header is used to "communicate additional information regarding the successful authentication".
> 
> DIGEST use it in an optional manner, to convey additional information after a successful authentication.
> Scram is using it in a mandatory manner, to finalize the authentication, by conveying information for authenticating the server.
> 
> I think that Authentication-Info should be used by the server once the client is authenticated (i.e. the status code is not 401), to either convey additional information or finalize the authentication.
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 22 Feb 2015 19:24:39 +0100

> I think the purpose of the headers should be made more consistent across

Yes.

> https://github.com/httpwg/http-extensions/pull/47

Which means that we rule out the use of Auth-Info before the 
authentication is done.

I'm ok with this clarification, what do others think?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Feb 2015 11:30:26 +1100

Just a reminder - WGLC ends in a few days.

So far we have one issue against the document --
  https://github.com/httpwg/http-extensions/issues?q=is%3Aopen+is%3Aissue+label%3A308bis
...and it appears that this covers both Herve's and Yutaka's comments.

If you'd like to raise any other issues, please do so either in the tracker, or explicitly on-list ("I'd like to raise an issue..." or just "NEW ISSUE" in the Subject). There's been other discussion on-list, but it seems to have been resolved, so please be explicit if you feel it hasn't.

Regards,

> On 11 Feb 2015, at 9:59 am, Mark Nottingham <[email-masked]> wrote:
> 
> Everyone,
>

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 23 Feb 2015 09:35:29 +0900

I think it's OK and it should be.

We already have WWW-Authenticate: for
things before completion of authentication.

2015-02-23 3:24 GMT+09:00 Julian Reschke <[email-masked]>:
> Which means that we rule out the use of Auth-Info before the authentication
> is done.
>