Subject: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Date: Wed, 29 Mar 2006 19:19:39 -0800
List-Id: ietf-http-auth.osafoundation.org

Hi folks,
RFC 2617 doesn't specify a character set for usernames and passwords. 
Different implementations assume different charsets, and I've even heard 
that some browsers will use character set as selected in user 
preferences. This need to be addressed by explicitly specifying a 
character set and the only interoperable character set these days is UTF-8.

Does anybody know if updating RFC 2617 to say that username/passwords 
are UTF-8 would break any major implementation? For example, does 
anybody know if a major HTTP client/server implementation assume ISO 8859-1?

Thanks,
Alexey

Date: Wed, 29 Mar 2006 12:21:25 -0500
From: "Robert Sayre" <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-http-auth] Dinner logistics

On 3/20/06, Sam Hartman <[email-masked]> wrote:
>
> Hi.
> Where are we meeting?

Do the bar BOF participants have anything to report?

I have an additional data point from users of the Ruby On Rails Web
API. It seems they don't have a useful way to authenticate API traffic
without HTTPS.

<http://jamis.jamisbuck.org/articles/2006/03/27/web-services-rails-style#co=
mments>

--

Robert Sayre

Date: Wed, 22 Mar 2006 21:38:37 -0500
From: "Robert Sayre" <[email-masked]>
To: "HTTP authentication list" <[email-masked]>
Subject: [Ietf-http-auth] HMAC Digest draft and implementation news

In Internet-Drafts news, draft-sayre-http-hmac-digest-00.txt is now
available in the I-D directory. It's the same document I've posted
here before. One significant issue has come to light since then:
clients need to exclude standard and extension hop-by-hop headers from
the digest calculation. Per RFC 2616, extension hop-by-hop headers are
listed in the 'Connection' header.

In implementation news, Joe Gregorio and Thomas Broyer have added
experimental HMAC Digest support to the Python httplib2 library.

 <http://bitworking.org/projects/httplib2/>

 <http://sourceforge.net/tracker/?func=3Ddetail&atid=3D818437&aid=3D1455955=
&group_id=3D161082>

thanks,

Robert Sayre

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Date: Mon, 20 Mar 2006 18:15:24 -0600
To: Nicolas Williams <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>

On 20-Mar-06, at 4:19 PM, Nicolas Williams wrote:

> On Mon, Mar 20, 2006 at 02:35:13PM -0600, RL 'Bob' Morgan wrote:
>>
>> Dunno what people have in mind exactly, but when we met on the
>> ietf-http-auth topic in Vancouver we had 14 and it was difficult  
>> to do
>> dinner and have a rational conversation.  I suspect if we combine  
>> with the
>> likely sizeable dix-interested folks it will be unwieldy even  
>> beyond IETF
>> traditions.  I tend the think the dix conversation and the ietf- 
>> http-auth
>> conversation are quite different, also.
>
> The Vancouver dinner BoF was not helped by the fact that it was  
> held in
> a very noisy restaurant...

So far La Esquina has been pretty quiet. Happy to relocate if it is  
too noisy

-- Dick

Content-class: urn:content-classes:message
Subject: Re: [Ietf-http-auth] Dinner logistics
Date: Mon, 20 Mar 2006 14:55:47 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dick Hardt" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64C71.6D2651CA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

What time?

 -----Original Message-----
From: 	Dick Hardt [mailto:[email-masked]]
Sent:	Mon Mar 20 12:29:55 2006
To:	Alexey Melnikov
Cc:	[email-masked]; Sam Hartman
Subject:	Re: [Ietf-http-auth] Dinner logistics

>>
>> We are talking about tuesday now right?
>>
> No. Today.

correct -- likely get together again tomorrow night as well

-- Dick
_______________________________________________
Ietf-http-auth mailing list
[email-masked]
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

------_=_NextPart_001_01C64C71.6D2651CA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [Ietf-http-auth] Dinner logistics</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>What time?<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Dick Hardt [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent:&nbsp;&nbsp; Mon Mar 20 12:29:55 2006<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Alexey Melnikov<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]; Sam =
Hartman<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [Ietf-http-auth] =
Dinner logistics<BR>
<BR>
&gt;&gt;<BR>
&gt;&gt; We are talking about tuesday now right?<BR>
&gt;&gt;<BR>
&gt; No. Today.<BR>
<BR>
correct -- likely get together again tomorrow night as well<BR>
<BR>
-- Dick<BR>
_______________________________________________<BR>
Ietf-http-auth mailing list<BR>
[email-masked]<BR>
<A =
HREF=3D"http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http=
-auth">http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-=
auth</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C64C71.6D2651CA--

Date: Mon, 20 Mar 2006 16:19:25 -0600
From: Nicolas Williams <[email-masked]>
To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

On Mon, Mar 20, 2006 at 02:35:13PM -0600, RL 'Bob' Morgan wrote:
> 
> Dunno what people have in mind exactly, but when we met on the 
> ietf-http-auth topic in Vancouver we had 14 and it was difficult to do 
> dinner and have a rational conversation.  I suspect if we combine with the 
> likely sizeable dix-interested folks it will be unwieldy even beyond IETF 
> traditions.  I tend the think the dix conversation and the ietf-http-auth 
> conversation are quite different, also.

The Vancouver dinner BoF was not helped by the fact that it was held in
a very noisy restaurant...

> I would be inclined to have an ietf-http-auth bar bof later in the week. 
> Maybe lunch Tuesday or Wednesday?  Or dinner ...

I'm here only tonight.  That might encourage you to hold it some other
night, but I hope not!

Date: Mon, 20 Mar 2006 16:46:58 -0600
From: Cyrus Daboo <[email-masked]>
To: Sam Hartman <[email-masked]>, RL 'Bob' Morgan <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked]

Hi Sam,

--On March 20, 2006 5:39:43 PM -0500 Sam Hartman <[email-masked]> 
wrote:

> I could do lunch Wednesday.
> However we only have Nico tonight.
>
> I do agree that it is likely to not be very productive with a large
> mob.
>

Proposal: lets get together with the DIX folks (details below) and if it 
looks like we will have a large mob we can split off to another table at 
the same venue.

--On March 20, 2006 3:17:15 PM -0600 Dick Hardt <[email-masked]> wrote:

> We are thinking 8PM @ La Esquina (the mexican restaurant in Atrium II)
>
> John and I will be there @ 7 to score some tables if anyone wants to
> come by earlier.

-- 
Cyrus Daboo

To: "RL 'Bob' Morgan" <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
nReferences: <[email-masked]> <[email-masked]> <[email-masked]>
From: Sam Hartman <[email-masked]>
Date: Mon, 20 Mar 2006 16:39:43 -0500
Cc: [email-masked]

I could do lunch Wednesday.
However we only have Nico tonight.

I do agree that it is likely to not be very productive with a large
mob.

Date: Mon, 20 Mar 2006 22:06:13 +0100
From: Leif Johansson <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

>> We are talking about tuesday now right?
>>  
>>
> No. Today.
> 

Ok, so when and where and (seconding Bob) how does it become
a discussion rather than a dinner-group?

	Cheers Leif

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] Dinner logistics
Date: Mon, 20 Mar 2006 12:39:39 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Dick Hardt" <[email-masked]>, "Alexey Melnikov" <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0016_01C64C2C.1E005C90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Anyone brought a punt with them? 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Dick Hardt
> Sent: Monday, March 20, 2006 2:29 PM
> To: Alexey Melnikov
> Cc: [email-masked]; Sam Hartman
> Subject: Re: [Ietf-http-auth] Dinner logistics
> 
> >>
> >> We are talking about tuesday now right?
> >>
> > No. Today.
> 
> correct -- likely get together again tomorrow night as well
> 
> -- Dick
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
> 
> 

------=_NextPart_000_0016_01C64C2C.1E005C90
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0016_01C64C2C.1E005C90--

Date: Mon, 20 Mar 2006 14:37:48 -0600 (CST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

Oh well, OK, I now see Dick's dinner info, so hey, let's go with the flow. 
I guess if we need to talk http-auth later in the week we can figure that 
out and do so.

  - RL "Bob"

Date: Mon, 20 Mar 2006 14:35:13 -0600 (CST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

Dunno what people have in mind exactly, but when we met on the 
ietf-http-auth topic in Vancouver we had 14 and it was difficult to do 
dinner and have a rational conversation.  I suspect if we combine with the 
likely sizeable dix-interested folks it will be unwieldy even beyond IETF 
traditions.  I tend the think the dix conversation and the ietf-http-auth 
conversation are quite different, also.

I would be inclined to have an ietf-http-auth bar bof later in the week. 
Maybe lunch Tuesday or Wednesday?  Or dinner ...

  - RL "Bob"

On Mon, 20 Mar 2006, Cyrus Daboo wrote:

> Hi Sam,
>
> --On March 20, 2006 11:16:12 AM -0500 Sam Hartman <[email-masked]> 
> wrote:
>
>> Where are we meeting?
>
> I think we were planning on tying in with the DIX folks. Does anyone know 
> what there arrangements are? Failing that we just meet at the message board 
> after the last session and go from there...
>
> -- 
> Cyrus Daboo
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Date: Mon, 20 Mar 2006 14:29:24 -0600
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked], Sam Hartman <[email-masked]>

>>
>> We are talking about tuesday now right?
>>
> No. Today.

correct -- likely get together again tomorrow night as well

-- Dick

Date: Mon, 20 Mar 2006 12:22:43 -0800
From: Alexey Melnikov <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

Leif Johansson wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Cyrus Daboo wrote:
>  
>
>>Hi Sam,
>>
>>--On March 20, 2006 11:16:12 AM -0500 Sam Hartman
>><[email-masked]> wrote:
>>    
>>
>>>Where are we meeting?
>>>      
>>>
>>I think we were planning on tying in with the DIX folks. Does anyone
>>know what there arrangements are? Failing that we just meet at the
>>message board after the last session and go from there...
>>    
>>
>
>We are talking about tuesday now right?
>  
>
No. Today.

Date: Mon, 20 Mar 2006 21:20:18 +0100
From: Leif Johansson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Dinner logistics
Cc: [email-masked], Sam Hartman <[email-masked]>

Cyrus Daboo wrote:
> Hi Sam,
> 
> --On March 20, 2006 11:16:12 AM -0500 Sam Hartman
> <[email-masked]> wrote:
> 
>> Where are we meeting?
> 
> I think we were planning on tying in with the DIX folks. Does anyone
> know what there arrangements are? Failing that we just meet at the
> message board after the last session and go from there...
> 

We are talking about tuesday now right?

From: Dick Hardt <[email-masked]>
Date: Mon, 20 Mar 2006 14:17:15 -0600
To: Digital Identity Exchange <[email-masked]>, HTTP authentication list <[email-masked]>
Cc: Sam Hartman <[email-masked]>
Subject: [Ietf-http-auth] Dinner Logistics

We are thinking 8PM @ La Esquina (the mexican restaurant in Atrium II)

John and I will be there @ 7 to score some tables if anyone wants to  
come by earlier.

fyi: my cel is 415.846.4549

-- Dick

On 20-Mar-06, at 3:11 PM, Cyrus Daboo wrote:

> Hi Sam,
>
> --On March 20, 2006 11:16:12 AM -0500 Sam Hartman <hartmans- 
> [email-masked]> wrote:
>
>> Where are we meeting?
>
> I think we were planning on tying in with the DIX folks. Does  
> anyone know what there arrangements are? Failing that we just meet  
> at the message board after the last session and go from there...
>
> -- 
> Cyrus Daboo
>
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>
>

Date: Mon, 20 Mar 2006 15:11:31 -0600
From: Cyrus Daboo <[email-masked]>
To: Sam Hartman <[email-masked]>, [email-masked]
Subject: Re: [Ietf-http-auth] Dinner logistics

Hi Sam,

--On March 20, 2006 11:16:12 AM -0500 Sam Hartman <[email-masked]> 
wrote:

> Where are we meeting?

I think we were planning on tying in with the DIX folks. Does anyone know 
what there arrangements are? Failing that we just meet at the message board 
after the last session and go from there...

-- 
Cyrus Daboo

To: [email-masked]
From: Sam Hartman <[email-masked]>
Date: Mon, 20 Mar 2006 10:16:12 -0500
Subject: [Ietf-http-auth] Dinner logistics

Hi.
Where are we meeting?

Subject: Re: [Ietf-http-auth] Proxies
From: Scott Lawrence <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Fri, 10 Mar 2006 17:23:16 -0500
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Thu, 2006-03-09 at 17:22 -0500, Jeffrey Altman wrote:

> > 
> > Again, not true.  When a proxy gets CONNECT, if there is another proxy
> > between itself and the origin server, then it should send the CONNECT to
> > that proxy; each proxy in the chain only goes into tunnel mode when the
> > 2xx response has been sent back toward the client.  The CONNECT may be
> > sent all the way to the origin server, which should just response with a
> > 2xx.
> 
> This is exactly what 2817 says.   The first proxy can obtain
> authentication data from the client.  Does the second proxy use that
> same authentication data or is it authenticating the first proxy?
> I just don't know to do here based upon the spec.

That is covered in 2616 - proxy authentication is always hop by hop, so
any 407 received on the origin server side of a proxy is a request for
the proxy-proxy credentials - 407 is never forwarded toward a user by a
proxy.

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

Date: Thu, 09 Mar 2006 17:22:05 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Scott Lawrence <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

This is a cryptographically signed message in MIME format.

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

Scott Lawrence wrote:
> On Thu, 2006-03-09 at 13:52 -0500, Jeffrey Altman wrote:
>> There are a couple of issues that I see with using HTTP CONNECT.  The
>> first is that CONNECT is not standardized 
> 
> Not true. RFC 2817 standardizes CONNECT.

As far as I can tell the description in 2817 is insufficient to provide
for interoperable clients and servers as it does not specify the
interactions with Proxy-authentication.

>> Here is where I believe we are at:
>>
>> (1) We can deal with proxies by deciding that the correct way to handle
>>     then is to avoid them via the use of HTTP CONNECT and Proxy
>>     Authentication to allow end-to-end TLS.
>>
>>     This works fine for a single Proxy server and would fail for
>>     multiple proxy servers unless the application knew ahead of time
>>     how many proxy servers to contact.  If TLS was used to communicate
>>     with each proxy server in turn, it would also require a high amount
>>     of overhead as TLS is tunneled inside itself.
> 
> Again, not true.  When a proxy gets CONNECT, if there is another proxy
> between itself and the origin server, then it should send the CONNECT to
> that proxy; each proxy in the chain only goes into tunnel mode when the
> 2xx response has been sent back toward the client.  The CONNECT may be
> sent all the way to the origin server, which should just response with a
> 2xx.

This is exactly what 2817 says.   The first proxy can obtain
authentication data from the client.  Does the second proxy use that
same authentication data or is it authenticating the first proxy?
I just don't know to do here based upon the spec.

Jeffrey Altman

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

--------------ms080608000400080508010903--

Date: Thu, 9 Mar 2006 15:42:11 -0600
From: Nicolas Williams <[email-masked]>
To: Mark Baker <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Thu, Mar 09, 2006 at 04:36:32PM -0500, Mark Baker wrote:
> 2616 reserves it.  2817 defines it.

Ah, I missed that.  Bah!

Date: Thu, 9 Mar 2006 16:36:32 -0500
From: "Mark Baker" <[email-masked]>
Sender: [email-masked]
To: "Nicolas Williams" <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

2616 reserves it.  2817 defines it.

On 3/9/06, Nicolas Williams <[email-masked]> wrote:
> Not true.  RFC2817 *reserves* CONNECT for the purpose for which it was
> ultimately used, but does not specify how to use it.

--
Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca

Date: Thu, 9 Mar 2006 15:23:55 -0600
From: Nicolas Williams <[email-masked]>
To: Scott Lawrence <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Thu, Mar 09, 2006 at 03:05:49PM -0500, Scott Lawrence wrote:
> On Thu, 2006-03-09 at 13:52 -0500, Jeffrey Altman wrote:
> > There are a couple of issues that I see with using HTTP CONNECT.  The
> > first is that CONNECT is not standardized 
> 
> Not true. RFC 2817 standardizes CONNECT.

Not true.  RFC2817 *reserves* CONNECT for the purpose for which it was
ultimately used, but does not specify how to use it.

Date: Thu, 9 Mar 2006 15:22:48 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Thu, Mar 09, 2006 at 01:52:13PM -0500, Jeffrey Altman wrote:
>     (b) we can mutually authenticate the client to each proxy server
>         in turn without credential delegation.  However, in order to
>         implement this we need to construct a mechanism by which the
>         proxies pass back to the client the channel bindings data
>         necessary to protect the subsequent hops.  (btw, this model is
>         very similar to what will need to be done for EAP.)

Yes, and I think we may even have discussed this at Vancouver, though
not seriously.  Of course, in the EAP case the situation is reversed --
it's the server that cares about the channel bindings between the client
and the authenticator.

> One of the big questions that we need to answer because it affects the
> complexity of the solutions is "do we even want to support more than one
> proxy server between the client and the destination?"

I asked this, but technically it shouldn't be much harder to support
proxy chains than to support this in the first place; we can build on
the same idea.  What's difficult about proxy chains is trust: how does a
client decide if a given proxy beyond the first one is to be trusted?

Nico
-- 

Subject: Re: [Ietf-http-auth] Proxies
From: Scott Lawrence <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Thu, 09 Mar 2006 15:05:49 -0500
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Thu, 2006-03-09 at 13:52 -0500, Jeffrey Altman wrote:
> There are a couple of issues that I see with using HTTP CONNECT.  The
> first is that CONNECT is not standardized 

Not true. RFC 2817 standardizes CONNECT.

> Here is where I believe we are at:
> 
> (1) We can deal with proxies by deciding that the correct way to handle
>     then is to avoid them via the use of HTTP CONNECT and Proxy
>     Authentication to allow end-to-end TLS.
> 
>     This works fine for a single Proxy server and would fail for
>     multiple proxy servers unless the application knew ahead of time
>     how many proxy servers to contact.  If TLS was used to communicate
>     with each proxy server in turn, it would also require a high amount
>     of overhead as TLS is tunneled inside itself.

Again, not true.  When a proxy gets CONNECT, if there is another proxy
between itself and the origin server, then it should send the CONNECT to
that proxy; each proxy in the chain only goes into tunnel mode when the
2xx response has been sent back toward the client.  The CONNECT may be
sent all the way to the origin server, which should just response with a
2xx.

-- 
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: Thu, 09 Mar 2006 20:10:34 +0100
From: Leif Johansson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Re: Proxies

Sam Hartman wrote:
> OK, so people seem to be forgetting a lot of the vancouver discussions
> and going off in wildly different directions.
> 
> I do not believe a series of short email messages is going to be a
> reasonable way to make progress on the proxy question.
> 

The discussions in Vancouver had a format which wasn't as conducive to
participation and progress as they could have been. The food was good
 though :)

	Cheers Leif

