From benl@google.com Thu Jan 6 07:29:48 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40E83A6E1A for ; Thu, 6 Jan 2011 07:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.417 X-Spam-Level: X-Spam-Status: No, score=-104.417 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 BhTTmrloTPEK for ; Thu, 6 Jan 2011 07:29:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id ED1C23A6C4F for ; Thu, 6 Jan 2011 07:29:46 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p06FVruA008275 for ; Thu, 6 Jan 2011 07:31:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294327913; bh=UP69RRHWGGYUU/4X7jvHl3J8mX4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=tffwv5pj1cfBxD2UXrNiPA9hnISD7CFCPAfxxhAbDNjqV18FhGKKdq/fWbqDK2rlg pX5D1iypM0wn9OQoG9f9Q== Received: from qwa26 (qwa26.prod.google.com [10.241.193.26]) by wpaz13.hot.corp.google.com with ESMTP id p06FV0iQ006169 for ; Thu, 6 Jan 2011 07:31:52 -0800 Received: by qwa26 with SMTP id 26so16435418qwa.0 for ; Thu, 06 Jan 2011 07:31:52 -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; bh=4HF7vbiBG5YS3CoUX9wu70DOSHl4iLZrUnsX4DNBd8w=; b=BWKqmSdEvTDeyQ2eqttv3+gBNEmZ8ZTujH6HL3DADxzsmbBUAlcazFi9amXmpe/stX C8Xwy0FBWlv0jfqgUknQ== 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; b=hH30kqLSSKa1ZEPU9Hu/va/17y7O5RquFN4F2cWEnZwLtv6zPxOQENUmecs1T29R8b EpxWBDsyopxO1loOVpOQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr2980674qcb.104.1294327911945; Thu, 06 Jan 2011 07:31:51 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 07:31:51 -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: Thu, 6 Jan 2011 15:31:51 +0000 Message-ID: From: Ben Laurie To: Robert Sayre Content-Type: multipart/alternative; boundary=00163630f5376a161c04992f33be X-System-Of-Record: true Cc: "apps-discuss@ietf.org" , "Roy T. Fielding" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 15:29:49 -0000 --00163630f5376a161c04992f33be Content-Type: text/plain; charset=ISO-8859-1 On 6 January 2011 01:28, Robert Sayre wrote: > > Peter Saint-Andre wrote: > > 2. In 2007, Robert Sayre put together a few slides on the topic: > > http://people.mozilla.com/~sayrer/2007/auth.html > > These are back on the Web, in case anyone missed them (probably not). > > On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding > wrote: > > > > Define them all and let's have a bake-off. It has been 16 years since > > HTTP auth was taken out of our hands so that the security experts could > > define something perfect. Zero progress so far. > > I think the IETF might do better to focus on a smaller problem, at > first. People often use self-signed certificates with HTTP/TLS, even > though the first thing their websites ask the 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 solution, then the > larger issue of authentication on the entire Web seems like a tough > nut to crack. > 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. 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 because 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 the 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 simulated so as to get hold of the underlying password? The answer to this problem is hard, since it brings us back to taking the UI out of the sites hands. > It could be that the reasons for this lack of progress are > nontechnical. Just throwing that out there. > If you think UI is nontechnical, then I agree. Cheers, Ben. --00163630f5376a161c04992f33be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 January 2011 01:28, Robert Sayre <sayrer@gmail.com> wrote:
> Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 2. In 2007, Robert Sayre put together a few slides on the topic:
> http://people.mozilla.com/~sayrer/2007/auth.html

These are back on the Web, in case anyone missed them (probably not).=

On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>
> Define them all and let's have a bake-off. =A0It has been 16 years= since
> HTTP auth was taken out of our hands so that the security experts coul= d
> define something 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 with HTTP/TLS, even
though the first thing their websites ask the 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 solution, then the
larger issue of authentication on the entire Web seems like a tough
nut to crack.

Two comments (one really = being a response to Roy):

1. The IETF has fixed th= e problem, but no-one is using the fix - perhaps because it is not clear th= at 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 thu= s provide secure mutual authentication despite password reuse.

2. I have often heard (though I am not aware of hard ev= idence for this, nevertheless I find it plausible) that one reason no-one h= as bothered to improve HTTP auth is because no-one would use it since site = owners want to control the user experience around signin. It seems to me, t= herefore, 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 the loo= k, while appropriate HTML elements or JS code can deal with the secure exch= ange 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 ph= ished, how does the user know those elements are actually being used, rathe= r than simulated so as to get hold of the underlying password?

The answer to this problem is hard, since it brings us = back to taking the UI out of the sites hands.

=A0<= /div>
It could be that the reasons for this lack of progress are
nontechnical. Just throwing that out there.

=
If you think UI is nontechnical, then I agree.

Cheers,

Ben.

--00163630f5376a161c04992f33be-- From marsh@extendedsubset.com Sun Dec 19 14:02:03 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EF43A6911; Sun, 19 Dec 2010 14:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, SARE_OBFU_MILLIONS=1.213] 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 X8qCV2TyjfYu; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A327C3A6910; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PURMA-000Jc4-IS; Sun, 19 Dec 2010 22:03:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A4FA360C7; Sun, 19 Dec 2010 22:03:52 +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: U2FsdGVkX18timQ4um115qKSoyKjKv9Us5qWv7NZVf4= Message-ID: <4D0E8148.7060607@extendedsubset.com> 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: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: General discussion of application-layer protocols , Adrien de Croy , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 19 Dec 2010 22:02:03 -0000 X-Original-Date: Sun, 19 Dec 2010 16:03:52 -0600 X-List-Received-Date: Sun, 19 Dec 2010 22:02:03 -0000 On 12/19/2010 03:49 PM, Ben Laurie wrote: > On 19 December 2010 11:12, Adrien de Croy wrote: >> Imagine if >> everyone needed a client certificate to send any mail. We'd have no spam. > > Nonsense. We'd just restrict spam to owned machines, of which there > are only a few tens or hundreds of milliions, if we're lucky. Nonsense. We'd have no mail. Or rather some other store-and-forward messaging system would arise and not be called mail. Look back far enough and you'll find all kinds of "electronic mail" services implementing the full range of peer and end user authentication, and sender-pays models. There was no spam on those systems, or at least not enough that anyone felt like they needed a word for it. Guess why we use the one we use today. - Marsh From adrien@qbik.com Sun Dec 19 14:04:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7373A6914; Sun, 19 Dec 2010 14:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.724 X-Spam-Level: X-Spam-Status: No, score=-4.724 tagged_above=-999 required=5 tests=[AWL=-3.338, BAYES_00=-2.599, SARE_OBFU_MILLIONS=1.213] 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 BQQ--g7lqNuP; Sun, 19 Dec 2010 14:04:45 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 834BF3A6915; Sun, 19 Dec 2010 14:04:43 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3109)) with SMTP id <0017865124@smtp.qbik.com>; Mon, 20 Dec 2010 11:06:32 +1300 Message-ID: <4D0E81E8.8010000@qbik.com> From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 19 Dec 2010 22:04:46 -0000 X-Original-Date: Mon, 20 Dec 2010 11:06:32 +1300 X-List-Received-Date: Sun, 19 Dec 2010 22:04:46 -0000 On 20/12/2010 10:49 a.m., Ben Laurie wrote: > On 19 December 2010 11:12, Adrien de Croy wrote: >> Imagine if >> everyone needed a client certificate to send any mail. We'd have no spam. > Nonsense. We'd just restrict spam to owned machines, of which there > are only a few tens or hundreds of milliions, if we're lucky. only if no-one revoked their certificate. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From hallam@gmail.com Tue Dec 21 18:06:44 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AAC3A695E; Tue, 21 Dec 2010 18:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=0.198, 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 dm3p9CHzs6QV; Tue, 21 Dec 2010 18:06:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 065FE3A6953; Tue, 21 Dec 2010 18:06:41 -0800 (PST) Received: by gyd12 with SMTP id 12so2087789gyd.31 for ; Tue, 21 Dec 2010 18:08:39 -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=/OBpDxIGVnuTvTy89iuDk01J0co6lWZLFRhL9rLCI6Q=; b=TxYs8CaOWzmRmcvntots3pocMWPSvJI5QGoxBNehNqJygt0ua9hOqhHePmpPoxnIl2 +3K51lyktOUdTB8fGRTx6JuAa2uRO4DIGXb5pyNgWvAf2rQvSXeqiBTh1rqof+tO2Xd2 1SkUiO5AA2871KVjzgS9Pkl/RgZChq0zsnIhQ= 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=q0SFOZuF8Otihl3+ehyAu+mAxfB0moPAT/bmrMWuBtPMJsrUDNaJfgGURE8F9MP4VA /ZAowIxWGmTeSOUdR4oargvEesKtzGBpQZmovog/mBFHhOyvd6qRQGRUORo7xUFYjRq1 XRoj9P7kXHhwX7uzpAJgdrXhqeLx0/B6IOht0= MIME-Version: 1.0 Received: by 10.100.57.11 with SMTP id f11mr565295ana.205.1292983718641; Tue, 21 Dec 2010 18:08:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 18:08:38 -0800 (PST) In-Reply-To: <1292958219.2800.22.camel@destiny> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> <1292958219.2800.22.camel@destiny> Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=0016e644c7044000210497f63b9d X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 22 Dec 2010 02:06:44 -0000 X-Original-Date: Wed, 22 Dec 2010 02:08:38 +0000 X-List-Received-Date: Wed, 22 Dec 2010 02:06:44 -0000 --0016e644c7044000210497f63b9d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey Hutzelman wrote: > On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote: > > > > > As Web sites discover that their account holders cannot remember their > > username, most have adopted email addresses as account identifiers. > > That is what we should use as the basis for federated web > > authentication. > > > > > > > > > > So if the user account identifier looks like username@example.com, how > > does an entity verify that a purported user has a valid claim to that > > account? > > > > > > The obvious mechanism in my view is to use DNS based discovery of an > > authentication service. For example, we might use the ESRV scheme I > > have been working on: > > > > > > _auth._ws.example.com ESRV 0 prot "_saml._ws" > > _auth._ws.example.com ESRV 0 prot "_xcat._ws" > > > > > > Which declares that the SAML and 'XCAT' (presumably kitten in XML) > > protocols may be used to resolve authentication requests. > > > > > I see two fundamental technical problems with this approach: > > 1) It relies on unsecured DNS to be secure. Particularly, you suggest > that, in order to discover a means to securely authenticate users > associated with some entity with which I have no prior relationship, I > should look up information about that entity in the DNS. But DNSSEC is > not widely-deployed enough (yet) for that to be realistic. Further, I'm > generally opposed to schemes that rely on the integrity of the DNS to > secure applications, because, at the enterprise level and below, the > operators of the DNS are frequently not entrusted with the security of > applications. I mistrust any system which insists on forcing that to > change, while providing no recourse to those for whom such a policy is > unacceptable (and no, "advertise in the DNS whether to use the DNS" is > not such a recourse!). > No, there is no reliance on DNSSEC here, ideally the relationship is authenticated end-to-end using an EV cert. DNSSEC would be acceptable however. > 2) It makes the assumption that my email service provider is interested > in providing authentication services to me, and that I'm interested in > giving them the ability to impersonate me to my bank. > > > > > Again, no. The assumption is that you will choose an authentication provider that may or may not be your current email provider. It is assumed that there will be certain email forwarding taking place - at the account holder's discretion. But if you use lame.com as your email you would end up going somewhere else for your authentication if they won't support it. I'd be much happier to see a model wherein, at registration time, I tell > a service my public key, and then it uses public-key cryptography to > authenticate me in the future. Unfortunately, there are a number of > practical problems there, such as dealing with multiple clients per > user, kiosks, reinstalling machines, stolen credentials, etc., and it's > really preferable to avoid having every service provider deal with those > issues, rather than a much smaller number of authentication providers. > Raw public keys work less well than people think here. A public key identifies a device, never a person. To make a binding to a person you need infrastructure like I am describing here. We are in the UK for Xmas, between the four of us we brought ten computers (three laptops, on kindle, on iPad, two nintendo DS and three iPhones). Only some of those devices are single user and four of the devices are shared by all four of us. So I would very much like to pair a federated authentication scheme for people with a device level public key. I would also like to employ strong two factor schemes that can be tied to device level keying. But client certs alone do not serve this need. -- Website: http://hallambaker.com/ --0016e644c7044000210497f63b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey= Hutzelman <jhutz@cmu= .edu> wrote:
On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker w= rote:

