i.e. SRV or similar. I can show people = how to fix up the issues to do with use of non-canonical names.

Client authenticates to authentication ser= vice using any protocol they both support.

This is quite simple to implement, just stick a list of supported auth= services in the DNS.

We can re-use all those exis= ting auth protocols that work (SAML would be a good choice but we don't= need to be overly restrictive here.)

HTTP carries a standardized, non-linkable = auth token

I have so= me ideas on how we could modify DIGEST to do this. DIGEST would not be prob= lematic if the password had 128 bits of ergodicity and we upgraded the dige= st function.

The reason for re-using DIGEST here would be to avoid p= atent encumbrances. I considered the issue of linkability at great length w= hen writing the original DIGEST design.

At the moment I am focused on getting the foundation laid. B= ut I will try to come up with a full proposal before Prague.

I know that you can achieve some of the desired aut= hentication properties with public keys at the client. The problem is that = our current use of computers has gone way beyond the one-machine-per-person= paradigm

On a recent trip to Europe with the family I counted th= at we had 10 computers with us capable of supporting IP (3 laptops, 3 iPhon= es, 2 Nintendos, 1 iPad and a kindle).

Cardspace h= as some really, really great properties but they are totally lost when you = try to make the service accessible from multiple machines by putting it = 9;in the cloud'. In fact, other than a manager, I have never found anyo= ne who reven thinks they know what they mean by 'in the cloud' for = CardSpace. I certainly have never seen an explanation I can understand.=A0<= /div>

Devices get lost. Devices get stolen. We don't want= to encourage that so there needs to be something more than just a certific= ate based client auth scheme.

I thi= nk we need some form of centralized (for given account) account management = in the mix so that the user can authorize/deauthorize devices for use (c.f.= Amazon's Kindle account management)

So there are basically two architectural options for us= ing public key. One is to use it strictly between the client and the auth s= ervice and use a token like approach as discussed above. Another is for the= auth service to issue an assertion of the form 'you can tell its fred = by this public key (amongst others)'.

SAML already has support for both approaches BTW.=A0

On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie <= benl@google.com> wrote:
> >
> On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
>>
>> >= ; Peter Saint-Andre <stpeter@stpet= er.im> wrote:
>> > 2. In 2007, Robert Sayre put together a few slides on the top= ic:
>> > http://people.mozilla.com/~sayrer/2007/auth.html
>>
>> These are back on the Web, in case anyone missed them (probably no= t).
>>
>> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fieldin= g <fielding@gbiv.com>
>= ;> wrote:
>> >
>> > Define them all and let's have a bake-of= f. =A0It has been 16 years since
>> > HTTP auth was taken out o= f our hands so that the security experts could
>> > define some= thing perfect. =A0Zero progress so far.
>>
>> I think the IETF might do better to focus on a smaller= problem, at
>> first. People often use self-signed certificates w= ith HTTP/TLS, even
>> though the first thing their websites ask th= e user to do is type a
>> username and password into a form. There are some well-understood = ways
>> to make this process more secure. Why hasn't the IETF = fixed this
>> problem? If this smaller problem has no ready soluti= on, then the
>> larger issue of authentication on the entire Web seems like a toug= h
>> nut to crack.
>
> Two comments (one really being = a response to Roy):
> 1. The IETF has fixed the problem, but no-one i= s using the fix - perhaps
> because it is not clear that it is the fix. I speak of RFC 4279, TLS> pre-shared keys. These could be derived from a hash of the password = and the
> site name, for example, and thus provide secure mutual auth= entication
> despite password reuse.
> 2. I have often heard (though I am not= aware of hard evidence for this,
> nevertheless I find it plausible)= that one reason no-one has bothered to
> improve HTTP auth is becaus= e no-one would use it since site owners want to
> control the user experience around signin. It seems to me, therefore, = that
> HTTP is the wrong layer to fix the problem at - it needs to be= pushed down
> into HTML or Javascript so that the page can control t= he look, while
> appropriate HTML elements or JS code can deal with the secure exchange= of
> data.
> Of course, this still leaves the issue of trusted= path: although we can
> provide elements which are safe to use, even= when being phished, how does
> the user know those elements are actually being used, rather than simu= lated
> so as to get hold of the underlying password?
> The ans= wer to this problem is hard, since it brings us back to taking the UI
> out of the sites hands.
> =A0
>>
>> It could b= e that the reasons for this lack of progress are
>> nontechnical. = Just throwing that out there.
>
> If you think UI is nontechnic= al, then I agree.
> Cheers,
> Ben.
>
> _________________________________= ______________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>

--
Website: http://hallambaker.com/

--0016e644dbc60acc57049957ef07-- From hallam@gmail.com Sat Jan 8 08:19:38 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3AE28C13A; Sat, 8 Jan 2011 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv2k8-0ECqSB; Sat, 8 Jan 2011 08:19:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DD14728C116; Sat, 8 Jan 2011 08:19:34 -0800 (PST) Received: by yxt33 with SMTP id 33so7991387yxt.31 for ; Sat, 08 Jan 2011 08:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P/kVq8JqTkbriAI2YHZ98j+IH6nPYaKiXLgMS1MrhJg=; b=gj3y71kH8mkwf9cxcnOrEcJQbI+UOFHppgDDPLZGHIdfFFp2xvOoVOpWrXtvD+yUkA +LKTe3Xre6ZFVGT3kLsOPfjpJ4+FCR/k4ryZHG6UBxHuR3hliF/G0Ra32UC7Ftq25kiT CSSObZqQKWywj3P9ZvOUXBi4SBO5ct7i6a2U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=akVsGITiA3khO4gDCJU1IG1XlVTf0CvbBpjMaP9HTk7XT1qtjcDuiz08xafz+rqNOS +wqrQGZtiyzvfSjsGG6J0XLtD94i1iVJMpQmw12JwA00AmVcNDKtrDrIp3Wm4HuFW/B6 MyZXCnpieOCjP1JWjS/yGhBmH0vu4YVZLrxzI= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr15882518ank.1.1294503702896; Sat, 08 Jan 2011 08:21:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:21:42 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:21:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=00163662e65b5f211d049958212f Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:19:38 -0000 --00163662e65b5f211d049958212f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > On 6 January 2011 16:03, David Morris wrote: > > > > > > On Thu, 6 Jan 2011, Ben Laurie wrote: > > > >> The answer to this problem is hard, since it brings us back to taking > the UI > >> out of the sites hands. > > > > Which is only helpful if you can somehow gaurantee that the user agent > > software hasn't been compromised. Not something I'd bet on... > > That's rather overstating it. It's perfectly helpful when the UA > software hasn't been compromised, which is a non-zero fraction of the > time. > > When the UA s/w has been compromised I'm quite happy to fail to fix > the problem: the right answer to that is to improve the robustness of > the UA. +1 If the UA is stuffed then the user is totally and utterly stuffed anyway. In particular if the UA is stuffed then a forms based experience is just as stuffed. If we are going to hypothecate attack models people have to be willing to apply them to their preferred solution too. The sensible approach is to work out how to stop the user from being stuffed e.g. * Comodo's free Anti-Virus with Default Deny Protection (TM) * Use code signing + trustworthy computing * Use a restricted browser Now I have a lot of ideas on how we can tackle these, but they are not relevant to this debate. I do however have a different take on the UI issue. HTML forms did have an advantage over the pathetic UI that browsers provided for BASIC and DIGEST (most don't even tell the user which is in use). But a federated auth scheme supported at the HTTP level could be simpler still. Instead of the user having to register for each site, they register once. Instead of the user having to log in to each site they log in once per session. Instead of the site having to manage lost passwords and forgotten accounts because the user has hundreds, this problem does not exist. It is a user interface crisis that is driving this need in my view. -- Website: http://hallambaker.com/ --00163662e65b5f211d049958212f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:

On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>
>
> On Thu, 6 Jan 2011, Ben Laurie wrote:
>
>> The answer to this problem is hard, since it brings us back to tak= ing the UI
>> out of the sites hands.
>
> Which is only helpful if you can somehow gaurantee that the user agent=
> software hasn't been compromised. Not something I'd bet on...<= br>

That's rather overstating it. It's perfectly helpful when the= UA
software hasn't been compromised, which is a non-zero fraction of the time.

When the UA s/w has been compromised I'm quite happy to fail to fix
the problem: the right answer to that is to improve the robustness of
the UA.

If the = UA is stuffed then the user is totally and utterly stuffed anyway.=A0

In particular if the UA is stuffed then a forms based e= xperience is just as stuffed. If we are going to hypothecate attack models = people have to be willing to apply them to their preferred solution too.

The sensible approach is to work out how= to stop the user from being stuffed e.g.=A0

=A0* = Comodo's free Anti-Virus with Default Deny Protection (TM)

= =A0* Use code signing + trustworthy computing

=A0* Use a restricted browser=A0

Now I have a= lot of ideas on how we can tackle these, but they are not relevant to this= debate.

I do however have a differ= ent take on the UI issue.=A0

HTML forms did have an advantage over the pathetic UI t= hat browsers provided for BASIC and DIGEST (most don't even tell the us= er which is in use).

But a federated auth scheme s= upported at the HTTP level could be simpler still. Instead of the user havi= ng to register for each site, they register once. Instead of the user havin= g to log in to each site they log in once per session. Instead of the site = having to manage lost passwords and forgotten accounts because the user has= hundreds, this problem does not exist.

It is a user interface crisis that is dr= iving this need in my view.

-- Website: http://hallambaker.com/
--00163662e65b5f211d049958212f-- From hallam@gmail.com Sat Jan 8 09:50:39 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2C23A67FB; Sat, 8 Jan 2011 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20paQQnmkSN0; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4885D3A67E3; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: by gxk28 with SMTP id 28so8482976gxk.31 for ; Sat, 08 Jan 2011 09:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6bo8ZioF39rKL6lWvOQo5g2WqHHhQncsxAnkblyge2E=; b=jWIHeGDUOh6avcUiKYI7wTYJwXy3jV8Acwp85reJHuvwsDKt8TaSgr8SGj5bn7Q7bv jG2GSHJKVTAA9sgZKU7NZ4wuZ42O+jZbnhxcQUq74l1TCZaXmMIaC0yNxPR6LkqMfWnL tuiYH6ugrFSmbfe0lfKwHBKdlGFwnHo2lWpJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g3FpArmvl34jXqveOoAO3WWa9XUrTArhTTE14LqMm9R3QH4k7wPphX8fK/KgZnsYnM jBigHkW3i9jMtNPJtsOOxoaJFUSZhDnDiNwBUhJwN42VR72PMU6XBpttZm04NoXcFF3p +mWIZVwfHvsxDrYrql6OzS8B9K/d4dEIHJ0SA= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2521122ane.171.1294509165388; Sat, 08 Jan 2011 09:52:45 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 09:52:45 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

Date: Sat, 8 Jan 2011 12:52:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Blaine Cook Content-Type: multipart/alternative; boundary=0016e644dbc6f623100499596635 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:50:39 -0000 --0016e644dbc6f623100499596635 Content-Type: text/plain; charset=ISO-8859-1 OAUTH and Webfinger are both pretty much as good as you can expect to achieve if you decide at the start that you are not going to modify the infrastructure. But that decision limits what you can expect to achieve. A particular problem with OAuth is that you can only use the identity providers that are supported by the particular site. So I had to use my Twitter account to play spymaster. And when Twitter got shirty and started blocking other players accounts they lost their game account and their twitter account at the same time. There are people who think I should get a facebook account just so that I can use their application. Not happening. As for WebFinger, it works, but not nearly as well as a clean DNS scheme. DNS is designed to address this problem, HTTP is not. And solving the problem with HTTP requires us to have a scheme that involves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to make matters work some those parts are not just moving, they are changing. I think it is a very good idea to look at WebFinger and OAuth and see how to realize these approaches direct in the infrastructure. But they should be seen as starting points, not ends. On Sat, Jan 8, 2011 at 12:37 PM, Blaine Cook wrote: > Two points: > > 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all > don't like it, but it's used to authenticate more HTTP requests by > volume and users than everything-except-cookies combined. You may want > to consider the design of OAuth when proceeding with these > discussions, rather than the laundry list of [completely] failed > protocols. > > 2. With respect to federated auth, especially using email address-like > identifiers, there has been a bevy of (deployed) work in this regard. > The effort is called webfinger, and is worth a look. Instead of DNS, > we use host-meta based HTTP lookups to dereference the identifiers. > Many diaspora and status.net installs are using it today, and there > are several proposals towards building a security & privacy > infrastructure on top of webfinger (webid is one such proposal whose > incorporation of client-side TLS certificates in a browser context > makes me very weary of its potential for success). > > b. > > On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: > >> > >> On 6 January 2011 16:03, David Morris wrote: > >> > > >> > > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: > >> > > >> >> The answer to this problem is hard, since it brings us back to taking > >> >> the UI > >> >> out of the sites hands. > >> > > >> > Which is only helpful if you can somehow gaurantee that the user agent > >> > software hasn't been compromised. Not something I'd bet on... > >> > >> That's rather overstating it. It's perfectly helpful when the UA > >> software hasn't been compromised, which is a non-zero fraction of the > >> time. > >> > >> When the UA s/w has been compromised I'm quite happy to fail to fix > >> the problem: the right answer to that is to improve the robustness of > >> the UA. > > > > +1 > > If the UA is stuffed then the user is totally and utterly stuffed anyway. > > In particular if the UA is stuffed then a forms based experience is just > as > > stuffed. If we are going to hypothecate attack models people have to be > > willing to apply them to their preferred solution too. > > > > The sensible approach is to work out how to stop the user from being > stuffed > > e.g. > > * Comodo's free Anti-Virus with Default Deny Protection (TM) > > * Use code signing + trustworthy computing > > * Use a restricted browser > > Now I have a lot of ideas on how we can tackle these, but they are not > > relevant to this debate. > > > > I do however have a different take on the UI issue. > > HTML forms did have an advantage over the pathetic UI that browsers > provided > > for BASIC and DIGEST (most don't even tell the user which is in use). > > But a federated auth scheme supported at the HTTP level could be simpler > > still. Instead of the user having to register for each site, they > register > > once. Instead of the user having to log in to each site they log in once > per > > session. Instead of the site having to manage lost passwords and > forgotten > > accounts because the user has hundreds, this problem does not exist. > > > > It is a user interface crisis that is driving this need in my view. > > > > -- > > Website: http://hallambaker.com/ > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > -- Website: http://hallambaker.com/ --0016e644dbc6f623100499596635 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OAUTH and Webfinger are both pretty much as good as you can expect to achie= ve if you decide at the start that you are not going to modify the infrastr= ucture.

But that decision limits what you can expect to = achieve.

A particular problem with OAuth is that = you can only use the identity providers that are supported by the particula= r site. So I had to use my Twitter account to play spymaster. And when Twit= ter got shirty and started blocking other players accounts they lost their = game account and their twitter account at the same time.

There are people who think I should get a facebook acco= unt just so that I can use their application. Not happening.

As for WebFinger, it works, but not nearly as wel= l as a clean DNS scheme. DNS is designed to address this problem, HTTP is n= ot. And solving the problem with HTTP requires us to have a scheme that inv= olves DNS + HTTP + SSL + PKIX which is rather a lot of moving parts and to = make matters work some those parts are not just moving, they are changing.<= /div>

I think it is a very good idea to look a= t WebFinger and OAuth and see how to realize these approaches direct in the= infrastructure. But they should be seen as starting points, not ends.

On Sat, Jan 8, 2011 at 12:37 PM, Bl= aine Cook <romeda@= gmail.com> wrote:

Two points:

1. In this entire thread, no-one has mentioned OAuth. Maybe y'all
don't like it, but it's used to authenticate more HTTP requests by<= br> volume and users than everything-except-cookies combined. You may want
to consider the design of OAuth when proceeding with these
discussions, rather than the laundry list of [completely] failed
protocols.

2. With respect to federated auth, especially using email address-like
identifiers, there has been a bevy of (deployed) work in this regard.
The effort is called webfinger, and is worth a look. Instead of DNS,
we use host-meta based HTTP lookups to dereference the identifiers.
Many diaspora and status.ne= t installs are using it today, and there
are several proposals towards building a security & privacy
infrastructure on top of webfinger (webid is one such proposal whose
incorporation of client-side TLS certificates in a browser context
makes me very weary of its potential for success).

b.

On 8 January 2011 08:21, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie <benl@google.com> wrote:
>>
>> On 6 January 2011 16:03, David Morris <dwm@xpasc.com> wrote:
>> >
>> >
>> > On Thu, 6 Jan 2011, Ben Laurie wrote:
>> >
>> >> The answer to this problem is hard, since it brings us ba= ck to taking
>> >> the UI
>> >> out of the sites hands.
>> >
>> > Which is only helpful if you can somehow gaurantee that the u= ser agent
>> > software hasn't been compromised. Not something I'd b= et on...
>>
>> That's rather overstating it. It's perfectly helpful when = the UA
>> software hasn't been compromised, which is a non-zero fraction= of the
>> time.
>>
>> When the UA s/w has been compromised I'm quite happy to fail t= o fix
>> the problem: the right answer to that is to improve the robustness= of
>> the UA.
>
> +1
> If the UA is stuffed then the user is totally and utterly stuffed anyw= ay.
> In particular if the UA is stuffed then a forms based experience is ju= st as
> stuffed. If we are going to hypothecate attack models people have to b= e
> willing to apply them to their preferred solution too.
>
> The sensible approach is to work out how to stop the user from being s= tuffed
> e.g.
> =A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =A0* Use code signing + trustworthy computing
> =A0* Use a restricted browser
> Now I have a lot of ideas on how we can tackle these, but they are not=
> relevant to this debate.
>
> I do however have a different take on the UI issue.
> HTML forms did have an advantage over the pathetic UI that browsers pr= ovided
> for BASIC and DIGEST (most don't even tell the user which is in us= e).
> But a federated auth scheme supported at the HTTP level could be simpl= er
> still. Instead of the user having to register for each site, they regi= ster
> once. Instead of the user having to log in to each site they log in on= ce per
> session. Instead of the site having to manage lost passwords and forgo= tten
> accounts because the user has hundreds, this problem does not exist. >
> It is a user interface crisis that is driving this need in my view. >
> --
> Website: http://= hallambaker.com/
>
>

> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--
Website: http://hallambaker.com/

--0016e644dbc6f623100499596635-- From yaronf.ietf@gmail.com Fri Jan 7 04:55:13 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F443A686E; Fri, 7 Jan 2011 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L07Vm7cKoG49; Fri, 7 Jan 2011 04:55:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C40053A6873; Fri, 7 Jan 2011 04:55:11 -0800 (PST) Received: by wwa36 with SMTP id 36so17450279wwa.13 for ; Fri, 07 Jan 2011 04:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8wB0BVHtoZNLSagh8m1PIgBE1XzJFln/PN6afWFMKh4=; b=QTG8DuwxYK0cZzA6ewan7/LdBbZYmKKxpzg2DNm/xhX8G7uB5Q/m/C93aeI/dxnyaX eiMykX00X8Oc3ayEBouf3tPxvn7BRNgxJU6sv1PLiLKbo3nmI7wUNwH+GJ/mHmea7Ed8 nLTsxkv2Y9Q/5gTg03Y9VubfDodTM0DZiGmzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=T09V7sxDVE5FcbtNEmBRmlCkwYQJJqg7IlHHFYQjTB8aKt33za5sqgjjIfBCWPoqxU U1r23HIBdfdMahaVbuRanLxQ134YuLZRSeLjjMPWhlSr8Cq17tUKHV0m3BOlnnl2C/Gy 8ZVIQ+/6DOVts8WRKg/hBey8kdSTErwi/HSHI= Received: by 10.227.177.10 with SMTP id bg10mr9575207wbb.148.1294405033432; Fri, 07 Jan 2011 04:57:13 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id f35sm17642679wbf.20.2011.01.07.04.57.08 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 04:57:12 -0800 (PST) Message-ID: <4D270DA1.7020408@gmail.com> Date: Fri, 07 Jan 2011 14:57:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> In-Reply-To: <87lj2xj592.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 10:46:17 -0800 Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:55:13 -0000 Another issue is that SRP (as opposed to other protocols in this space) is not provably secure, and in fact has had relatively little cryptographic review, AFAIK. I would be glad to be proven wrong on the second point. Thanks, Yaron On 01/07/2011 01:57 PM, Simon Josefsson wrote: > One way to mitigate the dictionary attack problem is to do PBKDF#2 > processing of the password before it hits TLS-PSK. > > However I agree that TLS-SRP have superior properties, and it is widely > implemented. There is no practical reason to prefer TLS-PSK over > TLS-PSK for password-based TLS authentication. One issue is that RFC > 5054 is Informational rather than Standards Track (same issue as for > TLS-OpenPGP), which is due to political reasons. > > /Simon > > Yaron Sheffer writes: > >> [Culling down the mailing lists] >> >> Hi Ben, >> >> No, RFC 4279 should not be used with (a hash of) human-memorable >> passwords, because it would be vulnerable to dictionary attacks. See >> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >> schemes should be used instead. >> >> Thanks, >> Yaron >> >> On 01/06/2011 05:31 PM, Ben Laurie wrote: >> [...] >> >>> >>> >>> Two comments (one really being a response to Roy): >>> >>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>> pre-shared keys. These could be derived from a hash of the password and >>> the site name, for example, and thus provide secure mutual >>> authentication despite password reuse. >>> >> [...] From yaronf.ietf@gmail.com Fri Jan 7 08:34:11 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3931C3A68D0; Fri, 7 Jan 2011 08:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdmEHsYHNX-5; Fri, 7 Jan 2011 08:34:09 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6CCEF3A68C0; Fri, 7 Jan 2011 08:34:07 -0800 (PST) Received: by wyf23 with SMTP id 23so18465156wyf.31 for ; Fri, 07 Jan 2011 08:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=f+fhP7UPeAW6UH0hkHpFz2PBxTHW8cDCICMCIxYY4y4=; b=bkAQbjgZzk7YNxPuU63NW1UzbRZ7Kv5eCS5KDn1eyGXHRiObV7DbDXiVTZXfEC7R18 4ZF3VLRiu8PSb233/p1fm2rYP+YV0iNw7AT7x4z90QzN9B2JIeg97FNIF1Pmzo9uQF0/ o3DhSuD8r5FFERLjJCBceK8KP+j9YkLdAHnjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=b0E815ule1RlK1rqsgYuXpdVdjAgrqfNLgC9tuiKDDdTo6w7IlCoXO58vRbHlPQMhq LGNGsC3DQEVTajKdcBMyy0xZoIkfrbrGhuZiy0kzCtQq1S5fQWo/L0YG850z72IheJb/ EoOXqRNnMBryTt3rrxdWSWZ54kOOwD87dhAMo= Received: by 10.227.141.197 with SMTP id n5mr8212052wbu.100.1294416320023; Fri, 07 Jan 2011 08:05:20 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id 11sm17773721wbj.13.2011.01.07.08.05.12 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 08:05:18 -0800 (PST) Message-ID: <4D2739B5.5060107@gmail.com> Date: Fri, 07 Jan 2011 18:05:09 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> In-Reply-To: <874o9kiy7f.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 10:46:17 -0800 Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:34:11 -0000 - I am not a cryptographer, so I am treading on extremely thin ice here. - SRP is certainly better than using PSK with passwords, which is *definitely* vulnerable to dictionary attacks. - That said, I have done my little bit of due diligence (talked to the author of SRP and to several cryptographers who've played with some of these schemes). Personally, I would rather use a protocol that's been formally proven (PACE, AugPAKE, other descendants of EKE) or has had real solid cryptographic review (the original EKE). Again, I would be happy to be proven wrong on this. - Even if we start with a mathematically perfect protocol, we are bound to make design and engineering mistakes. And Marsh and his like will happily poke holes into these implementations :-) But I'd like to avoid compounding the risk with cryptographically unsound protocols. Thanks, Yaron On 01/07/2011 04:29 PM, Simon Josefsson wrote: > The initial paper contains a security analysis with some reduction-style > arguments: > > http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 > > As with any crypto document from that time, it will lack in how the > assumptions are stated and the reductions are made. That considered, is > there something in particular that you think is missing in there? > > We can fix the problem with lack of review by implementing and deploying > the protocol, then certainly researchers are bound to focus on it. ;-) > > /Simon > > Yaron Sheffer writes: > >> Another issue is that SRP (as opposed to other protocols in this >> space) is not provably secure, and in fact has had relatively little >> cryptographic review, AFAIK. I would be glad to be proven wrong on the >> second point. >> >> Thanks, >> Yaron >> >> On 01/07/2011 01:57 PM, Simon Josefsson wrote: >>> One way to mitigate the dictionary attack problem is to do PBKDF#2 >>> processing of the password before it hits TLS-PSK. >>> >>> However I agree that TLS-SRP have superior properties, and it is widely >>> implemented. There is no practical reason to prefer TLS-PSK over >>> TLS-PSK for password-based TLS authentication. One issue is that RFC >>> 5054 is Informational rather than Standards Track (same issue as for >>> TLS-OpenPGP), which is due to political reasons. >>> >>> /Simon >>> >>> Yaron Sheffer writes: >>> >>>> [Culling down the mailing lists] >>>> >>>> Hi Ben, >>>> >>>> No, RFC 4279 should not be used with (a hash of) human-memorable >>>> passwords, because it would be vulnerable to dictionary attacks. See >>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>>> schemes should be used instead. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>>> [...] >>>> >>>>> >>>>> >>>>> Two comments (one really being a response to Roy): >>>>> >>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>>> pre-shared keys. These could be derived from a hash of the password and >>>>> the site name, for example, and thus provide secure mutual >>>>> authentication despite password reuse. >>>>> >>>> [...] From tim-research@sentinelchicken.org Fri Jan 7 09:40:09 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2193A6920 for ; Fri, 7 Jan 2011 09:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYxbRhChvSXa for ; Fri, 7 Jan 2011 09:40:08 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id 9915D3A68C5 for ; Fri, 7 Jan 2011 09:40:08 -0800 (PST) Received: (qmail 11445 invoked from network); 7 Jan 2011 17:44:41 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 7 Jan 2011 17:44:41 -0000 Received: (qmail 26929 invoked from network); 7 Jan 2011 17:45:32 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 7 Jan 2011 17:45:32 -0000 Received: (nullmailer pid 20253 invoked by uid 1000); Fri, 07 Jan 2011 17:42:13 -0000 Date: Fri, 7 Jan 2011 09:42:13 -0800 From: Tim To: Simon Josefsson Message-ID: <20110107174213.GA6792@sentinelchicken.org> References: <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> <87fwt4ejs9.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fwt4ejs9.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Sat, 08 Jan 2011 10:46:17 -0800 Cc: "kitten@ietf.org" , "http-auth@ietf.org" , websec , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [http-auth] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 17:40:09 -0000 > One final addition here, the situation for PSK depends on the flavour > and whether you are talking about active or passive attackers. The > statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK. > Section 7.2 of 4279: > > For the PSK ciphersuites, an attacker can get the information > required for an off-line attack by eavesdropping on a TLS handshake, > or by getting a valid client to attempt connection with the attacker > (by tricking the client to connect to the wrong address, or by > intercepting a connection attempt to the correct address, for > instance). > > For the DHE_PSK ciphersuites, an attacker can obtain the information > by getting a valid client to attempt connection with the attacker. > Passive eavesdropping alone is not sufficient. > > For the RSA_PSK ciphersuites, only the server (authenticated using > RSA and certificates) can obtain sufficient information for an > off-line attack. In the general case, I don't think it is useful to differentiate between passive and active attackers. Performing man-in-the-middle attacks is no more difficult (in a big-O sense) than performing passive attacks. In almost every modern network, these attacks require the same level of network access. Just a pet peeve of mine. cheers, tim From romeda@gmail.com Sat Jan 8 09:35:35 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B324D3A67B5; Sat, 8 Jan 2011 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1de9OjHbzeT; Sat, 8 Jan 2011 09:35:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E3BA93A67AD; Sat, 8 Jan 2011 09:35:17 -0800 (PST) Received: by wyf23 with SMTP id 23so19276867wyf.31 for ; Sat, 08 Jan 2011 09:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=K/xHYytBU+XmnS87+Mqw5HmwQyDfHfNbg8QAUiR6Wps=; b=FU7xxzQDcdWQZzLfDdqfAvH5LhwNpJwDoV5kMBUDLVRqgOtgxKKTgb6scom9ELoz5U TTUnuSDNxTuODZ0ZYkw4PPEB1/Ot7pTnPBnHfVpfQRaOQEPNhr+aVxRElpsF7dqxUPEL 2bsgcy/+LYq9A9JDJzhkxvmFOqzeQlzPCk0Z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=gNBj6PYnDHrSnvc/htfrh9KcFkHuYGy9L16H7r83JLBiGwvaWyy+HhTTfx+0WR5UXs HnoZAXB8V/u5aA50esEsA1o+wr6xcDrbrPLaZ3BQq8t8JI83jyVDCHhRiAP+n7TcVTDM j0SN1HZkPd+tBnieT7PjD7bisA2tRMECNkIJk= Received: by 10.216.59.143 with SMTP id s15mr410638wec.49.1294508241087; Sat, 08 Jan 2011 09:37:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 09:37:00 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

From: Blaine Cook Date: Sat, 8 Jan 2011 09:37:00 -0800 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 08 Jan 2011 10:46:17 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 17:35:35 -0000 Two points: 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all don't like it, but it's used to authenticate more HTTP requests by volume and users than everything-except-cookies combined. You may want to consider the design of OAuth when proceeding with these discussions, rather than the laundry list of [completely] failed protocols. 2. With respect to federated auth, especially using email address-like identifiers, there has been a bevy of (deployed) work in this regard. The effort is called webfinger, and is worth a look. Instead of DNS, we use host-meta based HTTP lookups to dereference the identifiers. Many diaspora and status.net installs are using it today, and there are several proposals towards building a security & privacy infrastructure on top of webfinger (webid is one such proposal whose incorporation of client-side TLS certificates in a browser context makes me very weary of its potential for success). b. On 8 January 2011 08:21, Phillip Hallam-Baker wrote: > On Thu, Jan 6, 2011 at 1:16 PM, Ben Laurie wrote: >> >> On 6 January 2011 16:03, David Morris wrote: >> > >> > >> > On Thu, 6 Jan 2011, Ben Laurie wrote: >> > >> >> The answer to this problem is hard, since it brings us back to taking >> >> the UI >> >> out of the sites hands. >> > >> > Which is only helpful if you can somehow gaurantee that the user agent >> > software hasn't been compromised. Not something I'd bet on... >> >> That's rather overstating it. It's perfectly helpful when the UA >> software hasn't been compromised, which is a non-zero fraction of the >> time. >> >> When the UA s/w has been compromised I'm quite happy to fail to fix >> the problem: the right answer to that is to improve the robustness of >> the UA. > > +1 > If the UA is stuffed then the user is totally and utterly stuffed anyway. > In particular if the UA is stuffed then a forms based experience is just = as > stuffed. If we are going to hypothecate attack models people have to be > willing to apply them to their preferred solution too. > > The sensible approach is to work out how to stop the user from being stuf= fed > e.g. > =C2=A0* Comodo's free Anti-Virus with Default Deny Protection (TM) > =C2=A0* Use code signing + trustworthy computing > =C2=A0* Use a restricted browser > Now I have a lot of ideas on how we can tackle these, but they are not > relevant to this debate. > > I do however have a different take on the UI issue. > HTML forms did have an advantage over the pathetic UI that browsers provi= ded > for BASIC and DIGEST (most don't even tell the user which is in use). > But a federated auth scheme supported at the HTTP level could be simpler > still. Instead of the user having to register for each site, they registe= r > once. Instead of the user having to log in to each site they log in once = per > session. Instead of the site having to manage lost passwords and forgotte= n > accounts because the user has hundreds, this problem does not exist. > > It is a user interface crisis that is driving this need in my view. > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From zedshaw@zedshaw.com Sat Jan 8 11:47:45 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834943A6818; Sat, 8 Jan 2011 11:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH1qQ8WU6rNZ; Sat, 8 Jan 2011 11:47:44 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 562A03A6814; Sat, 8 Jan 2011 11:47:43 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 55D6D1D87C1; Sat, 8 Jan 2011 11:49:52 -0800 (PST) Date: Sat, 8 Jan 2011 11:49:52 -0800 From: "Zed A. Shaw" To: Blaine Cook Message-ID: <20110108194952.GS12542@zedshaw> Mail-Followup-To: "Zed A. Shaw" , Blaine Cook , Phillip Hallam-Baker , Ben Laurie , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 08 Jan 2011 12:55:03 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:18:07 -0000 On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: > Two points: > > 1. In this entire thread, no-one has mentioned OAuth. Maybe y'all > don't like it, but it's used to authenticate more HTTP requests by > volume and users than everything-except-cookies combined. You may want > to consider the design of OAuth when proceeding with these > discussions, rather than the laundry list of [completely] failed > protocols. I don't normally respond, just being a lurker, but this statement is competely wrong Blaine. OAuth may be used for more requests, but not more sites. It's used on a tiny number of sites, with OpenID being used on way many more, and even then, not nowhere near the number of websites that form based authentication and browser authentication methods. Don't equate twitter having a ton of traffic to OAuth being some kind of raving success, and sure as hell don't evaluate the technical merits of something by its popularity. > 2. With respect to federated auth, especially using email address-like > identifiers, there has been a bevy of (deployed) work in this regard. > The effort is called webfinger, and is worth a look. Instead of DNS, > we use host-meta based HTTP lookups to dereference the identifiers. > Many diaspora and status.net installs are using it today, and there > are several proposals towards building a security & privacy > infrastructure on top of webfinger (webid is one such proposal whose > incorporation of client-side TLS certificates in a browser context > makes me very weary of its potential for success). While I agree that TLS client side isn't going to work, none of the proposed authentication methods will work without a change to browsers to support a way for two websites to establish a session in the browser. If that feature existed you would cut down on a lot of the complexity of things like OpenID and OAuth. -- Zed A. Shaw http://zedshaw.com/ From marsh@extendedsubset.com Sat Jan 8 13:31:00 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D5A3A683E; Sat, 8 Jan 2011 13:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4bPP+UTK2H0; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 493D93A683C; Sat, 8 Jan 2011 13:30:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PbgPH-000IjG-DU; Sat, 08 Jan 2011 21:33:03 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BB8EB603D; Sat, 8 Jan 2011 21:33:00 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/yNdr6BhRuIy23ofn2b5a1o+UJfu2Keao= Message-ID: <4D28D80B.2020006@extendedsubset.com> Date: Sat, 08 Jan 2011 15:32:59 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 08 Jan 2011 16:02:05 -0800 Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [http-auth] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:31:00 -0000 On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: > I think that Ben is right that we are solving the wrong problem. I think Ben is nearly always right. :-) But let me toss out a different perspective. I'll try carefully and hope that this doesn't come across as trolling, but it is a bit contrarian (hopefully in a good way). > The problem is that users are asked to maintain accounts at literally > HUNDREDS of accounts. > > And some cretins, some utter morons, some bog-brained berks think it is > reasonable to tell the user to have a different password for every one! Such users have asked to do business with hundreds of entities, so at least something is working right. The user is free to use the same password everywhere (more convenient), or use a different password at every site (more secure). Many users like to set up "domains of password re-use" among several like-sites. The user is free to decide the point on the trade-off that works for them. I use a different password for everything. I write them down on blank business cards and keep them physically secure. I have taught some small children to use this scheme and they have no trouble with it. Most web browsers and sites remember the passwords anyway so the paper is really just backup. > I can't remember the account names, the password is easy as I only had > one (for non financial) - until those cretins at Gawker screwed up. Now > I have to reset my password at all those places. So you had decided on a coarse-grained scheme: financial and non-financial. Seems reasonable on the surface. Say you have a dozen sites across which you share a password. These sites are really secure - let's estimate the probability that each one will be breached or compromised or you will accidentally login unencrypted from a public internet location is only 1 in 10 per year. Hey a 90% success rate isn't bad, right? But the probability that they will all succeed is 0.9^12 = 28% over a year. Expect to be changing that password every few months. In the case of "HUNDREDS of accounts", 0.9^200 = 0.000000001. Well, those of the sort of odds you're supposed to serve the attacker, not yourself. > We have to solve the federated auth problem and it is really, really easy: No, it borders on the impossible. > Account Name is the RFC 821/822 email address. > > This is what the Web has started to adopt of its own accord as a > user account identifier. It is the only one that people can remember > reliably. Which is why everyone just has one email address? Come on, most people have several. And often they do so for a reason, it's not just that people get new ISPs or switch for new features all the time. I train my kids to lie about their names and ages when they do stuff online. They don't have emails. You don't have a personal email and a work email at least? > Authentication service is resolved via DNS service lookup > i.e. SRV or similar. I can show people how to fix up the issues to > do with use of non-canonical names. [skipping a bunch of technical stuff] > I know that you can achieve some of the desired authentication > properties with public keys at the client. The problem is that our > current use of computers has gone way beyond the one-machine-per-person > paradigm > On a recent trip to Europe with the family I counted that we had 10 > computers with us capable of supporting IP (3 laptops, 3 iPhones, 2 > Nintendos, 1 iPad and a kindle). It was only a brief period in the history of computing that might have ever been true anyway. Before networks "user identity" hardly mattered. Immediately after networks, we got heterogeneous networks. As soon as heterogeneous networks arrived, we got single sign-on. I think the deeper problem today is that most people looking at the issue are coming from the service provider side. Their job is made greatly simpler if they can assume 1 user = 1 person = 1 email etc. So they make this assumption as much as they can get away with it. But the reality is that people don't work that way. Historically, people have had multiple identities and they presented themselves differently to different parties. This is intentional and it's not duplicitous, its part of normal social interaction. When you discuss business matters at work you give out a business card with a business phone number and address on it. When you meet people at church or school, you give people your home phone. Your home phone and address were the ones printed in the directory. So the fact that "a person" has more than one "device" is not the big problem (that's actually sometimes a desperate solution from the perspective of the user). The problem for the service provider is that they don't want to give up the simplifying assumption (and the behavioral tracking it enables) that a real person represents an atomic unit of identity. Aside from the brittleness of their security, this is one reason why centralized identity, top-down federated authentication and single-sign-on schemes are not a good plan for the web. They don't accurately model the problem domain. These schemes originated for use in corporate and university settings which, at the end of the day, have all of the protected resources owned by a single party. The universal ritual for everyone's first day at a new job is the granting of a new username, password, and email identity for use in that specific context. So single sign-on was designed so that one person could be granted access to, say, the file server, email, printer, and maybe the phone system, all within the restricted context of their "employee-ness" at one specific company. Even though multiple systems are involved, it's still fundamentally a one-to-one relationship between two identities, the person-as-employee and the company-as-employer. This doesn't map to the web with multiple persons each needing to control the mapping of their own multiple identities to multiple corporations. I don't want to pull out my US State Department-issued passport in order to leave a comment on some random blog or log into an online game. I don't want to use any of my gmail addresses for that either. Bad things happen when you force-fit the wrong model on to the design. Security and privacy are always the first to go. (Somewhere I saw the other day somebody seriously proposing using Facebook as a centralized identity authority.) More subtly, people find the system harder to use, and overall they just don't like it or trust it as much. People won't use it, or they'll use it and not like it, or they won't use it as much, or they'll figure out a way to defeat it. > Cardspace has some really, really great properties but they are totally > lost when you try to make the service accessible from multiple machines > by putting it 'in the cloud'. In fact, other than a manager, I have > never found anyone who reven thinks they know what they mean by 'in the > cloud' for CardSpace. I certainly have never seen an explanation I can > understand. Cloud is largely an experiment in making unwarranted assumptions about identity in the other direction: between the corporation and their devices. > Devices get lost. Devices get stolen. My impression is that lost and stolen devices are significant, but they're by far not the biggest security issue on the web. > We don't want to encourage that so > there needs to be something more than just a certificate based client > auth scheme. > > I think we need some form of centralized (for given account) account > management in the mix so that the user can authorize/deauthorize devices > for use (c.f. Amazon's Kindle account management) You're not going to create everybody's favorite web authentication infrastructure if it has the goal of controlling people use of their own devices. > So there are basically two architectural options for using public key. > One is to use it strictly between the client and the auth service and > use a token like approach as discussed above. Another is for the auth > service to issue an assertion of the form 'you can tell its fred by this > public key (amongst others)'. > SAML already has support for both approaches BTW. Forget the wants of corporations and websites, they exist only because of their customers and users who outnumber them a millionfold. Forget mechanisms for now, those are simple engineering once the problem is stated correctly. What do people want to do? What would they want to do if they knew to ask for it? How can we help them do it in the most secure way possible? How can we give people the tools to manage their own identities and make their own security-convenience trade-offs in the most informed way? Regards, - Marsh From romeda@gmail.com Sat Jan 8 17:27:45 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878EC28C157; Sat, 8 Jan 2011 17:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.349 X-Spam-Level: X-Spam-Status: No, score=-104.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CHuczRPWZBj; Sat, 8 Jan 2011 17:27:43 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 716E728C0D8; Sat, 8 Jan 2011 17:27:42 -0800 (PST) Received: by wwa36 with SMTP id 36so18596520wwa.13 for ; Sat, 08 Jan 2011 17:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=afxLGSrBPz4bvHwp6VG7sozjob/7t1YO0xeVPH7/4wU=; b=LAQdyT9SddL8nJPhVQM29j6ZoZWBU/E9RdL3dcQirexwAxBPozXDZ7R8vOxplF5rDX pFjcIvOVsoXraVaAoigoriOzby1Vb5bpOibBUZFxefgem0XrfG3Rn9ZgZZb3HPJCgqNi R8mjqJHHWIO0driOK5UwZbhB8m9IcGUiv4KRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=W00D/vRaeMJ9JFN6mWMx9sDgFjHR+OAwMhDTnEtxnjcdIaIr5rkVlZ7DByNvMeDYzG 5/zSOQnpfLw3pRace51aLC/URn3bISpnzt4Im8calKLP9JFUc4/cInuXHJkc/AsqHLnA Cp3q0SjBiSJ/ix2U6AtTOIZ27Ltj1Pjqyu1Q0= Received: by 10.216.142.101 with SMTP id h79mr26233429wej.49.1294536590896; Sat, 08 Jan 2011 17:29:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sat, 8 Jan 2011 17:29:29 -0800 (PST) In-Reply-To: <20110108194952.GS12542@zedshaw> References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

<20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sat, 8 Jan 2011 17:29:29 -0800 Message-ID: To: "Zed A. Shaw" , Blaine Cook , Phillip Hallam-Baker , Ben Laurie , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 09 Jan 2011 04:23:22 -0800 Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 01:27:45 -0000 On 8 January 2011 11:49, Zed A. Shaw wrote: > On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: > I don't normally respond, just being a lurker, but this statement is > competely wrong Blaine. =C2=A0OAuth may be used for more requests, but no= t > more sites. =C2=A0It's used on a tiny number of sites, with OpenID being = used > on way many more, and even then, not nowhere near the number of websites > that form based authentication and browser authentication methods. > > Don't equate twitter having a ton of traffic to OAuth being some kind of > raving success, and sure as hell don't evaluate the technical merits of > something by its popularity. Agreed - though, facebook is also using oauth-based (not 1.0, but essentially the same approach) logins, and there are a number of other sites that do provide oauth-based login infrastructure. Moreover, the nudge towards oauth is intended with the movement towards a new auth infrastructure in mind. We'd need some kind of discovery / negotiation mechanism on top to make it not the one-or-two-companies-own-the-web play that login-over-oauth is now. (c.f. OpenID Connect). b. > While I agree that TLS client side isn't going to work, none of the > proposed authentication methods will work without a change to browsers > to support a way for two websites to establish a session in the browser. > If that feature existed you would cut down on a lot of the complexity of > things like OpenID and OAuth. Again, agreed. ;-) for the record, I don't think that OAuth itself is a suitable replacement for HTTP authorisation, but wanted to stir the pot, especially away from overwrought technical solutions that don't actually solve anyone's needs. b. From benl@google.com Sun Jan 9 06:19:41 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43E03A69B9 for ; Sun, 9 Jan 2011 06:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.255 X-Spam-Level: X-Spam-Status: No, score=-104.255 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pB11vZ4ybn8 for ; Sun, 9 Jan 2011 06:19:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6FD923A69B1 for ; Sun, 9 Jan 2011 06:19:40 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p09DiELc027793 for ; Sun, 9 Jan 2011 05:44:14 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294580654; bh=/mk8a9m6BHBI1j9A8YYpAAJT3g0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=rBd7e5LDKWOIj5qUWv3wG0oA2pnQGelokPC4sYnssr7Zzj8vz/Z6UYrf25BqbH1/I wOBB+UrZDr/XjglaTzg2Q== Received: from vws9 (vws9.prod.google.com [10.241.21.137]) by wpaz21.hot.corp.google.com with ESMTP id p09DiCWh019485 for ; Sun, 9 Jan 2011 05:44:13 -0800 Received: by vws9 with SMTP id 9so7678484vws.13 for ; Sun, 09 Jan 2011 05:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZRWqqE2GC4FvKBmajUqrY7ravsT74mc/cg/K4kzh7cM=; b=GcGbegD1O4aILaEJyw/n4kMpuLQjeb5LMacygSf0Zp49ph4nEnffspaTdOBCTWDX8Y A1EW0TKeMxpuyF7lmcZg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WX+kK4B4G3HeErl5S2/G/I1bA3Ykj3FXsZiU9f1dd+V96cJhNoRJYYontlCDmNFKW/ qNFiploG2G8enySMzZHg== MIME-Version: 1.0 Received: by 10.220.202.131 with SMTP id fe3mr8379018vcb.183.1294580652479; Sun, 09 Jan 2011 05:44:12 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 05:44:12 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

