- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 11 Feb 2015 11:45:15 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
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
Received on Wednesday, 11 February 2015 10:45:51 UTC