Subject: Re: [Ietf-http-auth] Goals of this list?
From: Cat Okita <[email-masked]>
To: Joe Gregorio <[email-masked]>
Cc: HTTP authentication list <[email-masked]>
Date: Mon, 19 Dec 2005 23:32:23 -0500 (EST)
List-Id: ietf-http-auth.osafoundation.org

On Mon, 19 Dec 2005, Joe Gregorio wrote:
>> On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
>>> 1) new mechanism for secure credential exchange that addresses the
>>> issues with digest mode of basic auth
>>>
>>> 2) ways for authentication mechanisms other than username/password be
>>> used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerberos
>
> Then I am probably on the wrong list. As I said previously
> we have different target audiences that have different needs.
> Right now the status-quo in the weblog world is plain text
> passwords sent in an XML-RPC payload [1]. In many cases
> this is used to access either Blogger (which is free) or
> an installation of WordPress[2]. Buying a $14.95 certificate
> or setting up some kind of PKI infrastructure on the server-side
> is simply not a realistic suggestion.

I don't think that you're on the wrong list at all.

The question(s) I've been seeing appear to center around

 	"How can we do http-auth in a reasonable and flexible way,
 	supporting a choice of multiple authentication mechanisms for both
 	interactive and non-interactive clients."

Your specific case can easily be abstracted into this (generic) lump.  As
far as PKI and certs are concerned, I can't say that it seems appropriate 
to your particular concern, although both might be useful to a different
problem (updating my insurance coverage, perhaps?).

cheers!
==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."

Subject: Re: [Ietf-http-auth] Strong Password Authentication
From: Justin Chapweske <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Mon, 19 Dec 2005 18:35:58 -0600
Cc: HTTP authentication list <[email-masked]>

To clarify, I'm not saying that NATZ was before SRP, but rather that
NATZ may be a different construct that achieves similar benefits.  NATZ
is pretty much just CRAM plus a Diffie-Hellman exchange and may turn out
to fall outside the SRP patents.

On Mon, 2005-12-19 at 17:56 -0600, Nicolas Williams wrote:
> On Mon, Dec 19, 2005 at 05:49:10PM -0600, Justin Chapweske wrote:
> > Well, you may be in luck.  In '98 I independently invented a system with
> > similar advantages as SRP and B-SPEKE called "NATZ" (short for
> > "Natalie").
> 
> Too late.

Date: Mon, 19 Dec 2005 19:05:06 -0500
From: Jeffrey Altman <[email-masked]>
Organization: Secure Endpoints Inc.
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Strong Password Authentication
Cc: HTTP authentication list <[email-masked]>

This is a cryptographically signed message in MIME format.

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

Nicolas Williams wrote:
> On Mon, Dec 19, 2005 at 05:49:10PM -0600, Justin Chapweske wrote:
>> Well, you may be in luck.  In '98 I independently invented a system with
>> similar advantages as SRP and B-SPEKE called "NATZ" (short for
>> "Natalie").
> 
> Too late.

The reason Nico says "too late" is because it is not a question of
whether no not the implementation is independent.  What matters is
whether or not it was published prior to the date of the existing
patented algorithms in that space.  It is the inability to prove that
there is no existing patent that might be used to sue an implementer
with that is preventing the use of SRP.

Jeffrey Altman

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

--------------ms060702050804090506070601--

Date: Mon, 19 Dec 2005 17:56:02 -0600
From: Nicolas Williams <[email-masked]>
To: Justin Chapweske <[email-masked]>
Subject: Re: [Ietf-http-auth] Strong Password Authentication
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 05:49:10PM -0600, Justin Chapweske wrote:
> Well, you may be in luck.  In '98 I independently invented a system with
> similar advantages as SRP and B-SPEKE called "NATZ" (short for
> "Natalie").

Too late.

From: Justin Chapweske <[email-masked]>
To: Leif Johansson <[email-masked]>
Date: Mon, 19 Dec 2005 17:49:10 -0600
Cc: HTTP authentication list <[email-masked]>, Nicolas Williams <[email-masked]>
Subject: [Ietf-http-auth] Strong Password Authentication

Well, you may be in luck.  In '98 I independently invented a system with
similar advantages as SRP and B-SPEKE called "NATZ" (short for
"Natalie").

I was much younger when I wrote this and I haven't thought about it in
years, so it may be blatantly insecure, but if it turns out to be a
useful tool, I'd be happy if the IETF or W3C were to use it as long as
long as I am given credit.

http://groups.google.com/group/sci.crypt/browse_thread/thread/a7e6b2d99da9f679/2b848383574e8e36?lnk=st&q=natz+scram&rnum=2&hl=en#2b848383574e8e36

Enjoy, and please forgive the lack of rigor.

-Justin

On Mon, 2005-12-19 at 20:58 +0100, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Justin Chapweske wrote:
> > Toxic?  SRP seems like a nearly ideal mechanism for password-based
> > authentication between two parties.  No offline dictionary attacks, a
> > secure session key is generated, etc.
> > 
> > 
> 
> Toxic == licence-challenged

Date: Mon, 19 Dec 2005 20:58:48 +0100
From: Leif Johansson <[email-masked]>
To: Justin Chapweske <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>, Nicolas Williams <[email-masked]>

Justin Chapweske wrote:
> Toxic?  SRP seems like a nearly ideal mechanism for password-based
> authentication between two parties.  No offline dictionary attacks, a
> secure session key is generated, etc.
> 
> 

Toxic == licence-challenged

	Cheers Leif

