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

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Mar 2015 10:27:18 +0100

On 2015-02-20 05:15, Mark Nottingham wrote:
> Now <https://github.com/httpwg/http-extensions/issues/49>.

...closed (I already had applied Hervé's changes earlier).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Mar 2015 13:52:13 +0100

On 2015-02-11 11:10, Amos Jeffries wrote:
> 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.

I'll track this separately as 
<https://github.com/httpwg/http-extensions/issues/52>.

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

Tracked as <https://github.com/httpwg/http-extensions/issues/50>; 
proposed next text:

    A proxy forwarding a response is not allowed to modify the field
    value in any way.

(see 
<https://github.com/httpwg/http-extensions/commit/e175586ede472946b1428bb355c3195b21cdf06b>).

Does this work for you, Amos?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 02 Mar 2015 02:01:12 +1300

> Does this work for you, Amos?

Yes.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Mar 2015 22:44:53 +0100

On 2015-02-11 11:10, Amos Jeffries wrote:
> ...
>>> 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.
> ...

Now tracked as <https://github.com/httpwg/http-extensions/issues/51>.

Would it be sufficient to steal from 
<http://greenbytes.de/tech/webdav/rfc7235.html#rfc.section.4.3.p.2>:

"Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 
only to the next outbound client on the response chain. This is because 
only the client that chose a given proxy is likely to have the 
credentials necessary for authentication. However, when multiple proxies 
are used within the same administrative domain, such as office and 
regional caching proxies within a large corporate network, it is common 
for credentials to be generated by the user agent and passed through the 
hierarchy until consumed. Hence, in such a configuration, it will appear 
as if Proxy-Authenticate is being forwarded because each proxy will send 
the same challenge set."

rewriting it to:

"However, unlike Authentication-Info, the Proxy-Authentication-Info 
header field applies only to the next outbound client on the response 
chain. This is because only the client that chose a given proxy is 
likely to have the credentials necessary for authentication. However, 
when multiple proxies are used within the same administrative domain, 
such as office and regional caching proxies within a large corporate 
network, it is common for credentials to be generated by the user agent 
and passed through the hierarchy until consumed. Hence, in such a 
configuration, it will appear as if Proxy-Authentication-Info is being 
forwarded because each proxy will send the same challenge set."

?

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 02 Mar 2015 14:06:35 +1300

> forwarded because each proxy will send the same challenge set."

Exactly what I was suggesting at the start of the thread, sorry if I
wasn't clear.

Yes that works for me (still).

Amos

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Mar 2015 11:41:56 +0100

> Yes that works for me (still).

OK, applied with 
<https://github.com/httpwg/http-extensions/commit/dd222be84c5cd9e6f087f4ab4d73e224beb84fa1>.

Best regards, Julian