Subject: Re: [Ietf-http-auth] Implementation likelihood?
From: "Roy T. Fielding" <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Cc: HTTP authentication list <[email-masked]>
Date: Wed, 23 Nov 2005 13:10:29 -0800
List-Id: ietf-http-auth.osafoundation.org

On Nov 23, 2005, at 12:47 PM, Jeffrey Altman wrote:
> I'm not sure I understand why I need a new transport layer.
> HTTP is a message-based protocol.   GSS is a message-based protocol.
>
> Why can't I simply define a HTTP AUTH mechanism that negotiates a
> GSS context and then simply require that all HTTP message contents
> after the negotiation be data encrypted/integrity protected with the
> GSS context?

What do you want to do differently from what was tried (and failed)
in S-HTTP?

    <http://www.homeport.org/~adam/shttp.html>
    <http://www.ietf.org/rfc/rfc2660.txt>

There are ways to do that stuff using an entirely new protocol
like waka.  In contrast, the overhead of doing so within the
HTTP/MIME syntax makes it non-deployable.

....Roy

Date: Wed, 23 Nov 2005 21:07:34 +0000
From: Joe Orton <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Mail-Followup-To: HTTP authentication list <[email-masked]>

On Wed, Nov 23, 2005 at 03:47:20PM -0500, Jeffrey Altman wrote:
> Joe Orton wrote:
> 
> > But an HTTP auth scheme can only be an HTTP auth scheme, and if what you 
> > actually want to do is to negotiate a new transport layer (which you 
> > really do with any Kerberos solution, be that SASL or GSSAPI) then you 
> > need a spec for an HTTP-over-SASL or an HTTP-over-GSSAPI transport 
> > layer, not merely an HTTP auth scheme.
> > 
> > joe
> 
> I'm not sure I understand why I need a new transport layer.
> HTTP is a message-based protocol.   GSS is a message-based protocol.
> 
> Why can't I simply define a HTTP AUTH mechanism that negotiates a
> GSS context and then simply require that all HTTP message contents
> after the negotiation be data encrypted/integrity protected with the
> GSS context?

You can negotiate an upgrade to a new transport layer, 2616 has a 
defined mechanism for doing that - the Upgrade header, and 2817 
introduced a mechanism to allow server-mandated upgrades.  But you can't 
magically switch to a new transport layer because an HTTP auth exchanged 
happened to take place (as the HTTP/SASL draft attempted).

You can (I think) define a protocol which performs the GSSAPI 
negotiation as a normal HTTP auth exchange followed by a server-mandated 
upgrade to a GSSAPI.

i.e.

> GET /secret HTTP/1.1

< HTTP/1.1 401 Go away
< WWW-Authenticate: GSSAPI

> GET /secret HTTP/1.1
> Authorization: GSSAPI gssapibase64token

< HTTP/1.1 426 Upgrade Required
< Upgrade: GSSAPI/1.0, HTTP/1.1

<...switch to GSSAPI-encrypted transport for remainder of connection..>

joe

Date: Wed, 23 Nov 2005 15:47:20 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?

This is a cryptographically signed message in MIME format.

--------------ms020502080905030409050207
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joe Orton wrote:

> But an HTTP auth scheme can only be an HTTP auth scheme, and if what you 
> actually want to do is to negotiate a new transport layer (which you 
> really do with any Kerberos solution, be that SASL or GSSAPI) then you 
> need a spec for an HTTP-over-SASL or an HTTP-over-GSSAPI transport 
> layer, not merely an HTTP auth scheme.
> 
> joe

I'm not sure I understand why I need a new transport layer.
HTTP is a message-based protocol.   GSS is a message-based protocol.

Why can't I simply define a HTTP AUTH mechanism that negotiates a
GSS context and then simply require that all HTTP message contents
after the negotiation be data encrypted/integrity protected with the
GSS context?

Jeffrey Altman

--------------ms020502080905030409050207
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020502080905030409050207--

Date: Wed, 23 Nov 2005 20:39:40 +0000
From: Joe Orton <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Mail-Followup-To: HTTP authentication list <[email-masked]>

On Wed, Nov 23, 2005 at 12:46:36PM -0600, Nicolas Williams wrote:
> Note that these two motivations are one and the same: we just want more
> choices of remote authentication mechanism in HTTP applications.
>
> Sometimes the choice will be Kerberos V, sometimes it will be a
> SAML-based mechanism, sometimes it will be a PKIX-based mechanism,
> sometimes it will be some password digest mechanism, sometimes it will
> be a challenge/response token mechanism, etc...  Whatever is appropriate
> for any given {user, service}.  Kerberos V may well dominate intranets
> sure, while SAML and password mechanisms domainate on the wider
> Internet, but that's not important -- having these choices is.
> 
> However, whatever we do we should have to do it no more than once: it
> should be possible to add new mechanisms without having to revise the
> base HTTP authentication specs again.

I'm not sure exactly what you're getting at there: it's already possible 
to define and deploy new HTTP auth schemes without changing RFC 2616 or 
2617 one bit.

But an HTTP auth scheme can only be an HTTP auth scheme, and if what you 
actually want to do is to negotiate a new transport layer (which you 
really do with any Kerberos solution, be that SASL or GSSAPI) then you 
need a spec for an HTTP-over-SASL or an HTTP-over-GSSAPI transport 
layer, not merely an HTTP auth scheme.

joe

Date: Wed, 23 Nov 2005 14:00:53 -0600
From: Nicolas Williams <[email-masked]>
To: Scott Lawrence <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>, Jeffrey Mogul <[email-masked]>

On Wed, Nov 23, 2005 at 01:56:00PM -0500, Scott Lawrence wrote:
> On Wed, 2005-11-23 at 12:46 -0600, Nicolas Williams wrote:
> > However, whatever we do we should have to do it no more than once: it
> > should be possible to add new mechanisms without having to revise the
> > base HTTP authentication specs again.
> 
> Changing the specs is the least of the problem; getting interoperable
> implementations that users can count on existing is the problem.  Web
> sites won't use a system that any significant subset of browsers don't
> implement, and browsers won't implement a system that web sites don't
> use.  Creating more choices makes that dilemma much worse, not better.

I don't agree.

The MS HTTP Negotiate extension, for example, has gained some ground on
intranets and probably not at all on the wider Internet (after all,
there is no global Kerberos V realm infrastructure -- no TLD realms, no
x-realm relations between them, nothing -- and don't ask about NTLM!).

There was room for that extension, and it added choices, and initially
there were only Microsoft implementations, yet now Mozilla and Apache
and others implement it also.

So, I think experience indicates that adding more choices is not an
obviously fatally flawed approach.

Nico
-- 

Subject: Re: [Ietf-http-auth] Implementation likelihood?
From: Scott Lawrence <[email-masked]>
To: Nicolas Williams <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Wed, 23 Nov 2005 13:56:00 -0500
Cc: HTTP authentication list <[email-masked]>, Jeffrey Mogul <[email-masked]>

> On Wed, Nov 23, 2005 at 01:17:11PM +0000, Joe Orton wrote:
> > I think it's worth noting that there are probably two separate 
> > motivations for people being here:

> > 1) those looking for a way to do Kerberos authentication with HTTP so 
> > they can do SSO internally - this can't really be done simply as a new 
> > HTTP auth scheme
> > 
> > 2) those looking for a new HTTP authentication scheme for use on the Web 
> > which isn't Digest or Basic (simpler/better/different/whatever)

On Wed, 2005-11-23 at 12:46 -0600, Nicolas Williams wrote:

> Note that these two motivations are one and the same: we just want more
> choices of remote authentication mechanism in HTTP applications.
> 
> Sometimes the choice will be Kerberos V, sometimes it will be a
> SAML-based mechanism, sometimes it will be a PKIX-based mechanism,
> sometimes it will be some password digest mechanism, sometimes it will
> be a challenge/response token mechanism, etc...  Whatever is appropriate
> for any given {user, service}.  Kerberos V may well dominate intranets
> sure, while SAML and password mechanisms domainate on the wider
> Internet, but that's not important -- having these choices is.
> 
> However, whatever we do we should have to do it no more than once: it
> should be possible to add new mechanisms without having to revise the
> base HTTP authentication specs again.

Changing the specs is the least of the problem; getting interoperable
implementations that users can count on existing is the problem.  Web
sites won't use a system that any significant subset of browsers don't
implement, and browsers won't implement a system that web sites don't
use.  Creating more choices makes that dilemma much worse, not better.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

Date: Wed, 23 Nov 2005 12:46:36 -0600
From: Nicolas Williams <[email-masked]>
To: Joe Orton <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>, Jeffrey Mogul <[email-masked]>

On Wed, Nov 23, 2005 at 01:17:11PM +0000, Joe Orton wrote:
> On Tue, Nov 15, 2005 at 12:24:47PM -0800, Lisa Dusseault wrote:
> > We had a great participation from security experts at the HTTP-Auth bar 
> > BOF, but not so many HTTP experts.  Is there anybody implementing HTTP, 
> > WebDAV or CalDAV, or other HTTP-based protocol, or who would be likely 
> > to implement a new security mechanism, and who can evaluate or even 
> > react to the various security proposals?
> 
> I would certainly.

Excellent.

> I think it's worth noting that there are probably two separate 
> motivations for people being here:
> 
> 1) those looking for a way to do Kerberos authentication with HTTP so 
> they can do SSO internally - this can't really be done simply as a new 
> HTTP auth scheme
> 
> 2) those looking for a new HTTP authentication scheme for use on the Web 
> which isn't Digest or Basic (simpler/better/different/whatever)

Note that these two motivations are one and the same: we just want more
choices of remote authentication mechanism in HTTP applications.

Sometimes the choice will be Kerberos V, sometimes it will be a
SAML-based mechanism, sometimes it will be a PKIX-based mechanism,
sometimes it will be some password digest mechanism, sometimes it will
be a challenge/response token mechanism, etc...  Whatever is appropriate
for any given {user, service}.  Kerberos V may well dominate intranets
sure, while SAML and password mechanisms domainate on the wider
Internet, but that's not important -- having these choices is.

However, whatever we do we should have to do it no more than once: it
should be possible to add new mechanisms without having to revise the
base HTTP authentication specs again.

Nico
-- 

Date: Wed, 23 Nov 2005 13:17:11 +0000
From: Joe Orton <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>, Jeffrey Mogul <[email-masked]>

On Tue, Nov 15, 2005 at 12:24:47PM -0800, Lisa Dusseault wrote:
> We had a great participation from security experts at the HTTP-Auth bar 
> BOF, but not so many HTTP experts.  Is there anybody implementing HTTP, 
> WebDAV or CalDAV, or other HTTP-based protocol, or who would be likely 
> to implement a new security mechanism, and who can evaluate or even 
> react to the various security proposals?

I would certainly.

I think it's worth noting that there are probably two separate 
motivations for people being here:

1) those looking for a way to do Kerberos authentication with HTTP so 
they can do SSO internally - this can't really be done simply as a new 
HTTP auth scheme

2) those looking for a new HTTP authentication scheme for use on the Web 
which isn't Digest or Basic (simpler/better/different/whatever)

joe

From: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Implementation likelihood?
Date: Mon, 21 Nov 2005 00:30:53 -0500
To: Lisa Dusseault <[email-masked]>
Cc: HTTP authentication list <[email-masked]>, Jeffrey Mogul <[email-masked]>

On 15-Nov-05, at 3:24 PM, Lisa Dusseault wrote:

> We had a great participation from security experts at the HTTP-Auth  
> bar BOF, but not so many HTTP experts.  Is there anybody  
> implementing HTTP, WebDAV or CalDAV, or other HTTP-based protocol,  
> or who would be likely to implement a new security mechanism, and  
> who can evaluate or even react to the various security proposals?

We'd certainly be interested in implementing a broadly-supported HTTP  
auth standard, if it was any good. =)

I don't know who would do the typing, but we have pluggable auth for  
HTTP now, so people should be able to prototype with an extension for  
us to evaluate for inclusion in Firefox 2 (or whatever release is  
appropriate for when the standard bakes down).

Dan Mosedale is doing a bunch of CalDAV and related-infrastructure  
work, and might be a good person to cajole into helping with that.

Mike

Date: Fri, 18 Nov 2005 12:46:48 -0600
From: Nicolas Williams <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