Subject: Re: [Ietf-http-auth] Goals of this list?
From: Justin Chapweske <[email-masked]>
To: Nicolas Williams <[email-masked]>
Date: Mon, 19 Dec 2005 12:46:48 -0600
Cc: HTTP authentication list <[email-masked]>

Toxic?  SRP seems like a nearly ideal mechanism for password-based
authentication between two parties.  No offline dictionary attacks, a
secure session key is generated, etc.

> > 
> > Or if it uses a PAKE method like EKE, SRP, etc....
> 
> Yes, but I assumed we'd all agree those are toxic.  I assumed that
> simply because that's how it tends to work out.

Date: Mon, 19 Dec 2005 12:06:05 -0600
From: Nicolas Williams <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 09:58:24AM -0800, Lisa Dusseault wrote:
> I believe Atom publishing has roughly the same requirements as CalDAV 
> and WebDAV, so if this list ends up pursuing work which doesn't pursue 
> those requirements, I for one would still pursue those requirements.  
> It's just too early to split the list or declare stuff out of scope 
> because we haven't even got a good problem statement yet.

I agree.  I should say that I signed up to help solve that problem; I
happen to think that adding more choices at the HTTP layer will help,
thus my "me too" to Dick's point (2).

Date: Mon, 19 Dec 2005 09:56:11 -0600
From: Nicolas Williams <[email-masked]>
To: Joe Gregorio <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 10:31:42AM -0500, Joe Gregorio wrote:
> On 12/19/05, Nicolas Williams <[email-masked]> wrote:
> > On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
> > > (2) is what I joined the list for.
> >
> > Me too.
> 
> Then I am probably on the wrong list. As I said previously
> we have different target audiences that have different needs.
> Right now the status-quo in the weblog world is plain text
> passwords sent in an XML-RPC payload [1]. In many cases
> this is used to access either Blogger (which is free) or
> an installation of WordPress[2]. Buying a $14.95 certificate
> or setting up some kind of PKI infrastructure on the server-side
> is simply not a realistic suggestion.

Er, who said anything about the alternative being $14.95 certificates?

> These are real users with a real problem and as unsexy as
> it may be they deserve real security.

Agreed.

We need password-based mechanisms that work for you.  We also need
mechanisms that do other things.

For the kind of use you describe a PSK + [password-based] enrollment
mechanism might suffice.  But what if a blog host site and its users
could authenticate using credentials for some federated system?  Such
credentials might or might not cost $14.95 -- but some users will prefer
them over passwords.

Nico
-- 

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Date: Mon, 19 Dec 2005 09:58:24 -0800
To: Joe Gregorio <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

I believe Atom publishing has roughly the same requirements as CalDAV 
and WebDAV, so if this list ends up pursuing work which doesn't pursue 
those requirements, I for one would still pursue those requirements.  
It's just too early to split the list or declare stuff out of scope 
because we haven't even got a good problem statement yet.

Lisa

On Dec 19, 2005, at 7:31 AM, Joe Gregorio wrote:

> On 12/19/05, Nicolas Williams <[email-masked]> wrote:
>> On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
>>> I have seen a number of different topics go by on this list, and not
>>> certain what the goal is. Here are a couple stabs at what I, with my
>>> little bitty brain,  have gathered are the potential goals:
>>>
>>> 1) new mechanism for secure credential exchange that addresses the
>>> issues with digest mode of basic auth
>>>
>>> 2) ways for authentication mechanisms other than username/password be
>>> used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, 
>>> Kerberos
>>>
>>> Given the ease of MITM today if TLS is not used, and that someone
>>> could easily monitor and hijack a running session, I don't think (1)
>>> is possible. (but always keen to learn new things!)
>>
>> Password based mechanisms can be resistant to MITM attacks, but only 
>> if
>> the password equivalent/verifier held by the server is salted uniquely
>> and not shared with other servers or if the mechanism is a
>> proxied-Kerberos type mechanism (think EAP).
>>
>>> (2) is what I joined the list for.
>>
>> Me too.
>
> Then I am probably on the wrong list. As I said previously
> we have different target audiences that have different needs.
> Right now the status-quo in the weblog world is plain text
> passwords sent in an XML-RPC payload [1]. In many cases
> this is used to access either Blogger (which is free) or
> an installation of WordPress[2]. Buying a $14.95 certificate
> or setting up some kind of PKI infrastructure on the server-side
> is simply not a realistic suggestion.
>
> These are real users with a real problem and as unsexy as
> it may be they deserve real security.
>
>    -joe
>
> [1] http://www.blogger.com/developers/api/1_docs/xmlrpc_newPost.html
> [2] http://codex.wordpress.org/XML-RPC_Support
>
> --
> Joe Gregorio        http://bitworking.org
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

Date: Mon, 19 Dec 2005 10:31:42 -0500
From: Joe Gregorio <[email-masked]>
To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On 12/19/05, Nicolas Williams <[email-masked]> wrote:
> On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
> > I have seen a number of different topics go by on this list, and not
> > certain what the goal is. Here are a couple stabs at what I, with my
> > little bitty brain,  have gathered are the potential goals:
> >
> > 1) new mechanism for secure credential exchange that addresses the
> > issues with digest mode of basic auth
> >
> > 2) ways for authentication mechanisms other than username/password be
> > used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerbero=
s
> >
> > Given the ease of MITM today if TLS is not used, and that someone
> > could easily monitor and hijack a running session, I don't think (1)
> > is possible. (but always keen to learn new things!)
>
> Password based mechanisms can be resistant to MITM attacks, but only if
> the password equivalent/verifier held by the server is salted uniquely
> and not shared with other servers or if the mechanism is a
> proxied-Kerberos type mechanism (think EAP).
>
> > (2) is what I joined the list for.
>
> Me too.