To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
From: Eric Rescorla <[email-masked]>
Date: Thu, 09 Mar 2006 10:54:04 -0800
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>
Reply-To: EKR <[email-masked]>

Jeffrey Altman <[email-masked]> writes:

> Mike Shaver wrote:
>> On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:
>> 
>>> You seem to be forgetting that HTTP has these things called proxies.
>>> HTTP auth is end-to-end but TLS is hop-by-hop.
>> 
>> Most HTTP proxies support CONNECT specifically to permit TLS to operate
>> end-to-end, do they not?  (They can independently support TLS transit
>> between the proxy and the client, but very few do, and it's orthogonal
>> to the TLS-with-the-target-server issue.)
>> 
>> Mike
>
> There are a couple of issues that I see with using HTTP CONNECT.  The
> first is that CONNECT is not standardized and the properties of the
> connections created via its use vary greatly.  Some severely restrict
> the ports on which it can be used.  Others apply very restricted time
> limits or data flow restrictions.  I saw one proxy that supported
> CONNECT that would only allow a few Kbytes of data to flow outbound.

Well, it's technically standardized--see RFC 2817. I don't have any
real data on how consistent implementations are.

-Ekr

Date: Thu, 09 Mar 2006 13:52:13 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

This is a cryptographically signed message in MIME format.

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

Mike Shaver wrote:
> On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:
> 
>> You seem to be forgetting that HTTP has these things called proxies.
>> HTTP auth is end-to-end but TLS is hop-by-hop.
> 
> Most HTTP proxies support CONNECT specifically to permit TLS to operate
> end-to-end, do they not?  (They can independently support TLS transit
> between the proxy and the client, but very few do, and it's orthogonal
> to the TLS-with-the-target-server issue.)
> 
> Mike

There are a couple of issues that I see with using HTTP CONNECT.  The
first is that CONNECT is not standardized and the properties of the
connections created via its use vary greatly.  Some severely restrict
the ports on which it can be used.  Others apply very restricted time
limits or data flow restrictions.  I saw one proxy that supported
CONNECT that would only allow a few Kbytes of data to flow outbound.

Even assuming that CONNECT was well documented and consistent deployed
we still have the authentication issue.  You don't want to leave web
servers configured so that CONNECT can be used.  Doing so allows the
server to hide the source of attacks against other sites.  So we must
have Proxy authentication even when using CONNECT.

The last issue related to CONNECT is that one of the primary reasons
that large organizations impose proxies is to audit the communications.
When CONNECT is used to allow end to end TLS, then the organization is
unable to audit the content of the connection.

Here is where I believe we are at:

(1) We can deal with proxies by deciding that the correct way to handle
    then is to avoid them via the use of HTTP CONNECT and Proxy
    Authentication to allow end-to-end TLS.

    This works fine for a single Proxy server and would fail for
    multiple proxy servers unless the application knew ahead of time
    how many proxy servers to contact.  If TLS was used to communicate
    with each proxy server in turn, it would also require a high amount
    of overhead as TLS is tunneled inside itself.

(2) We can deal with proxies by allowing the proxies to use TLS to
    protect each hop in two different ways:

    (a) we can mutually authenticate the first proxy and then delegate
        a credential that can be used by the proxy to authenticate to
        the next hop on the client's behalf.  In this case each hop
        will have channel bindings applied to it to bind the
        authentication to the TLS layer.

    (b) we can mutually authenticate the client to each proxy server
        in turn without credential delegation.  However, in order to
        implement this we need to construct a mechanism by which the
        proxies pass back to the client the channel bindings data
        necessary to protect the subsequent hops.  (btw, this model is
        very similar to what will need to be done for EAP.)

One of the big questions that we need to answer because it affects the
complexity of the solutions is "do we even want to support more than one
proxy server between the client and the destination?"

Jeffrey Altman

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

--------------ms080808080104050904070800--

Date: Thu, 9 Mar 2006 11:53:45 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Re: Proxies
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>

On Wed, Mar 08, 2006 at 10:03:50AM -0500, Sam Hartman wrote:
> OK, so people seem to be forgetting a lot of the vancouver discussions
> and going off in wildly different directions.
> 
> I do not believe a series of short email messages is going to be a
> reasonable way to make progress on the proxy question.

To be fair we only identified the proxy problem and did not work out
even requirements at Vancouver.

So, first things first: as far as TLS/SASL/GSS combinations, we need to
have requirements with respect to proxy traversal.

Questions:

 - Do we need to cater to proxies?  (Almost certainly "yes")

 - Do proxies need to see application protocol data in the clear?

   This is the crucial question.  If the answer is "no" then either
   straight SASL or CONNECT + TLS + SASL will do.

   If the answer is "yes" then we have to wonder whether we still want
   channel bindings, because if we do then there is a way to make this
   work, but it's fairly complex, and if we then don't want channel
   bindings then do we still want session protection and to heck with
   the proxies that want to see data in the clear.

 - How many proxy hops are reasonable?  1 proxy?  >1?

If we should need to support proxies while letting them see application
protocol data in the clear and we still want channel bindings, then we
can do channel bindings for the last leg (last proxy to actual server)
by having the last proxy send the channel bindings back to the client,
and the client would have to decide which proxies/proxy chains it trusts
(and maybe we could even do SASL/GSS w/ channel bindings to each proxy
to make sure that the proxies use TLS between each other).

That's pretty complicated.  And all for proxies that want cleartext app
data.

Nico
-- 

To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Mar 2006 20:01:59 -0500
Cc: [email-masked]

>>>>> "Cyrus" == Cyrus Daboo <[email-masked]> writes:

    Cyrus> Hi Sam, --On March 7, 2006 8:36:39 PM -0500 Sam Hartman
    Cyrus> <[email-masked]> wrote:

    >> I'd be interested in joining a Monday evening bof.

    Cyrus> OK, it seems like Monday evening is it - perhaps tied in
    Cyrus> with DIX, if its OK with those folks.

Note that I'd also be happy to join a BOF some other time as well.  My
comment was not meant to impply anything other than specific
availability then.

To: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Mar 2006 10:01:22 -0500
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>

>>>>> "Mike" == Mike Shaver <[email-masked]> writes:

    Mike> On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:
    >> You seem to be forgetting that HTTP has these things called
    >> proxies.  HTTP auth is end-to-end but TLS is hop-by-hop.

    Mike> Most HTTP proxies support CONNECT specifically to permit TLS
    Mike> to operate end-to-end, do they not?  (They can independently
    Mike> support TLS transit between the proxy and the client, but
    Mike> very few do, and it's orthogonal to the
    Mike> TLS-with-the-target-server issue.)

Yes, you can use connect.

I think our experience with the earlier sasl draft suggests we don't
want to bind ourselves to connect.

To: Leif Johansson <[email-masked]>
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Mar 2006 10:03:50 -0500
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Re: Proxies

OK, so people seem to be forgetting a lot of the vancouver discussions
and going off in wildly different directions.

I do not believe a series of short email messages is going to be a
reasonable way to make progress on the proxy question.

Date: Wed, 08 Mar 2006 09:28:15 -0500
From: Cyrus Daboo <[email-masked]>
To: Sam Hartman <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Cc: [email-masked]

Hi Sam,

--On March 7, 2006 8:36:39 PM -0500 Sam Hartman <[email-masked]> 
wrote:

> I'd be interested in joining a Monday evening bof.

OK, it seems like Monday evening is it - perhaps tied in with DIX, if its 
OK with those folks.

-- 
Cyrus Daboo

Date: Wed, 8 Mar 2006 12:04:35 -0500
From: "Robert Sayre" <[email-masked]>
To: [email-masked]
Subject: [Ietf-http-auth] SASL mechanism in draft-sayre-http-hmac-digest-00?

On 3/7/06, Sam Hartman <[email-masked]> wrote:
>
> SASL digest-md5 and http digest share secret key forms.
>
> You could easily meet my requirement by specifying both a sasl
> mechanism and an http mechanism in the same draft.

I don't have the time or need to specify a SASL mechanism mirroring
the scheme I've sketched out. I wouldn't have a problem with someone
else writing that part, though.

If anyone reading would like to be a co-author responsible for the
SASL aspects, please send me email off-list.

In the meantime, I noticed that implementing HMAC Digest for my
Mozilla-based client application has the nice side-effect of making a
Firefox authentication extension easy to package. So, I should have
that going in a few days.

--

Robert Sayre

Date: Wed, 08 Mar 2006 09:09:37 +0100
From: Leif Johansson <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Re: Proxies

>
>You seem to be forgetting that HTTP has these things called proxies.
>HTTP auth is end-to-end but TLS is hop-by-hop.
>
>I would like to have a brainstorming session with someone about what
>proxy behavior you want to have.
>
>I promised to do that as a vancouver follow-on but failed to do so.
>
>  
>
What about adding support for mutual auth to Negotiate? That way you can at
least have mutual auth end2end if not TLS. Just brainstorming now mind 
you but
adding mutual to Negotiate should not be too difficult - in fact from 
reading the
draft it almost seems that support for the full handshake was left out 
by accident.

       MVH leifj

Date: Wed, 8 Mar 2006 01:52:38 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 09:05:31PM -0500, Sam Hartman wrote:
> I would like to have a brainstorming session with someone about what
> proxy behavior you want to have.

Preferably: no proxies :)

But yes, we need to know whether proxies want to have access to the
application protocol data in the clear or simply need to be able to do
traffic analysis/filtering.  Of course, no cleartext for the proxy means
no caching.

We also need to know how many hops to expect and at which one we might
start TLS to the web server, if at all.

If proxies need cleartext then ideally we can have a proxy start TLS
between it and the server end and then pass the channel bindings back to
the client.  We might want to have the client use TLS to that proxy, but
things get complicated by then if we have multiple hops to that proxy.

Nico
-- 

Date: Wed, 8 Mar 2006 00:25:19 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 06:28:29PM -0800, Hallam-Baker, Phillip wrote:
> > This is implicitly conceding that there won't be a single, 
> > global, exclusive federation.
> 
> No, it is recognizing that this is what DNS already does.

You lost me here.  I must be missing something.

> I think we could easily build and deploy the scheme this year. 

The DNS SRV thing?  Maybe.  Where's the proposal?  I'd like to review it.

> > Unnecessary snarking.  I don't see you proposing good 
> > abstractions here, and that's what matters here and now.  
> 
> My point was that I know how to do abstractions, been there, done that. SAML
> provides a real pretty solution to the whole scheme and you can just drop in
> anything you like.
> 
> I think that there is something missing here, a piece of critical glue that
> has been left out.

Well, yes.  SAML1.0 specifically did not define credentials,
authentication, key exchange...  SAML2.0 doesn't either, but adds items
needed to build them.