On Thu, Nov 17, 2005 at 03:55:17PM -0800, Roy T. Fielding wrote:
> On Nov 17, 2005, at 3:23 PM, Nicolas Williams wrote:
> 
> >Are you asking for this for browser-based applications?  Or for otheror
> >all applications layered over HTTP?
> 
> All.
> 
> >Have you no interest in credential types other than password digests?
> 
> There is probably a way to spec client certificates such that they

So, certificates aren't the only kind of credential other than
passwords...  Too much TLS, me thinks :)

> act as a digest.  Password is just a shared secret.  However, certs
> create a different cost/complexity issue and thus a different HTTP
> auth mechanism.  Auth mechanisms should be categorized by what the
> server has to store in order to authenticate a request.

I'm trying to parse this; I take some of it to mean that you want any
such security mechanisms to be like password digest in that you exchange
some tokens, validate stuff and call it a day -- all fairly well
abstracted.

Of course, that's pretty much what is on the table here as that is how
SASL and the GSS-API mechanisms handle authentication.

You're also begging for simplicity.  I'm not sure if you mean only in
terms of management of such things as trust anchors, private
keys/tokens, policies, Kerberos V principal keys, etc, or if you also
might be referring to the outputs of authentication / inputs to
authorization.  But in any case complexity will be a function of the
mechanisms used, and in any given situation the choice of mechanism will
be a function of many variables (in the Internet as a whole this means:
the market).

> >Are you saying that session protection isn't worth it?  Or simply that
> >expensive public key operations (e.g., for perfect forward security)
> >aren't worth it?
> 
> There is no such thing as perfect forward security, and no I wouldn't
> care about that even if it did exist.  HTTP auth operates with a
> known trade-off of speed/simplicity versus security.  You don't
> "solve" HTTP security by making it immune to all attacks -- you just
> make it not worth implementing.  I have no interest in session
> protection because HTTP/1.1 was designed to be independent of TCP
> precisely so that it could run run quite well within existing and
> future session-layer connections with whatever levels of security
> you might like (personally, I like SSH tunnels).
> 
> I do have an interest in message encryption for future protocols,
> but not for HTTP/1.x.

I think we all agree -- we're not trying to provide session protection
directly in HTTP as we can leverage TLS (and/or other protocols) for
that.

We're trying to provide better authentication mechanism choices...

...and to make sure that authentication can be cryptographically bound
to whatever channels, where there are any, secure HTTP traffic, whether
it be TLS, SSHv2, or, even, IPsec.

> >Also, I suspect that users of non-browser-based HTTP applications will
> >likely care more about session protection than users of browser-based
> >apps.
> 
> No.  Non-browser-based apps just need a standard HTTP auth -- they
> have the same security issues as browsers once non-standard forms
> and cookies are replaced.

I agree, with the caveat that when session protection is desired then
authentication done in HTTP must be bound to some secure channel, and
this must be feasible.

I think you must have thought that I was proposing that we add
cryptographic session protection to HTTP directly.  I am not.

Nico
-- 

Date: Fri, 18 Nov 2005 07:17:02 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Joe Gregorio <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms030103000302050602020909
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Joe Gregorio wrote:
> On 11/17/05, Roy T. Fielding <[email-masked]> wrote:
>> Digest should be replaced with a new algorithm that includes
>> only qop=auth, client-generated nonces and a simple timestamp
>> based on the last 401 response's Date field.  Anything more than
>> that is just as expensive for the server to implement as SSL/TLS.
> 
> +1.  That's exactly what the Atom Publishing Protocol needs.
> 
> The use case from the Atom Publishing Protocol it would be
> a single picture POST'd from a cellphone to a server
> that implements the auth completely in a CGI script.
> 
> No sessions.
> Simple and straight forward to implement.
> Server-side is implementable in a CGI script.
> 
>    -joe

I am going to re-write this requirement to mean that:

(1) the Web Server must publish in the environment the
necessary Channel Binding data for use by the CGI

(2) the scripting languages used for CGI programming (such as Ruby,
Python, Perl, ...) provide support for a GSS API Language Binding.

Jeffrey Altman

--------------ms030103000302050602020909
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030103000302050602020909--

Date: Fri, 18 Nov 2005 12:22:54 +0100
From: Leif Johansson <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

Jeffrey Altman wrote:
> Roy T. Fielding wrote:
> 
>>On Nov 17, 2005, at 3:23 PM, Nicolas Williams wrote:
>>
>>>Are you saying that session protection isn't worth it?  Or simply that
>>>expensive public key operations (e.g., for perfect forward security)
>>>aren't worth it?
>>
>>There is no such thing as perfect forward security, and no I wouldn't
>>care about that even if it did exist.  HTTP auth operates with a
>>known trade-off of speed/simplicity versus security.  You don't
>>"solve" HTTP security by making it immune to all attacks -- you just
>>make it not worth implementing.  I have no interest in session
>>protection because HTTP/1.1 was designed to be independent of TCP
>>precisely so that it could run run quite well within existing and
>>future session-layer connections with whatever levels of security
>>you might like (personally, I like SSH tunnels).
>>
>>I do have an interest in message encryption for future protocols,
>>but not for HTTP/1.x.
> 
> 
> I am going to insist that whatever authentication method is agreed upon
> provide support for the equivalent of the GSSAPI concept of a "channel
> binding" between an authenticated security context and an underlying
> cryptographic session across which the context was negotiated.  For
> reference please read
> 
> http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-01.txt
> 
> There is no need to add message encryption to HTTP.   There is very
> much a requirement that the authentication performed within an HTTP
> exchange be bound to the method used to protect it.  If there is no
> such binding provided then the authentication is useless as you are
> open to man in the middle attacks.
> 
> Jeffrey Altman

Hear hear! I can't see the benefit of building anything less than that.

	Cheers leifj

Date: Fri, 18 Nov 2005 02:36:59 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms020301070703080802070408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Roy T. Fielding wrote:
> On Nov 17, 2005, at 3:23 PM, Nicolas Williams wrote:
>> Are you saying that session protection isn't worth it?  Or simply that
>> expensive public key operations (e.g., for perfect forward security)
>> aren't worth it?
> 
> There is no such thing as perfect forward security, and no I wouldn't
> care about that even if it did exist.  HTTP auth operates with a
> known trade-off of speed/simplicity versus security.  You don't
> "solve" HTTP security by making it immune to all attacks -- you just
> make it not worth implementing.  I have no interest in session
> protection because HTTP/1.1 was designed to be independent of TCP
> precisely so that it could run run quite well within existing and
> future session-layer connections with whatever levels of security
> you might like (personally, I like SSH tunnels).
> 
> I do have an interest in message encryption for future protocols,
> but not for HTTP/1.x.

I am going to insist that whatever authentication method is agreed upon
provide support for the equivalent of the GSSAPI concept of a "channel
binding" between an authenticated security context and an underlying
cryptographic session across which the context was negotiated.  For
reference please read

http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-channel-bindings-01.txt

There is no need to add message encryption to HTTP.   There is very
much a requirement that the authentication performed within an HTTP
exchange be bound to the method used to protect it.  If there is no
such binding provided then the authentication is useless as you are
open to man in the middle attacks.

Jeffrey Altman

--------------ms020301070703080802070408
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020301070703080802070408--

Date: Thu, 17 Nov 2005 21:27:49 -0500
From: Joe Gregorio <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

On 11/17/05, Roy T. Fielding <[email-masked]> wrote:
> Digest should be replaced with a new algorithm that includes
> only qop=3Dauth, client-generated nonces and a simple timestamp
> based on the last 401 response's Date field.  Anything more than
> that is just as expensive for the server to implement as SSL/TLS.

+1.  That's exactly what the Atom Publishing Protocol needs.

The use case from the Atom Publishing Protocol it would be
a single picture POST'd from a cellphone to a server
that implements the auth completely in a CGI script.

No sessions.
Simple and straight forward to implement.
Server-side is implementable in a CGI script.

   -joe

--
Joe Gregorio        http://bitworking.org

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Date: Thu, 17 Nov 2005 15:55:17 -0800
To: Nicolas Williams <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

On Nov 17, 2005, at 3:23 PM, Nicolas Williams wrote:

> Are you asking for this for browser-based applications?  Or for otheror
> all applications layered over HTTP?

All.

> Have you no interest in credential types other than password digests?

There is probably a way to spec client certificates such that they
act as a digest.  Password is just a shared secret.  However, certs
create a different cost/complexity issue and thus a different HTTP
auth mechanism.  Auth mechanisms should be categorized by what the
server has to store in order to authenticate a request.

> Are you saying that session protection isn't worth it?  Or simply that
> expensive public key operations (e.g., for perfect forward security)
> aren't worth it?

There is no such thing as perfect forward security, and no I wouldn't
care about that even if it did exist.  HTTP auth operates with a
known trade-off of speed/simplicity versus security.  You don't
"solve" HTTP security by making it immune to all attacks -- you just
make it not worth implementing.  I have no interest in session
protection because HTTP/1.1 was designed to be independent of TCP
precisely so that it could run run quite well within existing and
future session-layer connections with whatever levels of security
you might like (personally, I like SSH tunnels).

I do have an interest in message encryption for future protocols,
but not for HTTP/1.x.

> IMO, for many web services, indeed, session protection isn't all that
> important, and so PFS isn't either.  But authentication using 
> credential
> types other than passwords is.

Sure, but you still need to spec it as a digest exchange because
encryption of the entire message is an entirely separate protocol,
not HTTP authentication.

> Also, I suspect that users of non-browser-based HTTP applications will
> likely care more about session protection than users of browser-based
> apps.

No.  Non-browser-based apps just need a standard HTTP auth -- they
have the same security issues as browsers once non-standard forms
and cookies are replaced.

....Roy

Date: Thu, 17 Nov 2005 17:23:06 -0600
From: Nicolas Williams <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

On Thu, Nov 17, 2005 at 03:08:52PM -0800, Roy T. Fielding wrote:
> Digest should be replaced with a new algorithm that includes
> only qop=auth, client-generated nonces and a simple timestamp
> based on the last 401 response's Date field.  Anything more than
> that is just as expensive for the server to implement as SSL/TLS.

Are you asking for this for browser-based applications?  Or for otheror
all applications layered over HTTP?

Have you no interest in credential types other than password digests?

Are you saying that session protection isn't worth it?  Or simply that
expensive public key operations (e.g., for perfect forward security)
aren't worth it?

IMO, for many web services, indeed, session protection isn't all that
important, and so PFS isn't either.  But authentication using credential
types other than passwords is.

Also, I suspect that users of non-browser-based HTTP applications will
likely care more about session protection than users of browser-based
apps.  Using SSL/TLS for session protection is fine, provided that
there's a way to tie in user authentication based on credentials better
than passwords and/or a way to key SSL/TLS session without expensive
public key crypto.

Nico
-- 

From: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Date: Thu, 17 Nov 2005 15:08:52 -0800
To: Scott Lawrence <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

On Nov 16, 2005, at 5:17 AM, Scott Lawrence wrote:

> On Tue, 2005-11-15 at 16:24 -0800, Roy T. Fielding wrote:
>
>> HTTP Digest isn't used because the algorithm was flawed (hash
>> of password instead of hash of hashed password)
>
> Just for the record - MD5-sess mode _is_ hash of hashed password, and
> could be used to define a very nice single-signon protocol.  We never
> specified a protocol that the web server could use to get a session key
> that was issued by an authentication service, but the MD5-sess mode
> allows for it.

Yes, but that wasn't implemented because of all the complexity added
for nonce handling and fear that implementing Digest in a stateless
way would lead to all sorts of whiners posting security alerts about
replay attacks.

>> , too much
>> baggage was added on for the sake of non-repeatable hashes
>> and message integrity,
>
> At the time, people seemed to think that replay and integrity 
> protection
> were important services, but then people are funny that way.

Everybody wants more security.  Nobody wants to pay for it.
The cost here was that it became so complex that correct implementation
was very difficult, complete implementation was impossible for a
stateless server, and anyone who tried to implement it was barraged
with "security alerts" because the RFC recommends far more than
anyone (not running SSL) ever needs.

>> and because a single bug in MSIE
>> (truncating query args from the URI before hashing) interferes
>> with deployment.  HTTP auth isn't used in general because browsers
>> ignore the HTML content of the 401 message and present idiotic
>> dialogs instead.
>
> That's because the 401 messages could not specify any way to actually
> replace the idiotic dialogs.

They could just fine -- they simply don't for the usual chicken and
egg reasons.