>
> As Web sites discover that their account holders cannot remember their=
> username, most have adopted email addresses as account identifiers. > That is what we should use as the basis for federated web
> authentication.
>
>
>
>
> So if the user account identifier looks like username@example.com, how
> does an entity verify that a purported user has a va= lid claim to that
> account?
>
>
> The obvious mechanism in my view is to use DNS based discovery of an > authentication service. For example, we might use the ESRV scheme I > have been working on:
>
>
> _auth._ws.ex= ample.com =A0ESRV 0 prot "_saml._ws"
> _auth._ws.example.= com =A0ESRV 0 prot "_xcat._ws"
>
>
> Which declares that the SAML and 'XCAT' (presumably kitten in = XML)
> protocols may be used to resolve authentication requests.
>


I see two fundamental technical problems with this approach:

1) It relies on unsecured DNS to be secure. =A0Particularly, you suggest that, in order to discover a means to securely authenticate users
associated with some entity with which I have no prior relationship, I
should look up information about that entity in the DNS. =A0But DNSSEC is not widely-deployed enough (yet) for that to be realistic. =A0Further, I= 9;m
generally opposed to schemes that rely on the integrity of the DNS to
secure applications, because, at the enterprise level and below, the
operators of the DNS are frequently not entrusted with the security of
applications. =A0I mistrust any system which insists on forcing that to
change, while providing no recourse to those for whom such a policy is
unacceptable (and no, "advertise in the DNS whether to use the DNS&quo= t; is
not such a recourse!).

No, there is no = reliance on DNSSEC here, ideally the relationship is authenticated end-to-e= nd using an EV cert.

DNSSEC would be acceptable ho= wever.

=A0
2) It makes the assumption that my email service provider is interested
in providing authentication services to me, and that I'm interested in<= br> giving them the ability to impersonate me to my bank.
>
>

Again, no.

The assumption is that you will choose an authentication provider th= at may or may not be your current email provider. It is assumed that there = will be certain email forwarding taking place - at the account holder's= discretion.=A0

But if you = use lame.com as your email you would end up= going somewhere else for your authentication if they won't support it.=


<= div class=3D"gmail_quote">

I'd be much happier to see a model wherein, at registration time, I tel= l
a service my public key, and then it uses public-key cryptography to
authenticate me in the future. =A0Unfortunately, there are a number of
practical problems there, such as dealing with multiple clients per
user, kiosks, reinstalling machines, stolen credentials, etc., and it's=
really preferable to avoid having every service provider deal with those issues, rather than a much smaller number of authentication providers.

Raw public keys work less well than people think her= e.

A public key identifies a device, never a person. To = make a binding to a person you need infrastructure like I am describing her= e.=A0

We are in the UK for Xmas, between the four of us we br= ought ten computers (three laptops, on kindle, on iPad, two nintendo DS and= three iPhones). Only some of those devices are single user and four of the= devices are shared by all four of us.