Then I am probably on the wrong list. As I said previously
we have different target audiences that have different needs.
Right now the status-quo in the weblog world is plain text
passwords sent in an XML-RPC payload [1]. In many cases
this is used to access either Blogger (which is free) or
an installation of WordPress[2]. Buying a $14.95 certificate
or setting up some kind of PKI infrastructure on the server-side
is simply not a realistic suggestion.

These are real users with a real problem and as unsexy as
it may be they deserve real security.

   -joe

[1] http://www.blogger.com/developers/api/1_docs/xmlrpc_newPost.html
[2] http://codex.wordpress.org/XML-RPC_Support

--
Joe Gregorio        http://bitworking.org

Date: Mon, 19 Dec 2005 10:13:43 -0600
From: Nicolas Williams <[email-masked]>
To: Eric Rescorla <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 06:00:15AM -0800, Eric Rescorla wrote:
> Nicolas Williams <[email-masked]> writes:
> 
> > On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
> >> I have seen a number of different topics go by on this list, and not  
> >> certain what the goal is. Here are a couple stabs at what I, with my  
> >> little bitty brain,  have gathered are the potential goals:
> >> 
> >> 1) new mechanism for secure credential exchange that addresses the  
> >> issues with digest mode of basic auth
> >> 
> >> 2) ways for authentication mechanisms other than username/password be  
> >> used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerberos
> >> 
> >> Given the ease of MITM today if TLS is not used, and that someone  
> >> could easily monitor and hijack a running session, I don't think (1)  
> >> is possible. (but always keen to learn new things!)
> >
> > Password based mechanisms can be resistant to MITM attacks, but only if
> > the password equivalent/verifier held by the server is salted uniquely
> > and not shared with other servers or if the mechanism is a
> > proxied-Kerberos type mechanism (think EAP).
> 
> Or if it uses a PAKE method like EKE, SRP, etc....

Yes, but I assumed we'd all agree those are toxic.  I assumed that
simply because that's how it tends to work out.

Nico
-- 

To: Nicolas Williams <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Dec 2005 06:00:15 -0800
Cc: HTTP authentication list <[email-masked]>
Reply-To: EKR <[email-masked]>

Nicolas Williams <[email-masked]> writes:

> On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
>> I have seen a number of different topics go by on this list, and not  
>> certain what the goal is. Here are a couple stabs at what I, with my  
>> little bitty brain,  have gathered are the potential goals:
>> 
>> 1) new mechanism for secure credential exchange that addresses the  
>> issues with digest mode of basic auth
>> 
>> 2) ways for authentication mechanisms other than username/password be  
>> used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerberos
>> 
>> Given the ease of MITM today if TLS is not used, and that someone  
>> could easily monitor and hijack a running session, I don't think (1)  
>> is possible. (but always keen to learn new things!)
>
> Password based mechanisms can be resistant to MITM attacks, but only if
> the password equivalent/verifier held by the server is salted uniquely
> and not shared with other servers or if the mechanism is a
> proxied-Kerberos type mechanism (think EAP).

Or if it uses a PAKE method like EKE, SRP, etc....

-Ekr

Date: Mon, 19 Dec 2005 01:10:15 -0600
From: Nicolas Williams <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 12:51:49AM -0600, Nicolas Williams wrote:
> On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
> > Given the ease of MITM today if TLS is not used, and that someone  
> > could easily monitor and hijack a running session, I don't think (1)  
> > is possible. (but always keen to learn new things!)
> 
> Password based mechanisms can be resistant to MITM attacks, but only if
> the password equivalent/verifier held by the server is salted uniquely
> and not shared with other servers or if the mechanism is a
> proxied-Kerberos type mechanism (think EAP).

Of course, preventing an MITM from getting material suitable for
off-line dictionary attacks is another story altogether.

Anyways, we shouldn't probably be doing mechanism design on this list.

I would like us to focus on: supporting multiple mechanisms, primarily,
but also supporting channel binding to TLS and/or keying of TLS from
such mechanisms, as discussed at the Vancouver dinner BoF.

Nico
-- 

Date: Mon, 19 Dec 2005 01:04:12 -0600
From: Nicolas Williams <[email-masked]>
To: Joe Gregorio <[email-masked]>
Subject: Re: [Ietf-http-auth] Digest
Cc: HTTP authentication list <[email-masked]>

On Mon, Dec 19, 2005 at 12:06:49AM -0500, Joe Gregorio wrote:
> On 12/18/05, Scott Cantor <[email-masked]> wrote:
> > Perhaps, but any scheme that requires application servers to handle user
> > secrets is pretty impractical in my book.
> 
> For my edification, what do you consider a 'user secret'?
> For example, in the case of digest the server only needs to know
> H(A1) to verify the validity of an Authorization header, where
> H(A1) is an MD5 hash of the string
> 
>   unq(username-value) ":" unq(realm-value) ":" passwd
> 
> Would you consider H(A1) a 'user secret'?

If the security of the mechanism depends on H(A1) being kept secret,
then it, being derived from a user secret and also needing to be kept
secret, would, in fact, be a "user secret."

Now, if the server is to be authenticated to the client through a secret
derived from a user secret, then the security of the mechanism would,
indeed, depend on that derivative.

And you can't forgo authentication of the server to the client (or at
least shouldn't want to) though you might use something else for
authenticating the server to client -- but you quickly realize that that
something else has to be a public key, and I assume that you would like
to avoid public key crypto (though I also think you shouldn't want to
avoid it).