>> What we need is a simple mechanism for the server to indicate
>> to the client that digest authentication is available and to
>> use the included message as the input dialog.  If digest isn't
>> good enough, then define an HTTP AA method that is -- just don't
>> waste our time with any session-based junk.  There is
>> absolutely no reason to turn HTTP into TLS or SSH when we can
>> already use HTTP within a session protocol.  HTTP already has
>> the Upgrade header field.
>
>> The above is all we need for non-browser clients.  For browsers,
>> it simply requires the browser developers to allow something
>> in the response to indicate that the 401 message body should
>> be used for UI; standard form field names could then be used
>> to supply the authentication values for the client to construct
>> credentials for the next HTTP request.
>
> We tried to fix that and some other problems with a submission to W3C 
> to
> specify authentication interfaces:
> http://www.w3.org/TR/1999/NOTE-authentform-19990203  but at the time
> everyone was focused on simplifying HTML rather than adding to it.  Now
> that there is actually a reasonable extensibility mechanism for XHTML,
> it would probably be worth dusting that off.

HTML would have been fine -- the problem was the forum chosen.
The TAG has tried to find a place for that document a couple times.
Perhaps one of the new web applications groups will take it up.

Digest should be replaced with a new algorithm that includes
only qop=auth, client-generated nonces and a simple timestamp
based on the last 401 response's Date field.  Anything more than
that is just as expensive for the server to implement as SSL/TLS.

....Roy

Date: Wed, 16 Nov 2005 10:09:08 -0600
From: Nicolas Williams <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as	in	SAML	SASLMechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked]

On Wed, Nov 16, 2005 at 11:00:12AM -0500, Cyrus Daboo wrote:
> Hi Jeffrey,
> 
> --On November 16, 2005 10:56:43 AM -0500 Jeffrey Altman 
> <[email-masked]> wrote:
> 
> >Even though I am pointing out the above, I too would prefer a direct use
> >of GSS for this purpose.   I believe the GSS message oriented model is
> >better suited to incorporation in HTTP.
> 
> Could you explain that a little more for those of us who are not as 
> familiar with the intricacies of GSS as opposed to SASL?

SASL is stream-oriented -- apps write streams of octets; this is clearly
not suitable to use with any but stream-oriented transports.

The GSS-API is message-oriented and supports out of order message
delievery and processing and replay detection.  So clearly the GSS-API
can be used with any transport, whether message- or stream-oriented.

Both, of course, are transport-independent, but SASL is inherently
limited to transports like TCP.

Nico
-- 

Date: Wed, 16 Nov 2005 10:03:12 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in	SAML	SASLMechanism?
Cc: [email-masked], [email-masked], Gerald Beuchelt <[email-masked]>

On Wed, Nov 16, 2005 at 10:56:43AM -0500, Jeffrey Altman wrote:
> The justification for using SASL instead of GSS is simply a question of
> how much complexity must the application developer deal with when
> implementing it.   The SASL APIs tend to be easier for application
> developers to grasp than the GSS API although GSS API is a standard and
> SASL APIs are not.

If that is the question then I take the opposite view :)

I think that the GSS-API is much better thought out and well-formed as
an API.

> Even though I am pointing out the above, I too would prefer a direct use
> of GSS for this purpose.   I believe the GSS message oriented model is
> better suited to incorporation in HTTP.

Yes.

Date: Wed, 16 Nov 2005 11:00:12 -0500
From: Cyrus Daboo <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in	SAML	SASLMechanism?
Cc: [email-masked]

Hi Jeffrey,

--On November 16, 2005 10:56:43 AM -0500 Jeffrey Altman 
<[email-masked]> wrote:

> Even though I am pointing out the above, I too would prefer a direct use
> of GSS for this purpose.   I believe the GSS message oriented model is
> better suited to incorporation in HTTP.

Could you explain that a little more for those of us who are not as 
familiar with the intricacies of GSS as opposed to SASL?

-- 
Cyrus Daboo

Date: Wed, 16 Nov 2005 10:56:43 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Gerald Beuchelt <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML	SASLMechanism?
Cc: [email-masked], [email-masked], Nicolas Williams <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms060102070004010901080107
Content-Type: multipart/alternative;
	boundary="------------060201030806080206020108"

This is a multi-part message in MIME format.
--------------060201030806080206020108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Gerald Beuchelt wrote:
>
> I definitively see your points for chosing SASL from a protcol
> perspective.
>
> However, one of the reasons I prefer GSS over SASL is the fact that
> the Windows Security architecture uses SSPI. If we want to make
> adoption easy for that platform and encourage interoperability, GSS
> would probably a better choice.
>
> Best,
>
> Gerald
>
SASL is supported by Windows.

http://msdn.microsoft.com/library/en-us/secauthn/security/saslsetcontextoption.asp

The justification for using SASL instead of GSS is simply a question of
how much complexity must the application developer deal with when
implementing it.   The SASL APIs tend to be easier for application
developers to grasp than the GSS API although GSS API is a standard and
SASL APIs are not.

In the long run, it really doesn't matter.   Whenever a new mechanism is
defined, SAML or anything else, it should be defined as a GSS
mechanism.   That is because all GSS mechs automatically become SASL
mechs.   SASL needs to be extended to support a generic channel bindings
concept but that is something that can be proposed and added to the SASL
WG charter provided that we demonstrate its necessity.

Even though I am pointing out the above, I too would prefer a direct use
of GSS for this purpose.   I believe the GSS message oriented model is
better suited to incorporation in HTTP.

Jeffrey Altman

--------------060201030806080206020108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gerald Beuchelt wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="MS Exchange Server version 6.5.6944.0">
  <title>RE: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML
SASLMechanism?</title>
<!-- Converted from text/plain format -->
  <p><font size="2">I definitively see your points for chosing SASL
from a protcol perspective.<br>
  <br>
However, one of the reasons I prefer GSS over SASL is the fact that the
Windows Security architecture uses SSPI. If we want to make adoption
easy for that platform and encourage interoperability, GSS would
probably a better choice.<br>
  <br>
Best,<br>
  <br>
Gerald<br>
  </font></p>
</blockquote>
SASL is supported by Windows.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;
<a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/library/en-us/secauthn/security/saslsetcontextoption.asp">http://msdn.microsoft.com/library/en-us/secauthn/security/saslsetcontextoption.asp</a><br>
<br>
The justification for using SASL instead of GSS is simply a question of
how much complexity must the application developer deal with when
implementing it.&nbsp;&nbsp; The SASL APIs tend to be easier for application
developers to grasp than the GSS API although GSS API is a standard and
SASL APIs are not.<br>
<br>
In the long run, it really doesn't matter.&nbsp;&nbsp; Whenever a new mechanism
is defined, SAML or anything else, it should be defined as a GSS
mechanism.&nbsp;&nbsp; That is because all GSS mechs automatically become SASL
mechs.&nbsp;&nbsp; SASL needs to be extended to support a generic channel
bindings concept but that is something that can be proposed and added
to the SASL WG charter provided that we demonstrate its necessity.<br>
<br>
Even though I am pointing out the above, I too would prefer a direct
use of GSS for this purpose.&nbsp;&nbsp; I believe the GSS message oriented model
is better suited to incorporation in HTTP.<br>
<br>
Jeffrey Altman<br>
<br>
</body>
</html>

--------------060201030806080206020108--

--------------ms060102070004010901080107
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms060102070004010901080107--

Date: Wed, 16 Nov 2005 16:34:20 +0100
From: Leif Johansson <[email-masked]>
To: Gerald Beuchelt <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASLMechanism?
Cc: [email-masked]

Gerald Beuchelt wrote:
> I agree and go along with your assesment. The reason I brought this up
> was that I would not like to see a SASL-only mechanism, but rather see a
> GSS SAML mechanism that can then be used with SAML. I guess we are on
> the same page here?

I guess we are although I haven't really thought about the implications
for throwing a possible SAML GSS-pseudo mech into the mix. You made my
brain hurt.

	Cheers Leif

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASLMechanism?
Date: Wed, 16 Nov 2005 10:13:25 -0500
From: "Gerald Beuchelt" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5EAC0.4ABF39D6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree and go along with your assesment. The reason I brought this up =
was that I would not like to see a SASL-only mechanism, but rather see a =
GSS SAML mechanism that can then be used with SAML. I guess we are on =
the same page here?

-----Original Message-----
From: Leif Johansson [mailto:[email-masked]]
Sent: Wed 11/16/2005 9:32 AM
To: Gerald Beuchelt
Cc: [email-masked]
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?
=20

Gerald Beuchelt wrote:
> I definitively see your points for chosing SASL from a protcol =
perspective.
>=20
> However, one of the reasons I prefer GSS over SASL is the fact that =
the
> Windows Security architecture uses SSPI. If we want to make adoption
> easy for that platform and encourage interoperability, GSS would
> probably a better choice.

Its actually not one or the other - GSS (at least GSS-SPNEGO and
GSS-KRB5) are already defined as SASL mechanisms. The SASL/GSS
debate is over frameworks, not mechanisms. My summary of the debate
is:

- - I claim that the benefit of SASL over GSS (as frameworks) is
  pretty slim. I base this on the availability of SASL mechs on
  standards track which isn't already covered by existing HTTP
  authentication mechanisms (BASIC, X509 and DIGEST-MD5).

- - Nico, jaltman et al claim that SASL is as good as anything
  else and that non-standards-track mechs have to be taken into
  account aswell.

I agree with Nico: *shrug* sure whatever....

Please note though that the Microsoft-issue is yet a separate
discussion.

When designing a new http authentication mechanism it is probably
a good idea to take existing deployments into account. This is my main
argument for going with Negotiate with cbindings over anonymous tls;
this approach probably has a better chance of beeing widely deployed
since it basically already is.

	Cheers Leif

------_=_NextPart_001_01C5EAC0.4ABF39D6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6944.0">
<TITLE>RE: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I agree and go along with your assesment. The reason I =
brought this up was that I would not like to see a SASL-only mechanism, =
but rather see a GSS SAML mechanism that can then be used with SAML. I =
guess we are on the same page here?<BR>
<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Leif Johansson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Wed 11/16/2005 9:32 AM<BR>
To: Gerald Beuchelt<BR>
Cc: [email-masked]<BR>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?<BR>
<BR>
-----BEGIN PGP SIGNED MESSAGE-----<BR>
Hash: SHA1<BR>
<BR>
Gerald Beuchelt wrote:<BR>
&gt; I definitively see your points for chosing SASL from a protcol =
perspective.<BR>
&gt;<BR>
&gt; However, one of the reasons I prefer GSS over SASL is the fact that =
the<BR>
&gt; Windows Security architecture uses SSPI. If we want to make =
adoption<BR>
&gt; easy for that platform and encourage interoperability, GSS =
would<BR>
&gt; probably a better choice.<BR>
<BR>
Its actually not one or the other - GSS (at least GSS-SPNEGO and<BR>
GSS-KRB5) are already defined as SASL mechanisms. The SASL/GSS<BR>
debate is over frameworks, not mechanisms. My summary of the debate<BR>
is:<BR>
<BR>
- - I claim that the benefit of SASL over GSS (as frameworks) is<BR>
&nbsp; pretty slim. I base this on the availability of SASL mechs on<BR>
&nbsp; standards track which isn't already covered by existing HTTP<BR>
&nbsp; authentication mechanisms (BASIC, X509 and DIGEST-MD5).<BR>
<BR>
- - Nico, jaltman et al claim that SASL is as good as anything<BR>
&nbsp; else and that non-standards-track mechs have to be taken into<BR>
&nbsp; account aswell.<BR>
<BR>
I agree with Nico: *shrug* sure whatever....<BR>
<BR>
Please note though that the Microsoft-issue is yet a separate<BR>
discussion.<BR>
<BR>
When designing a new http authentication mechanism it is probably<BR>
a good idea to take existing deployments into account. This is my =
main<BR>
argument for going with Negotiate with cbindings over anonymous tls;<BR>
this approach probably has a better chance of beeing widely deployed<BR>
since it basically already is.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cheers Leif<BR>
-----BEGIN PGP SIGNATURE-----<BR>
Version: GnuPG v1.9.9 (GNU/Linux)<BR>
Comment: Using GnuPG with Thunderbird - <A =
HREF=3D"http://enigmail.mozdev.org">http://enigmail.mozdev.org</A><BR>
<BR>
iD8DBQFDe0Mb8Jx8FtbMZncRAuxkAJ0WIP2e/rJhZ06UdBpx7hPLewz7RgCff8Hj<BR>
xlZfTdrNkTjv2KSJ8Xiw40M=3D<BR>
=3Dej5R<BR>
-----END PGP SIGNATURE-----<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5EAC0.4ABF39D6--