So I would very much like to pair a federated authentication= scheme for people with a device level public key. I would also like to emp= loy strong two factor schemes that can be tied to device level keying. But = client certs alone do not serve this need.=A0
--0016e644c7044000210497f63b9d-- From hallam@gmail.com Wed Dec 22 10:09:52 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6, 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 bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -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 B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -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=mgKG9c/gWb6yXrkNacHqTGcIIEx1fZwdJJ2oemn7EBE=; b=ouWRplaVcxdpWHtQknwuz/4RfsDgTv5PCyZYgV/Z0CrvuSBUxfEbCSs8pRscEu9eW7 IEyno24F4oT8WrMwQyUvldBSOKDnnd7XNxy8CgXOwzEZJs2TqNws4T4Y8/63HMEABJoC YGPtV2ct38z60i8WYDotABc42sBc2aAounMSo= 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=V2DkssJFO1EzI+GoRXLSjxB86w5n3uEIPiCbjDvXvrY+LuKGwndt4k2QGQs/lditlp HXviFBtABeaLsqWoEkDQPgB6Au503ToQdEGp1LZVRamJlJbNVmH/9aepavlxD/883VUV WPVKauUGDFpkeGle8otm8Z0snefpwPfQ16vgE= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -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> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> <1292958219.2800.22.camel@destiny> Date: Wed, 22 Dec 2010 18:11:47 +0000 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=0016e644caf0c57c01049803af96 X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 18:09:52 -0000 --0016e644caf0c57c01049803af96 Content-Type: text/plain; charset=ISO-8859-1 [We seem to have dropped off the mailing lists, Jeffrey suggested I post this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelman wrote: > On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > > > No, there is no reliance on DNSSEC here, ideally the relationship is > > authenticated end-to-end using an EV cert. > > > > > > DNSSEC would be acceptable however. > > > > I don't follow. Your example shows an advertisement to service > providers that users from example.com can be authenticated to the SP by > using one of two authentication services. > Yes, it is assumed that there is some means of authenticating this binding, I did not specify what. > Unless I'm misunderstanding > you, this is about how the SP knows who to trust, and _not_ about how > the user's software talks to the user's identity provider. Thus EV is > really mostly irrelevant, since EV is about being able to make claims > that are really only meaningful when the relying party is controlled by > a human (the green bar is pretty, but I've yet to see an email server > that evaluates users' credentials on the basis of what color location > bar it sees). > You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the issuer applied validation practices that ensure a measure of accountability. > So, to accept a user's credentials, the SP needs to know two things: > 1) Is the assertion of user identity authentic? > 2) Does the assertion of user identity come from an authorized entity? > > The answer to (1) is provided by the authentication protocol in use, > which may well be public-key based. But that's not the part I'm worried > about. > > I am worried about (2). You show an example of one way to answer part > or all of (2). But you don't show how that answer is itself > authenticated. DNSSEC is certainly an acceptable answer to that, modulo > a whole bunch of conditions and issues that I'm willing to handwave > away, for now. But I don't think it can be the _only_ answer, for > reasons I've already raised. So, what's the other answer? > If there is a federated mechanism, there is going to have to be some registry of federation points available somewhere. We could use fred#facebook, jim#google and so on. But if there are friendly user identifiers and multiple auth providers there are going to be multiple repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to authenticate the in-zone data. How you authenticate the server when you arrive at it is another matter entirely. My view is that authentication providers should be considered to require substantial levels of infrastructure and planning. I totally reject the view floated in OpenID that it should be a design requirement that some fred in a shed can whack an authentication provider together from some Perl scripts without even bothering to upgrade to a recent version of perl. > > I'd be much happier to see a model wherein, at registration > > time, I tell > > a service my public key, and then it uses public-key > > cryptography to > > authenticate me in the future. Unfortunately, there are a > > number of > > practical problems there, such as dealing with multiple > > clients per > > user, kiosks, reinstalling machines, stolen credentials, etc., > > and it's > > really preferable to avoid having every service provider deal > > with those > > issues, rather than a much smaller number of authentication > > providers. > > > > Raw public keys work less well than people think here. > > > Raw public keys, usually wrapped in the completely unnecessary trappings > of a self-signed certificate, work surprisingly well in a wide variety > of circumstances. But they basically require first-order one-to-one > relationships between every client and every service provider, with all > the trappings required to deal with loss or compromise of the key, and > that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client to the authentication service. Less well as a means of federated authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds really convincing until you realize that they have not thought the problem through at all. > > To make a binding to a person you need infrastructure like I am > > describing here. > > > Not necessarily. I could imagine an infrastructure in which a user > authenticates to some key-management service, which then hands the user > his private key (the key belongs to the user, not the key-management > service, so revealing it to the user is OK). The user then uses that > key for authentication with whatever other services he wants. In fact, > to services other than the key-management service, this is > indistinguishable from the user having had the key all along. Of > course, it does involve the user handing his private key to some other > service, which has its own problems. > I don't like that approach because in my view a private key is something that should only ever exist in one place where it is created and later destroyed. I prefer an approach where the client-authentication provider authentication uses whatever tool is best and then the authentication provider supplies some form of token that can be used for authentication to at least one third party. That token could use public key, but symmetric is sufficient and more efficient. -- Website: http://hallambaker.com/ --0016e644caf0c57c01049803af96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[We seem to have dropp= ed off the mailing lists, Jeffrey suggested I post this which shows where w= e ended up.]

On Wed, Dec 22, 2010 at 3:02 AM, Jef= frey Hutzelman=A0<jhutz@cmu.edu>wrote:
On= Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote:

<= div class=3D"im" style=3D"color: rgb(80, 0, 80); ">> No, there is no rel= iance on DNSSEC here, ideally the relationship is
> authenticated end-to-end using an EV cert.
>
>
> DNS= SEC would be acceptable however.
>

I don't follow. =A0Your exam= ple shows an advertisement to service
providers that users from=A0example.com=A0can be authenticate= d to the SP by
using one of two authentication services.

Yes, it is assumed that there is some means of authenticatin= g this binding, I did not specify what.

=A0
=A0Unless I'm misunderstanding
you, this is about how the SP knows w= ho to trust, and _not_ about how
the user's software talks to the us= er's identity provider. =A0Thus EV is
really mostly irrelevant, sinc= e EV is about being able to make claims
that are really only meaningful when the relying party is controlled by
= a human (the green bar is pretty, but I've yet to see an email serverthat evaluates users' credentials on the basis of what color location=
bar it sees).

You do not understa= nd the purpose of EV then.=A0

EV is about accounta= bility. The green bar is displayed because the issuer applied validation pr= actices that ensure a measure of accountability.=A0

=A0=
So, to accept a user's credentials, the SP needs to know two things:1) Is the assertion of user identity authentic?
2) Does the assertion o= f user identity come from an authorized entity?

The answer to (1) is= provided by the authentication protocol in use,
which may well be public-key based. =A0But that's not the part I'm = worried
about.

I am worried about (2). =A0You show an example of = one way to answer part
or all of (2). =A0But you don't show how that= answer is itself
authenticated. =A0DNSSEC is certainly an acceptable answer to that, modulo<= br>a whole bunch of conditions and issues that I'm willing to handwave<= br>away, for now. =A0But I don't think it can be the _only_ answer, for=
reasons I've already raised. =A0So, what's the other answer?

If there is a federated mechanism, ther= e is going to have to be some registry of federation points available somew= here. We could use fred#facebook, jim#google and so on. But if there are fr= iendly user identifiers and multiple auth providers there are going to be m= ultiple repositories to disambiguate.

So there is going to be some PKI involved however you d= o it.


My preference is to use DNS f= or the signaling layer and DNSSEC to authenticate the in-zone data. How you= authenticate the server when you arrive at it is another matter entirely.= =A0

My view is that authentication providers should be cons= idered to require substantial levels of infrastructure and planning. I tota= lly reject the view floated in OpenID that it should be a design requiremen= t that some fred in a shed can whack an authentication provider together fr= om some Perl scripts without even bothering to upgrade to a recent version = of perl.

=A0=
> =A0 =A0 =A0 =A0 I'd be much happier to see a model wherein, a= t registration
> =A0 =A0 =A0 =A0 time, I tell
> =A0 =A0 =A0 =A0= a service my public key, and then it uses public-key
> =A0 =A0 =A0 = =A0 cryptography to
> =A0 =A0 =A0 =A0 authenticate me in the future. = =A0Unfortunately, there are a
> =A0 =A0 =A0 =A0 number of
> =A0 =A0 =A0 =A0 practical problems t= here, such as dealing with multiple
> =A0 =A0 =A0 =A0 clients per
= > =A0 =A0 =A0 =A0 user, kiosks, reinstalling machines, stolen credential= s, etc.,
> =A0 =A0 =A0 =A0 and it's
> =A0 =A0 =A0 =A0 really preferable to avoid having every service provid= er deal
> =A0 =A0 =A0 =A0 with those
> =A0 =A0 =A0 =A0 issues, = rather than a much smaller number of authentication
> =A0 =A0 =A0 =A0= providers.
>
> Raw public keys work less well than people thin= k here.
>
Raw public keys, usually wrapped in the completely unnecessar= y trappings
of a self-signed certificate, work surprisingly well in a wi= de variety
of circumstances. =A0But they basically require first-order o= ne-to-one
relationships between every client and every service provider, with all
= the trappings required to deal with loss or compromise of the key, and
t= hat simply doesn't scale to the Internet.

CardSpace works perfectly well as a method of authenticating the= client to the authentication service. Less well as a means of federated au= thentication.

Various people have proposed 'Ca= rdSpace' in the cloud. Which sounds really convincing until you realize= that they have not thought the problem through at all.

=A0=
> To make a binding to a person you need infrastructure like I am> describing here.
>
Not necessarily. =A0I could imagin= e an infrastructure in which a user
authenticates to some key-management= service, which then hands the user
his private key (the key belongs to the user, not the key-management
ser= vice, so revealing it to the user is OK). =A0The user then uses that
key= for authentication with whatever other services he wants. =A0In fact,
t= o services other than the key-management service, this is
indistinguishable from the user having had the key all along. =A0Of
cour= se, it does involve the user handing his private key to some other
servi= ce, which has its own problems.

I don't= like that approach because in my view a private key is something that shou= ld only ever exist in one place where it is created and later destroyed.
I prefer an approach where the client-authentication provider auth= entication uses whatever tool is best and then the authentication provider = supplies some form of token that can be used for authentication to at least= one third party.