The GSS-API has too simple a notion of naming and authorization (but
we're fixing this).

Standard ways of doing authentication, SAML-style identity description
and session protection have weak cryptographic binding.

Mechanism availability for the various frameworks varies, not due to
applicability issues but to historical ones (mainly that someone didn't
do the work).  So applications and frameworks tend to get matched up
according to mechanism availability and credentials infrastructures
available to a subset of an application community rather than according
to framework applicability to the application.  Users shouldn't have to
deploy authentication infrastructures to satisfy the whims of
application designers; application designers shouldn't have to so
constrain their customers' environments due to non-uniform
authentication mechanism availability.

Yes, there's work to do.  The issue I have with what you're saying is
that you're saying we should start from scratch.  Well, looking at
XMLenc, for example, or XML and FastInfoset, for another, makes me think
that starting from scratch is not necessarily a good idea.  Besides, we
have specifications and running code that would be easier to extend than
to re-write.

The DNS SRV thing is another story -- I see that as an out-of-band ID
selection helper, and that seems like a potentially good thing to me,
provided we get it right.  But that still leaves us with the problems
described above.

Nico
-- 

Date: Wed, 8 Mar 2006 00:04:44 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

On Wed, Mar 08, 2006 at 12:44:27AM -0500, Jeffrey Altman wrote:
> Mike Shaver wrote:
> > On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:
> > 
> >> You seem to be forgetting that HTTP has these things called proxies.
> >> HTTP auth is end-to-end but TLS is hop-by-hop.
> > 
> > Most HTTP proxies support CONNECT specifically to permit TLS to operate
> > end-to-end, do they not?  (They can independently support TLS transit
> > between the proxy and the client, but very few do, and it's orthogonal
> > to the TLS-with-the-target-server issue.)
> > 
> > Mike
> 
> I'm wondering if we can also consider using constrained delegation
> to allow authentication of the proxy.  We could then negotiate
> TLS and bind it to a GSS/Kerberos exchange, forward a constrained
> credential, and then have the proxy negotiate TLS and authenticate the
> next hop, etc.

Wouldn't it be easier to not have proxies?

(That's a rhetorical question.)

Date: Wed, 08 Mar 2006 00:44:27 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Cc: HTTP authentication list <[email-masked]>, Sam Hartman <[email-masked]>

This is a cryptographically signed message in MIME format.

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

Mike Shaver wrote:
> On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:
> 
>> You seem to be forgetting that HTTP has these things called proxies.
>> HTTP auth is end-to-end but TLS is hop-by-hop.
> 
> Most HTTP proxies support CONNECT specifically to permit TLS to operate
> end-to-end, do they not?  (They can independently support TLS transit
> between the proxy and the client, but very few do, and it's orthogonal
> to the TLS-with-the-target-server issue.)
> 
> Mike

I'm wondering if we can also consider using constrained delegation
to allow authentication of the proxy.  We could then negotiate
TLS and bind it to a GSS/Kerberos exchange, forward a constrained
credential, and then have the proxy negotiate TLS and authenticate the
next hop, etc.

Jeffrey Altman

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

--------------ms040509070904060907040909--

From: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Proxies
Date: Wed, 8 Mar 2006 00:25:36 -0500
To: Sam Hartman <[email-masked]>
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>

On 7-Mar-06, at 9:05 PM, Sam Hartman wrote:

> You seem to be forgetting that HTTP has these things called proxies.
> HTTP auth is end-to-end but TLS is hop-by-hop.

Most HTTP proxies support CONNECT specifically to permit TLS to  
operate end-to-end, do they not?  (They can independently support TLS  
transit between the proxy and the client, but very few do, and it's  
orthogonal to the TLS-with-the-target-server issue.)

Mike

To: "Robert Sayre" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
From: Sam Hartman <[email-masked]>
Date: Wed, 08 Mar 2006 00:20:13 -0500
Cc: [email-masked]

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> On 3/7/06, Sam Hartman <[email-masked]> wrote:
    >>  SASL digest-md5 and http digest share secret key forms.
    >> 
    >> You could easily meet my requirement by specifying both a sasl
    >> mechanism and an http mechanism in the same draft.

    Robert> I apologize if these questions seem combative, but doesn't
    Robert> RFC2831 demonstrate that a SASL mechanism could be
    Robert> specified later? If so, what's the purpose of your
    Robert> requirement?
It could be.  I don't think that would be a good idea though.  It's
been my experience that when credential types are available with some
substrates and not others or with some frameworks and not others, you
get people picking frameworks and substrates based in part on
availability of credentials.

I find that leads to very bad security design and creates problems in
the future so I'd like to strongly discourage it.

--Sam

Date: Tue, 7 Mar 2006 22:26:09 -0500
From: "Robert Sayre" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: [email-masked]

On 3/7/06, Sam Hartman <[email-masked]> wrote:
>
> SASL digest-md5 and http digest share secret key forms.
>
> You could easily meet my requirement by specifying both a sasl
> mechanism and an http mechanism in the same draft.

I apologize if these questions seem combative, but doesn't RFC2831
demonstrate that a SASL mechanism could be specified later? If so,
what's the purpose of your requirement?

--

Robert Sayre

To: "Robert Sayre" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Mar 2006 22:11:57 -0500
Cc: [email-masked]

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> I think this requirement would be reasonable if the IETF
    Robert> had already provided a useful secret key form for HTTP. It
    Robert> hasn't. The IETF has also standardized several
    Robert> authentication technologies that don't work with HTTP
    Robert> (e.g. SASL)[1].

SASL digest-md5 and http digest share secret key forms.

You could easily meet my requirement by specifying both a sasl
mechanism and an http mechanism in the same draft.

Content-class: urn:content-classes:message
Date: Tue, 7 Mar 2006 18:59:42 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] RE: Gooie federated love

This is a multi-part message in MIME format.

------=_NextPart_000_0017_01C64232.705CDD50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> From: Sam Hartman [mailto:[email-masked]] 

> This is an interesting idea.  Thanks for causing me to have a 
> lot more to think about.  I'm not sure whether I agree with 
> this direction--I certainly don't agree with this as a 
> singleton direction.
> 
> Things to think about:
> 
> * How does the browser find the appropriate mechanism/get the blob of
>   goo to send to the website.

An unmodified stock browser can do federated digest as is, the protocol is
the same at the client level.

An enhanced browser can offer a range of authentication options and find out
which one the particular user wants to use by cracking the uniform user
identifier.

So when you type in [email-masked] (or some spam obfuscated decoy account)

Say the browser supports xxx-kerberospw, xxx-oathpki, xxx-oathotp
Say MIT only supports the kerberos federated auth service

The browser looks for:
	_xxx-kerberospw._tcp.mit.edu    SRV
	_xxx-oathpki._tcp.mit.edu     SRV
	_xxx-otp._tcp.mit.edu         SRV

It only gets back a result for kerberos so it knows that that is your
preferred federated auth mechanism.

The enhanced browser can then ask for your kerberos password (via an
appropriately spoof proof user interface naturally), do a kerberos protocol
specific interaction with the MIT kerberized auth service and get some form
of token from the service that can then be passed through the HTTP auth
channel. 

Note that this mechanism does leave the relying party web server asking the
question 'is this really the MIT federated kerb server'. This can be
addressed via DKIM style naked keys in the DNS or by naked keys augmented by
X.509 certificates.

Note also that an enhaced browser could expose a GSS-API interface.

> * How do you do mutual authentication/channel bindings?

I consider mutual auth involving people/machines as being completely
separate from the mutual auth between machines case.

If people are involved mutual auth has to be first and foremost a user
interface concern. That is what I will be presenting on at the W3C workshop.

If there are ni people involved use the WS-* stack.

------=_NextPart_000_0017_01C64232.705CDD50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0017_01C64232.705CDD50--

Date: Tue, 7 Mar 2006 21:47:10 -0500
From: "Robert Sayre" <[email-masked]>
To: "Sam Hartman" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: [email-masked]

On 3/7/06, Sam Hartman <[email-masked]> wrote:
> So, if you invent a new secret key form for HTTP, I want
> to require you to somehow make it work with email, LDAP, Jabber and
> other IETF protocols.

I think this requirement would be reasonable if the IETF had already
provided a useful secret key form for HTTP. It hasn't. The IETF has
also standardized several authentication technologies that don't work
with HTTP (e.g. SASL)[1].

I would also say that the form proposed in my draft is more useful
than HTTP Digest, because HTTP servers can use it with existing
authentication databases that only store a hashed password. That's
pretty much every single database that isn't set up for Digest, and
since no one uses Digest, that's pretty much every single
authentication database.

All that said, it doesn't really matter if the IETF chooses to reject the w=
ork.

[1] http://lists.osafoundation.org/pipermail/ietf-http-auth/2005-November/0=
00055.html

--

Robert Sayre

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 18:28:29 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C6422E.138D6440
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> > No, that has been done so many times, I have done it twice myself.
> 
> Which frameworks did you use/create, and in what context?

I was the original editor of the SAML 1.0 spec and the author of XTASS which
is the assertion framework on which it is based.

I was also an editor of WS-Security and I am an author of several input
docs.

I designed XKMS, I was the original designer and proposer of HTTP digest.

> This is implicitly conceding that there won't be a single, 
> global, exclusive federation.

No, it is recognizing that this is what DNS already does.

I think we could easily build and deploy the scheme this year. 

> Unnecessary snarking.  I don't see you proposing good 
> abstractions here, and that's what matters here and now.  

My point was that I know how to do abstractions, been there, done that. SAML
provides a real pretty solution to the whole scheme and you can just drop in
anything you like.

I think that there is something missing here, a piece of critical glue that
has been left out.

Identity frameworks to date have been long on hype, short on delivery, great
on flashy diagrams, short on clarity. In short it looks just like network
hypertext did until Tim came along and dropped in the URI.

------=_NextPart_000_0012_01C6422E.138D6440
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0012_01C6422E.138D6440--

To: "Robert Sayre" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Mar 2006 21:26:44 -0500
Cc: [email-masked]

I'm uncomfortable with significant extensions to http digest,
particularly any extension that would support a new credential type.

In my role as security area director, I want to see convergence of
authentication technologies in the IETF.  At a minimum this means that
the credentials for one form of authentication need to be useful
elsewhere.  So, if you invent a new secret key form for HTTP, I want
to require you to somehow make it work with email, LDAP, Jabber and
other IETF protocols.

Long term, I'd actually like to encourage code reuse.  I don't think I can make that a requirement today.

I do think I can make a strong argument against proliferation of
credential types outside the existing frameworks.

--Sam

To: "Hallam-Baker, Phillip" <[email-masked]>
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Mar 2006 21:20:02 -0500
Cc: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Gooie federated love

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    >> From: Nicolas Williams [mailto:[email-masked]]

    >> And the SAML effort I mentioned earlier is about making GSS-API
    >> mechanisms that leverag SAML, which you should find pleasing
    >> (though perhaps you dislike SAML, or otherwise think we should
    >> start over, like Phillip, but at least we should agree on the
    >> framework matter).

    Hallam-Baker,> What I was arguing for was working out how to use
    Hallam-Baker,> HTTP to carry generic authentication blobs that
    Hallam-Baker,> enable federated auth.

This is an interesting idea.  Thanks for causing me to have a lot more
to think about.  I'm not sure whether I agree with this direction--I
certainly don't agree with this as a singleton direction.

Things to think about:

* How does the browser find the appropriate mechanism/get the blob of
  goo to send to the website.

* How do you do mutual authentication/channel bindings?

To: Jeffrey Altman <[email-masked]>
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Mar 2006 21:05:31 -0500
Cc: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Proxies

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> You can use Anonymous-DH TLS ciphers in combination with
    Jeffrey> any authentication framework that allows for channel
    Jeffrey> bindings.  The binding data for TLS is the client and
    Jeffrey> server finished messages which consist of history of
    Jeffrey> every message sent or received independently by the
    Jeffrey> client and the server.  If the bindings don't verify you
    Jeffrey> drop the connection.  If they do verify then you know
    Jeffrey> that there is no man in the middle.

You seem to be forgetting that HTTP has these things called proxies.
HTTP auth is end-to-end but TLS is hop-by-hop.

I would like to have a brainstorming session with someone about what
proxy behavior you want to have.

I promised to do that as a vancouver follow-on but failed to do so.

To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
From: Sam Hartman <[email-masked]>
Date: Tue, 07 Mar 2006 20:36:39 -0500
Cc: [email-masked]

I'd be interested in joining a Monday evening bof.

Date: Tue, 7 Mar 2006 17:18:49 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 02:33:58PM -0800, Hallam-Baker, Phillip wrote:
> > > The problem I think we need to solve is the problem of how 
> > a user can 
> > > authenticate to any Web site using an authentication 
> > technology that 
> > > they select without the need for any support from the Web 
> > site whatsoever.
> > 
> > Then you need a framework.
> 
> No, that has been done so many times, I have done it twice myself.

Which frameworks did you use/create, and in what context?

> OK we can argue the need for some form of mechanism ID to allow the
> authentication service to support different authentication protocols on
> different systems.

This is implicitly conceding that there won't be a single, global,
exclusive federation.

> > This is where abstractions help the most; lacking a proper 
> > abstraction you refer to "[a] bag of bits to send to the 
> > relevant auth server,"
> > which unnecessarily constrains the solution space in ways 
> > that are bad for security.
> 
> Before you get too much into teaching me abstraction please take a look at
> the author list on SAML 1.0, Web Services 1.0 and HTTP Digest Auth. 

Unnecessary snarking.  I don't see you proposing good abstractions here,
and that's what matters here and now.  I've my name on several
standards-track IETF documents, and several Internet-Drafts likely to
become standards-track IETF documents; so what?  If I'm wrong on
something I'm wrong, no matter what past achievements I may have.

> > A proper security mechanism abstraction (which the GSS-API 
> > is) does not so unnecessarily constrain the solution space; 
> > to the contrary, it gives mechanism designers more freedom.
> 
> The point I am making here is that to make a system work you have to make
> some decisions. GSSAPI allows those decisions to be punted off into the
> indefinite future which is why so little has got done.

If you mean the ID selection problem, well, that won't go away.

If you mean what mechanisms we choose to design, well, making it
possible to have many mechanisms *is* the point of a framework like the
GSS-API.  I see that as a feature, not a bug, but this comes from not
believing in a global, unique, exclusive ID system.

Nico
-- 

Date: Tue, 7 Mar 2006 17:03:37 -0600
From: Nicolas Williams <[email-masked]>
To: Jeffrey Altman <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 05:55:40PM -0500, Jeffrey Altman wrote:
> Leif Johansson wrote:
> > 
> >>> Please supply more (better!) reasons for one vs. the other :)
> > 
> > Then (pragmatically) I'd say TLS will be more difficult to deploy given
> > the fact that most TLS implementations aren't quick to extend the set of
> > mechanisms they support.
> > 
> > Also I (dare) re-iterate that there will probably be dependency-loops
> > for at least one GSSAPI implementation I am aware of :-) but that should
> > certainly not stop anyone.
> > 
> > I have heard Love and others speak favorably about the combination of
> > anonymous TLS or BTNS and something like Negotiate. That way you don't
> > depend on two infrastructures (PKI for host-certs and whatever you use
> > for GSSAPI).

Ah, I'd forgotten that choice (how could I!  I was at the Vancouver
dinner BoF where we discussed it).

Date: Tue, 7 Mar 2006 17:01:16 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: Jeffrey Altman <[email-masked]>, HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 02:49:05PM -0800, Hallam-Baker, Phillip wrote:
> If we had a uniform unique identifier for the principal, Web servers could
> use existing Kerberos to log in to any site on the Web.

A single, global Kerberos federation (i.e., TLD realms with cross-realm
relationships with each other and each with child realms, all
corresponding to the DNS namespace) is no more and no less _politically_
nor _technically_ feasible than a single global PKI.

That there is no such Kerberos federation doesn't mean it's technically
infeasible, or that Kerberos is technically inferior to PKI
(particularly once PKCROSS is added to the picture).  Just as the fact
that there is no such global PKI does not mean that PKI is a failure.

Neither exists because neither is _politically_ feasible at this time.

Here I don't refer to political party politics, of course.  Instead I
refer to the difficulty of accurately assessing unique political
identities (as in by a state or state-like authority).  But you can see
how this impacts domestic politics in many countries.

Date: Tue, 07 Mar 2006 17:58:50 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

This is a cryptographically signed message in MIME format.

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

Leif Johansson wrote:
> 
>>> Please supply more (better!) reasons for one vs. the other :)
> 
> Then (pragmatically) I'd say TLS will be more difficult to deploy given
> the fact that most TLS implementations aren't quick to extend the set of
> mechanisms they support.
> 
> Also I (dare) re-iterate that there will probably be dependency-loops
> for at least one GSSAPI implementation I am aware of :-) but that should
> certainly not stop anyone.
> 
> I have heard Love and others speak favorably about the combination of
> anonymous TLS or BTNS and something like Negotiate. That way you don't
> depend on two infrastructures (PKI for host-certs and whatever you use
> for GSSAPI).
> 
> 	MVH leifj

You can use Anonymous-DH TLS ciphers in combination with any
authentication framework that allows for channel bindings.  The binding
data for TLS is the client and server finished messages which consist of
history of every message sent or received independently by the client
and the server.  If the bindings don't verify you drop the connection.
If they do verify then you know that there is no man in the middle.

There have been proposals to replace 2712 with something that is RFC4120
friendly but they were shelved several years ago in the IETF because the
Kerberos WG did not have the cycles to work on it.  The authors then
changed jobs and no longer had an interest in pursuing the work.

At this point I see little benefit to embedding Kerberos within TLS
because the layering approach of Anon-DH TLS following by
GSS-API/Kerberos (or SRP or ...) works so well.

Jeffrey Altman

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

--------------ms020409040708040201020904--

Date: Tue, 7 Mar 2006 16:53:33 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 02:33:58PM -0800, Hallam-Baker, Phillip wrote:
> > > There are plenty of folk who can tell you the abstract data 
> > that fits 
> > > into these flows. What I do not see at this point are the two 
> > > ingredients required to make the system work in practice:
> > > 
> > > 1) A unique identifier syntax
> > > 2) The binding of the bags of bits to the HTTP protocol.
> > 
> > Wrong abstraction!
> > 
> > My alternative:
> > 
> > 1) mechanism ID
> > 2) local principal name (with generic and/or 
> > mechanism-specific syntax)
> > 3) target principal name (")
> > 4) credential for (2) to authenticate to (3) and/or (3) to (2).
> 
> I don't really understand what you mean by the local principle name here.
> The Internet is global, the local authentication problem has been solved for
> over a decade.

The Internet may be global, but identity isn't really (e.g., I've a
colleague who is a citizen of three nations).