Date: Wed, 16 Nov 2005 15:32:59 +0100
From: Leif Johansson <[email-masked]>
To: Gerald Beuchelt <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASLMechanism?
Cc: [email-masked]

Gerald Beuchelt wrote:
> I definitively see your points for chosing SASL from a protcol perspective.
> 
> However, one of the reasons I prefer GSS over SASL is the fact that the
> Windows Security architecture uses SSPI. If we want to make adoption
> easy for that platform and encourage interoperability, GSS would
> probably a better choice.

Its actually not one or the other - GSS (at least GSS-SPNEGO and
GSS-KRB5) are already defined as SASL mechanisms. The SASL/GSS
debate is over frameworks, not mechanisms. My summary of the debate
is:

- - I claim that the benefit of SASL over GSS (as frameworks) is
  pretty slim. I base this on the availability of SASL mechs on
  standards track which isn't already covered by existing HTTP
  authentication mechanisms (BASIC, X509 and DIGEST-MD5).

- - Nico, jaltman et al claim that SASL is as good as anything
  else and that non-standards-track mechs have to be taken into
  account aswell.

I agree with Nico: *shrug* sure whatever....

Please note though that the Microsoft-issue is yet a separate
discussion.

When designing a new http authentication mechanism it is probably
a good idea to take existing deployments into account. This is my main
argument for going with Negotiate with cbindings over anonymous tls;
this approach probably has a better chance of beeing widely deployed
since it basically already is.

	Cheers Leif

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASLMechanism?
Date: Wed, 16 Nov 2005 09:04:31 -0500
From: "Gerald Beuchelt" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>, "Leif Johansson" <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5EAB7.076C3958
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I definitively see your points for chosing SASL from a protcol =
perspective.=20

However, one of the reasons I prefer GSS over SASL is the fact that the =
Windows Security architecture uses SSPI. If we want to make adoption =
easy for that platform and encourage interoperability, GSS would =
probably a better choice.=20

Best,=20

Gerald

-----Original Message-----
From: [email-masked] on behalf of =
Nicolas Williams
Sent: Tue 11/15/2005 3:41 PM
To: Leif Johansson
Cc: Jeffrey Altman; [email-masked]; =
[email-masked]
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?
=20
On Tue, Nov 15, 2005 at 09:37:23PM +0100, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Nicolas Williams wrote:
> > On Tue, Nov 15, 2005 at 08:13:03PM +0100, Leif Johansson wrote:
> >=20
> >>>No fair :)  The password/MD5-based SASL mechanisms are exactly the =
ones
> >>>we'd want to have a GSS mechanism for...
> >>
> >>And exactly the ones you probably need to make historic pretty soon =
:-)
> >=20
> >=20
> > We want to reuse credentials, not necessarily the mechanism as it
> > stands.
> >=20
>=20
> Not sure how you can separate those unless you assume clear-text
> passwords... but I'll not pursue this further.
>=20
> > Alexey has agreed to add channel bindings support to MD5-DIGEST and =
what
> > not, so I think we're on the right track.
>=20
> K, cool. Since I don't see a flourish of support for using GSS =
directly
> I guess SASL it is :-)

*shrug*

I much prefer the GSS-API in general, and would rather not create more
dependencies on SASL, but I'm willing to go with SASL if need be.

Still, it seems to me that porting MD5-DIGEST to GSS shouldn't be hard
and is likely worth doing.

Nico
--=20
_______________________________________________
SAML-mechanism mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/saml-mechanism

------_=_NextPart_001_01C5EAB7.076C3958
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6944.0">
<TITLE>RE: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>I definitively see your points for chosing SASL from a =
protcol perspective.<BR>
<BR>
However, one of the reasons I prefer GSS over SASL is the fact that the =
Windows Security architecture uses SSPI. If we want to make adoption =
easy for that platform and encourage interoperability, GSS would =
probably a better choice.<BR>
<BR>
Best,<BR>
<BR>
Gerald<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: [email-masked] on behalf of =
Nicolas Williams<BR>
Sent: Tue 11/15/2005 3:41 PM<BR>
To: Leif Johansson<BR>
Cc: Jeffrey Altman; [email-masked]; =
[email-masked]<BR>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML =
SASLMechanism?<BR>
<BR>
On Tue, Nov 15, 2005 at 09:37:23PM +0100, Leif Johansson wrote:<BR>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<BR>
&gt; Hash: SHA1<BR>
&gt;<BR>
&gt; Nicolas Williams wrote:<BR>
&gt; &gt; On Tue, Nov 15, 2005 at 08:13:03PM +0100, Leif Johansson =
wrote:<BR>
&gt; &gt;<BR>
&gt; &gt;&gt;&gt;No fair :)&nbsp; The password/MD5-based SASL mechanisms =
are exactly the ones<BR>
&gt; &gt;&gt;&gt;we'd want to have a GSS mechanism for...<BR>
&gt; &gt;&gt;<BR>
&gt; &gt;&gt;And exactly the ones you probably need to make historic =
pretty soon :-)<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; We want to reuse credentials, not necessarily the mechanism as =
it<BR>
&gt; &gt; stands.<BR>
&gt; &gt;<BR>
&gt;<BR>
&gt; Not sure how you can separate those unless you assume =
clear-text<BR>
&gt; passwords... but I'll not pursue this further.<BR>
&gt;<BR>
&gt; &gt; Alexey has agreed to add channel bindings support to =
MD5-DIGEST and what<BR>
&gt; &gt; not, so I think we're on the right track.<BR>
&gt;<BR>
&gt; K, cool. Since I don't see a flourish of support for using GSS =
directly<BR>
&gt; I guess SASL it is :-)<BR>
<BR>
*shrug*<BR>
<BR>
I much prefer the GSS-API in general, and would rather not create =
more<BR>
dependencies on SASL, but I'm willing to go with SASL if need be.<BR>
<BR>
Still, it seems to me that porting MD5-DIGEST to GSS shouldn't be =
hard<BR>
and is likely worth doing.<BR>
<BR>
Nico<BR>
--<BR>
_______________________________________________<BR>
SAML-mechanism mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"https://mailman1.u.washington.edu/mailman/listinfo/saml-mechanism=
">https://mailman1.u.washington.edu/mailman/listinfo/saml-mechanism</A><B=
R>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5EAB7.076C3958--

Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
From: Scott Lawrence <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Wed, 16 Nov 2005 08:17:11 -0500
Cc: HTTP authentication list <[email-masked]>

On Tue, 2005-11-15 at 16:24 -0800, Roy T. Fielding wrote:

> HTTP Digest isn't used because the algorithm was flawed (hash
> of password instead of hash of hashed password)

Just for the record - MD5-sess mode _is_ hash of hashed password, and
could be used to define a very nice single-signon protocol.  We never
specified a protocol that the web server could use to get a session key
that was issued by an authentication service, but the MD5-sess mode
allows for it.

> , too much
> baggage was added on for the sake of non-repeatable hashes
> and message integrity, 

At the time, people seemed to think that replay and integrity protection
were important services, but then people are funny that way.

> and because a single bug in MSIE
> (truncating query args from the URI before hashing) interferes
> with deployment.  HTTP auth isn't used in general because browsers
> ignore the HTML content of the 401 message and present idiotic
> dialogs instead.

That's because the 401 messages could not specify any way to actually
replace the idiotic dialogs.  

> What we need is a simple mechanism for the server to indicate
> to the client that digest authentication is available and to
> use the included message as the input dialog.  If digest isn't
> good enough, then define an HTTP AA method that is -- just don't
> waste our time with any session-based junk.  There is
> absolutely no reason to turn HTTP into TLS or SSH when we can
> already use HTTP within a session protocol.  HTTP already has
> the Upgrade header field.

> The above is all we need for non-browser clients.  For browsers,
> it simply requires the browser developers to allow something
> in the response to indicate that the 401 message body should
> be used for UI; standard form field names could then be used
> to supply the authentication values for the client to construct
> credentials for the next HTTP request.

We tried to fix that and some other problems with a submission to W3C to
specify authentication interfaces:
http://www.w3.org/TR/1999/NOTE-authentform-19990203  but at the time
everyone was focused on simplifying HTML rather than adding to it.  Now
that there is actually a reasonable extensibility mechanism for XHTML,
it would probably be worth dusting that off.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

Date: Wed, 16 Nov 2005 00:26:44 -0600
From: Nicolas Williams <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Implementation likelihood?
Cc: HTTP authentication list <[email-masked]>

On Tue, Nov 15, 2005 at 04:24:08PM -0800, Roy T. Fielding wrote:
> >We had a great participation from security experts at the HTTP-Auth 
> >bar BOF, but not so many HTTP experts.  Is there anybody implementing 
> >HTTP, WebDAV or CalDAV, or other HTTP-based protocol, or who would be 
> >likely to implement a new security mechanism, and who can evaluate or 
> >even react to the various security proposals?
> >
> >Joe(s)? Justin? Scott? Mike? Roy? Jeff?
> 
> Not if it involves SAML or SASL.  SAML is too complicated and
> restricted by patents.  SASL is not suitable for use in
> stateless communication protocols.

Stateless or not bound to single sessions?  And what about SASL makes it
not suitable for use with those?  It's stream orientation?

The proposal to date does not involve using SASL security layers, so
SASL's stream orientation should not be an issue; and if it were then
the answer would be to use the GSS-API (which is message oriented)
instead.

> [...]
> What we need is a simple mechanism for the server to indicate
> to the client that digest authentication is available and to
> use the included message as the input dialog.  If digest isn't
> good enough, then define an HTTP AA method that is -- just don't
> waste our time with any session-based junk.  [...]

AA?  But some of us have nice authentication infrastructures like
Kerberos V and SAML identity providers that we'd like to use for
HTTP-based applications.

Nico
-- 

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Nov 2005 16:24:08 -0800
To: Lisa Dusseault <[email-masked]>
Cc: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Re: Implementation likelihood?

> We had a great participation from security experts at the HTTP-Auth 
> bar BOF, but not so many HTTP experts.  Is there anybody implementing 
> HTTP, WebDAV or CalDAV, or other HTTP-based protocol, or who would be 
> likely to implement a new security mechanism, and who can evaluate or 
> even react to the various security proposals?
>
> Joe(s)? Justin? Scott? Mike? Roy? Jeff?

Not if it involves SAML or SASL.  SAML is too complicated and
restricted by patents.  SASL is not suitable for use in
stateless communication protocols.

HTTP Digest isn't used because the algorithm was flawed (hash
of password instead of hash of hashed password), too much
baggage was added on for the sake of non-repeatable hashes
and message integrity, and because a single bug in MSIE
(truncating query args from the URI before hashing) interferes
with deployment.  HTTP auth isn't used in general because browsers
ignore the HTML content of the 401 message and present idiotic
dialogs instead.

What we need is a simple mechanism for the server to indicate
to the client that digest authentication is available and to
use the included message as the input dialog.  If digest isn't
good enough, then define an HTTP AA method that is -- just don't
waste our time with any session-based junk.  There is
absolutely no reason to turn HTTP into TLS or SSH when we can
already use HTTP within a session protocol.  HTTP already has
the Upgrade header field.

The above is all we need for non-browser clients.  For browsers,
it simply requires the browser developers to allow something
in the response to indicate that the 401 message body should
be used for UI; standard form field names could then be used
to supply the authentication values for the client to construct
credentials for the next HTTP request.

....Roy

From: "Scott Cantor" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>, "'HTTP authentication list'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Implementation likelihood?
Date: Tue, 15 Nov 2005 16:01:19 -0500
Organization: The Ohio State University

> We had a great participation from security experts at the HTTP-Auth bar 
> BOF, but not so many HTTP experts.  Is there anybody implementing HTTP, 
> WebDAV or CalDAV, or other HTTP-based protocol, or who would be likely 
> to implement a new security mechanism, and who can evaluate or even 
> react to the various security proposals?

I'm not in that group, but I can say that without these tools being amenable
to SSO, we're really seriously hobbled and I think that's true of many
campuses.

Given an actual specification for using SAML with HTTP that I could get a
server to support cleanly, I care enough that I'd probably hack on an open
source DAV library to make it work if for no other reason then to show what
needs to be done.

-- Scott

