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

[Amos Jeffries <[e-mail]>]

On 31/01/2015 3:11 a.m., Rifaat Shekh-Yusef wrote:
> 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?
> 

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