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

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. 

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.

Thanks

-Jonathan Silvera

-----Original Message-----
From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] 
Sent: Monday, July 9, 2012 10:18 AM
To: Yutaka OIWA
Cc: HTTP Working Group
Subject: Re: draft-montenegro-httpbis-multilegged-auth-01

On 09/07/2012 04:01, Yutaka OIWA wrote:
> Dear Alexey,
>
> 2012/7/9 Alexey Melnikov<alexey.melnikov@isode.com>:
>> I think it is worth investing some WG time into this proposal, because several proposals (+ existing Kerberos) are already multilegged. Otherwise new schemes would need to reinvent this, for example using "sid" directive.
> I agree that it is good to have a unified vehicle for managing 
> sessions for multi-legged auth.
>
> Actually, more than three-quarters of
> my proposal is technically a common vehicle for multi-legged 
> authentication with optional re-use of key-based shared secret for 
> authorizing multiple requests without full key-exchange.
> I think Alexey's SCRAM-SHA1 proposal completely fits with this model, 
> and I actually thought to propose, to Alexey, to merge 
> session-managing part of two proposals to one unified scheme.  One 
> possibility for me is to write (or propose) an experimental draft for 
> putting SCRAM-SHA1 onto my vehicle, to see how it works or not.
Dear Yutaka,
I reviewed your draft and I thought that several features of it are indeed generic among HTTP authentication mechanisms and should be split out to a generic HTTP authentication related document (or at least into a separate section of one of your existing drafts).

So yes, I generally support doing what you suggest. But I think it might be worth delaying any specific work until the WG decides on which HTTP authentication-related documents it should work.
> Gabriel's draft is interesting in the way that connection-based 
> existing authentication schemes (NTLM and Negotiate) into HTTP/2.0 
> world.  These things are declared "broken" in current HTTP/1.1-bis 
> discussions, and without considerations it will not be useful for 
> HTTP/2.0.
> There should be a debate about how we treat existing connection-based 
> authentication for future, and if we decide it will survive, we will 
> need Gabriel's one or similar.
>
> For key-based multi-legged authentications (things similar Digest, 
> including Mutual and SCRAM-SHA1), at the first glance, it seems not 
> well designed for key-based, but it is still interesting for me, 
> because it will show how these things are different, and how the 
> common things can be picked up.
>
> My intuition at current moment is to have TWO common vehicles for 
> HTTP-layer multi-legged authentications, one for connection-based and 
> one for key-based (this is not a strong opinion, just an observation).
> I want to continue research on how these two things are related, to 
> make common things common, and to keep different things different :-)

I haven't made my mind about this issue yet. So I am looking forward for more discussion.

Best Regards,
Alexey

Received on Monday, 9 July 2012 21:17:49 UTC