Subject: Call for adoption: draft-reschke-httpauth-auth-info-00

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Jan 2015 09:45:57 +1100

Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.

I've discussed it with Barry and he agrees that it's a reasonable thing for us to do.

Please discuss; we'll make a decision about adoption on 1 Feb 2015.

Regards,

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jan 2015 16:21:45 -0800

> Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.

I'd like to see the fact that this is a *response* header field more
prominent in the document.  The word "return" is used, but in this
context, that's fairly ambiguous.

More fundamentally, I see a correlation issue if clients provide
multiple *Authorization header fields.  The response they receive will
contain some unaggregated name-value pairs in this header field.

  "Its semantics are defined by the applicable authentication scheme."

I don't know how that can be interpreted in the general sense since
there isn't a way of identifying the corresponding scheme.

And doesn't it need anti-collision machinery for the parameters?

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 29 Jan 2015 10:25:13 +0900

> contain some unaggregated name-value pairs in this header field.

RFC7235 says that HTTP clients can send only one
"credentials" set in the Authorization: or Proxy-authorization: header,
as defined in Sections 4.2 and 4.4.
One "credentials" belongs to a single scheme.
So, "the applicable authentication scheme" means that
the unique scheme which the client has included in the corresponding request.

Of course, I've wished if the existing Digest authentication scheme had
included an "auth-scheme" in the existing Authentication-Info: header.
If it had a syntax like "Authentication-Info: Digest ...", it would be
self-contained and more clearer.
It's already in use (as a Digest-scheme specific header), and
it cannot be changed without inter-op issues.

-- 
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    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]

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 29 Jan 2015 16:01:47 +1300

On 29/01/2015 2:25 p.m., Yutaka OIWA wrote:
> 2015-01-29 9:21 GMT+09:00 Martin Thomson:

Theres nothing stopping a scheme=Digest parameter being specified or
sent in that header. It just wont be used by legacy implementations is all.

Would be worth bringing up to teh httpauth WG before they seal the next
Digest version in stone if its that important to you.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Jan 2015 14:35:10 +1100

So, you support adopting it?

Regards,

> On 29 Jan 2015, at 11:21 am, Martin Thomson <[email-masked]> wrote:
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jan 2015 08:41:13 +0100

> context, that's fairly ambiguous.

Will do.

(Which reminds me that in the list of considerations for new header 
fields in 7231, most apply to request header fields; we may want to 
restructure that text in the future)

> And doesn't it need anti-collision machinery for the parameters?

See Yutaka's answer.

Best regards, Julian

---

From: Hervé Ruellan <[email-masked]>
Date: Fri, 30 Jan 2015 13:34:23 +0100

I think it's a good thing to have a common mechanism that could be 
reused by several authentication schemes (at least DIGEST and SCRAM for 
now).

I find that the definition of the Authentication-Info header field is 
fuzzier in this draft than it was in DIGEST. In DIGEST this header field 
is intended to be used for "information regarding the successful 
authentication of a client response".
I'd tweak the wording in the draft to put back this precision. I think 
it would alleviate Martin's concerns. Or did I miss something?

Regards,

Hervé.

On 01/29/2015 08:41 AM, Julian Reschke wrote:
>>> Julian has proposed that
>>> <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be
>>> adopted by this WG, with the aim of getting to LC quickly so that it
>>> can be referenced by other efforts.
>>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jan 2015 13:55:36 +0100

> it would alleviate Martin's concerns. Or did I miss something?

No, you didn't miss anything. Sounds like a good point (to stick with 
what 2617 said unless we have good reason to change it).

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 30 Jan 2015 09:11:39 -0500

Why would we restrict the use of this header in future protocols based on
the Digest usage of this header?
What would be the harm in allowing the new protocol that uses the header to
restrict it usage?

Regards,
 Rifaat

On Fri, Jan 30, 2015 at 7:55 AM, Julian Reschke <[email-masked]>
wrote:

> No, you didn't miss anything. Sounds like a good point (to stick with what
> 2617 said unless we have good reason to change it).
>
> Best regards, Julian
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 31 Jan 2015 10:45:18 +1300

> What would be the harm in allowing the new protocol that uses the header to

Information leaks. User credentials and secure token are potentially
stored in here, as are details specific to the internal operation of the
security algorithm selected/negotiated.

This header is clearly security related and very likely will be used to
transmit confidential information at some point. At the very least the
security, privacy, cacheability, and hop-by-hop re-usability behaviours
of this header need to be explicitly bounded.

i.e. recipients only implementing this spec need to be made aware of the
*potential* for critical information to be contained in traffic from
future schemes they do not implement already.

I expect this header to be used as a way to indicate implicit
non-cacheable authenticated response from out-of-band authentitication
(HTML login, federated, session resumption, connection auth with no
request credentials)
 - a direct way to kill^H^H contain auth Cookie data

Also as a way to pass Kerberos or NTLM username/group and TTL for the
credentials back to intermediaries without requiring them to participate
in the auth.

Each of these has different needs when it comes to security, but the one
thing they have in common is that they are still sensitive and related
to some previous possibly out-of-band, possibly incomplete
authentication process the recipient has nothing to do with.

I'm also fairly sure there are cases where no sensitive information at
all is transmitted, but security protection is not to protect against
best-case scenarios.

Amos