RE: draft-montenegro-httpbis-multilegged-auth-01

On 10.07.2012 09:16, Jonathan Silvera wrote:
> Dear Yutaka
>
> Supporting legacy authentication schemes, should not be the question
> to ask ourselves. While these schemes are labeled as "broken" in HTTP
> 1.1, in reality they are deployed and working. If multiplexing
> becomes a part of HTTP 2.0, as it is likely to be, these will be
> 'broken' not just in label, but in reality.

I take it you mean NTLM and Negotiate? since Basic and Digest are not 
declared broken, just somewhat unsafe.

NTLM/Negotiate are broken in both label and reality. To different 
degrees.

Try to use HTTP pipeline, HTTP persistent connection re-use, or try to 
operate them over any proxy which does not force stateful "pinning" onto 
*stateless* HTTP (Squid-3.0 for example) and you will see just how 
broken they are. Effects range from users not being able to login at 
all, logging in under other users credentials, to constant 
popup/challenge loops, some software even DoS the network attempting to 
retry automatically.
  This is broken by any definition.

The minor fact that some admin are willing to give up all those 
performance features of HTTP to gain the illusion of "working" is rather 
sad.


>
> The compatibility requirement of the HTTP 2.0 WG charter does not
> allow us to eliminate legacy schemes, as previous applications are
> supposed to keep on working, regardless of whether they are labeled 
> as
> 'broken" for HTTP 1.1 or not. I believe that HTTP2.0 provides us with
> a great opportunity to ensure schemes currently labeled as "broken",
> are properly supported from the beginning. Without support for these
> legacy schemes, the adoption of HTTP2.0 will unavoidably suffer.
>
> Another problem our proposal attempts to address, is that Kerberos'
> "dual mode" (authenticated connection or authenticated requests)
> introduces a lot of problems for clients today since there is no way
> to deterministically know which authentication type was negotiated. 
> It
> would be great to hear from the WG on thoughts around how we can 
> solve
> this problem in a generic way, in case more "dual mode" 
> authentication
> schemes arise in the future.


On this note, the "Negotiate" scheme specifies the ability to negotiate 
NTLM (connection-auth) over it. So IMHO, this scheme is 
connection-oriented due to that requirement.

I would like to see the "Kerberos" scheme formally specified as a 
separate scheme as the request-oriented form. In this way we can 
continue to support "Negotiate" as connection-oriented (HTTP 'broken') 
and "Kerberos" as request-oriented (HTTP 'working').

Anyone keen to do that leg-work?


AYJ

Received on Tuesday, 10 July 2012 01:10:51 UTC