<20110108194952.GS12542@zedshaw> Date: Sun, 9 Jan 2011 13:44:12 +0000 Message-ID: From: Ben Laurie To: Blaine Cook Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sun, 09 Jan 2011 09:01:36 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 14:19:42 -0000 On 9 January 2011 01:29, Blaine Cook wrote: > On 8 January 2011 11:49, Zed A. Shaw wrote: >> On Sat, Jan 08, 2011 at 09:37:00AM -0800, Blaine Cook wrote: >> I don't normally respond, just being a lurker, but this statement is >> competely wrong Blaine. =A0OAuth may be used for more requests, but not >> more sites. =A0It's used on a tiny number of sites, with OpenID being us= ed >> on way many more, and even then, not nowhere near the number of websites >> that form based authentication and browser authentication methods. >> >> Don't equate twitter having a ton of traffic to OAuth being some kind of >> raving success, and sure as hell don't evaluate the technical merits of >> something by its popularity. > > Agreed - though, facebook is also using oauth-based (not 1.0, but > essentially the same approach) logins, and there are a number of other > sites that do provide oauth-based login infrastructure. > > Moreover, the nudge towards oauth is intended with the movement > towards a new auth infrastructure in mind. We'd need some kind of > discovery / negotiation mechanism on top to make it not the > one-or-two-companies-own-the-web play that login-over-oauth is now. > (c.f. OpenID Connect). > > b. > >> While I agree that TLS client side isn't going to work, none of the >> proposed authentication methods will work without a change to browsers >> to support a way for two websites to establish a session in the browser. >> If that feature existed you would cut down on a lot of the complexity of >> things like OpenID and OAuth. > > Again, agreed. ;-) > > for the record, I don't think that OAuth itself is a suitable > replacement for HTTP authorisation, but wanted to stir the pot, > especially away from overwrought technical solutions that don't > actually solve anyone's needs. Towards ones that are ripe for phishing and have no privacy protections? I don't believe that's a good direction. From romeda@gmail.com Sun Jan 9 08:49:58 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D3E3A677E; Sun, 9 Jan 2011 08:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.682 X-Spam-Level: X-Spam-Status: No, score=-104.682 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-915Pk+xrKV; Sun, 9 Jan 2011 08:49:57 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 806623A6816; Sun, 9 Jan 2011 08:49:56 -0800 (PST) Received: by wyf23 with SMTP id 23so19771279wyf.31 for ; Sun, 09 Jan 2011 08:52:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=WIm+nFsAde/ye4Tom3yY4aVsYWqIxOmEG0wpwlytdzI=; b=Clwy4B80sy6LoL3fprCaKqTJWjn5jUnpqvWX13saEtPhxSf5b7x8DxNHBQSjcDcjCd lfcG5pVl93HS5iW0GIedlgBOnavigJXk4i2/IydnDkOElogTRR0AhkBJJLExNslRhjcb 3VhXaddZVP6P01QaxCJX/3QLZLRMHhtPUbNbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SCyIoxVnZRbGdpwm6boOG67l5B48h3JNw3U4Qv7Uwv2Fgk2Zdex0rweQm3owUIDeF7 p6Z+OnAy9Cb1o11hDx+iBjjsxaDOGtwHOfDokx3hRjYxfdoNN0LQ+E37lyu16j3Dhpyk refSLACQIk5R32y/JZB1jn0f41uSaOrFKq+z4= Received: by 10.216.177.9 with SMTP id c9mr26823431wem.34.1294591283468; Sun, 09 Jan 2011 08:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Sun, 9 Jan 2011 08:40:54 -0800 (PST) In-Reply-To: References: <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