Subject: Re: [Ietf-http-auth] Implementation likelihood?
From: Scott Lawrence <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Tue, 15 Nov 2005 15:42:12 -0500
Cc: HTTP authentication list <[email-masked]>, "Roy T.Fielding" <[email-masked]>, Jeffrey Mogul <[email-masked]>

On Tue, 2005-11-15 at 12:24 -0800, Lisa Dusseault wrote:
> We had a great participation from security experts at the HTTP-Auth bar 
> BOF, but not so many HTTP experts.  Is there anybody implementing HTTP, 
> WebDAV or CalDAV, or other HTTP-based protocol, or who would be likely 
> to implement a new security mechanism, and who can evaluate or even 
> react to the various security proposals?
> 
> Joe(s)? Justin? Scott? Mike? Roy? Jeff?

Not me.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

Date: Tue, 15 Nov 2005 14:41:24 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

On Tue, Nov 15, 2005 at 09:37:23PM +0100, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Nicolas Williams wrote:
> > On Tue, Nov 15, 2005 at 08:13:03PM +0100, Leif Johansson wrote:
> > 
> >>>No fair :)  The password/MD5-based SASL mechanisms are exactly the ones
> >>>we'd want to have a GSS mechanism for...
> >>
> >>And exactly the ones you probably need to make historic pretty soon :-)
> > 
> > 
> > We want to reuse credentials, not necessarily the mechanism as it
> > stands.
> > 
> 
> Not sure how you can separate those unless you assume clear-text
> passwords... but I'll not pursue this further.
> 
> > Alexey has agreed to add channel bindings support to MD5-DIGEST and what
> > not, so I think we're on the right track.
> 
> K, cool. Since I don't see a flourish of support for using GSS directly
> I guess SASL it is :-)

*shrug*

I much prefer the GSS-API in general, and would rather not create more
dependencies on SASL, but I'm willing to go with SASL if need be.

Still, it seems to me that porting MD5-DIGEST to GSS shouldn't be hard
and is likely worth doing.

Nico
-- 

Date: Tue, 15 Nov 2005 21:37:23 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

Nicolas Williams wrote:
> On Tue, Nov 15, 2005 at 08:13:03PM +0100, Leif Johansson wrote:
> 
>>>No fair :)  The password/MD5-based SASL mechanisms are exactly the ones
>>>we'd want to have a GSS mechanism for...
>>
>>And exactly the ones you probably need to make historic pretty soon :-)
> 
> 
> We want to reuse credentials, not necessarily the mechanism as it
> stands.
> 

Not sure how you can separate those unless you assume clear-text
passwords... but I'll not pursue this further.

> Alexey has agreed to add channel bindings support to MD5-DIGEST and what
> not, so I think we're on the right track.

K, cool. Since I don't see a flourish of support for using GSS directly
I guess SASL it is :-)

	Cheers Leif

Date: Tue, 15 Nov 2005 14:28:06 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

On Tue, Nov 15, 2005 at 08:13:03PM +0100, Leif Johansson wrote:
> 
> >
> >No fair :)  The password/MD5-based SASL mechanisms are exactly the ones
> >we'd want to have a GSS mechanism for...
> 
> And exactly the ones you probably need to make historic pretty soon :-)

We want to reuse credentials, not necessarily the mechanism as it
stands.

Alexey has agreed to add channel bindings support to MD5-DIGEST and what
not, so I think we're on the right track.

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Nov 2005 12:24:47 -0800
To: HTTP authentication list <[email-masked]>
Cc: "Roy T.Fielding" <[email-masked]>, Jeffrey Mogul <[email-masked]>
Subject: [Ietf-http-auth] Implementation likelihood?

We had a great participation from security experts at the HTTP-Auth bar 
BOF, but not so many HTTP experts.  Is there anybody implementing HTTP, 
WebDAV or CalDAV, or other HTTP-based protocol, or who would be likely 
to implement a new security mechanism, and who can evaluate or even 
react to the various security proposals?

Joe(s)? Justin? Scott? Mike? Roy? Jeff?

Lisa

Date: Tue, 15 Nov 2005 20:17:58 +0100
From: Leif Johansson <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

Jeffrey Altman wrote:
> Leif Johansson wrote:
> 
>>Could you give an example of a standardized sasl mech which has no
>>corresponding gss mech and which isn't MD5-based (and thus probably
>>under very close scrutiny these days)?
>>
>>    Cheers Leif
> 
> I don't have a complete list of  SASL mechanisms nor do I have a
> complete list of GSS mechanisms so
> I cannot speak to your question.   Not all mechanisms are developed
> within the IETF.

Sorry, I worked from the assumption that only standards-track mechs are
interesting when evaluating the benefits of one framework over the
other. I can certainly see your point even If I don't agree with it.

> 
> What I can say is that the IETF Security Area would prefer a world in
> which all applications are
> developed using SASL and all mechanisms are developed using GSS.  This
> provides the maximum reuse
> of effort and flexibility.

That means either adding cbindings to SASL or not using cbindings in 
GSS. Adding cbindings to SASL would seem to depend on a possible for
re-chartering of sasl-wg and not using cbindings in GSS is not an
option.

	Cheers Leif

Date: Tue, 15 Nov 2005 20:13:03 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

> 
> No fair :)  The password/MD5-based SASL mechanisms are exactly the ones
> we'd want to have a GSS mechanism for...

And exactly the ones you probably need to make historic pretty soon :-)

	Cheers Leif

Date: Tue, 15 Nov 2005 11:19:37 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: Jeffrey Altman <[email-masked]>, [email-masked], [email-masked]

On Tue, Nov 15, 2005 at 09:46:25AM +0100, Leif Johansson wrote:
> 
> >In that case, we then end up in a world in which there are no SASL
> >mechanisms other than GSS mechanisms.  SASL then becomes an higher level
> >GSS API.
> >
> >Is this an intermediary step towards API/Protocol convergence?
> >
> >Jeffrey Altman
> 
> Could you give an example of a standardized sasl mech which has no
> corresponding gss mech and which isn't MD5-based (and thus probably
> under very close scrutiny these days)?

No fair :)  The password/MD5-based SASL mechanisms are exactly the ones
we'd want to have a GSS mechanism for...

Plain too, perhaps, but probably only as a stackable mechanism that must
be stacked over another mechanism that provides acceptor authentication
and confidentiality protection (why, that sounds like LIPKEY).

Cheers,

Nico
-- 

Date: Tue, 15 Nov 2005 12:12:35 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms030308020203090808010505
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Leif Johansson wrote:
> Could you give an example of a standardized sasl mech which has no
> corresponding gss mech and which isn't MD5-based (and thus probably
> under very close scrutiny these days)?
>
>     Cheers Leif
I don't have a complete list of  SASL mechanisms nor do I have a
complete list of GSS mechanisms so
I cannot speak to your question.   Not all mechanisms are developed
within the IETF.

What I can say is that the IETF Security Area would prefer a world in
which all applications are
developed using SASL and all mechanisms are developed using GSS.  This
provides the maximum reuse
of effort and flexibility.

Jeffrey Altman

--------------ms030308020203090808010505
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030308020203090808010505--

Date: Tue, 15 Nov 2005 09:46:25 +0100
From: Leif Johansson <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

> In that case, we then end up in a world in which there are no SASL
> mechanisms other than GSS mechanisms.  SASL then becomes an higher level
> GSS API.
> 
> Is this an intermediary step towards API/Protocol convergence?
> 
> Jeffrey Altman

Could you give an example of a standardized sasl mech which has no
corresponding gss mech and which isn't MD5-based (and thus probably
under very close scrutiny these days)?

	Cheers Leif

Date: Mon, 14 Nov 2005 16:55:14 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

On Mon, Nov 14, 2005 at 04:48:41PM -0600, Nicolas Williams wrote:
> On Mon, Nov 14, 2005 at 05:43:59PM -0500, Jeffrey Altman wrote:
> > In that case, we then end up in a world in which there are no SASL
> > mechanisms other than GSS mechanisms.  SASL then becomes an higher level
> > GSS API.
> > 
> > Is this an intermediary step towards API/Protocol convergence?
> 
> It's an independent step.

Wrong word.  Not "independent" but also not "intermediary."  It is a
necessary step towards convergence but none of the other steps depend on
it.

Date: Mon, 14 Nov 2005 16:48:41 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

On Mon, Nov 14, 2005 at 05:43:59PM -0500, Jeffrey Altman wrote:
> Nicolas Williams wrote:
> > On Fri, Nov 11, 2005 at 02:11:34AM +0100, Leif Johansson wrote:
> > 
> > Exactly.
> > 
> > Note that if we do go in this direction and choose the GSS-API then
> > we'll probably want to "port" some SASL non-GSS mechanisms to the
> > GSS-API so we can use those credentials here.
> > 
> > Nico
> 
> In that case, we then end up in a world in which there are no SASL
> mechanisms other than GSS mechanisms.  SASL then becomes an higher level
> GSS API.
> 
> Is this an intermediary step towards API/Protocol convergence?

It's an independent step.

The GUAM effort proposes (it's not dead) to deal with EAP/GSS
convergence as SASL/GSS convergence is a simpler problem because SASL
already has a bridge to GSS mechanisms.

Nico
-- 

Date: Mon, 14 Nov 2005 17:43:59 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?
Cc: [email-masked], [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms070705040705040804060407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Nicolas Williams wrote:
> On Fri, Nov 11, 2005 at 02:11:34AM +0100, Leif Johansson wrote:
> 
> Exactly.
> 
> Note that if we do go in this direction and choose the GSS-API then
> we'll probably want to "port" some SASL non-GSS mechanisms to the
> GSS-API so we can use those credentials here.
> 
> Nico

In that case, we then end up in a world in which there are no SASL
mechanisms other than GSS mechanisms.  SASL then becomes an higher level
GSS API.

Is this an intermediary step towards API/Protocol convergence?

Jeffrey Altman

--------------ms070705040705040804060407
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070705040705040804060407--

Date: Mon, 14 Nov 2005 22:42:59 +0100
From: Leif Johansson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
Cc: HTTP authentication list <[email-masked]>

> 
> Does 
> <http://www.ietf.org/internet-drafts/draft-jaganathan-kerberos-http-01.txt> 
> fit into this mess anywhere?
> 

Personally I'd say yes, however you need to fix some things. First
Negotiate doesn't authenticate the server so you need to run it over
a secure channel - for instance http. That presents a bit of a problem
since you a) don't have a binding between the GSS-layer and the TLS-
layer and b) since you have to deploy two infrastructures - certs and
the infrastructure required by your GSS mech.

A possible solution is to use anonymous tls (or btns for that matter)
with channel-bindings to the underlying Negotiate layer. This would
satisfy most requirements stated except for one - you can't start with
a plain http 1.1 session and then decide to start using Negotiate since
http authentication mechanisms are decided at the beginning of the
session.

Personally I find this requirement a bit silly since most webbapp 
developers had to learn to deal with this situation long ago; when you
need authentication you redirect to a separate URL where authentication
is required.

	Cheers Leif

Date: Mon, 14 Nov 2005 14:57:44 -0500
From: Cyrus Daboo <[email-masked]>
To: Leif Johansson <[email-masked]>, Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
Cc: HTTP authentication list <[email-masked]>

Hi Leif,

--On November 14, 2005 8:18:29 PM +0100 Leif Johansson <[email-masked]> 
wrote:

>> Right. If you did that, you would want to reconsider the over
>> http/parallel decision, since GSS often has its own transport,
>> right?
>
> No... GSS is an abstract request-response token framework. As long
> as your protocol can encode and send a gss token (which is represented in
> the API layer as an octet buffer+length) you can use GSS much like you
> would use SASL from a protocol-integration perspective.
>
> Let me present a provocative argument for GSS instead of SASL: Apart
> from DIGEST-MD5 the most widely implemented and deployed SASL mech
> seems to be GSS. For HTTP this means that the only thing SASL adds to
> the mix is GSS (since DISEST is already specified for HTTP).l

Does 
<http://www.ietf.org/internet-drafts/draft-jaganathan-kerberos-http-01.txt> 
fit into this mess anywhere?

-- 
Cyrus Daboo

Date: Mon, 14 Nov 2005 20:18:29 +0100
From: Leif Johansson <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
Cc: HTTP authentication list <[email-masked]>

>>2.  It is definitely worth discussing whether the plan should be built
>>on the GSS framework rather than the SASL framework as the strawman is.
> 
> 
> Right. If you did that, you would want to reconsider the over
> http/parallel decision, since GSS often has its own transport,
> right?

