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

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

I strongly believe that this header MUST NOT be used for such a purpose.
Use of Authentication-Info: header should be limited to RFC-7235 in-band
authentications.
Out-of-band authentication can co-exist with RFC-7235-style
in-band authentication, and re-use of the headers for out-of-band
authentication will immediately cause conflicts.

There is several good reasons to bind out-of-band authentication and
HTTP, and there can be two solutions:

1) define an in-band WWW-Authenticate authentication scheme,
    using outcome of out-of-band authentication for
    in-band authorization.  Authentication-info: header can be used
    as a part of latter.

    OAuth is one of such an example.
    Or, we can simply define an tunnel in-band authentication scheme like

    WWW-Authenticate: OutOfBand medium=TLS-client-cert
    Authorization: OutOfBand medium=TLS-client-cert channel-binding=......

2) if there is a need for light-weight solution, we can define a new
    header for a specific purpose.


2015-02-12 5:57 GMT+09:00 Amos Jeffries <squid3@treenet.co.nz>:
> 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 Thursday, 12 February 2015 01:48:11 UTC