<20110108194952.GS12542@zedshaw> From: Blaine Cook Date: Sun, 9 Jan 2011 08:40:54 -0800 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Sun, 09 Jan 2011 09:01:36 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 16:49:58 -0000 > Towards ones that are ripe for phishing and have no privacy > protections? I don't believe that's a good direction. *shrug* If the alternative is Facebook handling everyone's logins, it can't get much worse, can it? b. From john-ietf@jck.com Sun Jan 9 10:19:58 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261273A67DF; Sun, 9 Jan 2011 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf1MTOuKT715; Sun, 9 Jan 2011 10:19:57 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A1B653A67D4; Sun, 9 Jan 2011 10:19:56 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Pbzu1-0009d1-SY; Sun, 09 Jan 2011 13:22:06 -0500 Date: Sun, 09 Jan 2011 13:22:04 -0500 From: John C Klensin To: Marsh Ray Message-ID: In-Reply-To: <4D28D80B.2020006@extendedsubset.com> References: <4D02AF81.6000907@stpeter.im>

<78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D28D80B.2020006@extendedsubset.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Sun, 09 Jan 2011 12:00:48 -0800 Cc: apps-discuss@ietf.org, "Roy T. Fielding" , websec , Robert Sayre , kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [http-auth] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 18:19:58 -0000 --On Saturday, January 08, 2011 15:32 -0600 Marsh Ray wrote: > On 01/08/2011 10:07 AM, Phillip Hallam-Baker wrote: >> I think that Ben is right that we are solving the wrong >> problem. > > I think Ben is nearly always right. :-) > > But let me toss out a different perspective. I'll try > carefully and hope that this doesn't come across as trolling, > but it is a bit contrarian (hopefully in a good way). >... Well, actually, I think this is constructive, useful, and rather nicely describes the other side of the problem. I would add that one important variation on "Person = Identity = Email address" has historically involved the use of subaddresses. Not only do they help considerably with mail management (pretty much their original purpose) but they provide an additional (weak but convenient) measure against email fraud and identify theft attempts (if I know that mail from my bank is going to be addressed to "john+12345@example.com" because that is the only address they have, then it is pretty clear where mail that supposedly comes from them but is addressed to "john+LargeRetailer@example.com" should be routed. Obviously, if an address that is used for only one vendor or correspondent gets into the hands of a spammer, it is lots easier to fix that problem as well. Address-per-correspondent also makes password-per-correspondent much easier too. Lots of web sites and providers have been really resistant to that approach. I had assumed before this that the problem was just stupidity, but parts of your comments could be expanded to lead to the inference that having me use more than one address is not in their interests. Whatever becomes of that tradeoff, the IETF should not, IMO, be doing things that encourage them in directions that reduce our privacy and ability to control our identities. >... > Which is why everyone just has one email address? Come on, > most people have several. And often they do so for a reason, > it's not just that people get new ISPs or switch for new > features all the time. I train my kids to lie about their > names and ages when they do stuff online. They don't have > emails. > > You don't have a personal email and a work email at least? >... exactly. with the emphasis on "at least" >... > Bad things happen when you force-fit the wrong model on to the > design. Security and privacy are always the first to go. > (Somewhere I saw the other day somebody seriously proposing > using Facebook as a centralized identity authority.) More > subtly, people find the system harder to use, and overall they > just don't like it or trust it as much. People won't use it, > or they'll use it and not like it, or they won't use it as > much, or they'll figure out a way to defeat it. Indeed. In all of the really significant cases, probably the latter. If I had a nickel for every sticky note with a password (sometimes slightly-disguised) stuck to a screen... But those notes are precisely a workaround for "you have to change your password frequently, you can't share passwords between systems, and we will insist by various means that you passwords are strong and that a given password is not obviously derivable from its predecessors" policies. >... john From benl@google.com Sun Jan 9 11:19:27 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBC473A67D4 for ; Sun, 9 Jan 2011 11:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.807 X-Spam-Level: X-Spam-Status: No, score=-103.807 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzTVLJz871LF for ; Sun, 9 Jan 2011 11:19:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CE8573A6833 for ; Sun, 9 Jan 2011 11:19:26 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p09JLbTr014152 for ; Sun, 9 Jan 2011 11:21:37 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294600897; bh=P5fHISLk/lO2e3DNf66/oc7YEsw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Content-Type:Content-Transfer-Encoding; b=Uqzl+VVDOfxAdlWsmDj8AOw2YkL8Vo7mZdNEj3JQyJxCP/wAWNt2i9KK2wyLYR/1T TWFz1PypiODDfVKfjIn7g== Received: from vws13 (vws13.prod.google.com [10.241.21.141]) by hpaq1.eem.corp.google.com with ESMTP id p09JLZ47015942 for ; Sun, 9 Jan 2011 11:21:36 -0800 Received: by vws13 with SMTP id 13so7400040vws.39 for ; Sun, 09 Jan 2011 11:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=huqt9woLFjVdG0rNeZu+5K/N6b16t1pAHbnnc7jOhbE=; b=sDgpLwAvCSPX/1UhP1lfxPZeJThR7bpM+mQosqvme2HLR0gXUfChWxoo1RAN4X70ik A6mw1b4SxGFWnvfPfp+w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=PcgNAAYdrsTihx9s+Vw7rPx3d7e6QjPs3bRNsD0aOk3tvZrb869ZxPlOzLtgTVgSEK XRAZf2E+CitZ3OWQwfBA== MIME-Version: 1.0 Received: by 10.220.200.13 with SMTP id eu13mr8472527vcb.148.1294600895187; Sun, 09 Jan 2011 11:21:35 -0800 (PST) Received: by 10.220.88.137 with HTTP; Sun, 9 Jan 2011 11:21:34 -0800 (PST) In-Reply-To: <20110109183236.GZ12542@zedshaw> References: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com>

<20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> Date: Sun, 9 Jan 2011 19:21:34 +0000 Message-ID: From: Ben Laurie To: "Zed A. Shaw" , Ben Laurie , Blaine Cook , Phillip Hallam-Baker , "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Mailman-Approved-At: Sun, 09 Jan 2011 12:00:48 -0800 Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 19:19:28 -0000 On 9 January 2011 18:32, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 01:44:12PM +0000, Ben Laurie wrote: >> > for the record, I don't think that OAuth itself is a suitable >> > replacement for HTTP authorisation, but wanted to stir the pot, >> > especially away from overwrought technical solutions that don't >> > actually solve anyone's needs. >> >> Towards ones that are ripe for phishing and have no privacy >> protections? I don't believe that's a good direction. > > Ripe for phishing? =A0I must have missed a whole conversation in all this > cross posting, because last I checked none of the proposed solutions > prevent phishing. > > If you can phish one site you can phish another. =A0It's not the sites or > the protocol that causes phishing, or whether you've got a billion > redirects or diffie-helman to the hilt. =A0OpenID or Oauth or > plain-old-form-auth don't prevent or cause phishing. > > What causes phishing is users have no idea that two websites are > different. Whilst I do not disagree with this claim, you are wrong. There are protocols which effectively prevent phishing - so long as password entry is done in an unspoofable UI. I am sure that you will respond that UI can be spoofed as easily as a website can be, and I'm almost ready to agree with that, given that we still don't have a good answer to that, however, my one small ray of hope in this regard is that there's only one UI we need to make unspoofable as opposed to a million websites. And, what's more, we don't really need to invoke it every time a user logs in to a website - really what we want is for the user to authenticate to their device and have the device handle the rest. OpenID and OAuth are particularly nasty, even by today's standards, because they provide a trivial route for the phisher to do a perfect MitM attack on the IdP. From zedshaw@zedshaw.com Sun Jan 9 12:14:17 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F773A681D; Sun, 9 Jan 2011 12:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnMopMB45VYx; Sun, 9 Jan 2011 12:14:16 -0800 (PST) Received: from mail.zedshaw.com (67-207-134-146.slicehost.net [67.207.134.146]) by core3.amsl.com (Postfix) with ESMTP id 3E8FE3A6810; Sun, 9 Jan 2011 12:14:16 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 864A91D87C1; Sun, 9 Jan 2011 12:16:27 -0800 (PST) Date: Sun, 9 Jan 2011 12:16:27 -0800 From: "Zed A. Shaw" To: Ben Laurie Message-ID: <20110109201627.GC12542@zedshaw> Mail-Followup-To: "Zed A. Shaw" , Ben Laurie