No... GSS is an abstract request-response token framework. As long
as your protocol can encode and send a gss token (which is represented 
in the API layer as an octet buffer+length) you can use GSS much like 
you would use SASL from a protocol-integration perspective.

Let me present a provocative argument for GSS instead of SASL: Apart
from DIGEST-MD5 the most widely implemented and deployed SASL mech
seems to be GSS. For HTTP this means that the only thing SASL adds to
the mix is GSS (since DISEST is already specified for HTTP).l

One might argue that using SASL gives implementors a way to leverage
components from existing SASL-enabled protocols - i.e if you implement
HTTP and IMAP - This is a valid argument but should be valued by looking
at how many only implement non-GSS SASL mechs. To me this feels like a
very thin argument for SASL over GSS.

	Cheers Leif

From: "Scott Cantor" <[email-masked]>
To: "'Eric Rescorla'" <[email-masked]>
Subject: RE: [Ietf-http-auth] summarize dinner-bof?
Date: Mon, 14 Nov 2005 12:38:42 -0500
Organization: The Ohio State University
Cc: 'HTTP authentication list' <[email-masked]>

> Right. If you did that, you would want to reconsider the over
> http/parallel decision, since GSS often has its own transport,
> right?

Isn't this sort of assuming that the existing mechanisms are the ones of
actual interest in doing all this? I would say in fact that it's potential
new mechanisms that are suited to distributed web-based authentication that
are interesting here (i.e. nothing involving a password is particularly
helpful, for example, otherwise we'd just use basic-auth and make life
simpler for ourselves).

So a useful question might be whether the mechanisms of actual interest to
deployers would have their own transport. I would think not, but I'm not
sure which mechanisms do now. I got the impression at one point that
Kerberos supposedly does, but that makes no sense to me, so I doubt I
understand the word "transport" in this context.

-- Scott

To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof? 
Date: Mon, 14 Nov 2005 09:28:25 -0800
From: Eric Rescorla <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

RL 'Bob' Morgan <[email-masked]> wrote:

> 
> Thanks, Eric.
> 
> I think Eric's note takes care of the dinner summary action item,
> since the dinner discussion more or less led to the strawman design.
> 
> Let me quickly note these things:
> 
> 1.  In the dinner discussion, and I think this is reflected in the
> strawman, HTTP proxy considerations were left out because it made
> everyone's brain hurt.  Putting them back in again is definitely
> needed, though I don't know enough about what the desiderata are for
> them to know what the effect of this would be.

Right. The key question here is how to carry the channel binding
over multiple HTTP options. Ouch.

> 2.  It is definitely worth discussing whether the plan should be built
> on the GSS framework rather than the SASL framework as the strawman is.

Right. If you did that, you would want to reconsider the over
http/parallel decision, since GSS often has its own transport,
right?

> 3.  I think there is more to the overall subject than the approach in
> the strawman.  In particular making forms authentication more
> non-browser-friendly would be very useful IMHO.

The obvious thing to do here is some sort of HTML "standard" for
representing this info. This sounds like a lot of fun. Not.

-Ekr

Date: Mon, 14 Nov 2005 08:02:37 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof? 

Thanks, Eric.

I think Eric's note takes care of the dinner summary action item, since 
the dinner discussion more or less led to the strawman design.

Let me quickly note these things:

1.  In the dinner discussion, and I think this is reflected in the 
strawman, HTTP proxy considerations were left out because it made 
everyone's brain hurt.  Putting them back in again is definitely needed, 
though I don't know enough about what the desiderata are for them to know 
what the effect of this would be.

2.  It is definitely worth discussing whether the plan should be built on 
the GSS framework rather than the SASL framework as the strawman is.

3.  I think there is more to the overall subject than the approach in the 
strawman.  In particular making forms authentication more 
non-browser-friendly would be very useful IMHO.

  - RL "Bob"

Date: Mon, 14 Nov 2005 09:21:13 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: "Diego R. Lopez" <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
Cc: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms020901090909060805080106
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Diego R. Lopez wrote:
> Hi,
> 
>> So, this analysis gives us the strawman that I mentioned in YVR:
>>
>> 1. SASL/TLS with channel bindings to establish an initial authentication.
>> 2. Cookies (maybe with a name change) for state management.
>> 3. Cookies to be bound to the TLS credentials of the server.
> 
> After a quick view at the proposal, I'd say it sounds reasonable
> (including the name change for the cookies), but there is an
> objection I've read a couple of times about not good enough channel
> bindings for TLS. I must confess I have no elements to make an
> opinion on it... What do you think?
> 

I do not believe the channel bindings are an area of concern.
The channel bindings for TLS can be defined as the concatenation
of the client and server finished messages.

What I would like to have clarified is, at what layer is SASL/TLS
being negotiated?  Is this traffic being negotiated below the HTTP
data stream or within the HTTP data stream?

Jeffrey Altman

--------------ms020901090909060805080106
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms020901090909060805080106--

Date: Mon, 14 Nov 2005 14:20:55 +0100
From: "Diego R. Lopez" <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
OpenPGP: id=B8CD62D1; url=http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xB8CD62D1
Cc: [email-masked]

Hi,

> So, this analysis gives us the strawman that I mentioned in YVR:
> 
> 1. SASL/TLS with channel bindings to establish an initial authentication.
> 2. Cookies (maybe with a name change) for state management.
> 3. Cookies to be bound to the TLS credentials of the server.

After a quick view at the proposal, I'd say it sounds reasonable
(including the name change for the cookies), but there is an
objection I've read a couple of times about not good enough channel
bindings for TLS. I must confess I have no elements to make an
opinion on it... What do you think?

-- 
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Red.es - RedIRIS
The Spanish NREN

e-mail: [email-masked]
jid:    [email-masked]
Tel:    +34 955 056 621
Mobile: +34 669 898 094
-----------------------------------------

To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof? 
Date: Sun, 13 Nov 2005 17:09:09 -0800
From: Eric Rescorla <[email-masked]>
Cc: [email-masked]

Here's my analysis of the situation.

The basic problem statement here is how to enable the use of a broad
range of authentication technologies (hereafter to be called SASL) with
HTTP and HTTP-based applications. This presents two major challenges:

1. Integrating SASL with HTTP.
2. State management.

Integrating SASL with HTTP
--------------------------
The basic problem with integrating SASL with HTTP is that SASL
per se (as opposed to specific mechanisms) has no generic support
for data protection. This may not be a problem in specific environments,
but in general it's probably attractive to be planning for a future
in which we want to at least provide traffic confidentiality and
probably provide message integrity. This either implies the provision
of a security layer for each SASL mechanism to be used or the use
of something like TLS. I prefer the latter for a number of reasons, not
least of which that I believe it minimizes engineering effort.

The naive way to use SASL with HTTPS is simply to do what Web sites
in general do: perform authentication over TLS and trust the TLS
channel. The problem with this design is that unless the client
authenticates the server, it is susceptible to active attack 
(MITM the TLS connection and then proxy the authentication)
Since it's desirable not to require the server to have a 3rd-party
certificate, this is not that attractive.

There are two potential solutions to this problem:

1. Use a channel binding.
2. Have the SASL mechanism emit a key which can be used to 
   authenticate TLS in PSK mode.

Each of these has attractive features. The channel binding does not
require that the SASL authentication mechanism actually produce
a key, which some do not (though note that it still won't work 
with mechanisms like OTP that don't have a cryptographic handshake).
It also lets you use HTTP to transport your authentication data,
which means you don't need auxiliary transport. This is attractive
for mechanisms like Digest that don't have transport built-in,
though unnecessary with something like Kerberos, which is capable
of establishing its own security association.

The PSK mode has the advantage that it totally avoids changing
HTTP to transport your SASL-type handshake. You just do whatever
external authentication you need and then feed the PSK to TLS. It's
also a looser coupling, so if, for instance, you were using EAP
over some other transport you could feed that key to TLS. Indeed,
that's one objective for TLS-PSK.

All that said, Digest (or CRAM-MD5) is probably the most important
SASL mechanism and since those need to have transport provided, this
kind of pushes us down the first path. (Note, though, that it's 
arguable that you could just use HTTP Digest in this case).

State Management
----------------
The basic problem with grafting any new authentication mechanism
onto HTTP is that HTTP sessions span multiple fetches and multiple
TCP connections. Because SASL basically assumes that connections
are long-lived, this is a poor fit. You certainly don't want to
have to key in your SecureID value every time your browser does
a fetch. This all necessitates some mechanism to span multiple
connections. The standard HTTP mechanism for this is cookies.

There are two major problems with cookies. The first is that they
have bad PR. That's easily solved by a name change.... The second
is that they're subject to passive attacks (a cookie is basically
a reusable password after all). This is solved by using TLS.

One problem that presents itself here is that if you've used SASL with a
channel binding to let you use TLS without a 3rd party certificate, it's
a shame to throw that away in your state management.  The simple fix for
that is for the client to record the public key/cert/whatever of the
server when it installs a cookie and not resend that cookie if the
key changes. No need to do any SSH warning-type stuff here. Just
discard the cookie silently. At worst this forces a re-authentication
which users are used to...

Note that one advantage of the PSK strategy mentioned above is that 
you don't need any explicit state management. You can just use the
PSK repeatedly.

Strawman and Analysis
---------------------
So, this analysis gives us the strawman that I mentioned in YVR:

1. SASL/TLS with channel bindings to establish an initial authentication.
2. Cookies (maybe with a name change) for state management.
3. Cookies to be bound to the TLS credentials of the server.

It's worth noting the limitations of this approach. Part (1) only
works with mechanisms which actually do some crypto (leaving out
SecureID, OTP, plain). It's kind of unnecessary with mechanisms
that have their own transport and can emit a key. The most
important mechanism that falls into this category is Digest, which
we could replicate with default HTTP without any complicated state
management stuff. 

Given this, do people feel that this is of sufficient utility to proceed
with?

Date: Fri, 11 Nov 2005 13:03:46 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?

On Fri, Nov 11, 2005 at 02:11:34AM +0100, Leif Johansson wrote:
> 
> >
> >I have talked to people who were at the meeting who didn't fully 
> >understand this and didn't seem to like the outcome.... This, however
> >must certainly be out of scope for this group.
> >
> >    Cheers Leif
> 
> To clarify - I don't object to the idea of using a pluggable mechanism
> to authenticate the user and combine that with cbindings and tls, I
> sorta object to introducing SASL to a protocol that hasn't already been
> so blessed. Imo Negotiate(+fixes)+cbindings+anonymous tls fits the bill
> and is cleaner (and also has the benefit of beeing quite close to the 
> currently deployed Negotiate mechanism).
> 
> The case for SASL is getting thin these days (imo) when the only widely
> deployed (?) mechanism (DIGEST-MD5) is under some amount of question in
> the light of recent developments. Any new shared-secred mechanism could
> just as well be written in the form of a gss-mech.
> 
> Nico and me just discussed this and we both agree that from 10k feet
> the sasl+tls+cbindings strawman looks sufficiently much like a 
> negotiate+tls+cbindings strawman and we both agree that this the rough
> way to proceed.

Exactly.

Note that if we do go in this direction and choose the GSS-API then
we'll probably want to "port" some SASL non-GSS mechanisms to the
GSS-API so we can use those credentials here.

Nico
-- 

Date: Fri, 11 Nov 2005 02:11:34 +0100
From: Leif Johansson <[email-masked]>
To: Leif Johansson <[email-masked]>
Cc: [email-masked], [email-masked], Nicolas Williams <[email-masked]>
Subject: [Ietf-http-auth] Re: [SAML-mechanism] RE: as in SAML SASL Mechanism?

> 
> I have talked to people who were at the meeting who didn't fully 
> understand this and didn't seem to like the outcome.... This, however
> must certainly be out of scope for this group.
> 
>     Cheers Leif

To clarify - I don't object to the idea of using a pluggable mechanism
to authenticate the user and combine that with cbindings and tls, I
sorta object to introducing SASL to a protocol that hasn't already been
so blessed. Imo Negotiate(+fixes)+cbindings+anonymous tls fits the bill
and is cleaner (and also has the benefit of beeing quite close to the 
currently deployed Negotiate mechanism).

The case for SASL is getting thin these days (imo) when the only widely
deployed (?) mechanism (DIGEST-MD5) is under some amount of question in
the light of recent developments. Any new shared-secred mechanism could
just as well be written in the form of a gss-mech.