More likely we'll have federations, and which federations a service or
user participates in will vary, either over time or contextually or
both.

I believe the ID selection problem will never go away.

> The problem is how to deploy an internet scale authentication scheme.

If you have a monopoly on the use of force (i.e., if you're a national
government) then it's relatively easy to achieve what you want, even at
the international scale (through treaties), though if you want a single
and exclusive such scheme used by all the result may not be in keeping
with the spirit of Enlightenment...

A treaty scheme could be set up by which every nation's citizens are to
be issued globally unique IDs and credentials, with nations federating
into a single global citizen authentication scheme.  Assuming you got
that far, markets (users and service providers) would still demand
alternatives, most of which would not be "internet scale," including a
plethora of identities per-person.  You cannot avoid the ID selection
problem except by forcing one-person-one-ID -- I predict that won't
happen (but that's easy!  Can't you see European, American, and other
cultural attitudes towards privacy, etcetera, being hard to finesse into
a single global ID system?).

Nico
-- 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 14:49:05 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Jeffrey Altman" <[email-masked]>, "HTTP authentication list" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C6420F.6DBB6C60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> [mailto:[email-masked]] On Behalf 
> Of Jeffrey Altman

>    It is nice to make the claim that we should start over 
> again from a clean slate but the reality of the world is that 
> there are billions of Kerberos principals out there in the 
> world.  Every single Windows 2000/XP, MacOS X, and UNIX/Linux 
> system is capable of supporting them and the libraries to 
> make use of the protocols already exist on the machines.

They are capable of supporting them in the context in which the Kerberos
architecture was designed to work. 

Kerberos is considerably less attactive once you move from the LAN to the
Internet. 

> I don't know what users you listen to but when I visit my 
> clients which consist of Wall St. financial firms, health 
> care providers, government labs, and academic institutions 
> there is one message that is repeated time and time again.  
> "Don't force me to deploy another identity management 
> infrastructure."  They have Kerberos already.

Hooking into Kerberos makes sense to me. Making use of GSS-API to do so does
not.

If we had a uniform unique identifier for the principal, Web servers could
use existing Kerberos to log in to any site on the Web.

> The biggest problem that Kerberos, GSS-API and SASL face are 
> not that they are "shiny geek toys" but that the development 
> of these protocols and APIs have been left primarily in the 
> hands of resource starved implementors

That is actually what I meant. It is easy to get someone to bang out the
code to provide some level of support the latest DNA-in-earwax biometric
scanner. It is much harder to get people to do useful stuff.

> The IETF Kerberos and GSS-API 
> Next Generation (Kitten) work groups are making slow and 
> consistent progress but the fact is that both groups are 
> severely resource starved.  If the resources applied to 
> Liberty had been applied to Kerberos and GSS-API, we would be 
> far along the path to a universal authentication system by now.

Resources are not something that arrives like mana from heaven. Working out
strategies for getting resources is the hard part.

In point of fact the reason Liberty exists at all is due to someone trying
to deploy Kerberos on an Internet scale. 

------=_NextPart_000_0005_01C6420F.6DBB6C60
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0005_01C6420F.6DBB6C60--

Date: Tue, 07 Mar 2006 23:45:49 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

> Please supply more (better!) reasons for one vs. the other :)

Then (pragmatically) I'd say TLS will be more difficult to deploy given
the fact that most TLS implementations aren't quick to extend the set of
mechanisms they support.

Also I (dare) re-iterate that there will probably be dependency-loops
for at least one GSSAPI implementation I am aware of :-) but that should
certainly not stop anyone.

I have heard Love and others speak favorably about the combination of
anonymous TLS or BTNS and something like Negotiate. That way you don't
depend on two infrastructures (PKI for host-certs and whatever you use
for GSSAPI).

	MVH leifj

Date: Tue, 07 Mar 2006 23:35:19 +0100
From: Leif Johansson <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

> Kerberos imposes an architecture on the problem that predates the discovery
> of PKI. I do not regard the later extensions to Kerberos as being useful,
> they combine the disadvantages of symmetric key schemes with the
> disadvantages of PKI. 

This is useful if your measure of success is if it is PKI or not. My
measure of success is how easy it is to actually write code that does
things.

	Cheers Leif

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 14:33:58 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C6420D.5095CB00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> > The problem I think we need to solve is the problem of how 
> a user can 
> > authenticate to any Web site using an authentication 
> technology that 
> > they select without the need for any support from the Web 
> site whatsoever.
> 
> Then you need a framework.

No, that has been done so many times, I have done it twice myself.

> Even better -- noone but your local token should need your 
> biometric information just for those purposes, so just 
> generate a large public key, select a commenter pseudonym, 
> register the key and the pseudonym together and use that key 
> to authenticate you when using that pseudonym.

At which point the 'biometric' token looks to the system just like it was
any other smartcard or OTP token and even the auth server does not need to
care.

> Yes -- make HTTP not care about the specifics.  That means 
> abstracting the process of authentication so that apps need 
> not know about mechanism details that are not relevant to them.
> 
> That's what I mean by frameworks.

I prefer the term packaging. There are plenty of abstract frameworks out
there.

> > The browser receives the 301 not-authorized response 
> together with 'fedauth'
> > as a mechanism and a challenge nonce
> > 
> > The browser retries, the request has 2 pieces of data:
> > 	B1) A globally unique identifier for the account to be 
> accessed (e.g. 
> > [email-masked])
> > 	B2) A bag of bits to send to the relevant auth server
> 
> No, not a bag of bits to send.  A mechanism ID, a principal 
> name and a credential handle.  The mechanism might send bits 
> in the clear, it might send bits to a KDC and get a 
> cryptographic credential, it might login to your smartcard 
> and use a cert, whatever.

My point is that as far as the web site is concerned this is simply a bag of
bits. Mechanism, schmecanism. The web site should not even know the
authentication mechanism unless the authentication server wants to let it
know.

The globally unique identifier should include the information required to
locate the auth server. I.e. it should include a DNS domain name. The SRV
record can be used for mapping from the domain name to the service name (and
yes I mean SRV this time rather than NAPTR).

OK we can argue the need for some form of mechanism ID to allow the
authentication service to support different authentication protocols on
different systems.

> This is where abstractions help the most; lacking a proper 
> abstraction you refer to "[a] bag of bits to send to the 
> relevant auth server,"
> which unnecessarily constrains the solution space in ways 
> that are bad for security.

Before you get too much into teaching me abstraction please take a look at
the author list on SAML 1.0, Web Services 1.0 and HTTP Digest Auth. 

> A proper security mechanism abstraction (which the GSS-API 
> is) does not so unnecessarily constrain the solution space; 
> to the contrary, it gives mechanism designers more freedom.

The point I am making here is that to make a system work you have to make
some decisions. GSSAPI allows those decisions to be punted off into the
indefinite future which is why so little has got done.

> > There are plenty of folk who can tell you the abstract data 
> that fits 
> > into these flows. What I do not see at this point are the two 
> > ingredients required to make the system work in practice:
> > 
> > 1) A unique identifier syntax
> > 2) The binding of the bags of bits to the HTTP protocol.
> 
> Wrong abstraction!
> 
> My alternative:
> 
> 1) mechanism ID
> 2) local principal name (with generic and/or 
> mechanism-specific syntax)
> 3) target principal name (")
> 4) credential for (2) to authenticate to (3) and/or (3) to (2).

I don't really understand what you mean by the local principle name here.
The Internet is global, the local authentication problem has been solved for
over a decade.

The problem is how to deploy an internet scale authentication scheme.

------=_NextPart_000_0000_01C6420D.5095CB00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01C6420D.5095CB00--

Date: Tue, 7 Mar 2006 16:31:52 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 11:24:08PM +0100, Leif Johansson wrote:
> Nicolas Williams wrote:
> > Should we build GSS-API/SASL (which?) into HTTP ala HTTP-Negotiate?  Or
> 
> That will be much easier to deploy. Kerberos-TLS has been tried. The
> fact that it failed imho had a lot to do with the dependency-loops it
> created in popular implementations.

Oh no, RFC2712 failed because it violently violated RFC1510
abstractions, which naturally translated into similarly violent
conflicts in actual code, which led to non-deployment of non-existing
implementations.

:/

> > should we extend TLS to support the use of the GSS-API/SASL?

Please supply more (better!) reasons for one vs. the other :)

I can think of some myself, of course; I'll supply mine later, after
thinking about them some more.

Nico
-- 

Date: Tue, 07 Mar 2006 23:24:08 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

Nicolas Williams wrote:
> On Tue, Mar 07, 2006 at 09:31:11PM +0100, Leif Johansson wrote:
>>> To me it's a no-brainer.  Let's teach HTTP and friends how to use the
>>> GSS-API and/or SASL.  Let's teach channel binding wherever it is
>>> appropriate.
>> Right on. I absolutely agree. Now let's just get a proposal on the
>> table we can work on.
> 
> I don't think everyone agrees, but we will never get full agreement.
> So, yes, let's get a proposal on the table.
> 
> Should we build GSS-API/SASL (which?) into HTTP ala HTTP-Negotiate?  Or

That will be much easier to deploy. Kerberos-TLS has been tried. The
fact that it failed imho had a lot to do with the dependency-loops it
created in popular implementations.

> should we extend TLS to support the use of the GSS-API/SASL?
> 
> Nico

Date: Tue, 7 Mar 2006 15:16:52 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 12:34:55PM -0800, Hallam-Baker, Phillip wrote:
> I do not regard either SASL or GSSAPI as a conspicuous success. They are
> unfortunate examples of shiny geek toys. If the people who are working on
> those schemes have not worked out how to apply them to the Web by now they
> are not going to.

Paraphrase: I do not regard either password-based mechanisms or PKI to
as conspicuous successes.  They are unfortunate examples of shiny geek
toys.  If the people who are working on those schemes have not worked
out how to apply them beyond web services by now they are not going to.

Obviously I don't believe that.

PKI has not and will not have universal deployment with global scope.
There's no need to hash out why here -- go look at cryptography list
archives for that.

Passwords suck.  But often that's all one has.

> Kerberos imposes an architecture on the problem that predates the discovery
> of PKI. I do not regard the later extensions to Kerberos as being useful,
> they combine the disadvantages of symmetric key schemes with the
> disadvantages of PKI. 

PKI wasn't "discovered."  And PKI imposes infrastructure requirements
(cert req submission, CAs, CRLs, OCSP, enrollment) that are not
altogether that different from Kerberos'.

> > I am not sure if the purpose of this list is to discuss 
> > short-term or long-term solutions or both. I'm interested in 
> > both. I need short-term solutions to be specified before any 
> > long-term solutions are :-)
> 
> Given the glacial pace of GSSAPI development - 20 years and counting I would
> suggest eliminating it fromw consideration.

Lately it has not been glacial.  Same for Kerberos V.

> The problem I think we need to solve is the problem of how a user can
> authenticate to any Web site using an authentication technology that they
> select without the need for any support from the Web site whatsoever.

Then you need a framework.

> I want passwords to be stored in as few places as possible. I want to get
> away from the current situation where every Web site has to maintain its own
> account database.

We all do.

> So for example: imagine that earprint recognition is invented. I want to be
> able to go down to Fry's, buy the first ever earprint recognizer off the
> shelf, register my biometric with a server that offers earprint recognition
> service and then use that device to log in to Slashdot, Americablog and
> Little Green Footballs.

Even better -- noone but your local token should need your biometric
information just for those purposes, so just generate a large public
key, select a commenter pseudonym, register the key and the pseudonym
together and use that key to authenticate you when using that pseudonym.

If you want your smartcard to use biometrics to authenticate users of
it, go for it.

> With a little attention to detail it is quite possible to support this
> particular case in HTTP. 

Yes -- make HTTP not care about the specifics.  That means abstracting
the process of authentication so that apps need not know about mechanism
details that are not relevant to them.

That's what I mean by frameworks.

> The browser receives the 301 not-authorized response together with 'fedauth'
> as a mechanism and a challenge nonce
> 
> The browser retries, the request has 2 pieces of data:
> 	B1) A globally unique identifier for the account to be accessed
> (e.g. [email-masked])
> 	B2) A bag of bits to send to the relevant auth server

No, not a bag of bits to send.  A mechanism ID, a principal name and a
credential handle.  The mechanism might send bits in the clear, it might
send bits to a KDC and get a cryptographic credential, it might login to
your smartcard and use a cert, whatever.

This is where abstractions help the most; lacking a proper abstraction
you refer to "[a] bag of bits to send to the relevant auth server,"
which unnecessarily constrains the solution space in ways that are bad
for security.

A proper security mechanism abstraction (which the GSS-API is) does not
so unnecessarily constrain the solution space; to the contrary, it gives
mechanism designers more freedom.

> The Web site:
> 	W1) breaks open the unique identifier to identify the domain
> 	W2) Forwards the bag of bits and the challenge nonce to the auth
> server

Again.

> The auth server
> 	A1) Performs what local auth might be required
> 	A2) Sends back back a response 'accept' or 'reject'

Again.

> There are plenty of folk who can tell you the abstract data that fits into
> these flows. What I do not see at this point are the two ingredients
> required to make the system work in practice:
> 
> 1) A unique identifier syntax
> 2) The binding of the bags of bits to the HTTP protocol.

Wrong abstraction!

My alternative:

1) mechanism ID
2) local principal name (with generic and/or mechanism-specific syntax)
3) target principal name (")
4) credential for (2) to authenticate to (3) and/or (3) to (2).

Note the similarity to: krb5 APIs, TLS, GSS-API, SASL.  Less similar:
EAP (but we're finding ways to finesse that too).

Selection of this four-tuple can be tricky in that in general it depends
on context (certs for this, passwords for that, ...), but that's a whole
'nother problem.

Nico
-- 

Date: Tue, 07 Mar 2006 16:12:04 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00

This is a cryptographically signed message in MIME format.

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

Hallam-Baker, Phillip wrote:
> Given the glacial pace of GSSAPI development - 20 years and counting I would
> suggest eliminating it fromw consideration.

My reaction to statements like this is that any technology that has been
useful for 20+ years must have done something right.  All APIs and
Protocols are the result of compromise and the GSS-API is no exception.
   It is nice to make the claim that we should start over again from a
clean slate but the reality of the world is that there are billions of
Kerberos principals out there in the world.  Every single Windows
2000/XP, MacOS X, and UNIX/Linux system is capable of supporting them
and the libraries to make use of the protocols already exist on the
machines.

I don't know what users you listen to but when I visit my clients which
consist of Wall St. financial firms, health care providers, government
labs, and academic institutions there is one message that is repeated
time and time again.  "Don't force me to deploy another identity
management infrastructure."  They have Kerberos already.  They have
large global infrastructures that are made up of dozens of realms (or
Windows domains) that all inter-operate.  Their complaints with Kerberos
and GSS-API are very straight forward.  They desire vendor neutral
Kerberos standards for:

 * the browser

 * database access

 * management tools for the Kerberos database

 * integration with authorization data

 * tools for managing multiple identities and automating the process
   of identity selection for the service the user desires to access

 * better libraries for user to user mode so that Kerberos can be used
   to authenticate instant message and other real-time communications
   between entities that are not services

 * constrained delegation

and above all they want documentation, training programs for
administrators and developers, and better support from their OS and
Application vendors.

The biggest problem that Kerberos, GSS-API and SASL face are not that
they are "shiny geek toys" but that the development of these protocols
and APIs have been left primarily in the hands of resource starved
implementors and the Application Vendors and Operating System Vendors
whom have lived off open source implementations for the last decade
have failed to participate in the process.  The IETF Kerberos and
GSS-API Next Generation (Kitten) work groups are making slow and
consistent progress but the fact is that both groups are severely
resource starved.  If the resources applied to Liberty had been applied
to Kerberos and GSS-API, we would be far along the path to a universal
authentication system by now.

Jeffrey Altman

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

--------------ms020801030700040404090204--

Date: Tue, 7 Mar 2006 14:45:00 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 09:31:11PM +0100, Leif Johansson wrote:
> > To me it's a no-brainer.  Let's teach HTTP and friends how to use the
> > GSS-API and/or SASL.  Let's teach channel binding wherever it is
> > appropriate.
> 
> Right on. I absolutely agree. Now let's just get a proposal on the
> table we can work on.

I don't think everyone agrees, but we will never get full agreement.
So, yes, let's get a proposal on the table.

Should we build GSS-API/SASL (which?) into HTTP ala HTTP-Negotiate?  Or
should we extend TLS to support the use of the GSS-API/SASL?

Nico
-- 

Date: Tue, 07 Mar 2006 12:43:43 -0800
From: James M Snell <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

Hello Phillip,

Would you consider something along the lines of [1] to at least be
heading in the right direction?

[1] http://www.snellspace.com/public/draft-snell-http-claim-auth-00.txt

Hallam-Baker, Phillip wrote:
> [snip]
> 
> The problem I think we need to solve is the problem of how a user can
> authenticate to any Web site using an authentication technology that they
> select without the need for any support from the Web site whatsoever.
> 
> I want passwords to be stored in as few places as possible. I want to get
> away from the current situation where every Web site has to maintain its own
> account database.
> 
> 
> So for example: imagine that earprint recognition is invented. I want to be
> able to go down to Fry's, buy the first ever earprint recognizer off the
> shelf, register my biometric with a server that offers earprint recognition
> service and then use that device to log in to Slashdot, Americablog and
> Little Green Footballs.
> 
> [snip]

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 12:34:55 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C641FC.AF3AFB00
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> From: Leif Johansson [mailto:[email-masked]] 

> Hallam-Baker, Phillip wrote:
> > The reason I suggest making federation the priority is because that 
> > solves the deployment problem and until the deployment problem is 
> > solved it is going to be impossible to deploy anything new.
> 

> Do you agree that we must work on both short- and long-term 
> solutions in the IETF? In this space short-term solutions 
> must include support for widely deployed security 
> infrastructure (eg Kerberos) in some form, most probably 
> through either SASL or GSSAPI. Everything else including 
> discussions about the relative merit of past choices is 
> completely irrelevant at this point in time.

I do not regard either SASL or GSSAPI as a conspicuous success. They are
unfortunate examples of shiny geek toys. If the people who are working on
those schemes have not worked out how to apply them to the Web by now they
are not going to.

Kerberos imposes an architecture on the problem that predates the discovery
of PKI. I do not regard the later extensions to Kerberos as being useful,
they combine the disadvantages of symmetric key schemes with the
disadvantages of PKI. 

> I am not sure if the purpose of this list is to discuss 
> short-term or long-term solutions or both. I'm interested in 
> both. I need short-term solutions to be specified before any 
> long-term solutions are :-)