But even if you use something else for server authentication you still
want to keep the password verifiers private to avoid off-line dictionary
attacks -- or you can use a computationally expensive function to derive
the verifier from the user secret (but this function has to be made more
expensive over time).

Nico
-- 

Date: Mon, 19 Dec 2005 00:51:49 -0600
From: Nicolas Williams <[email-masked]>
To: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Cc: HTTP authentication list <[email-masked]>

On Sun, Dec 18, 2005 at 08:35:58PM -0800, Dick Hardt wrote:
> I have seen a number of different topics go by on this list, and not  
> certain what the goal is. Here are a couple stabs at what I, with my  
> little bitty brain,  have gathered are the potential goals:
> 
> 1) new mechanism for secure credential exchange that addresses the  
> issues with digest mode of basic auth
> 
> 2) ways for authentication mechanisms other than username/password be  
> used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerberos
> 
> Given the ease of MITM today if TLS is not used, and that someone  
> could easily monitor and hijack a running session, I don't think (1)  
> is possible. (but always keen to learn new things!)

Password based mechanisms can be resistant to MITM attacks, but only if
the password equivalent/verifier held by the server is salted uniquely
and not shared with other servers or if the mechanism is a
proxied-Kerberos type mechanism (think EAP).

> (2) is what I joined the list for.

Me too.

Nico
-- 

Date: Mon, 19 Dec 2005 00:48:49 -0600
From: Nicolas Williams <[email-masked]>
To: Joe Gregorio <[email-masked]>
Subject: Re: [Ietf-http-auth] Digest
Cc: HTTP authentication list <[email-masked]>

On Sun, Dec 18, 2005 at 11:25:29PM -0500, Joe Gregorio wrote:
> On 12/18/05, Scott Cantor <[email-masked]> wrote:
> > > What does everyone see as the flaws in Digest and what
> > > are the requirements for a new auth scheme?
> >
> > I haven't studied the details of Digest, but if it requires that the web
> > server share a secret with the user (i.e. a password), then it is useless
> > for my purposes. The only server with knowledge of that secret is somewhere
> > else on the network and the application web servers have no business knowing
> > it.
> 
> Correct me if I am wrong, but it sounds like you
> are saying that it's Kerberos or nothing.

Speaking for myself: it's not about ONE mechanism or credential type,
but about having the flexibility in the protocol to support more than
one.

> > There may be trickery that could be used to make the kinds of credentials
> > that systems like SAML use show up within the constraints of the digest
> > approach, but I'm not sure how that's better than just supporting a better
> > authentication scheme.
> 
> I think we have very different target audiences in mind.

If you get into details of specific mechanisms, then yes.

Passwords are a terrible type of credential, but also a lot better than
nothing.  Clearly we'll need useful passwrod-based mechanisms, and if
MD5-DIGEST needs work, then by all means let's work on it.  But many
environments have Kerberos V and/or PKIs deployed, and those kinds of
credentials should be supported.  As well as AAA, and SAML and anything
else that appears later (although I doubt we'll have radically new kinds
of credentials).

Nico
-- 

From: "Scott Cantor" <[email-masked]>
To: "'Dick Hardt'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Goals of this list?
Date: Mon, 19 Dec 2005 00:25:37 -0500
Organization: The Ohio State University
Cc: 'HTTP authentication list' <[email-masked]>

> That was why I joined. But given some of the other traffic, others  
> seem to be talking about other topics -- but perhaps I just don't  
> understand how digest fits into these newer purposes.

Yes, I'm inclined to agree, but not knowing a lot about it, I'm just keeping
an open mind, and I'm sure that there are probably multiple use cases here.

> Reviewing the prior HTTP standards, a major assumption is that there  
> is a person at the client end. In many of the "newer purposes", the user
may
> be quite distant from the client making the HTTP calls.

In mine, it's not necessarily that the user isn't there, it's that there's
distance between the application and the source of authentication, as in
fact I think is the right design in most cases. Most of the use cases I
specifically know of for unattended clients don't involve pure HTTP (e.g.
SOAP), not that I'm dismissing that either.

-- Scott

From: "Scott Cantor" <[email-masked]>
To: "'Joe Gregorio'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Digest
Date: Mon, 19 Dec 2005 00:20:42 -0500
Organization: The Ohio State University
Cc: 'HTTP authentication list' <[email-masked]>

> For my edification, what do you consider a 'user secret'?

I suppose anything directly derived from a piece of knowledge that would be
shared only by the user and an authentication source (such as Kerberos).

> For example, in the case of digest the server only needs to know
> H(A1) to verify the validity of an Authorization header, where
> H(A1) is an MD5 hash of the string
> 
>   unq(username-value) ":" unq(realm-value) ":" passwd
> 
> Would you consider H(A1) a 'user secret'?

