W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Mon, 09 Jul 2012 18:17:45 +0100
Message-ID: <4FFB1239.9010406@isode.com>
To: Yutaka OIWA <y.oiwa@aist.go.jp>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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,
Received on Monday, 9 July 2012 17:18:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:04 UTC