Given the glacial pace of GSSAPI development - 20 years and counting I would
suggest eliminating it fromw consideration.

The problem I think we need to solve is the problem of how a user can
authenticate to any Web site using an authentication technology that they
select without the need for any support from the Web site whatsoever.

I want passwords to be stored in as few places as possible. I want to get
away from the current situation where every Web site has to maintain its own
account database.

So for example: imagine that earprint recognition is invented. I want to be
able to go down to Fry's, buy the first ever earprint recognizer off the
shelf, register my biometric with a server that offers earprint recognition
service and then use that device to log in to Slashdot, Americablog and
Little Green Footballs.

With a little attention to detail it is quite possible to support this
particular case in HTTP. 

The browser receives the 301 not-authorized response together with 'fedauth'
as a mechanism and a challenge nonce

The browser retries, the request has 2 pieces of data:
	B1) A globally unique identifier for the account to be accessed
(e.g. [email-masked])
	B2) A bag of bits to send to the relevant auth server

The Web site:
	W1) breaks open the unique identifier to identify the domain
	W2) Forwards the bag of bits and the challenge nonce to the auth
server

The auth server
	A1) Performs what local auth might be required
	A2) Sends back back a response 'accept' or 'reject'

There are plenty of folk who can tell you the abstract data that fits into
these flows. What I do not see at this point are the two ingredients
required to make the system work in practice:

1) A unique identifier syntax
2) The binding of the bags of bits to the HTTP protocol.

------=_NextPart_000_0000_01C641FC.AF3AFB00
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01C641FC.AF3AFB00--

Date: Tue, 07 Mar 2006 21:31:11 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

Nicolas Williams wrote:
> On Tue, Mar 07, 2006 at 09:02:51PM +0100, Leif Johansson wrote:
>> I am not sure if the purpose of this list is to discuss short-term or
>> long-term solutions or both. I'm interested in both. I need short-term
>> solutions to be specified before any long-term solutions are :-)
> 
> Are the sets of short-term and long-term solutions we might consider
> disjoint?
> 

Maybe and maybe not.

> I think we should promote specification and code re-use.

On general principle, yes, but it all depends on how long it takes
to get things specified and deployed.

> 
> I believe that the use of extensible frameworks will allow us to have a
> large degree of commonality in both, short-term solutions and long-term
> solutions.  I believe that both, the GSS-API and SASL are extensible
> frameworks suitable for our short- and long-term needs here.

I hope and believe this is true.

> 
> Frameworks won't save us the effort of developing or extending
> mechanisms.

> 
> But frameworks will save us a lot of effort in terms of: a) fitting new
> mechanisms into protocols that use such frameworks, b) application
> development.
> 
> From an economics p.o.v., this should reduce the costs and risks of
> developing new mechanisms, the barriers to entry.  It also should help
> make credentials/identities for any new mechanisms more easily
> "convertible" to other mechanisms, as Jeff Altman described, which
> should reduce the costs and risks of any explosion in mechanism
> offerings.
> 
> To me it's a no-brainer.  Let's teach HTTP and friends how to use the
> GSS-API and/or SASL.  Let's teach channel binding wherever it is
> appropriate.

Right on. I absolutely agree. Now let's just get a proposal on the
table we can work on.

> 
> Nico

Date: Tue, 7 Mar 2006 14:21:03 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 09:02:51PM +0100, Leif Johansson wrote:
> I am not sure if the purpose of this list is to discuss short-term or
> long-term solutions or both. I'm interested in both. I need short-term
> solutions to be specified before any long-term solutions are :-)

Are the sets of short-term and long-term solutions we might consider
disjoint?

I think we should promote specification and code re-use.

I believe that the use of extensible frameworks will allow us to have a
large degree of commonality in both, short-term solutions and long-term
solutions.  I believe that both, the GSS-API and SASL are extensible
frameworks suitable for our short- and long-term needs here.

Frameworks won't save us the effort of developing or extending
mechanisms.

But frameworks will save us a lot of effort in terms of: a) fitting new
mechanisms into protocols that use such frameworks, b) application
development.

>From an economics p.o.v., this should reduce the costs and risks of
developing new mechanisms, the barriers to entry.  It also should help
make credentials/identities for any new mechanisms more easily
"convertible" to other mechanisms, as Jeff Altman described, which
should reduce the costs and risks of any explosion in mechanism
offerings.

To me it's a no-brainer.  Let's teach HTTP and friends how to use the
GSS-API and/or SASL.  Let's teach channel binding wherever it is
appropriate.

Nico
-- 

Date: Tue, 7 Mar 2006 15:07:18 -0500
From: "Robert Sayre" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On 3/7/06, Leif Johansson <[email-masked]> wrote:
> Hallam-Baker, Phillip wrote:
> > The reason I suggest making federation the priority is because that sol=
ves
> > the deployment problem and until the deployment problem is solved it is
> > going to be impossible to deploy anything new.
>
> You are right and wrong. Clearly federation is an important issue.
...
> I need short-term
> solutions to be specified before any long-term solutions are :-)

Indeed. I see no reason to believe a new federated identity effort
will be more successful than past efforts (though it certainly could
happen). In the meantime, we might as well use the hindsight we have
to provide some alternatives to 2617.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Date: Tue, 07 Mar 2006 21:02:51 +0100
From: Leif Johansson <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

Hallam-Baker, Phillip wrote:
> The reason I suggest making federation the priority is because that solves
> the deployment problem and until the deployment problem is solved it is
> going to be impossible to deploy anything new.

You are right and wrong. Clearly federation is a? important issue. There
are already several deployed solutions for http which demonstrates that
people care enough about this issue to disagree with each other ;-)
Most of them (but not all of them) use SAML in some form.

Do you agree that we must work on both short- and long-term solutions in
the IETF? In this space short-term solutions must include support for
widely deployed security infrastructure (eg Kerberos) in some form, most
probably through either SASL or GSSAPI. Everything else including
discussions about the relative merit of past choices is completely
irrelevant at this point in time.

I am not sure if the purpose of this list is to discuss short-term or
long-term solutions or both. I'm interested in both. I need short-term
solutions to be specified before any long-term solutions are :-)

	Cheers Leif

Date: Tue, 07 Mar 2006 13:04:12 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00

This is a cryptographically signed message in MIME format.

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

Nicolas Williams wrote:
> On Mon, Mar 06, 2006 at 04:38:42PM -0800, Hallam-Baker, Phillip wrote:
>> When people get the politics wrong then wheels need to be reinvented.
> 
> I don't know enough about the political background of SAML to comment,
> except that from a practical standpoint if we can leverage SAML to do
> things it doesn't do today (for whatever political reasons) then it's
> worth considering.
> 
> Would you reinvent Kerberos V and PKI also?  It seems to me that there's
> plenty to complain about with respect to either of those!  :)

The direction that I want to use move towards is a world in which
authentication can migrate from one set of mechanisms to another.

PK/PKI or Password or ??? can be used to obtain a Kerberos initial
ticket granting ticket (tgt).  The tgt can be used to obtain service
tickets.  Cross realm (aka Federated) acquisition of service tickets
in foreign realms can be boot-strapped by the use of PK/PKI between
the KDCs.  Kerberos service tickets can be exchanged for X.509
certificates for performing client authentication using TLS when
appropriate.

The long term goal should be a world of universal authentication so
that users can experience the benefits of single sign-on and service
providers can gain the security of credential delegation and mutual
authentication.

SAML provides the necessary tools to describe the user via attributes
which will in turn affect what the user is allowed to do or experience.
There are well understood methods for combining SAML with existing
authentication mechanisms either by embedding or by layering.  Doing
so allows SAML to easily fit into the vision of universal authentication.

Every protocol and mechanism design has strengths and weaknesses.  The
goal should be to come up with a method to leverage the best protocol
and mechanism for the task without requiring that organizations deploy
yet another independent infrastructure.

>> I am very familiar with how SAML works. My point is that we need a mechanism
>> built into the browser/server. So pointing out other uses merely confuses. 
> 
> Into the browser/server, sure, but where in the protocol stack?  SAML
> was certainly integrated in the wrong place for my taste, but I think I
> understand (or understood) why.  Integrating at the HTTP layer seems
> much cleaner to me.  But one distasteful approach to integrating, say,
> PKI, into some application wouldn't make me want to throw PKI out with
> the bath water.

Obviously we need a solution that will work with browsers but we also
need one that works when the full set of functionality found in a
browser does not exist.  When we are using HTTP for both, certainly
we would like to have one solution that works in both spaces.  I have
no objection to layering security protocols provided that we can ensure
that there is an appropriate set of bindings such that if an
authentication is taking place within HTTP or on top of HTTP and it is
being protected by TLS (anonymous-DH or otherwise) that the
authentication is bound to the TLS client and server finished messages
on both sides of the connection.

The fact that SAML was integrated at one layer in during previous
attempts at solving a problem doesn't mean it can't also be integrated
at another layer to solve a different problem space.

Jeffrey Altman

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

--------------ms080009090305000709050701--

Date: Tue, 7 Mar 2006 11:02:55 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Tue, Mar 07, 2006 at 07:09:17AM -0800, Hallam-Baker, Phillip wrote:
> > From: Nicolas Williams [mailto:[email-masked]] 
> 
> > And the SAML effort I mentioned earlier is about making 
> > GSS-API mechanisms that leverag SAML, which you should find 
> > pleasing (though perhaps you dislike SAML, or otherwise think 
> > we should start over, like Phillip, but at least we should 
> > agree on the framework matter).
> 
> What I was arguing for was working out how to use HTTP to carry generic
> authentication blobs that enable federated auth.

Ah, pardon the misunderstanding.

> The starting point for such effeorts should always be use cases and
> requirements. The starting point should not be 'here are some shiny geek
> toys we can use'. I have been aware of GSS-API for over fifteen years now.
> If it was going to set the world on fire it would have done so long ago. The
> starting point for GSS-API seems to be a profusion of different mechanisms
> and protocols. That is a mistake, there are only two means of authentication
> that make good sense at the protocol level: a mechanism for password
> verification (including OTP and challenge/response variations) and a
> mechanism for PKI based auth.

Well, we disagree.  I don't care to judge the GSS-API by whether it set
the world on fire a decade ago, for one.  But also I don't agree about
the authentication mechanisms you list.  Kerberos did not take the world
by storm twenty years ago, yet arguably nowadays it is one of the most
widely deployed authentication mechanisms in intranets.  So certainly I
would add Kerberos to your list.  Similarly for password-based
mechanisms -- I'd add the currently untouchable zero-knowledge protocols
to the list; they won't be untouchable forever.  Finally, I'd add
PK-but-non-PKI mechanisms as well, as ad-hoc authentication has its
place (besides PGP and SSH examples, one common example I see given is
for enrollment for posting comments on blogs, so one can register
whatever name one wishes and keep using it exclusively and without
passwords).

> My preferred means of integrating biometric auth is to have the user
> authenticate to a trustworthy terminal, do the biometric there and have the
> terminal authenticate by PKI (or OTP).

Yes.

> When a framework gives me 20 ways of doing basic auth then something is very
> wrong.

The GSS-API doesn't do that as it is only a generic framework.  If there
were 20 GSS-API mechanisms then you'd have "20 ways of doing basic
auth."  In any case, what the GSS-API has lacked is interfaces that
provide more information about principals than merely display names (or
"exported" names).

> The auth component of SAML was designed to wrap around the Web mechanisms,
> the existing browser capabilities were taken as a starting point. To do
> otherwise would have been idiotic given what the group was trying to achieve
> and the forum where that was taking place. SAML is silent on the part of the
> protocol we need to have defined.

This doesn't mean that SAML can't be more tightly integrated with
authentication mechanisms.

Nico
-- 

Date: Tue, 07 Mar 2006 15:17:59 +0000
From: Alexey Melnikov <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Cc: [email-masked]

Dick Hardt wrote:

> On 6-Mar-06, at 10:36 AM, Alexey Melnikov wrote:
>
>> Cyrus Daboo wrote:
>>
>>> Hi folks,
>>> I think it is worthwhile to have another bar BOF in Dallas to  
>>> continue our discussions and see how we can progress, and I would  
>>> like to propose Monday night for that.
>>
>> I would recommend to have a bar BOF after the DIX BOF, which is on  
>> Tuesday morning.
>
> There are a few people from the DIX list that are planning on getting  
> together Monday night prior to the DIX BOF.

Can the two baf BOFs be combined on Monday evening?

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 07:09:17 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>, "Leif Johansson" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C641CF.31819750
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> From: Nicolas Williams [mailto:[email-masked]] 

> And the SAML effort I mentioned earlier is about making 
> GSS-API mechanisms that leverag SAML, which you should find 
> pleasing (though perhaps you dislike SAML, or otherwise think 
> we should start over, like Phillip, but at least we should 
> agree on the framework matter).

What I was arguing for was working out how to use HTTP to carry generic
authentication blobs that enable federated auth.

The starting point for such effeorts should always be use cases and
requirements. The starting point should not be 'here are some shiny geek
toys we can use'. I have been aware of GSS-API for over fifteen years now.
If it was going to set the world on fire it would have done so long ago. The
starting point for GSS-API seems to be a profusion of different mechanisms
and protocols. That is a mistake, there are only two means of authentication
that make good sense at the protocol level: a mechanism for password
verification (including OTP and challenge/response variations) and a
mechanism for PKI based auth.

My preferred means of integrating biometric auth is to have the user
authenticate to a trustworthy terminal, do the biometric there and have the
terminal authenticate by PKI (or OTP).

When a framework gives me 20 ways of doing basic auth then something is very
wrong.

