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

Hi Amos,


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

There are millions of users working in environments that require NTLM, who will find it very real if their deployments are broken by the new version of HTTP. It would be great to hear suggestions on how the proposal can be modified, to make sure multiplexing introduces minimal side effects for all implementers of multi-legged authentication schemes.

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

The dual mode I am referring to is independent of Negotiate, rather a characteristic of the Kerberos scheme itself. Kerberos (standalone or under Negotiate) can be request-oriented or connection-oriented. Problems arise due to the fact that there is no way to deterministically know which one will be used. 

Thanks

-Jonathan

-----Original Message-----
From: Amos Jeffries [mailto:squid3@treenet.co.nz] 
Sent: Monday, July 9, 2012 6:10 PM
To: ietf-http-wg@w3.org
Subject: 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 Wednesday, 11 July 2012 18:48:17 UTC