Yes, I don't think that's practical. I can't expect all the possible sources
of authentication I would want my application servers to support to permit
me to ask them to compute that hash for me (some may not be at all related
to my organization, that's the whole point of federation).

In the case of Kerberos, it couldn't be done anyway unless the computation
was specifically over the string-to-key of the password.

I could be missing all sorts of tricks involving your basic example, I'm
just not sure I get the value of trying to shoehorn things into a digest
model unless it would somehow magically just work with existing clients, I
suppose.

-- Scott

Date: Mon, 19 Dec 2005 00:06:49 -0500
From: Joe Gregorio <[email-masked]>
To: Scott Cantor <[email-masked]>
Subject: Re: [Ietf-http-auth] Digest
Cc: HTTP authentication list <[email-masked]>

On 12/18/05, Scott Cantor <[email-masked]> wrote:
> > Correct me if I am wrong, but it sounds like you
> > are saying that it's Kerberos or nothing.
>
> Not at all.
>
> > I think we have very different target audiences in mind.
>
> Perhaps, but any scheme that requires application servers to handle user
> secrets is pretty impractical in my book.

For my edification, what do you consider a 'user secret'?
For example, in the case of digest the server only needs to know
H(A1) to verify the validity of an Authorization header, where
H(A1) is an MD5 hash of the string

  unq(username-value) ":" unq(realm-value) ":" passwd

Would you consider H(A1) a 'user secret'?

   -joe

--
Joe Gregorio        http://bitworking.org

From: Dick Hardt <[email-masked]>
Subject: Re: [Ietf-http-auth] Goals of this list?
Date: Sun, 18 Dec 2005 21:02:58 -0800
To: "Scott Cantor" <[email-masked]>
Cc: 'HTTP authentication list' <[email-masked]>

On 18-Dec-05, at 8:44 PM, Scott Cantor wrote:

>> If there are two different projects here, perhaps we should have one
>> on this list and the other on a second list?
>
> I don't think there are two projects, I thought the point was to  
> discuss how
> HTTP authentication might be better able to support the newer  
> purposes to
> which HTTP is actually being put these days, particularly in newer
> applications like WebDAV.

That was why I joined. But given some of the other traffic, others  
seem to be talking about other topics -- but perhaps I just don't  
understand how digest fits into these newer purposes.

Reviewing the prior HTTP standards, a major assumption is that there  
is a person at the client end.
In many of the "newer purposes", the user may be quite distant from  
the client making the HTTP calls.

-- Dick

From: "Scott Cantor" <[email-masked]>
To: "'HTTP authentication list'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Goals of this list?
Date: Sun, 18 Dec 2005 23:44:02 -0500
Organization: The Ohio State University

> If there are two different projects here, perhaps we should have one  
> on this list and the other on a second list?

I don't think there are two projects, I thought the point was to discuss how
HTTP authentication might be better able to support the newer purposes to
which HTTP is actually being put these days, particularly in newer
applications like WebDAV.

There may be differences of opinion (and in fact differences in knowledge)
about what the actual limitations of HTTP authentication are, or what the
"important" use cases for authentication are, which might lead to
differences of opinion about the solution(s).

I could be wrong, but I don't think this is intended to be a technical list
focused on driving toward a particular solution proposal, at least not at
this point, so carving up the dialog seems premature.

-- Scott

From: "Scott Cantor" <[email-masked]>
To: "'Joe Gregorio'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Digest
Date: Sun, 18 Dec 2005 23:36:10 -0500
Organization: The Ohio State University
Cc: 'HTTP authentication list' <[email-masked]>

> Correct me if I am wrong, but it sounds like you
> are saying that it's Kerberos or nothing.

Not at all.

> I think we have very different target audiences in mind.

Perhaps, but any scheme that requires application servers to handle user
secrets is pretty impractical in my book. Regardless, why does a solution
have to preclude my use cases or yours?

One response has already indicated that my requirement doesn't preclude
digest. That's why I led with the caveat that I know nothing about it, so
maybe it's capable of encompassing what single sign-on systems do. Certainly
that isn't the perception out there, so perhaps there's some education
needed.

-- Scott

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Dec 2005 20:35:58 -0800
To: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Goals of this list?

I have seen a number of different topics go by on this list, and not  
certain what the goal is. Here are a couple stabs at what I, with my  
little bitty brain,  have gathered are the potential goals:

1) new mechanism for secure credential exchange that addresses the  
issues with digest mode of basic auth

2) ways for authentication mechanisms other than username/password be  
used to authenticate to a server eg. SAML, SXIP, Infocard/WS-*, Kerberos

Given the ease of MITM today if TLS is not used, and that someone  
could easily monitor and hijack a running session, I don't think (1)  
is possible. (but always keen to learn new things!)

(2) is what I joined the list for.

If there are two different projects here, perhaps we should have one  
on this list and the other on a second list?

my $0.02 worth

-- Dick

Date: Sun, 18 Dec 2005 23:25:29 -0500
From: Joe Gregorio <[email-masked]>
To: Scott Cantor <[email-masked]>
Subject: Re: [Ietf-http-auth] Digest
Cc: HTTP authentication list <[email-masked]>

On 12/18/05, Scott Cantor <[email-masked]> wrote:
> > What does everyone see as the flaws in Digest and what
> > are the requirements for a new auth scheme?
>
> I haven't studied the details of Digest, but if it requires that the web
> server share a secret with the user (i.e. a password), then it is useless
> for my purposes. The only server with knowledge of that secret is somewhe=
re
> else on the network and the application web servers have no business know=
ing
> it.

Correct me if I am wrong, but it sounds like you
are saying that it's Kerberos or nothing.

> There may be trickery that could be used to make the kinds of credentials
> that systems like SAML use show up within the constraints of the digest
> approach, but I'm not sure how that's better than just supporting a bette=
r
> authentication scheme.

I think we have very different target audiences in mind.

   -joe

--
Joe Gregorio        http://bitworking.org

Subject: RE: [Ietf-http-auth] Digest
From: Scott Lawrence <[email-masked]>
To: Scott Cantor <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Sun, 18 Dec 2005 22:09:59 -0500
Cc: 'HTTP authentication list' <[email-masked]>