The auth component of SAML was designed to wrap around the Web mechanisms,
the existing browser capabilities were taken as a starting point. To do
otherwise would have been idiotic given what the group was trying to achieve
and the forum where that was taking place. SAML is silent on the part of the
protocol we need to have defined.

------=_NextPart_000_0011_01C641CF.31819750
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0011_01C641CF.31819750--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Tue, 7 Mar 2006 06:38:46 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C641CA.EE442380
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The reason I suggest making federation the priority is because that solves
the deployment problem and until the deployment problem is solved it is
going to be impossible to deploy anything new.

> -----Original Message-----
> From: Robert Sayre [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 4:54 PM
> To: Hallam-Baker, Phillip
> Cc: Lisa Dusseault; HTTP authentication list
> Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
> 
> On 3/6/06, Hallam-Baker, Phillip <[email-masked]> wrote:
> >
> > The first priority is to make the authentication mechanism 
> capable of 
> > federation in a useful manner though.
> 
> I don't see why prioritization is needed. Federation seems 
> like a much more difficult, long term task. It's much more in 
> line with what the DIX group is working on.
> 
> It's a fine goal, but it doesn't have much to do with an HTTP 
> bandaid provided to give people a viable alternative to 
> sending clear text payloads with <password> XML elements in them.
> 
> --
> 
> Robert Sayre
> 
> 

------=_NextPart_000_0000_01C641CA.EE442380
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01C641CA.EE442380--

Date: Tue, 07 Mar 2006 09:20:07 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>

>>Agreed!
>>    
>>
>
>But I knew you'd agree :)
>  
>
We are so cosy now it's embarrasing.

Date: Tue, 7 Mar 2006 00:16:13 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>

On Tue, Mar 07, 2006 at 07:04:24AM +0100, Leif Johansson wrote:
> > Why should the browser vs. non-browser HTTP app considerations drive us
> > to have multiple authentication mechanisms, multiple credentials and
> > multiple identities for our users?  If we put authentication in the
> > right layer then it should not.
> 
> We already have multiple of everything in HTTP space. In the glorious
> future where everything is bright and shiny we will have a unified way
> to manage authentication.
> 
> Right now we have everybody and their grandma's favourite, be it SAML,
> certificates or passwords.
> 
> What we don't have afaik is a good way to use GSSAPI/Kerberos5/SASL
> as an HTTP authentication mechanism.

No kidding, but in this instance I was arguing against the SAML
browser/server model and for the push-authentication-down-to-HTTP model.
As you already know I'm a big fan of frameworks like GSS-API over ad-hoc
HTTP/whatever extensions for <pick an authentication flavour>.  That was
merely the next step :)

And the SAML effort I mentioned earlier is about making GSS-API
mechanisms that leverag SAML, which you should find pleasing (though
perhaps you dislike SAML, or otherwise think we should start over, like
Phillip, but at least we should agree on the framework matter).

> > 
> > The best reason I've seen yet is that web developers like to have
> > control over the user's authentication experience, which generally means
> > TLS with server certs and forms (POST) for password prompting (or just
> > forms).  This is really not a good reason, from *my* p.o.v.
> 
> Agreed!

But I knew you'd agree :)

Date: Tue, 07 Mar 2006 07:04:24 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>

> 
> Why should the browser vs. non-browser HTTP app considerations drive us
> to have multiple authentication mechanisms, multiple credentials and
> multiple identities for our users?  If we put authentication in the
> right layer then it should not.

We already have multiple of everything in HTTP space. In the glorious
future where everything is bright and shiny we will have a unified way
to manage authentication.

Right now we have everybody and their grandma's favourite, be it SAML,
certificates or passwords.

What we don't have afaik is a good way to use GSSAPI/Kerberos5/SASL
as an HTTP authentication mechanism.

> 
> The best reason I've seen yet is that web developers like to have
> control over the user's authentication experience, which generally means
> TLS with server certs and forms (POST) for password prompting (or just
> forms).  This is really not a good reason, from *my* p.o.v.

Agreed!

	Cheers Leif

Date: Tue, 07 Mar 2006 06:58:55 +0100
From: Leif Johansson <[email-masked]>
To: RL 'Bob' Morgan <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: 'HTTP authentication list' <[email-masked]>

RL 'Bob' Morgan wrote:
> 
>> Speaking for myself I want a larger improvement - I want kerberos with
>> credentials forwarding :-) Doing this for SOAP using WS-Security will
>> be a very big change. Doing it using Negotiate will be relatively minor.
> 
> But doing it with WS-Sec buys you the ability to carry SOAP messages
> across things other than HTTP and across multiple hops.  Are you saying
> you don't have those requirements?  8^)
> 
>  - RL "Bob"
> 

I am saying that that is 2.0, using a secured transport is 1.0. That
is what this list is about right - the bandaid. I am just saying that
there are good bandaid and then there are bandaids that are bandaids
on bandaids.

	Cheers Leif

Date: Mon, 6 Mar 2006 20:53:30 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Mon, Mar 06, 2006 at 04:38:42PM -0800, Hallam-Baker, Phillip wrote:
> When people get the politics wrong then wheels need to be reinvented.

I don't know enough about the political background of SAML to comment,
except that from a practical standpoint if we can leverage SAML to do
things it doesn't do today (for whatever political reasons) then it's
worth considering.

Would you reinvent Kerberos V and PKI also?  It seems to me that there's
plenty to complain about with respect to either of those!  :)

> I am very familiar with how SAML works. My point is that we need a mechanism
> built into the browser/server. So pointing out other uses merely confuses. 

Into the browser/server, sure, but where in the protocol stack?  SAML
was certainly integrated in the wrong place for my taste, but I think I
understand (or understood) why.  Integrating at the HTTP layer seems
much cleaner to me.  But one distasteful approach to integrating, say,
PKI, into some application wouldn't make me want to throw PKI out with
the bath water.

Nico
-- 

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Mon, 6 Mar 2006 16:38:42 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Nicolas Williams" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C64155.92A94430
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

When people get the politics wrong then wheels need to be reinvented.

I am very familiar with how SAML works. My point is that we need a mechanism
built into the browser/server. So pointing out other uses merely confuses. 

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 5:51 PM
> To: Hallam-Baker, Phillip
> Cc: Robert Sayre; Lisa Dusseault; HTTP authentication list
> Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
> 
> On Mon, Mar 06, 2006 at 12:48:57PM -0800, Hallam-Baker, Phillip wrote:
> > SAML almost does this but SAML is designed to layer on top of HTTP 
> > rather than integrate a new auth technique into the 
> standard browser 
> > flows. We need a bit of integration/profile effort.
> 
> It is true that this is how SAML has been integrated into 
> browser/server so far, but it is NOT true that this is the 
> only way SAML is designed to work.
> 
> SAML2.0 adds bits necessary to subsequently profile it so for 
> use as a standalone authentication mechanism.
> 
> In fact, there is a mailing list dedicated to the proposition 
> that SAML should be useful at layers where authentication 
> normally takes place:
> 
> https://mailman1.u.washington.edu/mailman/listinfo/saml-mechan
> ism                                             
> 
> The approaches being considered are:
> 
>  - decorate on the inside
> 
>    Shove SAML goo into existing authentication protocols, 
> e.g., in krb5
>    Authorization-Data.
> 
>  - decorate on the outside
> 
>    Stack a pseudo-mechanism above a concrete authentication mechanism
>    using the latter to protect the former's PDUs (which in turn
>    transport SAML goo).
> 
>    E.g., a GSS-API stackable pseudo-mechanism that uses an underlying
>    mechanism (e.g., Kerberos V) for basic authentication and session
>    protection facilities to securely exchange SAML goo.
> 
>  - native SAML mechanism
> 
>    Use XMLend/XMLdsig/whatever and SAML2.0 to create a SAML 
> *credential*
>    and handle authentication and key exchange in addition to 
> exchangeing
>    SAML goo.
> 
> Each of these approaches has its pros and cons.
> 
> SAML gives us things we'll need no matter what authentication 
> schemes we cook up, such as a way to describe principals for 
> authorization purposes.
> 
> We can either say "SAML lacks native authentication 
> facilities, let's start from scratch" or "SAML lacks native 
> authentication facilities, let's fix this AND/OR otherwise 
> mix SAML with other authentication mechanisms."  In the 
> interest of not re-inventing the wheel I prefer the latter.
> 
> Cheers,
> 
> Nico
> -- 
> 
> 

------=_NextPart_000_0005_01C64155.92A94430
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0005_01C64155.92A94430--

Date: Mon, 6 Mar 2006 15:47:07 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: 'HTTP authentication list' <[email-masked]>

> Speaking for myself I want a larger improvement - I want kerberos with 
> credentials forwarding :-) Doing this for SOAP using WS-Security will be 
> a very big change. Doing it using Negotiate will be relatively minor.

But doing it with WS-Sec buys you the ability to carry SOAP messages 
across things other than HTTP and across multiple hops.  Are you saying 
you don't have those requirements?  8^)

  - RL "Bob"

Date: Mon, 6 Mar 2006 16:57:05 -0600
From: Nicolas Williams <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>, "Hallam-Baker, Phillip" <[email-masked]>

On Mon, Mar 06, 2006 at 11:13:56PM +0100, Leif Johansson wrote:
> The threads I have seen on this list makes me think that one size does
> not fit all in this space. Originally this BOF/list was trying to find a
> new mech which would be useful to non-browser-based applications using
> http as a transport - cal/web-dav clients for instance.
> 
> However, the solutions suitable for an SOAP/HTTP client which is part of
> an n-tier application may well differ significantly from those of a
> caldav client where there is probably a user somewhere close at hand.

Because it's always possible to fall back on prompting for passwords?  I
guess so, but wouldn't we rather have room for credentials that don't
necessarily involve passwords (e.g., Kerberos, PKI, PK-but-not-PKI,
etc...)?

> In federation-space (especially in higher-ed) I have seen enough
> solutions which more or less fits the later but rarely the former
> of these two scenarios.

Why should the browser vs. non-browser HTTP app considerations drive us
to have multiple authentication mechanisms, multiple credentials and
multiple identities for our users?  If we put authentication in the
right layer then it should not.

The best reason I've seen yet is that web developers like to have
control over the user's authentication experience, which generally means
TLS with server certs and forms (POST) for password prompting (or just
forms).  This is really not a good reason, from *my* p.o.v.

Nico
-- 

Date: Mon, 6 Mar 2006 16:51:25 -0600
From: Nicolas Williams <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On Mon, Mar 06, 2006 at 12:48:57PM -0800, Hallam-Baker, Phillip wrote:
> SAML almost does this but SAML is designed to layer on top of HTTP rather
> than integrate a new auth technique into the standard browser flows. We need
> a bit of integration/profile effort.

It is true that this is how SAML has been integrated into browser/server
so far, but it is NOT true that this is the only way SAML is designed to
work.

SAML2.0 adds bits necessary to subsequently profile it so for use as a
standalone authentication mechanism.

In fact, there is a mailing list dedicated to the proposition that SAML
should be useful at layers where authentication normally takes place:

https://mailman1.u.washington.edu/mailman/listinfo/saml-mechanism                                             

The approaches being considered are:

 - decorate on the inside

   Shove SAML goo into existing authentication protocols, e.g., in krb5
   Authorization-Data.

 - decorate on the outside

   Stack a pseudo-mechanism above a concrete authentication mechanism
   using the latter to protect the former's PDUs (which in turn
   transport SAML goo).

   E.g., a GSS-API stackable pseudo-mechanism that uses an underlying
   mechanism (e.g., Kerberos V) for basic authentication and session
   protection facilities to securely exchange SAML goo.

 - native SAML mechanism

   Use XMLend/XMLdsig/whatever and SAML2.0 to create a SAML *credential*
   and handle authentication and key exchange in addition to exchangeing
   SAML goo.

Each of these approaches has its pros and cons.

SAML gives us things we'll need no matter what authentication schemes we
cook up, such as a way to describe principals for authorization
purposes.

We can either say "SAML lacks native authentication facilities, let's
start from scratch" or "SAML lacks native authentication facilities,
let's fix this AND/OR otherwise mix SAML with other authentication
mechanisms."  In the interest of not re-inventing the wheel I prefer the
latter.

Cheers,

Nico
-- 

Date: Mon, 06 Mar 2006 23:36:40 +0100
From: Leif Johansson <[email-masked]>
To: Scott Cantor <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: 'HTTP authentication list' <[email-masked]>

Scott Cantor wrote:
>> However, the solutions suitable for an SOAP/HTTP client which is part of
>> an n-tier application may well differ significantly from those of a
>> caldav client where there is probably a user somewhere close at hand.
> 
> SOAP/HTTP is a third (or more) set of considerations over and above the
> kinds of issues that come up for HTTP. I personally agree with PHB that
> defining yet more shared secret approaches just isn't all that useful
> because it's a very small improvement over what I can already do. I don't
> want a shared secret, period.

I agree.

> 
> But that's where one size still doesn't fit all because some people want a
> much smaller improvement.
> 

Speaking for myself I want a larger improvement - I want kerberos with
credentials forwarding :-) Doing this for SOAP using WS-Security will be
a very big change. Doing it using Negotiate will be relatively minor.

	Cheers Leif

From: "Scott Cantor" <[email-masked]>
To: "'Leif Johansson'" <[email-masked]>
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Mon, 6 Mar 2006 17:21:01 -0500
Organization: The Ohio State University
Cc: 'HTTP authentication list' <[email-masked]>

> However, the solutions suitable for an SOAP/HTTP client which is part of
> an n-tier application may well differ significantly from those of a
> caldav client where there is probably a user somewhere close at hand.

SOAP/HTTP is a third (or more) set of considerations over and above the
kinds of issues that come up for HTTP. I personally agree with PHB that
defining yet more shared secret approaches just isn't all that useful
because it's a very small improvement over what I can already do. I don't
want a shared secret, period.

But that's where one size still doesn't fit all because some people want a
much smaller improvement.

> In federation-space (especially in higher-ed) I have seen enough
> solutions which more or less fits the later but rarely the former
> of these two scenarios.

SOAP has lots of viable directions to go in and SAML itself already plays
increasingly well in that space. That isn't the problem here. Non-browser
access to non-HTTP services is frankly an easier problem because there's no
installed base of intransigent software.

-- Scott

Date: Mon, 06 Mar 2006 23:18:31 +0100
From: Leif Johansson <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Cc: [email-masked]

Nicolas Williams wrote:
> On Mon, Mar 06, 2006 at 12:20:21PM -0800, Dick Hardt wrote:
>> On 6-Mar-06, at 10:36 AM, Alexey Melnikov wrote:
>>
>>> Cyrus Daboo wrote:
>>>
>>>> Hi folks,
>>>> I think it is worthwhile to have another bar BOF in Dallas to  
>>>> continue our discussions and see how we can progress, and I would  
>>>> like to propose Monday night for that.
>>> I would recommend to have a bar BOF after the DIX BOF, which is on  
>>> Tuesday morning.
>> There are a few people from the DIX list that are planning on getting  
>> together Monday night prior to the DIX BOF.
> 
> Count me in.

+1

Date: Mon, 06 Mar 2006 23:13:56 +0100
From: Leif Johansson <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

Hallam-Baker, Phillip wrote:
> I agree that it would be nice to define an unpgraded auth mechanism for
> HTTP.
> 

The threads I have seen on this list makes me think that one size does
not fit all in this space. Originally this BOF/list was trying to find a
new mech which would be useful to non-browser-based applications using
http as a transport - cal/web-dav clients for instance.

However, the solutions suitable for an SOAP/HTTP client which is part of
an n-tier application may well differ significantly from those of a
caldav client where there is probably a user somewhere close at hand.

In federation-space (especially in higher-ed) I have seen enough
solutions which more or less fits the later but rarely the former
of these two scenarios.

	Cheers Leif

Date: Mon, 6 Mar 2006 16:54:09 -0500
From: "Robert Sayre" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>

On 3/6/06, Hallam-Baker, Phillip <[email-masked]> wrote:
>
> The first priority is to make the authentication mechanism capable of
> federation in a useful manner though.