That token could use public key, but symmetric is suffi= cient and more efficient.
 --0016e644caf0c57c01049803af96-- From hallam@gmail.com Wed Dec 22 13:37:38 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB5B3A6B37; Wed, 22 Dec 2010 13:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6] 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 ehVB8lML9y+F; Wed, 22 Dec 2010 13:37:36 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D3FB93A68BE; Wed, 22 Dec 2010 13:37:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlomAIf+EU3GmAcF/2dsb2JhbACUVYE0jhAIc6klgQgCiGuHKC6IXIJyglcEiwSDHQYUh3s X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="51313747" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Dec 2010 16:39:27 -0500 X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="559921885" Received: from unknown (HELO 307622ANEX1.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2010 16:39:26 -0500 Received: from mail pickup service by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC; Wed, 22 Dec 2010 22:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBA220.9C973700" Received: from 307622ANEX2.global.avaya.com ([135.64.140.15]) by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:13:08 +0100 Received: from co300216-co-erhwest.avaya.com ([198.152.7.5]) by 307622ANEX2.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:11:58 +0100 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by co300216-co-erhwest.avaya.com with ESMTP; 22 Dec 2010 13:11:58 -0500 Received: from mail.ietf.org ([64.170.98.32]) by co300216-co-ierwest.avaya.com with ESMTP; 22 Dec 2010 13:11:57 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13843A6B37; Wed, 22 Dec 2010 10:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) 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 bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -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 B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -0800 (PST) Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 22 Dec 2010 18:13:08.0215 (UTC) FILETIME=[E2B2A070:01CBA203] Date: Wed, 22 Dec 2010 19:11:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation Thread-Index: AcuiA7mTehF0T8iMSHeVmmOflr3UqQ== References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com><4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com><4D051731.1020400@isode.com> <4D054041.7010203@cisco.com><0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com><2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com><2229.1292239384.281779@puncture><96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org><2229.1292253372.639419@puncture><11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com><1292958219.2800.22.camel@destiny> From: "Phillip Hallam-Baker" Sender: To: "Jeffrey Hutzelman" X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 21:37:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA220.9C973700 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBA220.9C973700" ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [We seem to have dropped off the mailing lists, Jeffrey suggested I post = this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelmanwrote: On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > No, there is no reliance on DNSSEC here, ideally the relationship is > authenticated end-to-end using an EV cert. > > > DNSSEC would be acceptable however. > I don't follow. Your example shows an advertisement to service providers that users fromexample.com can be = authenticated to the SP by using one of two authentication services. Yes, it is assumed that there is some means of authenticating this = binding, I did not specify what. Unless I'm misunderstanding you, this is about how the SP knows who to trust, and _not_ about how the user's software talks to the user's identity provider. Thus EV is really mostly irrelevant, since EV is about being able to make claims that are really only meaningful when the relying party is controlled by a human (the green bar is pretty, but I've yet to see an email server that evaluates users' credentials on the basis of what color location bar it sees). You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the = issuer applied validation practices that ensure a measure of = accountability. So, to accept a user's credentials, the SP needs to know two things: 1) Is the assertion of user identity authentic? 2) Does the assertion of user identity come from an authorized entity? The answer to (1) is provided by the authentication protocol in use, which may well be public-key based. But that's not the part I'm worried about. I am worried about (2). You show an example of one way to answer part or all of (2). But you don't show how that answer is itself authenticated. DNSSEC is certainly an acceptable answer to that, modulo a whole bunch of conditions and issues that I'm willing to handwave away, for now. But I don't think it can be the _only_ answer, for reasons I've already raised. So, what's the other answer? If there is a federated mechanism, there is going to have to be some = registry of federation points available somewhere. We could use = fred#facebook, jim#google and so on. But if there are friendly user = identifiers and multiple auth providers there are going to be multiple = repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to = authenticate the in-zone data. How you authenticate the server when you = arrive at it is another matter entirely. My view is that authentication providers should be considered to require = substantial levels of infrastructure and planning. I totally reject the = view floated in OpenID that it should be a design requirement that some = fred in a shed can whack an authentication provider together from some = Perl scripts without even bothering to upgrade to a recent version of = perl. > I'd be much happier to see a model wherein, at registration > time, I tell > a service my public key, and then it uses public-key > cryptography to > authenticate me in the future. Unfortunately, there are a > number of > practical problems there, such as dealing with multiple > clients per > user, kiosks, reinstalling machines, stolen credentials, etc., > and it's > really preferable to avoid having every service provider deal > with those > issues, rather than a much smaller number of authentication > providers. > > Raw public keys work less well than people think here. > Raw public keys, usually wrapped in the completely unnecessary trappings of a self-signed certificate, work surprisingly well in a wide variety of circumstances. But they basically require first-order one-to-one relationships between every client and every service provider, with all the trappings required to deal with loss or compromise of the key, and that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client = to the authentication service. Less well as a means of federated = authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds = really convincing until you realize that they have not thought the = problem through at all. > To make a binding to a person you need infrastructure like I am > describing here. > Not necessarily. I could imagine an infrastructure in which a user authenticates to some key-management service, which then hands the user his private key (the key belongs to the user, not the key-management service, so revealing it to the user is OK). The user then uses that key for authentication with whatever other services he wants. In fact, to services other than the key-management service, this is indistinguishable from the user having had the key all along. Of course, it does involve the user handing his private key to some other service, which has its own problems. I don't like that approach because in my view a private key is something = that should only ever exist in one place where it is created and later = destroyed. I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party. That token could use public key, but symmetric is sufficient and more = efficient. -- Website:http://hallambaker.com/ ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[We seem to have dropped = off the mailing lists, Jeffrey suggested I post this which shows where = we ended up.]

On Wed, Dec 22, 2010 at = 3:02 AM, Jeffrey Hutzelman<jhutz@cmu.edu>wrote:
I don't follow. Your example shows = an advertisement to service
providers that users fromexample.comcan = be authenticated to the SP by
using one of two authentication = services.

Yes, it is assumed that there is some means of = authenticating this binding, I did not specify what.
Unless I'm misunderstanding
you, this is about how the SP knows = who to trust, and _not_ about how
the user's software talks to = the user's identity provider. Thus EV is
really mostly = irrelevant, since EV is about being able to make claims
that are really only meaningful when the relying party is controlled = by
a human (the green bar is pretty, but I've yet to see an email = server
that evaluates users' credentials on the basis of what = color location
bar it sees).

You do not = understand the purpose of EV then.

EV is about = accountability. The green bar is displayed because the issuer applied = validation practices that ensure a measure of accountability.
So, to accept a user's credentials, the SP needs to know two = things:
1) Is the assertion of user identity authentic?
2) Does = the assertion of user identity come from an authorized = entity?

The answer to (1) is provided by the authentication = protocol in use,
which may well be public-key based. But that's not the part I'm = worried
about.

I am worried about (2). You show an example of = one way to answer part
or all of (2). But you don't show how that = answer is itself
authenticated. DNSSEC is certainly an acceptable answer to that, = modulo
a whole bunch of conditions and issues that I'm willing to = handwave
away, for now. But I don't think it can be the _only_ = answer, for
reasons I've already raised. So, what's the other = answer?

If there is a = federated mechanism, there is going to have to be some registry of = federation points available somewhere. We could use fred#facebook, = jim#google and so on. But if there are friendly user identifiers and = multiple auth providers there are going to be multiple repositories to = disambiguate.

So there is going to be some PKI involved however = you do it.


My preference is to = use DNS for the signaling layer and DNSSEC to authenticate the in-zone = data. How you authenticate the server when you arrive at it is another = matter entirely.

My view is that authentication providers should be = considered to require substantial levels of infrastructure and planning. = I totally reject the view floated in OpenID that it should be a design = requirement that some fred in a shed can whack an authentication = provider together from some Perl scripts without even bothering to = upgrade to a recent version of perl.
> I'd be much happier to see a model wherein, at = registration
> time, I tell
> a service my public = key, and then it uses public-key
> cryptography to
> = authenticate me in the future. Unfortunately, there are a
> number of
> practical problems there, such as dealing = with multiple
> clients per
> user, kiosks, = reinstalling machines, stolen credentials, etc.,
> and = it's
> really preferable to avoid having every service provider = deal
> with those
> issues, rather than a much = smaller number of authentication
> providers.
>
> = Raw public keys work less well than people think here.
>
Raw public keys, usually wrapped in the completely = unnecessary trappings
of a self-signed certificate, work surprisingly = well in a wide variety
of circumstances. But they basically require = first-order one-to-one
relationships between every client and every service provider, with = all
the trappings required to deal with loss or compromise of the = key, and
that simply doesn't scale to the = Internet.

CardSpace works perfectly well as a method of authenticating = the client to the authentication service. Less well as a means of = federated authentication.

Various people have = proposed 'CardSpace' in the cloud. Which sounds really = convincing until you realize that they have not thought the problem = through at all.
> To make a binding to a person you need infrastructure like I = am
> describing here.
>
Not necessarily. I could = imagine an infrastructure in which a user
authenticates to some = key-management service, which then hands the user
his private key (the key belongs to the user, not the = key-management
service, so revealing it to the user is OK). The user = then uses that
key for authentication with whatever other services he = wants. In fact,
to services other than the key-management service, = this is
indistinguishable from the user having had the key all along. = Of
course, it does involve the user handing his private key to some = other
service, which has its own = problems.

I don't like that approach = because in my view a private key is something that should only ever = exist in one place where it is created and later destroyed.

I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party.