On Sun, 2005-12-18 at 22:04 -0500, Scott Cantor wrote:
> > What does everyone see as the flaws in Digest and what
> > are the requirements for a new auth scheme?
> 
> I haven't studied the details of Digest, but if it requires that the web
> server share a secret with the user (i.e. a password), then it is useless
> for my purposes. The only server with knowledge of that secret is somewhere
> else on the network and the application web servers have no business knowing
> it.

In the Digest md5-sess mode this is not required.

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

From: "Scott Cantor" <[email-masked]>
To: "'Joe Gregorio'" <[email-masked]>, "'HTTP authentication list'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Digest
Date: Sun, 18 Dec 2005 22:04:50 -0500
Organization: The Ohio State University

> What does everyone see as the flaws in Digest and what
> are the requirements for a new auth scheme?

I haven't studied the details of Digest, but if it requires that the web
server share a secret with the user (i.e. a password), then it is useless
for my purposes. The only server with knowledge of that secret is somewhere
else on the network and the application web servers have no business knowing
it.

There may be trickery that could be used to make the kinds of credentials
that systems like SAML use show up within the constraints of the digest
approach, but I'm not sure how that's better than just supporting a better
authentication scheme.

-- Scott

Date: Sun, 18 Dec 2005 01:48:51 -0500
From: Joe Gregorio <[email-masked]>
To: HTTP authentication list <[email-masked]>
Subject: [Ietf-http-auth] Digest

On 11/15/05, Roy T. Fielding <[email-masked]> wrote:
> > We had a great participation from security experts at the HTTP-Auth
> > bar BOF, but not so many HTTP experts.  Is there anybody implementing
> > HTTP, WebDAV or CalDAV, or other HTTP-based protocol, or who would be
> > likely to implement a new security mechanism, and who can evaluate or
> > even react to the various security proposals?
> >
> > Joe(s)? Justin? Scott? Mike? Roy? Jeff?
>
> Not if it involves SAML or SASL.  SAML is too complicated and
> restricted by patents.  SASL is not suitable for use in
> stateless communication protocols.
>
> HTTP Digest isn't used because the algorithm was flawed (hash
> of password instead of hash of hashed password), too much
> baggage was added on for the sake of non-repeatable hashes
> and message integrity, and because a single bug in MSIE
> (truncating query args from the URI before hashing) interferes
> with deployment.  HTTP auth isn't used in general because browsers
> ignore the HTML content of the 401 message and present idiotic
> dialogs instead.
>
> What we need is a simple mechanism for the server to indicate
> to the client that digest authentication is available and to
> use the included message as the input dialog.  If digest isn't
> good enough, then define an HTTP AA method that is -- just don't
> waste our time with any session-based junk.

Digest does have its problems but I think it is a good place
to start a discussion. Roy has already listed some of its
flaws:

1. Hash of password instead of hash of hashed password
2. Too much baggage was added on for the sake of
     non-repeatable hashes and message integrity
    (I can vouch for this, having implemented a variant of Digest myself,
    there are just too many options and variants, "qop" =3D("auth" | "auth-=
int"),
    "algorithm" "=3D" ( "MD5" | "MD5-sess")
    nonce count, etc.)

I can also add:

3. It is also vulnerable to the man in the middle attacks.

What does everyone see as the flaws in Digest and what
are the requirements for a new auth scheme?

   -joe

--
Joe Gregorio        http://bitworking.org

Date: Mon, 12 Dec 2005 10:44:55 -0500
From: Joe Gregorio <[email-masked]>
To: EKR <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
Cc: [email-masked]

On 12/12/05, Eric Rescorla <[email-masked]> wrote:
> Mike Shaver <[email-masked]> writes:
>
> > On 12-Dec-05, at 9:16 AM, Joe Gregorio wrote:
> >
> >> Isn't SSL tied to a specific IP address, and thus not an option in
> >> a shared hosting scenario?
> >
> > I believe it to be very rare for a certificate to be associated with
> > a specific IP address.  That would make most load balancing or simple
> > network-renumbering tasks vastly more difficult.
>
> I should mention that it's quite safe to have multiple IP addresses
> use the same certificate. It's going the other way that's the problem.

Yes, it is 'the other way around', one IP for multiple domain names,
that I was asking about.

   Thanks,
   -joe

--
Joe Gregorio        http://bitworking.org

From: "Scott Cantor" <[email-masked]>
To: "'Mike Shaver'" <[email-masked]>, "'Joe Gregorio'" <[email-masked]>
Subject: RE: [Ietf-http-auth] Whay is caldav special?
Date: Mon, 12 Dec 2005 10:44:12 -0500
Organization: The Ohio State University
Cc: [email-masked]

> > Isn't SSL tied to a specific IP address, and thus not an option in
> > a shared hosting scenario?
> 
> I believe it to be very rare for a certificate to be associated with  
> a specific IP address.  That would make most load balancing or simple  
> network-renumbering tasks vastly more difficult.

No, I think he's referring to the fact that for a single web server to host
multiple certificates requires using either multiple ports or multiple
addresses. If you dismiss the port option due to user issues, then indeed
SSL can be said to be "tied to a specific IP address".

-- Scott

To: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2005 07:38:35 -0800
Cc: [email-masked]
Reply-To: EKR <[email-masked]>

Mike Shaver <[email-masked]> writes:

> On 12-Dec-05, at 9:16 AM, Joe Gregorio wrote:
>
>> Isn't SSL tied to a specific IP address, and thus not an option in
>> a shared hosting scenario?
>
> I believe it to be very rare for a certificate to be associated with
> a specific IP address.  That would make most load balancing or simple
> network-renumbering tasks vastly more difficult.

I should mention that it's quite safe to have multiple IP addresses
use the same certificate. It's going the other way that's the problem.

-Ekr

To: Joe Gregorio <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Dec 2005 07:37:04 -0800
Cc: [email-masked]
Reply-To: EKR <[email-masked]>

Joe Gregorio <[email-masked]> writes:

> On 11/7/05, Scott Cantor <[email-masked]> wrote:
>> > > * Transmitting all page data over TLS puts too great a load on the
>> > >  servers.   Using a form allows just the form submission to be made
>> > >  over TLS.  This allows logon forms to be embedded as part of public
>> > >  multi-purpose web pages
>> >
>> > I've never understood this argument, since I always thought the vast
>> > majority of CPU hit is in the initial TLS establishment, not the stream
>> > protection, but I agree that people make the argument.
>>
>> I don't understand it because it means the actual protection of the
>> application reduces to a cookie that's exposed over an insecure channel,
>> which means the initial authentication itself starts to look rather
>> pointless. I have a pretty firm strategy here about making people asking to
>> limit the use of TLS feel somewhat silly about it.
>>
>> The usual arguments here against SSL tend to be cost. And that's also no
>> longer an issue with the rise of $14.95 certificates.
>
> Isn't SSL tied to a specific IP address, and thus not an option in
> a shared hosting scenario?

You're talking about name-based virtual hosting here, right?

Name-based virtual hosting in HTTP is done via the Host header.

If you're using 3rd party certificates for SSL server authentication,
then they're supposed to (RFC 2818) contain the server's host name.
But in a virtual hosting scenario, the server doesn't know which
certificate to provide until it's seen the Host header, which happens
after the SSL handshake. Doh!

There's an extension (RFC 3546) to carry this in the TLS ClientHello
field, but it's not widely implemented in servers. I'm not really
up on the level of client deployment (though my impression is its
low). Maybe someone from Mozilla can chime in...

At any rate, it's a "simple matter of programming".

-Ekr

From: Mike Shaver <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
Date: Mon, 12 Dec 2005 10:30:18 -0500
To: Joe Gregorio <[email-masked]>
Cc: [email-masked]

On 12-Dec-05, at 9:16 AM, Joe Gregorio wrote:

> Isn't SSL tied to a specific IP address, and thus not an option in
> a shared hosting scenario?

I believe it to be very rare for a certificate to be associated with  
a specific IP address.  That would make most load balancing or simple  
network-renumbering tasks vastly more difficult.

Mike

Date: Mon, 12 Dec 2005 09:16:47 -0500
From: Joe Gregorio <[email-masked]>
To: Scott Cantor <[email-masked]>
Subject: Re: [Ietf-http-auth] Whay is caldav special?
Cc: [email-masked]

On 11/7/05, Scott Cantor <[email-masked]> wrote:
> > > * Transmitting all page data over TLS puts too great a load on the
> > >  servers.   Using a form allows just the form submission to be made
> > >  over TLS.  This allows logon forms to be embedded as part of public
> > >  multi-purpose web pages
> >
> > I've never understood this argument, since I always thought the vast
> > majority of CPU hit is in the initial TLS establishment, not the stream
> > protection, but I agree that people make the argument.
>
> I don't understand it because it means the actual protection of the
> application reduces to a cookie that's exposed over an insecure channel,
> which means the initial authentication itself starts to look rather
> pointless. I have a pretty firm strategy here about making people asking =
to
> limit the use of TLS feel somewhat silly about it.
>
> The usual arguments here against SSL tend to be cost. And that's also no
> longer an issue with the rise of $14.95 certificates.

Isn't SSL tied to a specific IP address, and thus not an option in
a shared hosting scenario?

   -joe

--
Joe Gregorio        http://bitworking.org

From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez_Vega?= <[email-masked]>
Subject: Re: [Ietf-http-auth] Fwd: BeyondBasicAuthBof scheduling @ ApacheCon
Date: Thu, 8 Dec 2005 17:37:52 -0800
To: Lisa Dusseault <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

   A lightning lottery talk on the issue and why it needs to be  
solved would be welcome (plenary session, Tuesday 7:30PM) and may be  
a good chance to solicit interest in the BoF.

   Ping me at the conference (at the start of the session at the  
latest) if you are interested.

	-wsv

On Dec 7, 2005, at 3:13 PM, Lisa Dusseault wrote:

> FYI, just to see if any implementors were interested in working on  
> this topic, I asked for an ApacheCon BOF on the topic.  Help and  
> attendance is very welcome.
>
> Lisa
>
>
> Begin forwarded message:
>
>> From: Kenneth Tam <[email-masked]>
>> Date: December 7, 2005 3:08:05 PM PST
>> To: [email-masked]
>> Subject: BeyondBasicAuthBof scheduling @ ApacheCon
>>
>> Hi Lisa,
>>
>> I have a request of you, assuming you're the organizer of the
>> BeyondBasicAuthBof on Monday:
>>
>> http://wiki.apache.org/apachecon/BirdsOfaFeather
>>
>> I'm organizing the TuscanyScaBof which is in the same timeslot; I'd
>> like to trade locations with you, as our topic is very relevant to  
>> the
>> BoF going on in that room during the previous timeslot (SOA with
>> ServiceMix), and we think the audiences will likely overlap a
>> reasonable amount.  If that's fine with you, just let me know and  
>> I'll
>> edit the wiki appropriately.
>>
>> thanks!
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

From: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Fwd: BeyondBasicAuthBof scheduling @ ApacheCon
Date: Wed, 7 Dec 2005 15:47:33 -0800
To: Paul Querna <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

Looks like I was able to change it to Tues 8:30 pm.

Lisa

On Dec 7, 2005, at 3:31 PM, Paul Querna wrote:

> Lisa Dusseault wrote:
>> FYI, just to see if any implementors were interested in working on  
>> this
>> topic, I asked for an ApacheCon BOF on the topic. Help and attendance  
>> is
>> very welcome.
>>
>
> Can you ask to get it moved to a different time?
>
> It is currently conflicting with the Berkeley DB BOF, where they are
> giving out free beer and pizza. Oh, and I have an interest in both
> BOFs...  Tuesday would be good :)
>
> Thanks,
>
> Paul
>
>> Lisa
>>
>>
>> Begin forwarded message:
>>
>>     *From: *Kenneth Tam <[email-masked]>
>>     *Date: *December 7, 2005 3:08:05 PM PST
>>     *To: [email-masked]
>>     *Subject: BeyondBasicAuthBof scheduling @ ApacheCon
>>     *
>>     Hi Lisa,
>>
>>     I have a request of you, assuming you're the organizer of the
>>     BeyondBasicAuthBof on Monday:
>>
>>     http://wiki.apache.org/apachecon/BirdsOfaFeather
>>
>>     I'm organizing the TuscanyScaBof which is in the same timeslot;  
>> I'd
>>     like to trade locations with you, as our topic is very relevant  
>> to the
>>     BoF going on in that room during the previous timeslot (SOA with
>>     ServiceMix), and we think the audiences will likely overlap a
>>     reasonable amount. If that's fine with you, just let me know and  
>> I'll
>>     edit the wiki appropriately.
>>
>>     thanks!
>>
>>
>> ---------------------------------------------------------------------- 
>> --
>>
>> _______________________________________________
>> Ietf-http-auth mailing list
>> [email-masked]
>> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>