I don't see why prioritization is needed. Federation seems like a much
more difficult, long term task. It's much more in line with what the
DIX group is working on.

It's a fine goal, but it doesn't have much to do with an HTTP bandaid
provided to give people a viable alternative to sending clear text
payloads with <password> XML elements in them.

--

Robert Sayre

Date: Mon, 6 Mar 2006 13:45:34 -0800 (PST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Status of the Negotiate draft anyone?
Cc: HTTP authentication list <[email-masked]>

> draft-brezak-spnego-http-03.txt describes the use of SPNEGO as an HTTP 
> authentication mechanism (aka Negotiate). This mechanism has been widely 
> implemented of late but the draft is expired.
>
> Does anyone on this list know if anyone is working on an update to the 
> draft and if not if there is interest in renewed work on this draft?

Hmm, I thought sure I had seen it, around the time of the last IETF, in 
the RFC Editor's Queue and/or in the IETF ID-tracker with an indication 
that it was nearing publication, but I don't see any sign of that now ...

  - RL "Bob"

Date: Mon, 06 Mar 2006 22:42:30 +0100
From: Leif Johansson <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Status of the Negotiate draft anyone?
Cc: HTTP authentication list <[email-masked]>

Cyrus Daboo wrote:
> Hi Leif,
> 
> --On March 6, 2006 10:22:27 PM +0100 Leif Johansson <[email-masked]> wrote:
> 
>> draft-brezak-spnego-http-03.txt describes the use of SPNEGO as
>> an HTTP authentication mechanism (aka Negotiate). This mechanism
>> has been widely implemented of late but the draft is expired.
>>
>> Does anyone on this list know if anyone is working on an update
>> to the draft and if not if there is interest in renewed work on
>> this draft?
> 
> What about
> <http://www.ietf.org/internet-drafts/draft-jaganathan-kerberos-http-01.txt>
> which is in the rfc editor queue waiting to be published? I think its
> the same thing.
> 

Good news, thanks for the pointer!

Date: Mon, 06 Mar 2006 16:36:30 -0500
From: Cyrus Daboo <[email-masked]>
To: Leif Johansson <[email-masked]>, HTTP authentication list <[email-masked]>
Subject: Re: [Ietf-http-auth] Status of the Negotiate draft anyone?

Hi Leif,

--On March 6, 2006 10:22:27 PM +0100 Leif Johansson <[email-masked]> wrote:

> draft-brezak-spnego-http-03.txt describes the use of SPNEGO as
> an HTTP authentication mechanism (aka Negotiate). This mechanism
> has been widely implemented of late but the draft is expired.
>
> Does anyone on this list know if anyone is working on an update
> to the draft and if not if there is interest in renewed work on
> this draft?

What about 
<http://www.ietf.org/internet-drafts/draft-jaganathan-kerberos-http-01.txt> 
which is in the rfc editor queue waiting to be published? I think its the 
same thing.

-- 
Cyrus Daboo

Date: Mon, 06 Mar 2006 22:24:20 +0100
From: Leif Johansson <[email-masked]>
To: Leif Johansson <[email-masked]>
Subject: Re: [Ietf-http-auth] Status of the Negotiate draft anyone?
Cc: HTTP authentication list <[email-masked]>

Leif Johansson wrote:
> draft-brezak-spnego-http-03.txt describes the use of SPNEGO as
> an HTTP authentication mechanism (aka Negotiate). This mechanism
> has been widely implemented of late but the draft is expired.
> 
> Does anyone on this list know if anyone is working on an update
> to the draft and if not if there is interest in renewed work on
> this draft?
> 
> 	Cheers Leif

Sorry about the extra html - I meant to include the uri to a
copy of the draft.

Date: Mon, 06 Mar 2006 22:22:27 +0100
From: Leif Johansson <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Status of the Negotiate draft anyone?

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

draft-brezak-spnego-http-03.txt describes the use of SPNEGO as
an HTTP authentication mechanism (aka Negotiate). This mechanism
has been widely implemented of late but the draft is expired.

Does anyone on this list know if anyone is working on an update
to the draft and if not if there is interest in renewed work on
this draft?

	Cheers Leif

--------------040907050206070502070605
Content-Type: text/plain;
 name="draft-brezak-spnego-http-03.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-brezak-spnego-http-03.txt"

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="KEYWORDS" content="Draft-brezak-spnego-http-03.txt" />
<meta name="robots" content="index,follow" />
<link rel="shortcut icon" href="/favicon.ico" />
<link title="Creative Commons" type="application/rdf+xml" href="/index.php?title=Draft-brezak-spnego-http-03.txt&amp;action=creativecommons" rel="meta" />
<link rel="copyright" href="http://www.gnu.org/copyleft/fdl.html" />
    <title>Draft-brezak-spnego-http-03.txt - KerberosProtocols</title>
    <style type="text/css" media="screen,projection">/*<![CDATA[*/ @import "/skins/monobook/main.css"; /*]]>*/</style>
    <link rel="stylesheet" type="text/css" media="print" href="/skins/common/commonPrint.css" />
    <!--[if lt IE 5.5000]><style type="text/css">@import "/skins/monobook/IE50Fixes.css";</style><![endif]-->
    <!--[if IE 5.5000]><style type="text/css">@import "/skins/monobook/IE55Fixes.css";</style><![endif]-->
    <!--[if IE 6]><style type="text/css">@import "/skins/monobook/IE60Fixes.css";</style><![endif]-->
    <!--[if IE]><script type="text/javascript" src="/skins/common/IEFixes.js"></script>
    <meta http-equiv="imagetoolbar" content="no" /><![endif]-->
    <script type="text/javascript" src="/index.php?title=-&amp;action=raw&amp;gen=js"></script>    <script type="text/javascript" src="/skins/common/wikibits.js"></script>
    <style type="text/css">/*<![CDATA[*/
@import "/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=18000";
@import "/index.php?title=-&action=raw&gen=css";
/*]]>*/</style>          </head>
  <body         class="ns-0">
    <div id="globalWrapper">
      <div id="column-content">
	<div id="content">
	  <a name="top" id="contentTop"></a>
	  	  <h1 class="firstHeading">Draft-brezak-spnego-http-03.txt</h1>
	  <div id="bodyContent">
	    <h3 id="siteSub">From KerberosProtocols</h3>
	    <div id="contentSub"></div>
	    	    	    <!-- start content -->
	    <p>editors note: draft is expired!
</p>
<pre>

Kerberos working group                                         J.Brezak 
Internet Draft                                                Microsoft 
Document: draft-brezak-spnego-http-03.txt                               
Category: Informational                                                 
                                                          February 2002 

           HTTP Authentication: SPNEGO Access Authentication 
                 As implemented in Microsoft Windows 2000 

Status of this Memo 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 
   working documents of the Internet Engineering Task Force (IETF), its 
   areas, and its working groups. Note that other groups may also 
   distribute working documents as Internet-Drafts. Internet-Drafts are 
   draft documents valid for a maximum of six months and may be 
   updated, replaced, or obsoleted by other documents at any time. It 
   is inappropriate to use Internet- Drafts as reference material or to 
   cite them other than as &quot;work in progress.&quot; 
     
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
1. Abstract 
    
   This document describes how the Microsoft Internet Explorer (MSIE) 
   and Internet Information Services (IIS) incorporated in Microsoft 
   Windows 2000 use Kerberos for security enhancements of web 
   transactions. The HTTP auth-scheme of &quot;negotiate&quot; is defined here; 
   when the negotiation results in the selection of Kerberos, the 
   security services of authentication and optionally impersonation are 
   performed. 
    
   This document explains how HTTP authentication utilizes the SPNEGO 
   [7] GSSAPI mechanism. Details of SPNEGO implementation are not 
   provided in this document. 

2. Conventions used in this document 
    
   In examples, &quot;C:&quot; and &quot;S:&quot; indicate lines sent by the client and 
   server respectively. 
    
   The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, 
   &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,  &quot;MAY&quot;, and &quot;OPTIONAL&quot; in 
   this document are to be interpreted as described in RFC-2119 [3]. 

  
Brezak                 Category - Informational                      1 
 
                  HTTP SPNEGO Access Authentication     February 2002 

3. Access Authentication 
    
3.1 Reliance on the HTTP/1.1 Specification 
 
   This specification is a companion to the HTTP/1.1 specification [4] 
   and builds on the authentication mechanisms defined in [5]. It uses 
   the augmented BNF section 2.1 of that document, and relies on both 
   the non-terminals defined in that document and other aspects of the 
   HTTP/1.1 specification. 

4. HTTP Negotiate Authentication Scheme 
    
   Use of Kerberos is wrapped in an HTTP auth-scheme of &quot;Negotiate&quot;.  
   The auth-params exchanged use data formats defined for use with the 
   GSS-API [6].  In particular, they follow the formats set for the 
   SPNEGO [7] and Kerberos [8] mechanisms for GSSAPI.  The &quot;Negotiate&quot; 
   auth-scheme calls for the use of SPNEGO GSSAPI tokens which the 
   specific mechanism type specifies. 
    
   The current implementation of this protocol is limited to the use of 
   SPNEGO with the Kerberos and Microsoft NTLM protocols. 
    
4.1 The WWW-Authenticate Response Header 
    
   If the server receives a request for an access-protected object, and 
   an acceptable Authorization header has not been sent, the server 
   responds with a &quot;401 Unauthorized&quot; status code, and a &quot;WWW-
   Authenticate:&quot; header as per the framework described in [4]. The 
   initial WWW-Authenticate header will not carry any gssapi-data. 
    
   The negotiate scheme will operate as follows: 
    
        challenge       = &quot;Negotiate&quot; auth-data 
        auth-data       = 1#( [gssapi-data] ) 
         
   The meanings of the values of the directives used above are as 
   follows: 
    
   gssapi-data 
        If the gss_accept_security_context return a token for the 
        client, this directive contains the base64 encoding of an 
        InitialContextToken as defined in [6]. This is not present in 
        the initial response from the server. 
  
   A status code 200 status response can also carry a &quot;WWW-
   Authenticate&quot; response header containing the final leg of an 
   authentication. In this case, the gssapi-data will be present. 
   Before using the contents of the response, the gssapi-data should be 
   processed by gss_init_security_context to determine the state of the 
   security context. If this function indicates success, the response 
   can be used by the application. Otherwise an appropriate action 
   based on the authentication status should be. 

Brezak                 Category - Informational                      2 
 
                  HTTP SPNEGO Access Authentication     February 2002 

   For example the authentication could have failed on the final leg if 
   mutual authentication was requested and the server was not able to 
   prove its identity. In this case, the returned results are suspect. 
   It is not always possible to mutually authenticate the server before 
   the HTTP operation. POST methods are in this category. 
    
   When the Kerberos Version 5 GSSAPI mechanism [RFC-1964] is being 
   used, the HTTP server will be using a principal name of the form of 
   &quot;HTTP/&quot;. 
    
4.2 The Authorization Request Header 
 
   Upon receipt of the response containing a &quot;WWW-Authenticate&quot; header 
   from the server, the client is expected to retry the HTTP request, 
   passing a HTTP &quot;Authorization&quot; header line. This is defined 
   according to the framework described in [4] utilized as follows: 
    
        credentials             = &quot;Negotiate&quot; auth-data2 
        auth-data2              = 1#( gssapi-data ) 
                                 
   gssapi-data 
        This directive contains is the base64 encoding of an 
        InitialContextToken as defined in [6]. 
    
   Any returned code other than a success 2xx code represents an 
   authentication error. If a 401 containing a &quot;WWW-Authenticate&quot; 
   header with &quot;Negotiate&quot; and gssapi-data is returned from the server, 
   it is a continuation of the authentication request. 
    
   A client may initiate a connection to the server with an 
   &quot;Authorization&quot; header containing the initial token for the server. 
   This form will bypass the initial 401 error from the server when the 
   client knows that the server will accept the Negotiate HTTP 
   authentication type. 
    
5. Negotiate Operation Example 
    
   The client requests an access-protected document from server via a 
   GET method request. The URI of the document is 
   &quot;http://www.nowhere.org/dir/index.html&quot;. 
    
        C: GET dir/index.html 
    
   The first time the client requests the document, no Authorization 
   header is sent, so the server responds with: 
    
        S: HTTP/1.1 401 Unauthorized 
        S: WWW-Authenticate: Negotiate 
         
   The client will obtain the user credentials using the SPNEGO GSSAPI 
   mechanism type to identify generate a GSSAPI message to be sent to 
   the server with a new request, including the following Authorization 
   header: 

Brezak                 Category - Informational                      3 
 
                  HTTP SPNEGO Access Authentication     February 2002 

        C: GET dir/index.html 
        C: Authorization: Negotiate a87421000492aa874209af8bc028 
         
   The server will decode the gssapi-data and pass this to the SPNEGO 
   GSSAPI mechanism in the gss_accept_security_context function. If the 
   context is not complete, the server will respond with a 401 status 
   code with a WWW-Authenticate header containing the gssapi-data. 
    
        S: HTTP/1.1 401 Unauthorized 
        S: WWW-Authenticate: Negotiate 749efa7b23409c20b92356 
    
   The client will decode the gssapi-data and pass this into 
   gss_init_security_context and return the new gssapi-data to the 
   server. 
    
        C: GET dir/index.html 
        C: Authorization: Negotiate 89a8742aa8729a8b028 
    
   This cycle can continue until the security context is complete. 
    
   When the return value from the gss_accept_security_context function 
   indicates that the security context is complete, it may supply final 
   authentication data to be returned to the client. If the server has 
   more gssapi data to send to the client to complete the context it is 
   to be carried in WWW-Authenticate header with the final response 
   containing the HTTP body. 
    
        S: HTTP/1.1 200 Success 
        S: WWW-Authenticate: Negotiate ade0234568a4209af8bc0280289eca 
         
   The client will decode the gssapi-data and supply it to 
   gss_init_security_context using the context for this server. If the 
   status is successful from the final gss_init_security_context, the 
   response can be used by the application. 
 
7. Security Considerations 
 
   The SPNEGO HTTP authentication facility is only used to provide 
   authentication of a user to server. It provides no facilities for 
   protecting the HTTP headers or data including the Authorization and 
   WWW-Authenticate headers that are used to implement this mechanism. 
    
   This mechanism is not used for HTTP authentication to HTTP proxies. 
    
   If an HTTP proxy is used between the client and server, it must take 
   care to not share authenticated connections between different 
   authenticated clients to the same server. If this is not honored, 
   then the server can easily lose track of security context 
   associations. A proxy that correctly honors client to server 
   authentication integrity will supply the &quot;Proxy-support: Session-
   Based-Authentication&quot; HTTP header to the client in HTTP responses 
   from the proxy. The client MUST NOT utilize the SPNEGO HTTP 
   authentication mechanism through a proxy unless the proxy supplies 
   this header with the &quot;401 Unauthorized&quot; response from the server. 
  
Brezak                 Category - Informational                      4 
 
                  HTTP SPNEGO Access Authentication     February 2002 

   When using the SPNEGO HTTP authentication facility with client 
   supplied data such as PUT and POST, the authentication should be 
   complete between the client and server before sending the user data. 
   The return status from the gss_init_security_context will indicate 
   with the security context is complete. At this point the data can be 
   sent to the server. 

8. References 

   1  Bradner, S., &quot;The Internet Standards Process -- Revision 3&quot;, BCP 
      9, RFC 2026, October 1996. 
    
   3  Bradner, S., &quot;Key words for use in RFCs to Indicate Requirement 
      Levels&quot;, BCP 14, RFC 2119, March 1997 
    
   4 Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 
      Leach, P. and T. Berners-Lee, &quot;Hypertext Transfer Protocol -- 
      HTTP/1.1&quot;, RFC 2616, June 1999. 
     
   5 Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, 
      P., Luotonen, A., Stewart, L., &quot;HTTP Authentication: Basic and 
      Digest Access Authentication&quot;, RFC 2617, June 1999. 
    
   6 Linn, J., &quot;Generic Security Service Application Program Interface, 
      Version 2&quot;, RFC 2078, January 1997. 
    
   7 Baize, E., Pinkas, D., &quot;The Simple and Protected GSS-API 
      Negotiation Mechanism&quot;, RFC 2478, December 1998. 
    
   8 Linn, J., &quot;The Kerberos Version 5 GSS-API Mechanism&quot;, RFC 1964, 
      June 1996. 

    
    
10. Author's Addresses 
    
   John Brezak 
   Microsoft 
   One Microsoft Way 
   Redmond, Washington 
   Email: [email-masked] 

  
Brezak                 Category - Informational                      5 
 
                  HTTP SPNEGO Access Authentication     February 2002 

Full Copyright Statement 
 
   Copyright (C) The Internet Society (2001).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this   
   document itself may not be modified in any way, such as by removing   
   the copyright notice or references to the Internet Society or other   
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   &quot;AS IS&quot; basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.&quot; 

    

  
Brezak                 Category - Informational                      6

</pre>

<!-- Saved in parser cache with key kerberosprotocols:pcache:idhash:956-1!1!0!1!0!1!0!!en and timestamp 20060305052139 -->
<div class="printfooter">
Retrieved from "<a href="http://www.kerberosprotocols.org/index.php/Draft-brezak-spnego-http-03.txt">http://www.kerberosprotocols.org/index.php/Draft-brezak-spnego-http-03.txt</a>"</div>
	    	    <!-- end content -->
	    <div class="visualClear"></div>
	  </div>
	</div>
      </div>
      <div id="column-one">
	<div id="p-cactions" class="portlet">
	  <h5>Views</h5>
	  <ul>
	    <li id="ca-nstab-main"
	       class="selected"	       ><a href="/index.php/Draft-brezak-spnego-http-03.txt">Article</a></li><li id="ca-talk"
	       class="new"	       ><a href="/index.php?title=Talk:Draft-brezak-spnego-http-03.txt&amp;action=edit">Discussion</a></li><li id="ca-edit"
	       	       ><a href="/index.php?title=Draft-brezak-spnego-http-03.txt&amp;action=edit">Edit</a></li><li id="ca-history"
	       	       ><a href="/index.php?title=Draft-brezak-spnego-http-03.txt&amp;action=history">History</a></li>	  </ul>
	</div>
	<div class="portlet" id="p-personal">
	  <h5>Personal tools</h5>
	  <div class="pBody">
	    <ul>
	    <li id="pt-login"><a href="/index.php?title=Special:Userlogin&amp;returnto=Draft-brezak-spnego-http-03.txt">Create an account or log in</a></li>	    </ul>
	  </div>
	</div>
	<div class="portlet" id="p-logo">
	  <a style="background-image: url(/skins/common/images/wiki.png);"
	    href="/index.php/Main_Page"
	    title="Main Page"></a>
	</div>
	<script type="text/javascript"> if (window.isMSIE55) fixalpha(); </script>
	<div class="portlet" id="p-nav">
	  <h5>Navigation</h5>
	  <div class="pBody">
	    <ul>
	      	      <li id="n-mainpage"><a href="/index.php/Main_Page">Main Page</a></li>	      <li id="n-portal"><a href="/index.php/KerberosProtocols:Community_Portal">Community portal</a></li>	      <li id="n-currentevents"><a href="/index.php/Current_events">Current events</a></li>	      <li id="n-recentchanges"><a href="/index.php/Special:Recentchanges">Recent changes</a></li>	      <li id="n-randompage"><a href="/index.php/Special:Randompage">Random page</a></li>	      <li id="n-help"><a href="/index.php/Help:Contents">Help</a></li>	    </ul>
	  </div>
	</div>
	<div id="p-search" class="portlet">
	  <h5><label for="searchInput">Search</label></h5>
	  <div class="pBody">
	    <form name="searchform" action="/index.php/Special:Search" id="searchform">
	      <input id="searchInput" name="search" type="text"
	        accesskey="f" value="" />
	      <input type='submit' name="go" class="searchButton" id="searchGoButton"
	        value="Go"
	        />&nbsp;<input type='submit' name="fulltext"
	        class="searchButton"
	        value="Search" />
	    </form>
	  </div>
	</div>
	<div class="portlet" id="p-tb">
	  <h5>Toolbox</h5>
	  <div class="pBody">
	    <ul>
		  		  <li id="t-whatlinkshere"><a href="/index.php?title=Special:Whatlinkshere&amp;target=Draft-brezak-spnego-http-03.txt">What links here</a></li>
		  		  <li id="t-recentchangeslinked"><a href="/index.php?title=Special:Recentchangeslinked&amp;target=Draft-brezak-spnego-http-03.txt">Related changes</a></li>
		  	      	      	      	      	      	      	      	      	      <li id="t-specialpages"><a href="/index.php/Special:Specialpages">Special pages</a></li>	      	    </ul>
	  </div>
	</div>
	      </div><!-- end of the left (by default at least) column -->
      <div class="visualClear"></div>
      <div id="footer">
    <div id="f-poweredbyico"><a href="http://www.mediawiki.org/"><img src="/skins/common/images/poweredby_mediawiki_88x31.png" alt="MediaWiki" /></a></div>	<div id="f-copyrightico"><a href="http://www.gnu.org/copyleft/fdl.html"><img src="/skins/common/images/gnu-fdl.png" alt='GNU Free Documentation License 1.2' /></a></div>	<ul id="f-list">
	  <li id="f-lastmod"> This page was last modified 21:45, 9 Sep 2005.</li>	  <li id="f-viewcount">This page has been accessed 111 times.</li>	  	  <li id="f-copyright">Content is available under <a href="http://www.gnu.org/copyleft/fdl.html" class='external' title="http://www.gnu.org/copyleft/fdl.html" rel="nofollow">GNU Free Documentation License 1.2</a>.</li>	  <li id="f-about"><a href="/index.php/KerberosProtocols:About" title="KerberosProtocols:About">About KerberosProtocols</a></li>	  <li id="f-disclaimer"><a href="/index.php/KerberosProtocols:General_disclaimer" title="KerberosProtocols:General disclaimer">Disclaimers</a></li>	</ul>
      </div>
    </div>
    <!-- Served by lon-web-1.gradwell.net in 0.51 secs. -->
  </body>
</html>

--------------040907050206070502070605--

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Mon, 6 Mar 2006 12:48:57 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Robert Sayre" <[email-masked]>, "Lisa Dusseault" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C64135.7AB0D840
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I agree that it would be nice to define an unpgraded auth mechanism for
HTTP.

When Digest was written in 1993 the term MAC had not yet been coined and RSA
was still under patent for another 7 years. If we had had public key crypto
to work with the authentication alg would have been very different.

The first priority is to make the authentication mechanism capable of
federation in a useful manner though. Once we have that we can just slot in
new auth protocols and they can be used with any site on the Web. The real
barrier to deployment of better auth technologies is the fact that we now
have a three way sync up required to deploy a new mechanism. To deploy
retina scanning authentication as the baseline for Web auth we have to
upgrade all the browsers, all the users, all the sites. That is not going to
happen, the incentives are just wrong.

If we get that federation mechanism in there any individual who wants to use
stronger auth can do that unilaterally. They just go to an authentication
provider who suports the technique/protocol they want to use and download
the plug in for that particular mechanism. They can then use the technique
at any site on the netwhatsoever.

SAML almost does this but SAML is designed to layer on top of HTTP rather
than integrate a new auth technique into the standard browser flows. We need
a bit of integration/profile effort.

> -----Original Message-----
> From: Robert Sayre [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 1:52 PM
> To: Lisa Dusseault
> Cc: HTTP authentication list; Hallam-Baker, Phillip
> Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
> 
> On 3/3/06, Lisa Dusseault <[email-masked]> wrote:
> >
> > I'll be going to a W3C workshop on HTTP authentication <http:// 
> > www.w3.org/2005/Security/usability-ws/papers/> where I'd like to 
> > mention this I-D.
> 
> Shoot, I'm in New York. It's too bad registration is closed.
> 
> > Any comments on the use cases or requirements you have in mind for 
> > this?
> 
> My goal was to improve on 2617 in three ways: improve the 
> secret key algorithm, remove unnecessary Digest 
> features/options, and provide more practical message 
> integrity for unsafe methods.
> 
> The initial use case is non-browser HTTP authoring protocols 
> such as WebDAV and similar but smaller protocols. These are 
> often bolted-on to existing infrastructure, where passwords 
> have been stored in hashed form. For example, Hotmail submits 
> username/password as clear text over TLS. Wordpress 
> installations submit username/password as clear text over port 80.
> 
> Secondly, the economics of TLS make it impractical to deploy 
> everywhere and many applications don't require 
> confidentiality--a blog entry that's going to appear on a 
> public web server when it arrives doesn't need to be a 
> secret. All that's needed is hashed credentials and 
> better-than-nothing message integrity when the client submits .
> 
> The draft doesn't provide any message integrity for 
> responses, so it's definitely still vulnerable to MitM 
> attacks that trick the client into acting on a bogus 
> response, but I think it improves on Basic and Digest.
> 
> --
> 
> Robert Sayre
> 
> 

------=_NextPart_000_0000_01C64135.7AB0D840
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0000_01C64135.7AB0D840--

Date: Mon, 6 Mar 2006 14:22:17 -0600
From: Nicolas Williams <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Cc: [email-masked]

On Mon, Mar 06, 2006 at 12:20:21PM -0800, Dick Hardt wrote:
> 
> On 6-Mar-06, at 10:36 AM, Alexey Melnikov wrote:
> 
> >Cyrus Daboo wrote:
> >
> >>Hi folks,
> >>I think it is worthwhile to have another bar BOF in Dallas to  
> >>continue our discussions and see how we can progress, and I would  
> >>like to propose Monday night for that.
> >
> >I would recommend to have a bar BOF after the DIX BOF, which is on  
> >Tuesday morning.
> 
> There are a few people from the DIX list that are planning on getting  
> together Monday night prior to the DIX BOF.

Count me in.

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Date: Mon, 6 Mar 2006 12:20:21 -0800
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]

On 6-Mar-06, at 10:36 AM, Alexey Melnikov wrote:

> Cyrus Daboo wrote:
>
>> Hi folks,
>> I think it is worthwhile to have another bar BOF in Dallas to  
>> continue our discussions and see how we can progress, and I would  
>> like to propose Monday night for that.
>
> I would recommend to have a bar BOF after the DIX BOF, which is on  
> Tuesday morning.

There are a few people from the DIX list that are planning on getting  
together Monday night prior to the DIX BOF.

-- Dick

Date: Mon, 06 Mar 2006 11:26:29 -0800
From: James M Snell <[email-masked]>
To: [email-masked]
Subject: [Ietf-http-auth] Claim authentication

Following on the heels of Robert's hmac digest draft... I've been given
some thought recently to an alternative http basic and digest that is
fairly simple and would allow for weak authentication in situations
where the client does not have a prior existing relationship with the
server but the server still requires a verifiable identity (e.g. a
useful scenario for wiki's, comments on weblogs, etc).  The mechanism
I've come up with is based on signed identity claims.  For now I'm
calling it "Claim Authentication"

The pre-draft (which still needs quite a bit of work) is currently
available on my personal domain.

  http://www.snellspace.com/public/draft-snell-http-claim-auth-00.txt

I'd be very interested in what the members of this group think about
this approach.

- James Snell

Date: Mon, 6 Mar 2006 13:52:16 -0500
From: "Robert Sayre" <[email-masked]>
To: "Lisa Dusseault" <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Cc: HTTP authentication list <[email-masked]>, Phillip Hallam-Baker <[email-masked]>

On 3/3/06, Lisa Dusseault <[email-masked]> wrote:
>
> I'll be going to a W3C workshop on HTTP authentication <http://
> www.w3.org/2005/Security/usability-ws/papers/> where I'd like to
> mention this I-D.

Shoot, I'm in New York. It's too bad registration is closed.

> Any comments on the use cases or requirements you
> have in mind for this?

My goal was to improve on 2617 in three ways: improve the secret key
algorithm, remove unnecessary Digest features/options, and provide
more practical message integrity for unsafe methods.

The initial use case is non-browser HTTP authoring protocols such as
WebDAV and similar but smaller protocols. These are often bolted-on to
existing infrastructure, where passwords have been stored in hashed
form. For example, Hotmail submits username/password as clear text
over TLS. Wordpress installations submit username/password as clear
text over port 80.

Secondly, the economics of TLS make it impractical to deploy
everywhere and many applications don't require confidentiality--a blog
entry that's going to appear on a public web server when it arrives
doesn't need to be a secret. All that's needed is hashed credentials
and better-than-nothing message integrity when the client submits .

The draft doesn't provide any message integrity for responses, so it's
definitely still vulnerable to MitM attacks that trick the client into
acting on a bogus response, but I think it improves on Basic and
Digest.

--

Robert Sayre

Date: Mon, 06 Mar 2006 18:36:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-http-auth] Bar BOF in Dallas?
Cc: [email-masked]

Cyrus Daboo wrote:

> Hi folks,
> I think it is worthwhile to have another bar BOF in Dallas to continue 
> our discussions and see how we can progress, and I would like to 
> propose Monday night for that.

I would recommend to have a bar BOF after the DIX BOF, which is on 
Tuesday morning.

Date: Mon, 06 Mar 2006 13:32:22 -0500
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Subject: [Ietf-http-auth] Bar BOF in Dallas?

Hi folks,
I think it is worthwhile to have another bar BOF in Dallas to continue our 
discussions and see how we can progress, and I would like to propose Monday 
night for that.

-- 
Cyrus Daboo

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] draft-sayre-http-hmac-digest-00
Date: Fri, 3 Mar 2006 08:52:59 -0800
To: Robert Sayre <[email-masked]>, HTTP authentication list <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>