Nico and me just discussed this and we both agree that from 10k feet
the sasl+tls+cbindings strawman looks sufficiently much like a 
negotiate+tls+cbindings strawman and we both agree that this the rough
way to proceed.

	Cheers Leif

Date: Wed, 9 Nov 2005 13:52:24 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] summarize dinner-bof?
Cc: [email-masked]

I am intending to do so, but maybe not until Friday.  Others welcome to 
offer their versions, of course.

As a one-sentence no-doubt-only-semi-accurate summary:  we sketched out a 
way to integrate the SASL framework into HTTP (a rather different way than 
draft-nystrom-http-sasl-12.txt), relying on the authentication mechanism 
to provide material for channel binding in TLS, and relying on cookies (or 
perhaps some more focused cookie-like mechanism) for state management of 
the resulting session (which might of course span not only TCP connections 
but TLS sessions).

  - RL "Bob"

On Wed, 9 Nov 2005, Leif Johansson wrote:

>
> Maybe someone could summarize the outcome (as it was) of the
> dinner-bof last night? It felt like there was some level of
> agreement (at least where people could hear what was going on :-) )
> around a strawman from Eric.
>
> 	Cheers Leif

Date: Wed, 09 Nov 2005 22:18:00 +0100
From: Leif Johansson <[email-masked]>
To: [email-masked]
Subject: [Ietf-http-auth] summarize dinner-bof?

Maybe someone could summarize the outcome (as it was) of the
dinner-bof last night? It felt like there was some level of
agreement (at least where people could hear what was going on :-) )
around a strawman from Eric.

	Cheers Leif

From: "Scott Cantor" <[email-masked]>
To: "'Jeffrey Altman'" <[email-masked]>, <[email-masked]>
Subject: RE: [Ietf-http-auth] Whay is caldav special?
Date: Mon, 7 Nov 2005 22:00:50 -0500
Organization: The Ohio State University

> What the sites are trying to avoid is the use of TLS for protecting
> marketing data and all of the links users might choose other than the
> login operation.  It is interesting to note that Citigroup only began
> to redirect http://www.citicard.com to a TLS protected web page in the
> last two months.

That is distinct from what I was talking about, and not unusual here. I
wouldn't see that as an argument against basic-auth though.

> > The usual arguments here against SSL tend to be cost. And that's also no
> > longer an issue with the rise of $14.95 certificates.
> 
> The cost they are attempting to avoid is not the certificate cost.  It
> is the performance hit on the edge devices and their servers.

I was referring to the arguments I get here, meaning at Ohio State. And it's
rarely about capacity here, it's always "the certs are too expensive". Maybe
that's not others' experience, but it is mine.

> I believe this is true.  It should be clear that I am not saying that
> these are real problems.   I am pointing out that these are beliefs that
> others hold.

Sure. I think it's starting to change though.

-- Scott

Date: Mon, 07 Nov 2005 18:55:22 -0800
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: [email-masked]
Subject: Re: [Ietf-http-auth] Whay is caldav special?

This is a cryptographically signed message in MIME format.

--------------ms010509050702020601020301
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Scott Cantor wrote:
>>> * Transmitting all page data over TLS puts too great a load on the
>>>  servers.   Using a form allows just the form submission to be made
>>>  over TLS.  This allows logon forms to be embedded as part of public
>>>  multi-purpose web pages
>> I've never understood this argument, since I always thought the vast 
>> majority of CPU hit is in the initial TLS establishment, not the stream 
>> protection, but I agree that people make the argument.
> 
> I don't understand it because it means the actual protection of the
> application reduces to a cookie that's exposed over an insecure channel,
> which means the initial authentication itself starts to look rather
> pointless. I have a pretty firm strategy here about making people asking to
> limit the use of TLS feel somewhat silly about it.

Scott and Bob,

I think I have not communicated this properly.   Sites such as
http://www.mbna.com/ choose not to transmit the username / password form
over TLS but they do perform the form POST over TLS and proceed to
transmit all subsequent data across TLS.

What the sites are trying to avoid is the use of TLS for protecting
marketing data and all of the links users might choose other than the
login operation.  It is interesting to note that Citigroup only began
to redirect http://www.citicard.com to a TLS protected web page in the
last two months.

> The usual arguments here against SSL tend to be cost. And that's also no
> longer an issue with the rise of $14.95 certificates.

The cost they are attempting to avoid is not the certificate cost.  It
is the performance hit on the edge devices and their servers.

> Any web site with the need for lots of capacity for TLS has it because
> they're clustered mission-critical services. The rest are so light in load
> that it doesn't matter. I think the rise of 3Ghz commodity CPUs has pretty
> much killed the "TLS is too slow" argument.

I believe this is true.  It should be clear that I am not saying that
these are real problems.   I am pointing out that these are beliefs that
others hold.

Jeffrey Altman

--------------ms010509050702020601020301
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010509050702020601020301--

Subject: Re: [Ietf-http-auth] Whay is caldav special?
From: Scott Lawrence <[email-masked]>
To: RL 'Bob' Morgan <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Mon, 07 Nov 2005 18:22:01 -0800
Cc: Jeffrey Altman <[email-masked]>, [email-masked]

On Mon, 2005-11-07 at 15:44 -0800, RL 'Bob' Morgan wrote:
> On Fri, 30 Sep 2005, Jeffrey Altman wrote:
> 
> > Then let's start a list of the reasons why sites use forms instead of 
> > HTTP AUTH:

> > * Using forms places all of the control in the hands of the web site
> >  designer.  The choice of web server, its support for HTTP
> >  authentication, and the APIs to access it can be abstracted out of
> >  the equation.
> 
> This is I think the really big one.  Apps deployers like the web because 
> web pages can be whatever they want to be.  A institutional "weblogin" 
> page can have links to helpdesk info, institutional branding, hooks to 
> things like virus checkers, info about what SSO means, etc.  Or, the login 
> form can be just a part of an app site's main info-rich front page, as it 
> is for most corporate sites these days.
> 
> Now it's true that these pages could replace the username/password fields 
> in these forms with a button that would invoke basic or digest, and still 
> get the benefit of all the web page content.  But I think sites would 
> regard this as a step backwards in a couple of ways.  One is that they 
> regard the browser-popped-up username/password dialog as being an inferior 
> (or at least less site-controlled) user experience (in fact I think a case 
> could be made that most web site designers would prefer never to have 
> browser-controlled UI in the user experience if possible ...).  The other 
> is that they strongly prefer cookies for authentication state maintenance 
> rather than http-auth's replay methods, again because the web site has 
> control over the cookies.

Tried to fix that one years ago...
  http://www.w3.org/TR/1999/NOTE-authentform-19990203

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

From: "Scott Cantor" <[email-masked]>
To: "'RL 'Bob' Morgan'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Whay is caldav special?
Date: Mon, 7 Nov 2005 20:24:16 -0500
Organization: The Ohio State University
Cc: [email-masked]

> > * Transmitting all page data over TLS puts too great a load on the
> >  servers.   Using a form allows just the form submission to be made
> >  over TLS.  This allows logon forms to be embedded as part of public
> >  multi-purpose web pages
> 
> I've never understood this argument, since I always thought the vast 
> majority of CPU hit is in the initial TLS establishment, not the stream 
> protection, but I agree that people make the argument.

I don't understand it because it means the actual protection of the
application reduces to a cookie that's exposed over an insecure channel,
which means the initial authentication itself starts to look rather
pointless. I have a pretty firm strategy here about making people asking to
limit the use of TLS feel somewhat silly about it.

The usual arguments here against SSL tend to be cost. And that's also no
longer an issue with the rise of $14.95 certificates.

Any web site with the need for lots of capacity for TLS has it because
they're clustered mission-critical services. The rest are so light in load
that it doesn't matter. I think the rise of 3Ghz commodity CPUs has pretty
much killed the "TLS is too slow" argument.

> But to step back a pace:  I am inclined to think that setting a goal of 
> replacing forms/cookies for browser user signon is like putting the 
> toothpaste back in the tube (or more accurately like putting it back in a 
> billion tubes).  The myriad web signon schemes are devoted to making 
> form-based signon acceptable by reducing the amount that it has to be 
> done.  If improving the authentication capabilities of HTTP-using 
> non-browsers also helps browsers that would be great, but making it a 
> primary goal seems like asking for frustration.

I think it's a case of building it for one class of clients, and then
letting the market take over. If it's a superior experience because it gives
us other advantages, then web sites (or web sign-on systems) will evolve to
take advantage naturally.