Date: Wed, 07 Dec 2005 15:31:00 -0800
From: Paul Querna <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Subject: Re: [Ietf-http-auth] Fwd: BeyondBasicAuthBof scheduling @ ApacheCon
Cc: HTTP authentication list <[email-masked]>

Lisa Dusseault wrote:
> FYI, just to see if any implementors were interested in working on this
> topic, I asked for an ApacheCon BOF on the topic. Help and attendance is
> very welcome.
> 

Can you ask to get it moved to a different time?

It is currently conflicting with the Berkeley DB BOF, where they are
giving out free beer and pizza. Oh, and I have an interest in both
BOFs...  Tuesday would be good :)

Thanks,

Paul

> Lisa
> 
> 
> Begin forwarded message:
> 
>     *From: *Kenneth Tam <[email-masked]>
>     *Date: *December 7, 2005 3:08:05 PM PST
>     *To: [email-masked]
>     *Subject: BeyondBasicAuthBof scheduling @ ApacheCon
>     *
>     Hi Lisa,
> 
>     I have a request of you, assuming you're the organizer of the
>     BeyondBasicAuthBof on Monday:
> 
>     http://wiki.apache.org/apachecon/BirdsOfaFeather
> 
>     I'm organizing the TuscanyScaBof which is in the same timeslot; I'd
>     like to trade locations with you, as our topic is very relevant to the
>     BoF going on in that room during the previous timeslot (SOA with
>     ServiceMix), and we think the audiences will likely overlap a
>     reasonable amount. If that's fine with you, just let me know and I'll
>     edit the wiki appropriately.
> 
>     thanks!
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

To: HTTP authentication list <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Wed, 7 Dec 2005 15:13:03 -0800
Subject: [Ietf-http-auth] Fwd: BeyondBasicAuthBof scheduling @ ApacheCon

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

FYI, just to see if any implementors were interested in working on this 
topic, I asked for an ApacheCon BOF on the topic.  Help and attendance 
is very welcome.

Lisa

Begin forwarded message:

> From: Kenneth Tam <[email-masked]>
> Date: December 7, 2005 3:08:05 PM PST
> To: [email-masked]
> Subject: BeyondBasicAuthBof scheduling @ ApacheCon
>
> Hi Lisa,
>
> I have a request of you, assuming you're the organizer of the
> BeyondBasicAuthBof on Monday:
>
> http://wiki.apache.org/apachecon/BirdsOfaFeather
>
> I'm organizing the TuscanyScaBof which is in the same timeslot; I'd
> like to trade locations with you, as our topic is very relevant to the
> BoF going on in that room during the previous timeslot (SOA with
> ServiceMix), and we think the audiences will likely overlap a
> reasonable amount.  If that's fine with you, just let me know and I'll
> edit the wiki appropriately.
>
> thanks!

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

FYI, just to see if any implementors were interested in working on
this topic, I asked for an ApacheCon BOF on the topic.  Help and
attendance is very welcome.

Lisa

Begin forwarded message:

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

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>December 7, 2005 3:08:05 PM PST

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

<bold><color><param>0000,0000,0000</param>Subject:
</color>BeyondBasicAuthBof scheduling @ ApacheCon

</bold>

Hi Lisa,

I have a request of you, assuming you're the organizer of the

BeyondBasicAuthBof on Monday:

http://wiki.apache.org/apachecon/BirdsOfaFeather

I'm organizing the TuscanyScaBof which is in the same timeslot; I'd

like to trade locations with you, as our topic is very relevant to the

BoF going on in that room during the previous timeslot (SOA with

ServiceMix), and we think the audiences will likely overlap a

reasonable amount.  If that's fine with you, just let me know and I'll

edit the wiki appropriately.

thanks!

</excerpt>
--Apple-Mail-6-1071160924--