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

[Amos Jeffries <[e-mail]>]

On 11/02/2015 9:43 p.m., Julian Reschke wrote:
> On 2015-02-11 02:37, Amos Jeffries wrote:
>> On 11/02/2015 11:59 a.m., Mark Nottingham wrote:
>>> Everyone,
>>>
>>> Julian believes (with his editor hat on) that this is ready. As
>>> discussed, this is a simple document to pull the Authentication-Info
>>> and Proxy-Authentication-Info header fields out of 2617, so that
>>> they’re not associated with a particular authentication scheme
>>> (thereby avoiding lots of scheme-specific headers).
>>>
>>> Therefore, this is the announcement of WGLC for:
>>>   https://tools.ietf.org/html/draft-ietf-httpbis-auth-info-02
>>>
>>> Please review the document carefully, and comment on this list.
>>>
>>
>>
>> Section 3 paragraph 3 says "
>>   Intermediaries are not allowed to modify the field value in any way.
>> "
>>
>> RFC 7235 uses wording in the form:
>>    A proxy forwarding ... MUST NOT modify ...
>>
>> I believe the Authentication-Info should share both normative MUST NOT,
>> and term "proxy" instead of intermediary. Since there are legitimate
> 
> Right now the spec doesn't use any RFC 2119 terms, so if we do this,
> we'd need to apply it in more places.
> 
>> cases where gateways and/or other intermediaries may need to change it
>> per the relevant auth scheme.
> 
> Can you give an example?
> 

1) A gateway which is itself the client doing the authentication to the
origin needs the ability to strip the header it caused to exist.

2) An ESI gateway transforming the payload from multiple transactions,
only some of which are authenticated, or authenticated using different
schemes. Needs the ability to filter which (if any) the client gets
delivered.


> In any case, I agree that this ought to be consistent with RFC7235.
> 
> 
>> Section 4 uses the term "proxy authentication" referencing RFC 7235.
>>
>> In RFC 7235 there is no definition, and only a vague implied explanation
>> of that term via explaining what the 407 status means.
> 
> That's a problem of RFC 7235. This spec would be the wrong place to
> address this.
> 
> I think proposed text for rfc7235bis would be great.
> 
>> I believe the text in section 4 should be re-written to match the
>> per-header descriptions found in RFC 7235 sectio 4.3/4.3 paragraph 2.
> 
> Not sure how that would improve things.
> 
>> 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.


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

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


Amos