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

On 11/02/2015 11:45 p.m., Julian Reschke wrote:
> 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?

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.


> 
>>>> 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?

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.

> 
>> "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.

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

Received on Wednesday, 11 February 2015 20:58:11 UTC