Subject: RE: [dix] DRAFT: WAE BOF minutes

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 18 Jul 2006 06:46:06 -0700

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.

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.

Having six different algorithms to support password exchange is broken. Six different protocols is worse.

The point of a standards process is not what you put into the spec, its what you leave out.

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Tuesday, July 18, 2006 8:58 AM
> To: Digital Identity Exchange
> Subject: Re: [dix] DRAFT: WAE BOF minutes
> 
> On Sat, Jul 15, 2006 at 08:23:46PM +0200, Eliot Lear wrote:
> > Throughout the entire BoF there was a side conversation of 
> SASL v. GSS.
> 
> Mostly in the jabber room though...
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Joaquin Miller <[email-masked]>
Date: Tue, 18 Jul 2006 11:07:51 -0700

>The point of a standards process is not what you put into the spec, 

Well said!

Joaquin

(And certainly true.  It has to be understood, of course.  Example: A 
bolt standard lists many combinations of diameter and thread 
pitch.  Many.  But a vanishingly small percentage of the possible 
combinations, almost all of which are left out of that standard.

(In our business, a very effective way to ensure there is   n o 
t  interoperability is to provide many options.)

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Jul 2006 14:49:08 -0500

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jul 2006 13:35:02 -0700

> resumption stateless.  That would be nice, very nice, if we can get it.

Something like this?

4507 Transport Layer Security (TLS) Session Resumption without
     Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May
     2006. 

-Ekr

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 18 Jul 2006 16:45:04 -0500

>      Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May

Yes, exactly like that.  Good to see: a) it's already been done, b)
there's precedent for doing much the same thing with the GSS-API.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 Jul 2006 17:47:02 -0400

>      Server-Side State. J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. May

Do the the browser vendors know about this RFC?

Do Apache and Microsoft have any intention of implementing it?

Jeffrey Altman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Jul 2006 14:49:21 -0700

> Do Apache and Microsoft have any intention of implementing it?

Sorry, don't know the answer to either question.

-Ekr

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 18 Jul 2006 18:09:41 -0400

> Sorry, don't know the answer to either question.

We need to do a better job of promoting our protocols.

Jeffrey Altman

---

From: Dick Hardt <[email-masked]>
Date: Tue, 18 Jul 2006 23:50:39 -0700

> We need to do a better job of promoting our protocols.

or documenting protocols so it is clear what real world problems?

or perhaps the protocols don't solve the problem in a manner that  
works for the servers and browsers?

(I say this with little knowledge of the protocols or documents  
themselves)

---

From: Joe Orton <[email-masked]>
Date: Wed, 19 Jul 2006 09:46:28 +0100

> Do Apache and Microsoft have any intention of implementing it?

Getting the TLS extension supported in the SSL library is the hard part; 
enabling such things Apache-side in mod_ssl is generally simple.

joe

---

From: "Ben Laurie" <[email-masked]>
Date: Wed, 19 Jul 2006 11:59:20 +0100

> Do Apache and Microsoft have any intention of implementing it?

Apache gets it if OpenSSL gets it. Patches welcome :-)

---

From: "Ben Laurie" <[email-masked]>
Date: Wed, 19 Jul 2006 12:01:19 +0100

> We need to do a better job of promoting our protocols.

I'd note that most of the work of supporting these things has to be
done in OpenSSL, and unlike Apache, OpenSSL does not have a large
funded development community.

Expecting volunteers to rush to implement every cute TLS feature is
asking a lot. The way to make this happen is to find money for OpenSSL
development.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 19 Jul 2006 09:39:46 -0400

> asking a lot. The way to make this happen is to find money for OpenSSL

Ben:

I am very well aware that compared to the applications that use OpenSSL,
those working on OpenSSL find it next to impossible to obtain
contributions to support their efforts.  Individuals and small
businesses are not going to write a check for OpenSSL (or an OpenSSL
contributor) to develop this code.   That's not how people think.

Instead someone will write a check to Apache to implement support
for said feature because they want it in their web server.  The Apache
folks will respond with (a) once OpenSSL gives it to us we will have
it so don't worry about it; and (b) it won't do you any good anyway
because the browsers, webdav clients, etc. don't implement it.

We are therefore left with a serious catch-22.  The only way that we
can get functionality like this implemented is to first obtain agreement
from the client and server vendors.  Only then might it become
reasonable to expect end users to step up with funding.

Jeffrey Altman

---

From: "Ben Laurie" <[email-masked]>
Date: Wed, 19 Jul 2006 14:58:21 +0100

> reasonable to expect end users to step up with funding.

Browsers seem to be implementing these features faster. I'm told SNI
is in most major browsers now, for example.

What would help, actually, is keeping a league table of features and
where they're implemented, and thus making it obvious which ones have
to be done to make a feature useful.

Cheers,

Ben.

---

From: "Gavin Baumanis" <[email-masked]>
Date: Thu, 20 Jul 2006 13:39:11 +1000

>>> On Wednesday, July 19, 2006 at 23:58, in message
<[email-masked]>, "Ben
Laurie" <[email-masked]> wrote:

Sounds Like a great idea Ben,
However there is then the problem (and it always seems to be the same
problem);
 
Who is going to implement the table?
Who is going to update it?
Can we ensure that when a feature is added into a product that the
table editor is made aware of the new feature set for the product?
 
And that doesn't even cover setting the scope for what information is
needed to be covered in the table.
 
Now, not to be one of "those" that complains about things yet does
nothing about it... I am more than happy to contribute my time to the
creation / upkeep of the table if needed!
_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Richard Megginson <[email-masked]>
Date: Thu, 20 Jul 2006 08:58:19 -0600

> to be done to make a feature useful.
There is another crypto implementation for Apache - mod_nss - 
http://directory.fedora.redhat.com/wiki/Mod_nss

mod_nss uses Mozilla NSS for crypto - 
http://www.mozilla.org/projects/security/pki/nss/ - which is the same 
crypto found in Firefox/Thunderbird.  NSS is actively maintained and 
developed by Red Hat, Sun, and others in the Mozilla and open source 
community.