> In fact one possible solution path for webdav/caldav/app-clients (not 
> necessarily the one I'd advocate, but possible) is to specify that such 
> implementations should have enough browser features so that they could 
> handle form-based login and the rest of the signon machinery sites use 
> with it (redirects, cookies, etc).  This would be more or less what people

> mean when they say "making these clients compatible with federated 
> authentication".

Maybe, in the sense that federated authentication protocols today are
basically browser-centric, but I wouldn't want to limit the discussion to
that and assume that the federation standards wouldn't be willing to meet
folks halfway on this.

Of course, on the service/resource end, I don't think anything but cookies
is realistic, or at least something that ends up pretty much identical to
them anyway. Though it would obviously be pretty cool to end up with a state
token that wasn't so prone to theft and reuse.

-- Scott

Date: Mon, 7 Nov 2005 15:44:59 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
Cc: [email-masked]

On Fri, 30 Sep 2005, Jeffrey Altman wrote:

> Then let's start a list of the reasons why sites use forms instead of 
> HTTP AUTH:
>
> * Transmitting all page data over TLS puts too great a load on the
>  servers.   Using a form allows just the form submission to be made
>  over TLS.  This allows logon forms to be embedded as part of public
>  multi-purpose web pages

I've never understood this argument, since I always thought the vast 
majority of CPU hit is in the initial TLS establishment, not the stream 
protection, but I agree that people make the argument.

> * Username/Password pairs can be passed along to back end servers so
>  that they can be used to obtain additional credential forms that do
>  not require additional re-transmission such as Kerberos tickets.

Presumably this can be done with Basic too.  In fact most forms of 
"better" authentication that I might like to use with HTTP don't have the 
intermediate-gets-password feature.  So while this point is true I don't 
think it's relevant to the issue we're raising here.

> * Using forms places all of the control in the hands of the web site
>  designer.  The choice of web server, its support for HTTP
>  authentication, and the APIs to access it can be abstracted out of
>  the equation.

This is I think the really big one.  Apps deployers like the web because 
web pages can be whatever they want to be.  A institutional "weblogin" 
page can have links to helpdesk info, institutional branding, hooks to 
things like virus checkers, info about what SSO means, etc.  Or, the login 
form can be just a part of an app site's main info-rich front page, as it 
is for most corporate sites these days.

Now it's true that these pages could replace the username/password fields 
in these forms with a button that would invoke basic or digest, and still 
get the benefit of all the web page content.  But I think sites would 
regard this as a step backwards in a couple of ways.  One is that they 
regard the browser-popped-up username/password dialog as being an inferior 
(or at least less site-controlled) user experience (in fact I think a case 
could be made that most web site designers would prefer never to have 
browser-controlled UI in the user experience if possible ...).  The other 
is that they strongly prefer cookies for authentication state maintenance 
rather than http-auth's replay methods, again because the web site has 
control over the cookies.

But to step back a pace:  I am inclined to think that setting a goal of 
replacing forms/cookies for browser user signon is like putting the 
toothpaste back in the tube (or more accurately like putting it back in a 
billion tubes).  The myriad web signon schemes are devoted to making 
form-based signon acceptable by reducing the amount that it has to be 
done.  If improving the authentication capabilities of HTTP-using 
non-browsers also helps browsers that would be great, but making it a 
primary goal seems like asking for frustration.

In fact one possible solution path for webdav/caldav/app-clients (not 
necessarily the one I'd advocate, but possible) is to specify that such 
implementations should have enough browser features so that they could 
handle form-based login and the rest of the signon machinery sites use 
with it (redirects, cookies, etc).  This would be more or less what people 
mean when they say "making these clients compatible with federated 
authentication".

  - RL "Bob"

Date: Mon, 7 Nov 2005 02:27:47 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] caldav/webdav/http authentication bar BoF at IETF 64

> So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify 
> WG slot.  There is a XML-Patch-Ops BOF in that slot that might be an 
> overlap for some interested parties (not for me), or maybe others. 
> Dinner that evening, post-19:50, might be another alternative.

Looks like dinner is the best bet, perhaps with a rendezvous later for 
Jeffrey and any others who already have dinner plans.  Let's meet by the 
reg desk at 19:50 and go from there.

  - RL "Bob"

To: HTTP authentication list <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Sun, 6 Nov 2005 08:17:00 -0800
Subject: [Ietf-http-auth] Fwd: Correction: RFC 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2

--Apple-Mail-3-515281746
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

This is informational, but we should take a close look anyway

Lisa

Begin forwarded message:

> From: [email-masked]
> Date: November 4, 2005 5:53:22 PM PST
> To: [email-masked]
> Cc: [email-masked]
> Subject: Correction: RFC 4169 Hypertext Transfer Protocol (HTTP) 
> Digest Authentication Using Authentication and Key Agreement (AKA) 
> Version-2
>
>
> A new Request for Comments is now available in online RFC libraries.
>
>
>         RFC 4169
>
>         Title:      Hypertext Transfer Protocol (HTTP) Digest
>                     Authentication Using Authentication and Key
>                     Agreement (AKA) Version-2
>         Author(s):  V. Torvinen, J. Arkko, M. Naslund
>         Status:     Informational
>         Date:       November 2005
>         Mailbox:    [email-masked],
>                     [email-masked], [email-masked]
>         Pages:      13
>         Characters: 26429
>         Updates/Obsoletes/SeeAlso:    None
>
>         I-D Tag:    draft-torvinen-http-digest-aka-v2-02.txt
>
>         URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4169.txt
>
>
> HTTP Digest, as specified in RFC 2617, is known to be vulnerable to
> man-in-the-middle attacks if the client fails to authenticate the
> server in TLS, or if the same passwords are used for authentication
> in some other context without TLS.  This is a general problem that
> exists not just with HTTP Digest, but also with other IETF protocols
> that use tunneled authentication.  This document specifies version 2
> of the HTTP Digest AKA algorithm (RFC 3310).  This algorithm can be
> implemented in a way that it is resistant to the man-in-the-middle
> attack.
>
> This memo provides information for the Internet community.  It does
> not specify an Internet standard of any kind.  Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to [email-masked].  Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to [email-masked].
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to [email-masked] with the message body
> help: ways_to_get_rfcs.  For example:
>
>         To: [email-masked]
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to [email-masked].  
> Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
>
> Submissions for Requests for Comments should be sent to
> [email-masked].  Please consult RFC 2223, Instructions to 
> RFC
> Authors, for further information.
>
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

--Apple-Mail-3-515281746
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

This is informational, but we should take a close look anyway 

Lisa

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>November 4, 2005 5:53:22 PM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Cc:
</color></bold>[email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>Correction:
RFC 4169 Hypertext Transfer Protocol (HTTP) Digest Authentication
Using Authentication and Key Agreement (AKA) Version-2

</bold>

A new Request for Comments is now available in online RFC libraries.

        RFC 4169

        Title:      Hypertext Transfer Protocol (HTTP) Digest

                    Authentication Using Authentication and Key

                    Agreement (AKA) Version-2

        Author(s):  V. Torvinen, J. Arkko, M. Naslund

        Status:     Informational

        Date:       November 2005

        Mailbox:    [email-masked],

                    [email-masked], [email-masked]

        Pages:      13

        Characters: 26429

        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-torvinen-http-digest-aka-v2-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4169.txt

HTTP Digest, as specified in RFC 2617, is known to be vulnerable to

man-in-the-middle attacks if the client fails to authenticate the

server in TLS, or if the same passwords are used for authentication

in some other context without TLS.  This is a general problem that

exists not just with HTTP Digest, but also with other IETF protocols

that use tunneled authentication.  This document specifies version 2

of the HTTP Digest AKA algorithm (RFC 3310).  This algorithm can be

implemented in a way that it is resistant to the man-in-the-middle

attack.

This memo provides information for the Internet community.  It does

not specify an Internet standard of any kind.  Distribution of this

memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.

Requests to be added to or deleted from the IETF distribution list

should be sent to [email-masked].  Requests to be

added to or deleted from the RFC-DIST distribution list should

be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending

an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs.  For example:

        To: [email-masked]

        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the

author of the RFC in question, or to [email-masked]. 
Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

Submissions for Requests for Comments should be sent to

[email-masked].  Please consult RFC 2223, Instructions to
RFC

Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza

USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 

implementation to automatically retrieve the ASCII version

of the RFCs.

Content-Type: text/plain

Content-ID: <<[email-masked]>

_______________________________________________

IETF-Announce mailing list

[email-masked]

https://www1.ietf.org/mailman/listinfo/ietf-announce

</excerpt>
--Apple-Mail-3-515281746--

Subject: Re: [Ietf-http-auth] caldav/webdav/http authentication bar BoF at IETF 64
From: Scott Lawrence <[email-masked]>
To: RL 'Bob' Morgan <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Sat, 05 Nov 2005 08:27:48 -0500
Cc: HTTP authentication list <[email-masked]>, Calconnect Authenticate TC <[email-masked]>

On Fri, 2005-11-04 at 14:12 -0800, RL 'Bob' Morgan wrote:
> Let me first apologize for not having helped the conversation keep going 
> on the ietf-http-auth list after stirring up this issue in the first 
> place.  I will attempt to provide more fodder for discussion shortly.
> 
> However, what I would really like to do is find a time for folks to meet 
> at IETF 64 in Vancouver next week to chat about this issue and see if 
> there is concrete work to be done on it.
> 
> I know many of the calendar-oriented folks are only around Monday and some 
> of Tuesday, so it probably has to be on those days.
> 
> So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify WG 
> slot.  There is a XML-Patch-Ops BOF in that slot that might be an overlap 
> for some interested parties (not for me), or maybe others.  Dinner that 
> evening, post-19:50, might be another alternative.

I certainly would like to do both, so the after alternative works better
for me.  Tuesday after the scheduled sessions would also be ok.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX

To: "RL 'Bob' Morgan" <[email-masked]>
From: [email-masked]
Date: Fri, 4 Nov 2005 18:09:42 -0500
Cc: HTTP authentication list <[email-masked]>, Calconnect Authenticate TC <[email-masked]>, [email-masked]
Subject: [Ietf-http-auth] Re: [tc-authenticate-l] caldav/webdav/http authentication bar BoF at IETF 64

This is a multipart message in MIME format.
--=_alternative 007F3B00852570AF_=
Content-Type: text/plain; charset="US-ASCII"

I vote for the post 19:50 dinner option.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

"RL 'Bob' Morgan" <[email-masked]> 
Sent by: [email-masked]
11/04/2005 05:12 PM

To
HTTP authentication list <[email-masked]>
cc
Calconnect Authenticate TC <[email-masked]>
Subject
[tc-authenticate-l] caldav/webdav/http authentication bar BoF at IETF 64

Let me first apologize for not having helped the conversation keep going 
on the ietf-http-auth list after stirring up this issue in the first 
place.  I will attempt to provide more fodder for discussion shortly.

However, what I would really like to do is find a time for folks to meet 
at IETF 64 in Vancouver next week to chat about this issue and see if 
there is concrete work to be done on it.

I know many of the calendar-oriented folks are only around Monday and some 

of Tuesday, so it probably has to be on those days.

So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify WG 
slot.  There is a XML-Patch-Ops BOF in that slot that might be an overlap 
for some interested parties (not for me), or maybe others.  Dinner that 
evening, post-19:50, might be another alternative.

So if you'd like attend, let me know what time works for you and I'll try 
to optimize.

Feel free to let other interested/useful folks know about this.

  - RL "Bob"

--=_alternative 007F3B00852570AF_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">I vote for the post 19:50 dinner option.</font>
<br><font size=2 face="sans-serif">___________________<br>
Patricia Egen Consulting<br>
www.egenconsulting.com<br>
423-875-2652</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;RL 'Bob' Morgan&quot;
&lt;[email-masked]&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: [email-masked]</font>
<p><font size=1 face="sans-serif">11/04/2005 05:12 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">HTTP authentication list &lt;[email-masked]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Calconnect Authenticate TC &lt;[email-masked]&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[tc-authenticate-l] caldav/webdav/http
authentication bar BoF at IETF 64</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
Let me first apologize for not having helped the conversation keep going
<br>
on the ietf-http-auth list after stirring up this issue in the first <br>
place. &nbsp;I will attempt to provide more fodder for discussion shortly.<br>
<br>
However, what I would really like to do is find a time for folks to meet
<br>
at IETF 64 in Vancouver next week to chat about this issue and see if <br>
there is concrete work to be done on it.<br>
<br>
I know many of the calendar-oriented folks are only around Monday and some
<br>
of Tuesday, so it probably has to be on those days.<br>
<br>
So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify
WG <br>
slot. &nbsp;There is a XML-Patch-Ops BOF in that slot that might be an
overlap <br>
for some interested parties (not for me), or maybe others. &nbsp;Dinner
that <br>
evening, post-19:50, might be another alternative.<br>
<br>
So if you'd like attend, let me know what time works for you and I'll try
<br>
to optimize.<br>
<br>
Feel free to let other interested/useful folks know about this.<br>
<br>
 &nbsp;- RL &quot;Bob&quot;<br>
<br>
</tt></font>
<br>
--=_alternative 007F3B00852570AF_=--

Date: Fri, 04 Nov 2005 17:49:20 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] caldav/webdav/http authentication bar BoF at IETF 64
Cc: HTTP authentication list <[email-masked]>, Calconnect Authenticate TC <[email-masked]>

This is a cryptographically signed message in MIME format.

--------------ms070102060106090501060001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On Mondays there is traditional Kerberos dinner that I will be
attending.  Any chance of a post-dinner bar bof?

I would really appreciate it if folks would respond to the
e-mails I sent on 9/30/2005 describing what I believe are the
requirements for a solution and the reasons that organizations
currently rely on forms instead of HTTP AUTH.

Jeffrey Altman

--------------ms070102060106090501060001
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms070102060106090501060001--

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] caldav/webdav/http authentication bar BoF at IETF 64
Date: Fri, 4 Nov 2005 14:19:54 -0800
To: "RL 'Bob' Morgan" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>, Calconnect Authenticate TC <[email-masked]>

I'm chairing the XML-Patch-Ops BOF so I'd vote for the post 19:50 
dinner.  On Tuesday I'll be at an IMAPEXT dinner.

thx,
Lisa

On Nov 4, 2005, at 2:12 PM, RL 'Bob' Morgan wrote:

>
> Let me first apologize for not having helped the conversation keep 
> going on the ietf-http-auth list after stirring up this issue in the 
> first place.  I will attempt to provide more fodder for discussion 
> shortly.
>
> However, what I would really like to do is find a time for folks to 
> meet at IETF 64 in Vancouver next week to chat about this issue and 
> see if there is concrete work to be done on it.
>
> I know many of the calendar-oriented folks are only around Monday and 
> some of Tuesday, so it probably has to be on those days.
>
> So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify 
> WG slot.  There is a XML-Patch-Ops BOF in that slot that might be an 
> overlap for some interested parties (not for me), or maybe others.  
> Dinner that evening, post-19:50, might be another alternative.
>
> So if you'd like attend, let me know what time works for you and I'll 
> try to optimize.
>
> Feel free to let other interested/useful folks know about this.
>
>  - RL "Bob"
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

Date: Fri, 4 Nov 2005 14:12:11 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: HTTP authentication list <[email-masked]>
Cc: Calconnect Authenticate TC <[email-masked]>
Subject: [Ietf-http-auth] caldav/webdav/http authentication bar BoF at IETF 64

Let me first apologize for not having helped the conversation keep going 
on the ietf-http-auth list after stirring up this issue in the first 
place.  I will attempt to provide more fodder for discussion shortly.

However, what I would really like to do is find a time for folks to meet 
at IETF 64 in Vancouver next week to chat about this issue and see if 
there is concrete work to be done on it.

I know many of the calendar-oriented folks are only around Monday and some 
of Tuesday, so it probably has to be on those days.

So let me suggest 18:50-19:50 on Monday, ie the slot after the calsify WG 
slot.  There is a XML-Patch-Ops BOF in that slot that might be an overlap 
for some interested parties (not for me), or maybe others.  Dinner that 
evening, post-19:50, might be another alternative.

So if you'd like attend, let me know what time works for you and I'll try 
to optimize.

Feel free to let other interested/useful folks know about this.

  - RL "Bob"