That token could use public key, but symmetric is = sufficient and more efficient.
 ------_=_NextPart_002_01CBA220.9C973700-- ------_=_NextPart_001_01CBA220.9C973700 Content-Type: text/plain; name="ATT2808037.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2808037.txt Content-Disposition: inline; filename="ATT2808037.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlz Y3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== ------_=_NextPart_001_01CBA220.9C973700-- From sayrer@gmail.com Wed Jan 5 17:26:08 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5A13A6E4C; Wed, 5 Jan 2011 17:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_57=0.6, 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 kfd7k09rhiTF; Wed, 5 Jan 2011 17:26:07 -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 1C1AE3A6DD2; Wed, 5 Jan 2011 17:26:03 -0800 (PST) Received: by gxk28 with SMTP id 28so7425497gxk.31 for ; Wed, 05 Jan 2011 17:28:10 -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 :content-transfer-encoding; bh=SmSGVsL3s1/e2mEs3LupI5w3onGShvZ4UtUrWrsZAvc=; b=oqDjO5l9OasDvMqhtSRG5lBW5ly/sZVMnAjtawLZzAl/3BcHvbwgxm2A7LZBaVcfMN a9KveWQYf85Hokfz/WOSIeHFo5vugc3VUbSZ4nX7FUN/VFYr034yQl2lg0qKaJj1Dl2p 0X6JN5ZqZ8eGZJ643GK1sl/rs515U1g7olm48= 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:content-transfer-encoding; b=MrgU77VixIxQZ2qTzxT40ypYmHsE2NSX6bk0ijTIlvi7TaDvo2k6K4qaw7P0+/hZSX clJhXNhTjD8ISKOAGHVBWw9YYGd3FJ6Qdm2ZMA4Z4qpL51b+FZmDyeKAjVv6EA5Y0kvH Vt1pSfmVsKKdhYbvPCUzUw5ewnPuywqbjy6UQ= MIME-Version: 1.0 Received: by 10.90.4.7 with SMTP id 7mr1387636agd.100.1294277289574; Wed, 05 Jan 2011 17:28:09 -0800 (PST) Received: by 10.90.133.12 with HTTP; Wed, 5 Jan 2011 17:28:08 -0800 (PST) In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.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> Date: Wed, 5 Jan 2011 20:28:08 -0500 Message-ID: From: Robert Sayre To: "Roy T. Fielding" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 01:26:09 -0000 > Peter Saint-Andre wrote: > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html These are back on the Web, in case anyone missed them (probably not). On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. =A0It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. =A0Zero progress so far. Hard to disagree with this assessment. It's pretty easy to define something better than the current HTTP authentication mechanisms, but pretty hard to design something more popular than forms+cookies. I've looked at this problem a little bit, and I gather the strictly technical security properties we're looking for are pretty well understood. Deployment and presentation control are the tough parts. Presentation control is actually a security trade-off--to get the control web designers want, you have to present graphics before the server has been authenticated. Also, I suspect it will be difficult to deploy a new HTTP mechanism that can withstand replay and DoS attacks, unless proxy conformance gets a lot better. So, I think those advocating TLS-only solutions might turn out to win the day, but not because the security properties on offer are particularly compelling. I think the IETF might do better to focus on a smaller problem, at first. People often use self-signed certificates with HTTP/TLS, even though the first thing their websites ask the 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 solution, then the larger issue of authentication on the entire Web seems like a tough nut to crack. It could be that the reasons for this lack of progress are nontechnical. Just throwing that out there. --=20 Robert Sayre "I would have written a shorter letter, but I did not have the time." From dwm@xpasc.com Thu Jan 6 08:01:50 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C72A63A6EFF; Thu, 6 Jan 2011 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 n202LIwHccwW; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id 640053A6E48; Thu, 6 Jan 2011 08:01:49 -0800 (PST) Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id CDB7510058A; Thu, 6 Jan 2011 08:03:55 -0800 (PST) X-Propel-Return-Path: Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.2.exported $Rev: 9262 $) id iz6Urb16g3T0; Thu, 06 Jan 2011 08:03:55 -0800 Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 97631100585; Thu, 6 Jan 2011 08:03:55 -0800 (PST) Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id p06G3shY018211; Thu, 6 Jan 2011 08:03:54 -0800 Date: Thu, 6 Jan 2011 08:03:54 -0800 (PST) From: David Morris In-Reply-To: Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Propel-ID: iz6Urb16g3T0 X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:01:51 -0000 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... From tim-projects@sentinelchicken.org Thu Jan 6 08:23:56 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5015C3A6D79 for ; Thu, 6 Jan 2011 08:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=-0.275, 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 CtcbD3qEOBx2 for ; Thu, 6 Jan 2011 08:23:55 -0800 (PST) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by core3.amsl.com (Postfix) with ESMTP id BDB523A6C4F for ; Thu, 6 Jan 2011 08:23:54 -0800 (PST) Received: (qmail 3323 invoked from network); 6 Jan 2011 16:28:47 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jan 2011 16:28:47 -0000 Received: (qmail 23661 invoked from network); 6 Jan 2011 16:29:18 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jan 2011 16:29:18 -0000 Received: (nullmailer pid 15198 invoked by uid 1000); Thu, 06 Jan 2011 16:25:59 -0000 Date: Thu, 6 Jan 2011 08:25:59 -0800 From: Tim To: Ben Laurie Message-ID: <20110106162559.GQ6792@sentinelchicken.org> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Thu, 06 Jan 2011 10:06:47 -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: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 16:23:56 -0000 > 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. > > 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 because 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 the look, while > appropriate HTML elements or JS code can deal with the secure exchange of > data. Yes, the user experience piece is definitely the biggest adoption problem for HTTP auth, IMO. However, I disagree that HTTP is the wrong layer. It has already been shown (by myself and others) that using HTTP authentication and controlling the user experience can largely be achieved already. A few tweaks to browser 401 response behavior (which doesn't require standards changes) and the ability for servers to force a log out are all that's left to provide to make this reliable. As for RFC 4279, I'm not really familiar with it, but I imagine the mechansims which allow for user experience customization right now with HTTP auth could easily be extended to any TLS authentication mechansim. The only requirement there would be to add some simple language allowing for this behavior in [1]. That is, allow XMLHttpRequest objects to hand the credentials they already accept off to the TLS layer, either for RFC 4279 or for SRP/TLS. > 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 simulated > so as to get hold of the underlying password? > > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. Yes, so what I've outlined above and elsewhere is a relatively simple transition path to allow adoption of better authentication standards with customizable user interfaces. But those are problematic by design. However, I'd assert that moving web applications off of cookies to some lower-layer mechanism is going to be a required first step in order to provide authentication prompts that are part of the browser, for those who need that security. tim 1. http://www.w3.org/TR/XMLHttpRequest/ From benl@google.com Thu Jan 6 10:14:13 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1228C3A6CD7 for ; Thu, 6 Jan 2011 10:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.422 X-Spam-Level: X-Spam-Status: No, score=-103.422 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 85bk3KWKRe4w for ; Thu, 6 Jan 2011 10:14:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 186923A6CD8 for ; Thu, 6 Jan 2011 10:14:11 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p06IGHNh013717 for ; Thu, 6 Jan 2011 10:16:17 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294337778; bh=tOrSd+BaLDGYpH9HsyVCcafu+oA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=nhcwIisUO7oAkg66A8rDBAHv5zLtVTeKxgwhQrGOkd1tM+8dUs0mMmYzkOc12BMsQ vRwjIWFLBdC/r+miufS3g== Received: from qyk10 (qyk10.prod.google.com [10.241.83.138]) by hpaq6.eem.corp.google.com with ESMTP id p06IDV7F014212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Jan 2011 10:16:16 -0800 Received: by qyk10 with SMTP id 10so17630744qyk.8 for ; Thu, 06 Jan 2011 10:16:16 -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; bh=ztYKyBRdnEWKJBsTrbql2FglzmqVhvAw6IaIUfdkB7w=; b=BxXEavN29UHyrsu3lhFh4wtPxqyyfTe7rbvsAK9O9yU8bnoEzoceDOSlCK6QPcd3dG ll62XjLsoR18WS0HmO5Q== 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; b=FCRb0q97ppk3nPf0vWscaA0RV1zaAaw54FU7Dt4Ih57ZFclnJC0C5VptKxZu+gFzH7 b9AIO/Z0ax7qhwFKRnlQ== MIME-Version: 1.0 Received: by 10.229.215.135 with SMTP id he7mr3108759qcb.104.1294337776341; Thu, 06 Jan 2011 10:16:16 -0800 (PST) Received: by 10.220.88.137 with HTTP; Thu, 6 Jan 2011 10:16:15 -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: Thu, 6 Jan 2011 18:16:15 +0000 Message-ID: From: Ben Laurie To: David Morris Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:14:13 -0000 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. From turners@ieca.com Thu Jan 6 10:32:22 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DBBA3A6F2E for ; Thu, 6 Jan 2011 10:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 0JTPWubRBMUV for ; Thu, 6 Jan 2011 10:32:21 -0800 (PST) Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by core3.amsl.com (Postfix) with SMTP id 24F873A6C75 for ; Thu, 6 Jan 2011 10:32:21 -0800 (PST) Received: from [98.139.52.189] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 18:34:25 -0000 Received: from [98.139.52.174] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 18:34:25 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 18:34:25 -0000 X-Yahoo-Newman-Id: 279440.37103.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 23055 invoked from network); 6 Jan 2011 18:34:25 -0000 Received: from thunderfish.local (turners@96.231.125.241 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 06 Jan 2011 10:34:25 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: bsm2tqIVM1l7f.1nZmKmOHIozFUckg6IgABJ1uHP22dA2xq YwvqHESSG9vYzSLAckeOeAkO3LBLMjbB6JA6cjjTcfo99rq7y6Ua1N4vu4XI pplCZZEeTQNFvA337AxxO.qtZZ3AIHZbrSPBjdTLAMysZrs6IkdjwMKcavOO 1BagIMMNtOH6qXCiu.R1oDBz65Wd8f_kNyvas3S1wpbrRzq3bvRVrzF0rKsA YCEeaKOAgsJ3fK_WxnuXB6AO7evnZj_l1xAK98Xrgxcp_DjAzIISgYCzQaor 7XMPo8yao3ANqdRpqIDDxo.bs3_vS4EMh4A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D260B30.60103@ieca.com> Date: Thu, 06 Jan 2011 13:34:24 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: time to act on IETF-80 BOFs X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:32:22 -0000 FYI -------- Original Message -------- Subject: time to act on IETF-80 BOFs Date: Wed, 05 Jan 2011 22:29:34 +0100 From: Jari Arkko To: IETF Discussion , Working Group Chairs Just as a reminder, if any of you are thinking of proposing new IETF work: the deadline for BOF proposals for the next meeting is January 31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Jari From mouse@Sparkle.Rodents-Montreal.ORG Thu Jan 6 10:39:24 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5F3A6F43; Thu, 6 Jan 2011 10:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.792 X-Spam-Level: X-Spam-Status: No, score=-8.792 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8] 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 PImVhi95MZYY; Thu, 6 Jan 2011 10:39:23 -0800 (PST) Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by core3.amsl.com (Postfix) with ESMTP id CF3113A6F3A; Thu, 6 Jan 2011 10:39:22 -0800 (PST) Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA23900; Thu, 6 Jan 2011 13:35:40 -0500 (EST) Date: Thu, 6 Jan 2011 13:35:40 -0500 (EST) From: der Mouse Message-Id: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 6 Jan 2011 13:19:53 -0500 (EST) To: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org In-Reply-To: <4D0E8148.7060607@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> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 18:39:24 -0000 > Look back far enough and you'll find all kinds of "electronic mail" > services implementing the full range of peer and end user > authentication, and sender-pays models. There was no spam on those > systems, or at least not enough that anyone felt like they needed a > word for it. There was basically no spam on open-Internet SMTP mail either, at the time. Certainly "no spam" by today's standards. > Guess why we use the one we use today. At the time, the services you deride weren't providing a significant value-add. Today? They would be. Perhaps not enough to make up for their costs; probably not, in fact, or there'd be businesses arising in that space. As a side note, it's interesting to see how well the early Internet designers built; their systems are routinely being stressed several orders of magnitude beyond what they were designed for, and are holding up remarkably well. The postal system did collapse when it started suffering from spam; that's why the paper chain mail is actually illegal in many jurisdictions - it took down the postal system, once upon a time. The telphone system would collapse if phone spam outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they already do. I have a fax line set up, and get dozens of fax spams for every real fax. I've had to start adapting and applying my email spam fighting techniques there....) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From lnovikov@mitre.org Mon Jan 10 15:58:37 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58F73A680F; Mon, 10 Jan 2011 15:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, 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 MV6Tw96ADy-w; Mon, 10 Jan 2011 15:58:36 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 59F363A6814; Mon, 10 Jan 2011 15:58:36 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 189BD21B02A2; Mon, 10 Jan 2011 19:00:51 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 13C7C21B029E; Mon, 10 Jan 2011 19:00:51 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 10 Jan 2011 19:00:51 -0500 From: "Novikov, Lev" To: CICM Discussion List Date: Mon, 10 Jan 2011 18:58:29 -0500 Thread-Topic: -02 draft of CICM posted Thread-Index: AcskWWz5sLSa82ElSNe2wD4zt5uCjSMxqdPw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "saag@ietf.org" Subject: [saag] -02 draft of CICM posted X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:58:38 -0000 The -02 draft of the Common Interface to Cryptographic Modules (CICM) has b= een posted. Comments are solicited to . Some new issues have been discovered as a result of this recent work and wi= ll be raised on the mailing list soon. This revision restructures CICM into five documents as discussed back in Ju= ly: 1. [CICM-LM] An informative background document that provides an introducti= on to the space,=20 the terminology, and logical model. 2. [CICM] A normative base document that defines the basic types and the Co= nformance & Extension model. 3. [CICM-MM] A normative document that defines Module Management capabiliti= es. 4. [CICM-KM] A normative document that defines Key Management capabilities. 5. [CICM-CM] A normative document that defines Channel Management capabilit= ies. As discussed previously, the document labeled [CICM] is the normative docum= ent upon which all other documents (except CICM-LM) are based. Other Changes: - figures added to illustrate basic concepts - sample ICS added Pending Changes: - adding ABNF syntax for generating identifiers (in progress) Lev From marsh@extendedsubset.com Thu Jan 6 11:49:54 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C8F3A6F34; Thu, 6 Jan 2011 11:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 5IsN4qZgy7XQ; Thu, 6 Jan 2011 11:49:50 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 601543A6D06; Thu, 6 Jan 2011 11:49:50 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PavsL-0007lR-0x; Thu, 06 Jan 2011 19:51:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7DDDC603D; Thu, 6 Jan 2011 19:51:54 +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: U2FsdGVkX19YqhOZiaovwLDZ2QqifW+U3NXa/nAN2Ec= Message-ID: <4D261D59.9010405@extendedsubset.com> Date: Thu, 06 Jan 2011 13:51:53 -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: der Mouse References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> <4D0E8148.7060607@extendedsubset.com> <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201101061835.NAA23900@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Jan 2011 08:12:11 -0800 Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:49:54 -0000 On 01/06/2011 12:35 PM, der Mouse wrote: >> Look back far enough and you'll find all kinds of "electronic mail" >> services implementing the full range of peer and end user >> authentication, and sender-pays models. There was no spam on those >> systems, or at least not enough that anyone felt like they needed a >> word for it. > > There was basically no spam on open-Internet SMTP mail either, at the > time. Certainly "no spam" by today's standards. > >> Guess why we use the one we use today. > > At the time, the services you deride weren't providing a significant > value-add. I wasn't so much deriding them but saying there were points all over the trade-off curve and the market voted with its feet. Unambiguously. Of course, the marketing creeps followed. > Today? They would be. Perhaps not enough to make up for their costs; > probably not, in fact, or there'd be businesses arising in that space. There are plenty. It's a commoditized low-margin business these days. But the network infrastructure costs are not nearly the biggest cost once you factor in things like end-user support. E.g. http://www.google.com/search?q=hosted+vpn It occurred to me last night that one might recreate the good old days of the Internet with a VPN which allowed access to the good old folks who were on it back then. Sounds a little crass and elitist now that I propose it out loud. But imagine a global authenticated VPN where the only reason you could be banned is for spamming? Or one where you had to be at a university CS department? Or a whole set of overlapping criteria and you could choose what the membership criteria for your own view of the network? Your own personal Virtual Public Internet. > As a side note, it's interesting to see how well the early Internet > designers built; their systems are routinely being stressed several > orders of magnitude beyond what they were designed for, and are holding > up remarkably well. It is amazing, isn't it? > The postal system did collapse when it started > suffering from spam; that's why the paper chain mail is actually > illegal in many jurisdictions - it took down the postal system, once > upon a time. Nice. > The telphone system would collapse if phone spam > outnumbered real calls by 10, 25, 100 to 1. (Actually, in a sense they > already do. I have a fax line set up, and get dozens of fax spams for > every real fax. I've had to start adapting and applying my email spam > fighting techniques there....) We get so many unsolicited calls from telemarketers and robot dialers at home we don't answer the phone unless we recognize the caller ID. Sometimes family calling from roaming cell phones show up as 'unidentified caller' and we mistakenly don't answer. How much more broken can it be? - Marsh From hallam@gmail.com Sat Jan 8 08:05:35 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED07028C116; Sat, 8 Jan 2011 08:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=0.204, 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 6gCSwpkqFCfA; Sat, 8 Jan 2011 08:05:34 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 980FE28C115; Sat, 8 Jan 2011 08:05:30 -0800 (PST) Received: by yie19 with SMTP id 19so5709246yie.31 for ; Sat, 08 Jan 2011 08:07:38 -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=EZat7nI2OqohWyhSuZ4/WUlxZZdT1hBAk9ZOiTKdMs8=; b=IsStjSvSUvS0dPFDf1N3Ml3awrq6X6rj5PoZzGDm8t25H5pVn6+V+O8BlPF4zYXGiw 15TFFqfUG6WgkHRo9pfnC6zEIrglsN88NS7dz4gkaK9K3deHlpnk8vEW0vNrYsxJ4yyZ hWZlZEK/FamRcOPXqikvjrHHlsdrGvTmrl/lo= 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=WSyrgGBaHg3J5BznJYd6ZsF1Ar8HJ3QQhdyo4tPV51GGUNa4oJNsQCdx/zvFY8FyWK C5j2k8JRj00t4G/7PZ1MX0RU3qlQtl2dosSeNZKMm9U++nWz2mXgPU/iACBsZyYyhIrg IKFedcrAXxE3YeAiKRUmipB+NPHJj2bdEiEzY= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2476968ane.171.1294502858509; Sat, 08 Jan 2011 08:07:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:07:38 -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:07:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=0016e644dbc60acc57049957ef07 X-Mailman-Approved-At: Thu, 13 Jan 2011 08:12:12 -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: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 16:05:36 -0000 --0016e644dbc60acc57049957ef07 Content-Type: text/plain; charset=ISO-8859-1 I think that Ben is right that we are solving the wrong problem. 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! 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. We have to solve the federated auth problem and it is really, really easy: 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. 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. Client authenticates to authentication service 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 existing 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 some ideas on how we could modify DIGEST to do this. DIGEST would not be problematic if the password had 128 bits of ergodicity and we upgraded the digest function. The reason for re-using DIGEST here would be to avoid patent encumbrances. I considered the issue of linkability at great length when writing the original DIGEST design. At the moment I am focused on getting the foundation laid. But I will try to come up with a full proposal before Prague. 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). 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. Devices get lost. Devices get stolen. 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) 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. On Thu, Jan 6, 2011 at 10:31 AM, Ben Laurie wrote: > > > On 6 January 2011 01:28, Robert Sayre wrote: >> >> > Peter Saint-Andre wrote: >> > 2. In 2007, Robert Sayre put together a few slides on the topic: >> > http://people.mozilla.com/~sayrer/2007/auth.html >> >> These are back on the Web, in case anyone missed them (probably not). >> >> On Sun, Dec 12, 2010 at 5:39 PM, Roy T. Fielding >> wrote: >> > >> > Define them all and let's have a bake-off. It has been 16 years since >> > HTTP auth was taken out of our hands so that the security experts could >> > define something perfect. Zero progress so far. >> >> I think the IETF might do better to focus on a smaller problem, at >> first. People often use self-signed certificates with HTTP/TLS, even >> though the first thing their websites ask the 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 solution, then the >> larger issue of authentication on the entire Web seems like a tough >> nut to crack. > > 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. > 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 because 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 the 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 simulated > so as to get hold of the underlying password? > The answer to this problem is hard, since it brings us back to taking the UI > out of the sites hands. > >> >> It could be that the reasons for this lack of progress are >> nontechnical. Just throwing that out there. > > If you think UI is nontechnical, then I agree. > Cheers, > Ben. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > -- Website: http://hallambaker.com/ --0016e644dbc60acc57049957ef07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that Ben is right that we are solving the wrong problem.

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!


