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

[Julian Reschke <[e-mail]>]

On 2015-02-11 11:10, Amos Jeffries wrote:
> ...
> ...
>>> With mention specifically about how it differs from Authentication-Info
>>> by being hop-by-hop.
>>
>> 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.

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

>>> 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.
>>
>> 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)
>
> Information leak vulnerabilities.

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

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

>>
>>>    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.
>>
>> That was already answered. There can only be one authentication
>> 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.

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