Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

On 01.03.2012 13:07, Adrien de Croy wrote:
> On 1/03/2012 12:21 p.m., Henrik Nordström wrote:
>> tor 2012-03-01 klockan 11:57 +1300 skrev Adrien de Croy:
>>
>>> that depends on proxy design.  If the challenges and responses are 
>>> going
>>> over the same TCP connection it's pretty simple.
>> I won't go into this. HTTP is message oriented, not connection 
>> oriented.
>
> I'm not 100% convinced.  Esp with auth.  Even disregarding NTLM, any
> time you have a challenge and response, if the response comes to a
> server over a different TCP connection, then I think a lot of
> implementations will break.  Maybe therefore they are poorly 
> designed.
>
> If for instance multiple proxy clients are multiplexed over a pool of
> connections between the proxy and a server, so that subsequent
> requests on a connection to a server can be for any proxy client, 
> then
> the server's job of maintaining association of credentials, or
> deciding when to issue a challenge is made much more difficult than 
> if
> it assumes the connection is for only 1 user.
>
> Maybe if assuming 1 connection = 1 user is broken, it should be
> explicitly warned about in the spec.

Maybe. Part 1 section 2 goes into a lot of details but seems not to say 
that explicitly anywhere or have any diagram showing connection 
multiplexing.
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-18#section-2

>  The alternative though is either
> the server has to challenge every request, or the auth tokens
> submitted by clients can be used without round-trips, or some other
> token needs to be stored and looked up by the server in global (i.e.
> non-connection-oriented) memory.  Basic fits there, but does Digest?
> NTLM certainly doesn't of course.

You have switched from connection==user assumption to 
connection==client assumption mid-sentence.

The difference between client hop-by-hop concept and user end-to-end 
concept is critical to the arguments you seem to be making.

If you look past the optimizations HTTP does require a challenge on 
every request. For www-auth the UA clients optimize the round-trip out 
of existence by holding state about the origins previous challenges and 
sending credentials up front. At no point in the spec does HTTP permit 
intermediaries to use, validate or touch the user-to-origin credentials.
  proxy-auth credentials are specifically and directly hop-by-hop so 
that intermediaries can use them.

>
>>
>>> the main area we see the problem is actually not in proxy auth, but 
>>> when
>>> a proxy intercepts the connection, requires auth and then the 
>>> website
>>> requires auth as well.
>>>
>>> It's hard for the proxy to know whether an auth response should be
>>> processed by itself, or upstream.
>> Are you talking of transparent intercepting proxies doing NTLM here? 
>> If
>> you do then please stop, that's just happens to work because the
>> security model of NTLM is plain broken broken allowing it to be 
>> abused
>> in mitm attacks in completely insecure manners. end of discussion.
>
> actually any sort of auth when you intercept you no longer know who
> the target is.

When you intercept the target is not you. End of story.
There is no middle ground, the act of interception destroyed it.

>
>> Please let NTLM die a painful death.
>
> It's going to be a very long death.  It's just not going away.  I
> think we will still see significant use of it in 10 years from now.
>
> I'm not even sure how to implement Digest on windows (I've only
> briefly looked), but it looks quite difficult.
>
> Even Negotiate is still connection-oriented?

Negotiate needs to die as painful a death as NTLM. Long live Kerberos, 
which has hop-by-hop properties and despite its orientation hangup can 
be used almost as easily as Basic or Digest auth given a minimum of 
HTTP/1.1 across all hops.

>
>>> In most cases though where this happens, wouldn't the upstream 
>>> proxies
>>> be within the same administrative domain?  e.g. so creds should 
>>> work,
>>> and leakage shouldn't be a problem.
>> Even that assumption only holds for basic auth. With anything else 
>> it
>> breaks.
>
> ok
>
> So basically the answer remain: "use Digest".

Use something that works hop-by-hop and provides a realm or scoping. 
Digest being the oldest, but Kerberos, and OAuth also meet the criteria.

AYJ

Received on Thursday, 1 March 2012 01:05:31 UTC