I can't remember the account names, the password is easy as I o= nly had one (for non financial) - until those cretins at Gawker screwed up.= Now I have to reset my password at all those places.


We have to= solve the federated auth problem and it is really, really easy:

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 rel= iably.

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.

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: saag@core3.amsl.com Delivered-To: saag@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 X-Mailman-Approved-At: Thu, 13 Jan 2011 08:12:12 -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: [saag] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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.

+1

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 romeda@gmail.com Sat Jan 8 09:35:35 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@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: Thu, 13 Jan 2011 08:12:11 -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: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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 hallam@gmail.com Sat Jan 8 09:50:39 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@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 X-Mailman-Approved-At: Thu, 13 Jan 2011 08:12:12 -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: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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 marsh@extendedsubset.com Sat Jan 8 13:31:00 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@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: Thu, 13 Jan 2011 08:12:11 -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: [saag] [http-auth] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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: saag@core3.amsl.com Delivered-To: saag@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: Thu, 13 Jan 2011 08:12:11 -0800 Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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 05:42:05 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606863A69A4 for ; Sun, 9 Jan 2011 05:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.863 X-Spam-Level: X-Spam-Status: No, score=-103.863 tagged_above=-999 required=5 tests=[AWL=-0.886, 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 pDH8LwzhmDSX for ; Sun, 9 Jan 2011 05:42:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 4B10E3A69A9 for ; Sun, 9 Jan 2011 05:42:04 -0800 (PST) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p09DiENC004529 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 vws14 (vws14.prod.google.com [10.241.21.142]) by hpaq5.eem.corp.google.com with ESMTP id p09DiC04012168 for ; Sun, 9 Jan 2011 05:44:13 -0800 Received: by vws14 with SMTP id 14so7656768vws.23 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: Thu, 13 Jan 2011 08:12:11 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 13:42:05 -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: saag@core3.amsl.com Delivered-To: saag@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: Thu, 13 Jan 2011 08:12:11 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "Zed A. Shaw" , "http-auth@ietf.org" , "saag@ietf.org" , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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: saag@core3.amsl.com Delivered-To: saag@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: Thu, 13 Jan 2011 08:12:11 -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: [saag] [apps-discuss] [http-auth] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group 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 zedshaw@zedshaw.com Sun Jan 9 10:30:28 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43043A682E; Sun, 9 Jan 2011 10:30:28 -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 chFn4LkdQ-SK; Sun, 9 Jan 2011 10:30:27 -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 0C01F3A67FB; Sun, 9 Jan 2011 10:30:25 -0800 (PST) Received: by mail.zedshaw.com (Postfix, from userid 1000) id 28BF81D87C1; Sun, 9 Jan 2011 10:32:37 -0800 (PST) Date: Sun, 9 Jan 2011 10:32:37 -0800 From: "Zed A. Shaw" To: Ben Laurie Message-ID: <20110109183236.GZ12542@zedshaw> Mail-Followup-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" References: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <20110108194952.GS12542@zedshaw> 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: Thu, 13 Jan 2011 08:12:11 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Blaine Cook , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 18:30:29 -0000 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? I 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. It's not the sites or the protocol that causes phishing, or whether you've got a billion redirects or diffie-helman to the hilt. OpenID 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. As proof of this, I present to you the ReadWriteWeb/Facebook Login fiasco: http://www.readwriteweb.com/archives/facebook_wants_to_be_your_one_true_login.php This article became the #1 search result for "facebook login" for a short period of time on google. Not only did the users not realize RWW was *not* the facebook login, but they created accounts, logged in, and then complained that they didn't like the new facebook in the article comments. Yes, they thought RWW was the new facebook. They are totally different websites, with different designs and purposes, yet people had no idea. You may say that's a small sample, but this was done unintentionally. RWW didn't even try to change their site. A determined attacker can go much much farther than just this with a purposeful design that mimics the facebook login. And, this was people *logging in* to facebook, effectively using their direct login (which is also the connect login). That shows right there they have no idea where they're logging in to what, and that OpenID, OAuth, or any auth system doesn't help them. -- Zed A. Shaw http://zedshaw.com/ From benl@google.com Sun Jan 9 11:19:27 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FA83A683D 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: -104.133 X-Spam-Level: X-Spam-Status: No, score=-104.133 tagged_above=-999 required=5 tests=[AWL=-1.156, 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 sprpUdxQODrQ for ; Sun, 9 Jan 2011 11:19:26 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 817063A67D4 for ; Sun, 9 Jan 2011 11:19:26 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p09JLbv3001548 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 vws7 (vws7.prod.google.com [10.241.21.135]) by hpaq14.eem.corp.google.com with ESMTP id p09JLZqo020160 for ; Sun, 9 Jan 2011 11:21:36 -0800 Received: by vws7 with SMTP id 7so7445838vws.17 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: Thu, 13 Jan 2011 08:12:11 -0800 Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 19:19:27 -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: saag@core3.amsl.com Delivered-To: saag@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 , 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" References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> 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: Thu, 13 Jan 2011 08:12:11 -0800 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Blaine Cook , Phillip Hallam-Baker , "ietf-http-wg@w3.org Group" Subject: Re: [saag] [apps-discuss] [websec] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 20:14:17 -0000 On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: > 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. Alright, to avoid any "violent agreement", can you point me at any documentation you have on your proposed solution? -- Zed A. Shaw http://zedshaw.com/ From marsh@extendedsubset.com Sun Jan 9 13:05:34 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29593A6845; Sun, 9 Jan 2011 13:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] 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 RF7L6vdLdzC4; Sun, 9 Jan 2011 13:05:33 -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 1441E3A682A; Sun, 9 Jan 2011 13:05:33 -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 1Pc2UI-000AWy-T8; Sun, 09 Jan 2011 21:07:43 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 02A48603E; Sun, 9 Jan 2011 21:07:39 +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+pKk0IBf7xKDzPcNEDSwquAheGbBpfV5Q= Message-ID: <4D2A239C.6040801@extendedsubset.com> Date: Sun, 09 Jan 2011 15:07:40 -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: "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" References: <20110108194952.GS12542@zedshaw> <20110109183236.GZ12542@zedshaw> <20110109201627.GC12542@zedshaw> In-Reply-To: <20110109201627.GC12542@zedshaw> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 13 Jan 2011 08:12:11 -0800 Subject: Re: [saag] [websec] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 21:05:34 -0000 On 01/09/2011 02:16 PM, Zed A. Shaw wrote: > On Sun, Jan 09, 2011 at 07:21:34PM +0000, Ben Laurie wrote: >> 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. > > Alright, to avoid any "violent agreement", can you point me at any > documentation you have on your proposed solution? As you pointed out Zed, phishing isn't something that happens to a protocol or an application - it's something the user decides to do. Phishing can be said to have been prevented only when the user can be relied upon to refuse to enter his password into an insecure box. Now there may be some useful mitigations at the app or protocol level. For example, my bank asks for my username and then shows me a familiar picture (e.g., a rocking horse) that is supposed to prevent phishing. This stops phishing only in the sense that it requires the attacker to use a CGI proxy app rather than simple static phishing site. For some sites that probably cuts down on the rate of phishing attacks quite a bit. But something so easy to bypass is likely to depend on a steady supply of easier targets keeping the attackers busy. If I wanted that kind of security for my car, I should try to convince everyone else in town to leave theirs unlocked with the keys in the ignition. I don't think it will be useful against a determined, targeted attack. On 01/09/2011 02:13 PM, Peter Saint-Andre wrote: > > And please start cc'ing only http-auth@ietf.org, not all the other > lists. You're trying to convince users not to do something that the interface begs them to do, like hit 'reply all', or trying out every password they know. It's not part of the protocol. - Marsh From Jeff.Hodges@KingsMountain.com Fri Jan 21 17:09:21 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D72983A688A for ; Fri, 21 Jan 2011 17:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 y92ZofhXCDRl for ; Fri, 21 Jan 2011 17:09:21 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E42D13A687F for ; Fri, 21 Jan 2011 17:09:20 -0800 (PST) Received: (qmail 4606 invoked by uid 0); 22 Jan 2011 01:12:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 22 Jan 2011 01:12:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dj/wKyG+45ogwhAyDZjryPOrAC+fDxMHdZwndBNPzO89fjOzCPC9TOw4exFzXEQBLA5NQNq9P/LGtjt+D2wFHHvNCPyJZ6MEk0ZhiMP7ruplGKuAYDU1SsUd3kWgODQ7; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PgS1P-000684-IX; Fri, 21 Jan 2011 18:12:07 -0700 Message-ID: <4D3A2EE5.4030804@KingsMountain.com> Date: Fri, 21 Jan 2011 17:12:05 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF Security Area Advisory Group Subject: [saag] fyi: [certid] IESG approval of draft-saintandre-tls-server-id-check-14 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 01:09:21 -0000 Subject: [certid] IESG approval of draft-saintandre-tls-server-id-check-14 From: Peter Saint-Andre Date: Thu, 20 Jan 2011 19:20:57 -0700 (18:20 PST) To: IETF cert-based identity During its telechat earlier today, the IESG approved version -14 of draft-saintandre-tls-server-id-check as a Proposed Standard (not BCP). I'll leave it to Alexey Melnikov, our sponsoring area director, to explain the details about where we go from here (e.g., possible incorporation of small text modifications resulting from the discussion thread between Matt McCutchen and Jeff Hodges over the last 3 days). For myself, I fully expect to be working on a bis draft at some point in the next few years, because I don't think that this I-D is quite the final word on the topic. However, I do think it brings us closer to wide consensus regarding application service identity, and that perhaps the bis draft could be a true BCP (developed, I would think, within the TLS WG). Thanks to everyone who contributed to and provided feedback on this document -- your input is very much appreciated! Peter -- Peter Saint-Andre https://stpeter.im/ From turners@ieca.com Mon Jan 31 11:25:33 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755303A6C4E for ; Mon, 31 Jan 2011 11:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 63f5dlL-lCEc for ; Mon, 31 Jan 2011 11:25:32 -0800 (PST) Received: from nm21-vm0.bullet.mail.ac4.yahoo.com (nm21-vm0.bullet.mail.ac4.yahoo.com [98.139.53.216]) by core3.amsl.com (Postfix) with SMTP id 3E0A73A6C4D for ; Mon, 31 Jan 2011 11:25:32 -0800 (PST) Received: from [98.139.52.194] by nm21.bullet.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 19:28:47 -0000 Received: from [98.139.52.169] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 19:28:47 -0000 Received: from [127.0.0.1] by omp1052.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 19:28:47 -0000 X-Yahoo-Newman-Id: 125622.73661.bm@omp1052.mail.ac4.yahoo.com Received: (qmail 44236 invoked from network); 31 Jan 2011 19:28:46 -0000 Received: from thunderfish.local (turners@71.191.5.222 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 31 Jan 2011 11:28:46 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: eWVBKS8VM1n.iEZ3L6h3PtkM8VL.f7LjC1flUnj3UFIEj.S tIEPaquVQSPa_vu7zvyqxTHa77Udq_O0_hxjRw5YjSUMmBlK6Y7kaOAgbtVL M0kLyNO.50aYcNcEjsEmr1Qmh9LTDN8zqaSo.R_hGce5BtMpT8aIY5bYbov5 1EfFDcum8q43K2v6Aty0wWkC3MRt5XzUckp0Y24xyEZvNw3FTW5I1u8MDbzA BNWeFFeOvb2v8WHdX8Inu_QwOjR2Wvn8xnxcjdyL6TicFG8Jd3LqLrok- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D470D6E.5000809@ieca.com> Date: Mon, 31 Jan 2011 14:28:46 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] IETF 80 Security Sessions Requested To Date X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:25:33 -0000 All, IETF 80 is quickly approaching. I wanted to let everyone know about the meeting session requests that have been received to date: abfab dane dkim emu hokey nea pkix tls No request received: isms kitten krb Not intending to meet: ipsecme ltans I'll give everybody an update come tomorrow wrt the BOFs. spt From turners@ieca.com Mon Jan 31 11:57:43 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E303A6C6E for ; Mon, 31 Jan 2011 11:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 4hoJQMWwK3AQ for ; Mon, 31 Jan 2011 11:57:43 -0800 (PST) Received: from nm25-vm0.bullet.mail.ac4.yahoo.com (nm25-vm0.bullet.mail.ac4.yahoo.com [98.139.52.240]) by core3.amsl.com (Postfix) with SMTP id D4A3D3A6C57 for ; Mon, 31 Jan 2011 11:57:42 -0800 (PST) Received: from [98.139.52.194] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 20:00:57 -0000 Received: from [98.139.52.145] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 20:00:57 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 31 Jan 2011 20:00:57 -0000 X-Yahoo-Newman-Id: 800013.83434.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 40878 invoked from network); 31 Jan 2011 20:00:57 -0000 Received: from thunderfish.local (turners@71.191.5.222 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 31 Jan 2011 12:00:57 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 2.lAk9cVM1mo7TMverzNB6zBzGnzrR6Gn8QqW1dZVBreCCW mFO_TYEljsw6DlybvzsQggblr0qsm4NccwZ4p6DY43r_OFkgTHZfQuy9hw2J 61yKwgzWh9ibjpE44A9SNFQ2BGq1VICDCJGJeKPhepGNzBZEeByf0SkUISrH _xS04BON8ZldmEn6zFN4e8XtGSgzDExsTonaBXXnXFkqf12hX1S.8K1UOmeg ydydzIG4ShIID77hhLSIHd9_3r4cXyZ5hPv72hO8zj8UjbkRLHTNTrfjgGe1 _Wen6PY4yf6Z5HbBCLWgD0VqHNG7JDqk_Y3KvlA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4714F8.3040500@ieca.com> Date: Mon, 31 Jan 2011 15:00:56 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: NomCom 2010-2011: IESG Appointments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 19:57:44 -0000 In case you're not on the ietf-announce@ietf.org or ietf@ietf.org lists. Here are the IESG appointments. Congrats to Stephen. And, thanks to all those who offered to serve. spt -------- Original Message -------- Subject: NomCom 2010-2011: IESG Appointments Date: Mon, 31 Jan 2011 10:11:22 -0800 (PST) From: NomCom Chair To: IETF Announcement list Hi Folks, The 2010-2011 IETF Nominating committee is pleased to announce the selection of the IESG members whose two year terms start in March 2011. The following have been selected to serve as ADs by the nominating committee for the open IESG positions and confirmed by the IAB in their role as confirming body: GEN/IETF Chair: Russ Housley Applications: Pete Resnick Internet: Ralph Droms Operations and Management: Ron Bonica Real-time Applications and Infrastructure: Robert Sparks Routing: Adrian Farrel Security: Stephen Farrell Transport: Wesley Eddy Our thanks to the incumbents who are not returning for their outstanding service, to the many qualified members of the community who offered to serve, to the community for their assistance in this process, and to the named individuals above for agreeing to serve the community on the IESG. Best Regards, Thomas Walsh nomcom-chair@ietf.org twalsh@juniper.net _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From stephen.farrell@cs.tcd.ie Mon Jan 31 13:39:31 2011 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13B93A6CA2 for ; Mon, 31 Jan 2011 13:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 q1Qf0BlGkuOx for ; Mon, 31 Jan 2011 13:39:30 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id E255B3A6CA1 for ; Mon, 31 Jan 2011 13:39:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A671A3E407F; Mon, 31 Jan 2011 21:42:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1296510164; bh=j1xp2cTqgY/QJ4 OSNyWvI0x4IqnNmtyUHU8LJh3v6qM=; b=k1czNcmESjIa9Ks+NoJ46ni1HnO9ks kMloKjTSa0fASmGMv92XHsNadLSR36kKxXeZ/3e/KlGUa0paSyulGK6sdD2TkT65 kiHOrQFpo+5hn/HJSBSGCxnhUkX3wgjzTruc/8F3rYFup8GxqwvdHBcrq6lFiofT Zz+vOFbqDORWc6PgDO2SFmXfA2EHZux1qcNtztp2ugOmFe/5kCKpWh/khxxpwU96 QWSLE7yxZ1IonRiLw1pBQYcuNxX4mHKkpOXIeuJ8BJTfp1snWbSFpgYSSLvqozyu UKk+sEivys0eY1HgIcebYF8rNI79OwUmo9mnjchtz1wB871aoVTZ9oNA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fWl+bWW4-ubQ; Mon, 31 Jan 2011 21:42:44 +0000 (GMT) Received: from [10.87.48.5] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6CFB13E407D; Mon, 31 Jan 2011 21:42:43 +0000 (GMT) Message-ID: <4D472CD2.4070602@cs.tcd.ie> Date: Mon, 31 Jan 2011 21:42:42 +0000 From: Stephen Farrell 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: Sean Turner References: <4D4714F8.3040500@ieca.com> In-Reply-To: <4D4714F8.3040500@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Fwd: NomCom 2010-2011: IESG Appointments X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:39:31 -0000 On 31/01/11 20:00, Sean Turner wrote: > In case you're not on the ietf-announce@ietf.org or ietf@ietf.org lists. > Here are the IESG appointments. > > Congrats to Stephen. Thanks Sean. A tad scary, but I look forward to trying to help out as I can. (And I guess I'll have to anti-socialise my IETF meeting nights a bit too;-) S.