On Tue, Jul 18, 2006 at 06:46:06AM -0700, Hallam-Baker, Phillip wrote:
> Only comment I remember in the BOF itself was EKR pointing out that
> the underlying aim of SASL is essentially broken, I guess that also
> applies to GSSAPI. Options in crypto specs are usually bad.
There's discussion in the jabber room log. Relevant quotes:
[10:06:20] <ekr> So, this SASL-HTTP thing is a bitch, for a bunch of
technical reasons.
...
[10:06:44] <ekr> You sort of end-up with SASL + TLS + Channel Bindings.
...
[10:07:07] <Lisa> pigdog, adding SASL to HTTP is *really* problematic.
If somebody explains to me how it can actually work
with proxies and statelessness" and everything, I will
publicly call them a genius.
[10:07:14] <ekr> nico: maybe I'm out of the loop, but I thought that
SASL was considered to be the cool way to do GSS now.
...
There ensued a discussion to answer Lisa's point, which I can summarize
thusly:
The reason that SASL is "*really* problematic" is that it is stream
oriented, and we'd be using it in a protocol (HTTP) that isn't
necessarily a stream, but a sequence of streams (so, really,
message-oriented).
Whereas the GSS-API is message-oriented, which helps a lot. Using the
GSS-API we can build a pluggable HTTP authentication system that can
work without persistent HTTP 1.1 connections. We (Leif, Sam, myself,
others), believe we can even do it with statelessness on the server.
So, yes, SASL is fundamentally not useful to us in an HTTP context.
And no, the same is not true of the GSS-API.
To run multi-round-trip GSS-API mechanisms over HTTP without persistent
HTTP 1.1 connections and with server-side statelessness we'd simply
extend the HTTP NEGOTIATE extension to have the server send to clients
an exported GSS-API security context token encrypted in a key that is
known only to the server. The encrypted exported GSS-API security
context token would carry all the necessary state.
Come to think of it, TLS too could use the same approach to make session
resumption stateless. That would be nice, very nice, if we can get it.
> A distinction needs to be made between the authentication mechanism
> and the authentication protocol. Given an authentication mechanism
> such as a password, a public key, a biometric there should ideally be
> one protocol that supports that mechanism.
There are many ways to construct security mechanisms that use passwords.
Not all of them are applicable in all circumstances because they have
different cryptographic properties or because of IPR issues. Thus there
will be more than one password mechanism.
> Having six different algorithms to support password exchange is
> broken. Six different protocols is worse.
But we'll likely have at least two for some time to come:
challenge-response, SRP.
Possibly more: fortified schemes (e.g., challenge-response protected by
TLS and with channel binding to TLS). And such mechanisms will
typically have to provide upgrade paths for folks who already have
password credentials infrastructure.
Nico
--
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