Hi Robert,

I'll be going to a W3C workshop on HTTP authentication <http:// 
www.w3.org/2005/Security/usability-ws/papers/> where I'd like to  
mention this I-D.  Any comments on the use cases or requirements you  
have in mind for this?

Phillip Hallam-Baker has also recently been thinking about HTTP  
Digest usage.

Lisa

On Mar 2, 2006, at 10:33 PM, Robert Sayre wrote:

> All,
>
> I recently encountered a situation where I wanted to use Digest
> authentication, but only had already-hashed passwords to work with.
> So, I thought I would try fixing Digest authentication. I've read that
> many people want to do this, but I haven't seen any action in this
> area.
>
> The scheme presented in the draft below allows the client to include
> request header values in the digest, for message integrity. There is
> no provision for entity integrity checking. However, the client could
> include a Content-MD5 header, and the server would only have to verify
> that value after the client had passed the challenge. The scheme also
> omits server nonces, and forces clients to send creation timestamps
> instead.
>
> The draft includes working client and server Python scripts.
>
> http://franklinmint.fm/2006/03/03/draft-sayre-http-hmac-digest-00.html
> http://franklinmint.fm/2006/03/03/draft-sayre-http-hmac-digest-00.txt
>
> It has all the problems you would expect with shared-secret
> authentication. But, on the plus side, it works with drop-in PHP
> scripts like Wordpress, and I hope it's better than basic.
>
> --
>
> Robert Sayre
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

Date: Fri, 3 Mar 2006 01:33:12 -0500
From: "Robert Sayre" <[email-masked]>
To: [email-masked]
Subject: [Ietf-http-auth] draft-sayre-http-hmac-digest-00

All,

I recently encountered a situation where I wanted to use Digest
authentication, but only had already-hashed passwords to work with.
So, I thought I would try fixing Digest authentication. I've read that
many people want to do this, but I haven't seen any action in this
area.

The scheme presented in the draft below allows the client to include
request header values in the digest, for message integrity. There is
no provision for entity integrity checking. However, the client could
include a Content-MD5 header, and the server would only have to verify
that value after the client had passed the challenge. The scheme also
omits server nonces, and forces clients to send creation timestamps
instead.

The draft includes working client and server Python scripts.

http://franklinmint.fm/2006/03/03/draft-sayre-http-hmac-digest-00.html
http://franklinmint.fm/2006/03/03/draft-sayre-http-hmac-digest-00.txt

It has all the problems you would expect with shared-secret
authentication. But, on the plus side, it works with drop-in PHP
scripts like Wordpress, and I hope it's better than basic.

--

Robert Sayre