From benl@google.com Thu Jan 6 07:29:49 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0453A6C4F for ; Thu, 6 Jan 2011 07:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.766 X-Spam-Level: X-Spam-Status: No, score=-103.766 tagged_above=-999 required=5 tests=[AWL=-1.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 AvLjDz1qCfMm for ; Thu, 6 Jan 2011 07:29:48 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id E51DD3A6D79 for ; Thu, 6 Jan 2011 07:29:47 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p06FVrFM005294 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=1294327914; bh=UP69RRHWGGYUU/4X7jvHl3J8mX4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=u8nc7/xQZ+AARX/yPFSLYnoxdm3MNriL6XXSM3oYTi9uTzHemKJl8EeU6i0qQkJCF DTLfKTFQS5p8DHzPhqxoA== Received: from qwi2 (qwi2.prod.google.com [10.241.195.2]) by wpaz37.hot.corp.google.com with ESMTP id p06FViSb004051 for ; Thu, 6 Jan 2011 07:31:52 -0800 Received: by qwi2 with SMTP id 2so954376qwi.17 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: [kitten] [websec] [saag] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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 benl@google.com Thu Jan 6 10:14:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E943A6CDA for ; Thu, 6 Jan 2011 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.462 X-Spam-Level: X-Spam-Status: No, score=-104.462 tagged_above=-999 required=5 tests=[AWL=-1.485, 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 ZrsxTrbUEHb3 for ; Thu, 6 Jan 2011 10:14:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 116033A6CD7 for ; Thu, 6 Jan 2011 10:14:11 -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 p06IGIs2018768 for ; Thu, 6 Jan 2011 10:16:18 -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 qwj8 (qwj8.prod.google.com [10.241.195.72]) by hpaq14.eem.corp.google.com with ESMTP id p06IAPn6021695 for ; Thu, 6 Jan 2011 10:16:16 -0800 Received: by qwj8 with SMTP id 8so22238114qwj.15 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: [kitten] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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 marsh@extendedsubset.com Thu Jan 6 11:49:53 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@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 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: [kitten] [websec] [saag] [apps-discuss] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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 yaronf.ietf@gmail.com Fri Jan 7 00:22:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D19753A67DF; Fri, 7 Jan 2011 00:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhJL-wf+X3uj; Fri, 7 Jan 2011 00:22:22 -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 51F4F3A67AC; Fri, 7 Jan 2011 00:22:21 -0800 (PST) Received: by wyf23 with SMTP id 23so18048837wyf.31 for ; Fri, 07 Jan 2011 00:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bvz62BK4fx12WA6hU/WbK/IYmXIVZb/p3SDFBYoNc2U=; b=MDF1aMuJ4Y+z/44T285Lxq9VULCvQ5CayDkxd8BuJrL0W7HkQTcmju1SaI/rucgQ+B wkV05oOcnKG3HFzYxy3KdqSPAHJm2TTLOuDbTTZJFl2oMu8+CVmxx7LQS3j07BleCN19 G6W1OCki2WtDoivXxeGMBu00nWlUrX/OVy54E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BBbgYNF5bKC3+tM3USxnTgL3ULhBA74Su7NC7uoQIFG7kEEOQY8jktEkQvQr0jAjeL DUAqJeoPIzR7wjaz3aSh5Oj5MQaEF1iCfvMXLRSwPRb2VCrDzJf+FPe8NuTEA49AB7nw ecJpb0G75tPhHMUzvtUYUEmQxEkYuX/6JKwxo= Received: by 10.227.144.9 with SMTP id x9mr5823639wbu.103.1294388666421; Fri, 07 Jan 2011 00:24:26 -0800 (PST) Received: from [10.0.0.6] (bzq-109-67-17-212.red.bezeqint.net [109.67.17.212]) by mx.google.com with ESMTPS id q18sm17451343wbe.5.2011.01.07.00.24.23 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 00:24:24 -0800 (PST) Message-ID: <4D26CDB5.3090303@gmail.com> Date: Fri, 07 Jan 2011 10:24:21 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: 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> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [kitten] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 08:22:22 -0000 [Culling down the mailing lists] Hi Ben, No, RFC 4279 should not be used with (a hash of) human-memorable passwords, because it would be vulnerable to dictionary attacks. See http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar schemes should be used instead. Thanks, Yaron On 01/06/2011 05:31 PM, Ben Laurie wrote: [...] > > > Two comments (one really being a response to Roy): > > 1. The IETF has fixed the problem, but no-one is using the fix - perhaps > because it is not clear that it is the fix. I speak of RFC 4279, TLS > pre-shared keys. These could be derived from a hash of the password and > the site name, for example, and thus provide secure mutual > authentication despite password reuse. > [...] From simon@josefsson.org Fri Jan 7 03:56:37 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932173A681A; Fri, 7 Jan 2011 03:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pf3ZVe7Hfli6; Fri, 7 Jan 2011 03:56:36 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 0B3843A6802; Fri, 7 Jan 2011 03:56:35 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07BwHLE016162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 12:58:18 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::8nDH00IPo3MDcAi5:0OkO X-Hashcash: 1:22:110107:benl@google.com::dHOlZwuujRml5L2l:22Js X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::rU0voKwWmjJ0QWHV:4WYj X-Hashcash: 1:22:110107:fielding@gbiv.com::t/XSArwNppLa4r67:8VPg X-Hashcash: 1:22:110107:websec@ietf.org::cdv3XLGXhP86BgxX:H38W X-Hashcash: 1:22:110107:sayrer@gmail.com::fmh47cJIN2zlmH47:Ki/j X-Hashcash: 1:22:110107:http-auth@ietf.org::N8uIJ3hvQ1W7Sazv:X+gA X-Hashcash: 1:22:110107:kitten@ietf.org::FgG+yHbN3JD0r9Uq:kmyB Date: Fri, 07 Jan 2011 12:57:29 +0100 In-Reply-To: <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 10:24:21 +0200") Message-ID: <87lj2xj592.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [kitten] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 11:56:37 -0000 One way to mitigate the dictionary attack problem is to do PBKDF#2 processing of the password before it hits TLS-PSK. However I agree that TLS-SRP have superior properties, and it is widely implemented. There is no practical reason to prefer TLS-PSK over TLS-PSK for password-based TLS authentication. One issue is that RFC 5054 is Informational rather than Standards Track (same issue as for TLS-OpenPGP), which is due to political reasons. /Simon Yaron Sheffer writes: > [Culling down the mailing lists] > > Hi Ben, > > No, RFC 4279 should not be used with (a hash of) human-memorable > passwords, because it would be vulnerable to dictionary attacks. See > http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar > schemes should be used instead. > > Thanks, > Yaron > > On 01/06/2011 05:31 PM, Ben Laurie wrote: > [...] > >> >> >> Two comments (one really being a response to Roy): >> >> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >> because it is not clear that it is the fix. I speak of RFC 4279, TLS >> pre-shared keys. These could be derived from a hash of the password and >> the site name, for example, and thus provide secure mutual >> authentication despite password reuse. >> > [...] From benl@google.com Fri Jan 7 04:12:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E908D3A682F for ; Fri, 7 Jan 2011 04:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[AWL=-1.518, 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 ClYGmTydGENB for ; Fri, 7 Jan 2011 04:12:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8521F3A682E for ; Fri, 7 Jan 2011 04:12:28 -0800 (PST) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p07CEYPw004459 for ; Fri, 7 Jan 2011 04:14:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294402474; bh=ddHvYbpx8oj/DZTucKUBMRlo1fk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=wA6U/9K5RFfTYIZRwJb1uCudgDYkgbrDYkvdHKtZzyXt3HelKVbE27NfFoELPkcBD 4yGap7dUDU9V26pfOrKtA== Received: from qwi4 (qwi4.prod.google.com [10.241.195.4]) by hpaq12.eem.corp.google.com with ESMTP id p07CEW9b009523 for ; Fri, 7 Jan 2011 04:14:33 -0800 Received: by qwi4 with SMTP id 4so18326519qwi.11 for ; Fri, 07 Jan 2011 04:14:32 -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=tilmeHWzg1zhUdTg75BSgKYV8NkD8UASZdZvrU93zak=; b=LMMXaIfCReiFZpuNn9QVdkdKdYnjIxOU22yQIS4W/asj9CYD4e4gbNZnYQxo+ekrdn 8FGii/ktL/OIvFEceOgA== 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=LyjWj531N7H6aMeY0ZWVwuiSjteRmHAQORR8gGhS9KvvJ1rdlrTjZSRnyFCWqlUDHH YWH9D0/2l15l38TOUk0g== MIME-Version: 1.0 Received: by 10.229.95.11 with SMTP id b11mr22299686qcn.28.1294402472260; Fri, 07 Jan 2011 04:14:32 -0800 (PST) Received: by 10.220.88.137 with HTTP; Fri, 7 Jan 2011 04:14:32 -0800 (PST) In-Reply-To: <4D26CDB5.3090303@gmail.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> <4D26CDB5.3090303@gmail.com> Date: Fri, 7 Jan 2011 12:14:32 +0000 Message-ID: From: Ben Laurie To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [kitten] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:12:29 -0000 On 7 January 2011 08:24, Yaron Sheffer wrote: > [Culling down the mailing lists] > > Hi Ben, > > No, RFC 4279 should not be used with (a hash of) human-memorable password= s, > because it would be vulnerable to dictionary attacks. See > http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar sche= mes > should be used instead. Fair point, though there seem to be at least political barriers to using SRP, and EKE and friends have other issues. > > Thanks, > =A0 =A0 =A0 =A0Yaron > > On 01/06/2011 05:31 PM, Ben Laurie wrote: > [...] > >> >> >> Two comments (one really being a response to Roy): >> >> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >> because it is not clear that it is the fix. I speak of RFC 4279, TLS >> pre-shared keys. These could be derived from a hash of the password and >> the site name, for example, and thus provide secure mutual >> authentication despite password reuse. >> > [...] > From yaronf.ietf@gmail.com Fri Jan 7 04:55:13 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F443A686E; Fri, 7 Jan 2011 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L07Vm7cKoG49; Fri, 7 Jan 2011 04:55:12 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C40053A6873; Fri, 7 Jan 2011 04:55:11 -0800 (PST) Received: by wwa36 with SMTP id 36so17450279wwa.13 for ; Fri, 07 Jan 2011 04:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8wB0BVHtoZNLSagh8m1PIgBE1XzJFln/PN6afWFMKh4=; b=QTG8DuwxYK0cZzA6ewan7/LdBbZYmKKxpzg2DNm/xhX8G7uB5Q/m/C93aeI/dxnyaX eiMykX00X8Oc3ayEBouf3tPxvn7BRNgxJU6sv1PLiLKbo3nmI7wUNwH+GJ/mHmea7Ed8 nLTsxkv2Y9Q/5gTg03Y9VubfDodTM0DZiGmzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=T09V7sxDVE5FcbtNEmBRmlCkwYQJJqg7IlHHFYQjTB8aKt33za5sqgjjIfBCWPoqxU U1r23HIBdfdMahaVbuRanLxQ134YuLZRSeLjjMPWhlSr8Cq17tUKHV0m3BOlnnl2C/Gy 8ZVIQ+/6DOVts8WRKg/hBey8kdSTErwi/HSHI= Received: by 10.227.177.10 with SMTP id bg10mr9575207wbb.148.1294405033432; Fri, 07 Jan 2011 04:57:13 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id f35sm17642679wbf.20.2011.01.07.04.57.08 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 04:57:12 -0800 (PST) Message-ID: <4D270DA1.7020408@gmail.com> Date: Fri, 07 Jan 2011 14:57:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> In-Reply-To: <87lj2xj592.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [kitten] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 12:55:13 -0000 Another issue is that SRP (as opposed to other protocols in this space) is not provably secure, and in fact has had relatively little cryptographic review, AFAIK. I would be glad to be proven wrong on the second point. Thanks, Yaron On 01/07/2011 01:57 PM, Simon Josefsson wrote: > One way to mitigate the dictionary attack problem is to do PBKDF#2 > processing of the password before it hits TLS-PSK. > > However I agree that TLS-SRP have superior properties, and it is widely > implemented. There is no practical reason to prefer TLS-PSK over > TLS-PSK for password-based TLS authentication. One issue is that RFC > 5054 is Informational rather than Standards Track (same issue as for > TLS-OpenPGP), which is due to political reasons. > > /Simon > > Yaron Sheffer writes: > >> [Culling down the mailing lists] >> >> Hi Ben, >> >> No, RFC 4279 should not be used with (a hash of) human-memorable >> passwords, because it would be vulnerable to dictionary attacks. See >> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >> schemes should be used instead. >> >> Thanks, >> Yaron >> >> On 01/06/2011 05:31 PM, Ben Laurie wrote: >> [...] >> >>> >>> >>> Two comments (one really being a response to Roy): >>> >>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>> pre-shared keys. These could be derived from a hash of the password and >>> the site name, for example, and thus provide secure mutual >>> authentication despite password reuse. >>> >> [...] From simon@josefsson.org Fri Jan 7 06:28:47 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD4083A68D7; Fri, 7 Jan 2011 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 oP9OxbQBMBkV; Fri, 7 Jan 2011 06:28:46 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 4DC553A68BE; Fri, 7 Jan 2011 06:28:46 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07EUT7V023012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 15:30:31 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:http-auth@ietf.org::GFndAU08IAgP67Rw:8ppA X-Hashcash: 1:22:110107:benl@google.com::SQghvywdCmUGonlm:BhSZ X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::15dxnKRibF4RdeUL:HacJ X-Hashcash: 1:22:110107:websec@ietf.org::OgsJlC8FfpBk4Sw+:Ir1K X-Hashcash: 1:22:110107:sayrer@gmail.com::0uhHwungE9rrSt8t:Mjeq X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::GSKndXAjUb6XHs0d:GUHu X-Hashcash: 1:22:110107:fielding@gbiv.com::Db1vcS1WnfJxHa0F:eba1 X-Hashcash: 1:22:110107:kitten@ietf.org::LJT0AtYQinVS7GSd:p9dv Date: Fri, 07 Jan 2011 15:29:40 +0100 In-Reply-To: <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 14:57:05 +0200") Message-ID: <874o9kiy7f.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [kitten] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 14:28:48 -0000 The initial paper contains a security analysis with some reduction-style arguments: http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 As with any crypto document from that time, it will lack in how the assumptions are stated and the reductions are made. That considered, is there something in particular that you think is missing in there? We can fix the problem with lack of review by implementing and deploying the protocol, then certainly researchers are bound to focus on it. ;-) /Simon Yaron Sheffer writes: > Another issue is that SRP (as opposed to other protocols in this > space) is not provably secure, and in fact has had relatively little > cryptographic review, AFAIK. I would be glad to be proven wrong on the > second point. > > Thanks, > Yaron > > On 01/07/2011 01:57 PM, Simon Josefsson wrote: >> One way to mitigate the dictionary attack problem is to do PBKDF#2 >> processing of the password before it hits TLS-PSK. >> >> However I agree that TLS-SRP have superior properties, and it is widely >> implemented. There is no practical reason to prefer TLS-PSK over >> TLS-PSK for password-based TLS authentication. One issue is that RFC >> 5054 is Informational rather than Standards Track (same issue as for >> TLS-OpenPGP), which is due to political reasons. >> >> /Simon >> >> Yaron Sheffer writes: >> >>> [Culling down the mailing lists] >>> >>> Hi Ben, >>> >>> No, RFC 4279 should not be used with (a hash of) human-memorable >>> passwords, because it would be vulnerable to dictionary attacks. See >>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>> schemes should be used instead. >>> >>> Thanks, >>> Yaron >>> >>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>> [...] >>> >>>> >>>> >>>> Two comments (one really being a response to Roy): >>>> >>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>> pre-shared keys. These could be derived from a hash of the password and >>>> the site name, for example, and thus provide secure mutual >>>> authentication despite password reuse. >>>> >>> [...] From yaronf.ietf@gmail.com Fri Jan 7 08:34:11 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3931C3A68D0; Fri, 7 Jan 2011 08:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdmEHsYHNX-5; Fri, 7 Jan 2011 08:34:09 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6CCEF3A68C0; Fri, 7 Jan 2011 08:34:07 -0800 (PST) Received: by wyf23 with SMTP id 23so18465156wyf.31 for ; Fri, 07 Jan 2011 08:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=f+fhP7UPeAW6UH0hkHpFz2PBxTHW8cDCICMCIxYY4y4=; b=bkAQbjgZzk7YNxPuU63NW1UzbRZ7Kv5eCS5KDn1eyGXHRiObV7DbDXiVTZXfEC7R18 4ZF3VLRiu8PSb233/p1fm2rYP+YV0iNw7AT7x4z90QzN9B2JIeg97FNIF1Pmzo9uQF0/ o3DhSuD8r5FFERLjJCBceK8KP+j9YkLdAHnjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=b0E815ule1RlK1rqsgYuXpdVdjAgrqfNLgC9tuiKDDdTo6w7IlCoXO58vRbHlPQMhq LGNGsC3DQEVTajKdcBMyy0xZoIkfrbrGhuZiy0kzCtQq1S5fQWo/L0YG850z72IheJb/ EoOXqRNnMBryTt3rrxdWSWZ54kOOwD87dhAMo= Received: by 10.227.141.197 with SMTP id n5mr8212052wbu.100.1294416320023; Fri, 07 Jan 2011 08:05:20 -0800 (PST) Received: from [10.0.0.6] ([109.67.17.212]) by mx.google.com with ESMTPS id 11sm17773721wbj.13.2011.01.07.08.05.12 (version=SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 08:05:18 -0800 (PST) Message-ID: <4D2739B5.5060107@gmail.com> Date: Fri, 07 Jan 2011 18:05:09 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Simon Josefsson References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> In-Reply-To: <874o9kiy7f.fsf@latte.josefsson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [kitten] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:34:11 -0000 - I am not a cryptographer, so I am treading on extremely thin ice here. - SRP is certainly better than using PSK with passwords, which is *definitely* vulnerable to dictionary attacks. - That said, I have done my little bit of due diligence (talked to the author of SRP and to several cryptographers who've played with some of these schemes). Personally, I would rather use a protocol that's been formally proven (PACE, AugPAKE, other descendants of EKE) or has had real solid cryptographic review (the original EKE). Again, I would be happy to be proven wrong on this. - Even if we start with a mathematically perfect protocol, we are bound to make design and engineering mistakes. And Marsh and his like will happily poke holes into these implementations :-) But I'd like to avoid compounding the risk with cryptographically unsound protocols. Thanks, Yaron On 01/07/2011 04:29 PM, Simon Josefsson wrote: > The initial paper contains a security analysis with some reduction-style > arguments: > > http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 > > As with any crypto document from that time, it will lack in how the > assumptions are stated and the reductions are made. That considered, is > there something in particular that you think is missing in there? > > We can fix the problem with lack of review by implementing and deploying > the protocol, then certainly researchers are bound to focus on it. ;-) > > /Simon > > Yaron Sheffer writes: > >> Another issue is that SRP (as opposed to other protocols in this >> space) is not provably secure, and in fact has had relatively little >> cryptographic review, AFAIK. I would be glad to be proven wrong on the >> second point. >> >> Thanks, >> Yaron >> >> On 01/07/2011 01:57 PM, Simon Josefsson wrote: >>> One way to mitigate the dictionary attack problem is to do PBKDF#2 >>> processing of the password before it hits TLS-PSK. >>> >>> However I agree that TLS-SRP have superior properties, and it is widely >>> implemented. There is no practical reason to prefer TLS-PSK over >>> TLS-PSK for password-based TLS authentication. One issue is that RFC >>> 5054 is Informational rather than Standards Track (same issue as for >>> TLS-OpenPGP), which is due to political reasons. >>> >>> /Simon >>> >>> Yaron Sheffer writes: >>> >>>> [Culling down the mailing lists] >>>> >>>> Hi Ben, >>>> >>>> No, RFC 4279 should not be used with (a hash of) human-memorable >>>> passwords, because it would be vulnerable to dictionary attacks. See >>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>>> schemes should be used instead. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>>> [...] >>>> >>>>> >>>>> >>>>> Two comments (one really being a response to Roy): >>>>> >>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>>> pre-shared keys. These could be derived from a hash of the password and >>>>> the site name, for example, and thus provide secure mutual >>>>> authentication despite password reuse. >>>>> >>>> [...] From simon@josefsson.org Fri Jan 7 08:53:49 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04343A691B; Fri, 7 Jan 2011 08:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 fRYHDcNAmnt7; Fri, 7 Jan 2011 08:53:48 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 1A4573A68D0; Fri, 7 Jan 2011 08:53:46 -0800 (PST) Received: from latte.josefsson.org ([213.115.69.138]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p07GtadB029494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jan 2011 17:55:37 +0100 From: Simon Josefsson To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D26CDB5.3090303__44301.5923993245$1294388684$gmane$org@gmail.com> <87lj2xj592.fsf@latte.josefsson.org> <4D270DA1.7020408__25077.7970803485$1294405057$gmane$org@gmail.com> <874o9kiy7f.fsf@latte.josefsson.org> <4D2739B5.5060107@gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110107:sayrer@gmail.com::nKbrDoVZ8ntVn1sL:0vDu X-Hashcash: 1:22:110107:fielding@gbiv.com::Z60jztLM1WmVf/qd:5qoh X-Hashcash: 1:22:110107:http-auth@ietf.org::GkOKc/hUdEd3jjQ6:7Jem X-Hashcash: 1:22:110107:ietf-http-wg@w3.org::/a2sto5LOdFoRft1:9U3R X-Hashcash: 1:22:110107:benl@google.com::OwwzH5bedfc1Wks0:91D9 X-Hashcash: 1:22:110107:yaronf.ietf@gmail.com::QpYfSjOpmEpPPQqY:FztG X-Hashcash: 1:22:110107:kitten@ietf.org::Ztv2C0I277++hhXP:tdIu X-Hashcash: 1:22:110107:websec@ietf.org::sNFLAbNnd90XYcDs:+6RP Date: Fri, 07 Jan 2011 17:54:46 +0100 In-Reply-To: <4D2739B5.5060107@gmail.com> (Yaron Sheffer's message of "Fri, 07 Jan 2011 18:05:09 +0200") Message-ID: <87fwt4ejs9.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "Roy T. Fielding" , websec , Robert Sayre , "kitten@ietf.org" , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , Ben Laurie Subject: Re: [kitten] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jan 2011 16:53:49 -0000 Yaron Sheffer writes: > - I am not a cryptographer, so I am treading on extremely thin ice here. > > - SRP is certainly better than using PSK with passwords, which is > *definitely* vulnerable to dictionary attacks. One final addition here, the situation for PSK depends on the flavour and whether you are talking about active or passive attackers. The statement is true for plain PSK, but less so for DHE_PSK and RSA_PSK. Section 7.2 of 4279: For the PSK ciphersuites, an attacker can get the information required for an off-line attack by eavesdropping on a TLS handshake, or by getting a valid client to attempt connection with the attacker (by tricking the client to connect to the wrong address, or by intercepting a connection attempt to the correct address, for instance). For the DHE_PSK ciphersuites, an attacker can obtain the information by getting a valid client to attempt connection with the attacker. Passive eavesdropping alone is not sufficient. For the RSA_PSK ciphersuites, only the server (authenticated using RSA and certificates) can obtain sufficient information for an off-line attack. /Simon > - That said, I have done my little bit of due diligence (talked to the > author of SRP and to several cryptographers who've played with some of > these schemes). Personally, I would rather use a protocol that's been > formally proven (PACE, AugPAKE, other descendants of EKE) or has had > real solid cryptographic review (the original EKE). Again, I would be > happy to be proven wrong on this. > > - Even if we start with a mathematically perfect protocol, we are > bound to make design and engineering mistakes. And Marsh and his like > will happily poke holes into these implementations :-) But I'd like to > avoid compounding the risk with cryptographically unsound protocols. > > Thanks, > Yaron > > On 01/07/2011 04:29 PM, Simon Josefsson wrote: >> The initial paper contains a security analysis with some reduction-style >> arguments: >> >> http://srp.stanford.edu/ndss.html#SECTION00040000000000000000 >> >> As with any crypto document from that time, it will lack in how the >> assumptions are stated and the reductions are made. That considered, is >> there something in particular that you think is missing in there? >> >> We can fix the problem with lack of review by implementing and deploying >> the protocol, then certainly researchers are bound to focus on it. ;-) >> >> /Simon >> >> Yaron Sheffer writes: >> >>> Another issue is that SRP (as opposed to other protocols in this >>> space) is not provably secure, and in fact has had relatively little >>> cryptographic review, AFAIK. I would be glad to be proven wrong on the >>> second point. >>> >>> Thanks, >>> Yaron >>> >>> On 01/07/2011 01:57 PM, Simon Josefsson wrote: >>>> One way to mitigate the dictionary attack problem is to do PBKDF#2 >>>> processing of the password before it hits TLS-PSK. >>>> >>>> However I agree that TLS-SRP have superior properties, and it is widely >>>> implemented. There is no practical reason to prefer TLS-PSK over >>>> TLS-PSK for password-based TLS authentication. One issue is that RFC >>>> 5054 is Informational rather than Standards Track (same issue as for >>>> TLS-OpenPGP), which is due to political reasons. >>>> >>>> /Simon >>>> >>>> Yaron Sheffer writes: >>>> >>>>> [Culling down the mailing lists] >>>>> >>>>> Hi Ben, >>>>> >>>>> No, RFC 4279 should not be used with (a hash of) human-memorable >>>>> passwords, because it would be vulnerable to dictionary attacks. See >>>>> http://tools.ietf.org/html/rfc4279#section-7.2. SRP, EKE and similar >>>>> schemes should be used instead. >>>>> >>>>> Thanks, >>>>> Yaron >>>>> >>>>> On 01/06/2011 05:31 PM, Ben Laurie wrote: >>>>> [...] >>>>> >>>>>> >>>>>> >>>>>> Two comments (one really being a response to Roy): >>>>>> >>>>>> 1. The IETF has fixed the problem, but no-one is using the fix - perhaps >>>>>> because it is not clear that it is the fix. I speak of RFC 4279, TLS >>>>>> pre-shared keys. These could be derived from a hash of the password and >>>>>> the site name, for example, and thus provide secure mutual >>>>>> authentication despite password reuse. >>>>>> >>>>> [...] > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From hallam@gmail.com Sat Jan 8 08:05:35 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@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 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: [kitten] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3AE28C13A; Sat, 8 Jan 2011 08:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv2k8-0ECqSB; Sat, 8 Jan 2011 08:19:36 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DD14728C116; Sat, 8 Jan 2011 08:19:34 -0800 (PST) Received: by yxt33 with SMTP id 33so7991387yxt.31 for ; Sat, 08 Jan 2011 08:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=P/kVq8JqTkbriAI2YHZ98j+IH6nPYaKiXLgMS1MrhJg=; b=gj3y71kH8mkwf9cxcnOrEcJQbI+UOFHppgDDPLZGHIdfFFp2xvOoVOpWrXtvD+yUkA +LKTe3Xre6ZFVGT3kLsOPfjpJ4+FCR/k4ryZHG6UBxHuR3hliF/G0Ra32UC7Ftq25kiT CSSObZqQKWywj3P9ZvOUXBi4SBO5ct7i6a2U8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=akVsGITiA3khO4gDCJU1IG1XlVTf0CvbBpjMaP9HTk7XT1qtjcDuiz08xafz+rqNOS +wqrQGZtiyzvfSjsGG6J0XLtD94i1iVJMpQmw12JwA00AmVcNDKtrDrIp3Wm4HuFW/B6 MyZXCnpieOCjP1JWjS/yGhBmH0vu4YVZLrxzI= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr15882518ank.1.1294503702896; Sat, 08 Jan 2011 08:21:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 08:21:42 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 11:21:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=00163662e65b5f211d049958212f Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [kitten] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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 hallam@gmail.com Sat Jan 8 09:50:39 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2C23A67FB; Sat, 8 Jan 2011 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20paQQnmkSN0; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 4885D3A67E3; Sat, 8 Jan 2011 09:50:37 -0800 (PST) Received: by gxk28 with SMTP id 28so8482976gxk.31 for ; Sat, 08 Jan 2011 09:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6bo8ZioF39rKL6lWvOQo5g2WqHHhQncsxAnkblyge2E=; b=jWIHeGDUOh6avcUiKYI7wTYJwXy3jV8Acwp85reJHuvwsDKt8TaSgr8SGj5bn7Q7bv jG2GSHJKVTAA9sgZKU7NZ4wuZ42O+jZbnhxcQUq74l1TCZaXmMIaC0yNxPR6LkqMfWnL tuiYH6ugrFSmbfe0lfKwHBKdlGFwnHo2lWpJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g3FpArmvl34jXqveOoAO3WWa9XUrTArhTTE14LqMm9R3QH4k7wPphX8fK/KgZnsYnM jBigHkW3i9jMtNPJtsOOxoaJFUSZhDnDiNwBUhJwN42VR72PMU6XBpttZm04NoXcFF3p +mWIZVwfHvsxDrYrql6OzS8B9K/d4dEIHJ0SA= MIME-Version: 1.0 Received: by 10.100.173.13 with SMTP id v13mr2521122ane.171.1294509165388; Sat, 08 Jan 2011 09:52:45 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 8 Jan 2011 09:52:45 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Date: Sat, 8 Jan 2011 12:52:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Blaine Cook Content-Type: multipart/alternative; boundary=0016e644dbc6f623100499596635 Cc: "apps-discuss@ietf.org" , David Morris , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Ben Laurie , "ietf-http-wg@w3.org Group" Subject: Re: [kitten] [apps-discuss] [saag] [websec] HTTP authentication: the next generation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation 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 hartmans@painless-security.com Mon Jan 10 11:15:36 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007E73A6946; Mon, 10 Jan 2011 11:15:36 -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.032, 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 ZYcTEGKCxHV0; Mon, 10 Jan 2011 11:15:35 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DD4C03A683C; Mon, 10 Jan 2011 11:15:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 252752028C; Mon, 10 Jan 2011 14:16:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 433D14228; Mon, 10 Jan 2011 14:17:48 -0500 (EST) From: Sam Hartman To: abfab@ietf.org,kitten@ietf.org Date: Mon, 10 Jan 2011 14:17:48 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:15:36 -0000 Background: there was a discussion between authors of the abfab architecture proposal about multiple attribute providers. The idea is that you have an identity provider that is producing a set of attributes about a subject. In the case of ABFAB we're mostly thinking of a SAML IDP for this particular example. The IDP has some attributes it may be in a position to assert. But the IDP may also want to gather attributes from other sources and pass those along. One option it has is to simply pass the attributes along as if it issued them itself. That option isn't really interesting from a protocol standpoint because it is indistinguishable from the IDP actually issuing the attribute itself. That is probably a fine thing to do in certain deployments but we don't need to spend a lot of time on it. Another option is that the IDP can go actually get a SAML assertion (or attribute certificate or the like) and include that in what is sent to the RP. At first glance, the protocol implications of doing this look simple. You just stick the assertion in the existing bag of bits and move on. however, it's not that simple because of semantics. Today in ABFAB, we haven't done a great job of describing what the trust semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what has been going through at least Josh and my mind is that the RP SHOULD assume that the AAA framework provides an integrity protected channel for that SAML message. The message is actually issued by the IDP corresponding to the NAI used to make the access request. In addition, for the SAML assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP is asserting those attributes about the subject. That is, the RP need not perform any validation of the SAML assertion. The RP still needs to validate whether the IDP is permitted to make the claims it does. There's no requirement that these SAML assertions be signed. The IDP MAY sign the assertion; the RP MAY consider any signatures that are present. However in the interoperable case, any signatures that are present are ignored. If there are multiple assertions from the same IDP it seems reasonable to treat them all the same. Things get a lot more messy when assertions from multiple IDPs are included. What does it mean to include them in the AAA transport? I can think of several trust models that are appropriate depending on deployment: * The IDP corresponding to the subject's NAI has validated these additional assertions and wishes to assert that the attributes can be trusted. "If you trust me then you should trust these." Here, the assertions are being included either for convenience of packaging the attributes into some form the RP can process or because it is possible that the RP may be able to validate some signature and trust the attribute source more than the IDP. * The subject IDP has performed SAML validation on the assertions. However the IDP is making no claims about how trusted the attributes included in the additional assertions are. Even if the IDP would be permitted to make a claim made in an additional assertion, the RP needs to make an independent policy decision about whether the actual issuer should be permitted to make that claim. * Here are some assertions for the RP's convenience. The IDP makes no claims about them; not even the implied claim that they have not been modified in transit. They better be signed, the RP better have metadata for their issuer, and the RP is more or less on its own. Another source of complexity surrounds how an IDP links an assertion to a subject. What confidence is the RP asserting that the additional assertion describes the same principal as the access-accept message. Another potential source of complexity is how does the IDP know what information to gather? Does the IDP just know somehow? Does the RP pass information back? How does the RP make the policy decisions it needs to make? How does it get metadata that is needed? I think this sort of issue will also have impacts for kitten, because we'll need to describe it in the naming extensions interface. It seems like ABFAB is not going to be the only group facing these sorts of discussions; Kerberos is in the middle of a similar discussion right now. From lear@cisco.com Mon Jan 10 11:53:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E8328C0E4; Mon, 10 Jan 2011 11:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.2 X-Spam-Level: X-Spam-Status: No, score=-110.2 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 Lh3K7Wt4TrbR; Mon, 10 Jan 2011 11:53:38 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A94D028C0FF; Mon, 10 Jan 2011 11:53:37 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAFrzKk2Q/khNgWdsb2JhbACECJtkhF4VAQEWIiSieopTjXWCdYFjdASLCg Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Jan 2011 19:55:51 +0000 Received: from ams3-vpn-dhcp5297.cisco.com (ams3-vpn-dhcp5297.cisco.com [10.61.84.176]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0AJtpDW014723; Mon, 10 Jan 2011 19:55:51 GMT Message-ID: <4D2B644D.9090201@cisco.com> Date: Mon, 10 Jan 2011 20:55:57 +0100 From: Eliot Lear 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: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------080403070403000002060300" Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:53:40 -0000 This is a multi-part message in MIME format. --------------080403070403000002060300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sam, Thanks for taking the time to describe the problem. On 1/10/11 8:17 PM, Sam Hartman wrote: > Background: there was a discussion between authors of the abfab > architecture proposal about multiple attribute providers. > The idea is that you have an identity provider that is producing a set > of attributes about a subject. In the case of ABFAB we're mostly > thinking of a SAML IDP for this particular example. > > The IDP has some attributes it may be in a position to assert. > But the IDP may also want to gather attributes from other sources and > pass those along. > > One option it has is to simply pass the attributes along as if it issued > them itself. That option isn't really interesting from a protocol > standpoint because it is indistinguishable from the IDP actually issuing > the attribute itself. That is probably a fine thing to do in certain > deployments but we don't need to spend a lot of time on it. > > Another option is that the IDP can go actually get a SAML assertion (or > attribute certificate or the like) and include that in what is sent to > the RP. > > At first glance, the protocol implications of doing this look > simple. You just stick the assertion in the existing bag of bits and > move on. > > however, it's not that simple because of semantics. > > Today in ABFAB, we haven't done a great job of describing what the trust > semantics of the attribute in draft-ietf-abfab-aaa-saml are. However > what has been going through at least Josh and my mind is that the RP > SHOULD assume that the AAA framework provides an integrity protected > channel for that SAML message. The message is actually issued by the IDP > corresponding to the NAI used to make the access request. In addition, > for the SAML assertions sent from the IDP to the RP, the RP SHOULD > assume that the IDP is asserting those attributes about the subject. > That is, the RP need not perform any validation of the SAML > assertion. The RP still needs to validate whether the IDP is permitted > to make the claims it does. > There's no requirement that these SAML assertions be signed. > The IDP MAY sign the assertion; the RP MAY consider any signatures that > are present. However in the interoperable case, any signatures that are > present are ignored. You mean is that the security model you have in mind does not require that SAML assertions be signed? We may have an additional software layering problem- specifically, if they are present, and you're using a SAML library to parse the messages, from a practical standpoint, an error may be returned. However, I think what you're alluding to is that the lack of a signature itself is *part* of the problem of returning attributes from 3rd parties, since the associated connectivity of the AAA transport is providing authenticity and *not *the signature. > [snip] > Another source of complexity surrounds how an IDP links an assertion to > a subject. What confidence is the RP asserting that the additional > assertion describes the same principal as the access-accept message. On this point - the IdP either is or is not authoritative for knowing at the very least where the information is going to come from. The only question here is whether or not it is willing to vouch for the information itself. > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? And this is a generic problem with attribute providers. The general answer is either that the principal provides a pointer, or it finds the information through external means. Again, the only issues in this case are whether the IdP is providing some sort of surety, and whether it can be assumed that there is a trust relationship between the RP and the attribute provider. That latter one is a much bigger deal, IMHO! Regards, Eliot --------------080403070403000002060300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Sam,

Thanks for taking the time to describe the problem. 

On 1/10/11 8:17 PM, Sam Hartman wrote: 
Background: there was a discussion between authors of the abfab
architecture proposal about multiple attribute providers.
The idea is that you have an identity provider that is producing a set
of attributes about a subject. In the case of ABFAB we're mostly
thinking of a SAML IDP for this particular example.

The IDP  has some attributes it may be in a position to assert.
But the IDP may also want to gather attributes from other  sources and
pass those along.

One option it has is to simply pass the attributes along as if it issued
them itself.  That option isn't really interesting from a protocol
standpoint because it is indistinguishable from the IDP actually issuing
the attribute itself.  That is probably a fine thing to do in certain
deployments but we don't need to spend a lot of time on it.

Another option is that the IDP can go actually get a SAML assertion (or
attribute certificate or the like) and include that in what is sent to
the RP.

At first glance, the protocol implications of doing this look
simple. You just stick the assertion in the existing bag of bits and
move on.

however, it's not that simple because of semantics.

Today in ABFAB, we haven't done a great job of describing what the trust
semantics of the attribute in draft-ietf-abfab-aaa-saml are. However
what has been going through at least Josh and my mind is that the RP
SHOULD assume that the AAA framework provides an integrity protected
channel for that SAML message. The message is actually issued by the IDP
corresponding to the NAI used to make the access request. In addition,
for the SAML assertions sent from the IDP to the RP, the RP SHOULD
assume that the IDP is asserting those attributes about the subject.
That is, the RP need not perform any validation of the SAML
assertion. The RP still needs to validate whether the IDP is permitted
to make the claims it does.
There's no requirement that these SAML assertions be signed.
The IDP MAY sign the assertion; the RP MAY consider any signatures that
are present. However in the interoperable case, any signatures that are
present are ignored.

You mean is that the security model you have in mind does not require that SAML assertions be signed?  We may have an additional software layering problem- specifically, if they are present, and you're using a SAML library to parse the messages, from a practical standpoint, an error may be returned.

However, I think what you're alluding to is that the lack of a signature itself is part of the problem of returning attributes from 3rd parties, since the associated connectivity of the AAA transport is providing authenticity and not the signature.


[snip]


Another source of complexity surrounds how an IDP links an assertion to
a subject. What confidence is the RP asserting that the additional
assertion describes the same principal as the access-accept message.

On this point - the IdP either is or is not authoritative for knowing at the very least where the information is going to come from.  The only question here is whether or not it is willing to vouch for the information itself.
Another potential source of complexity is how does the IDP know what
information to gather? Does the IDP just know somehow? Does the RP pass
information back?
And this is a generic problem with attribute providers.  The general answer is either that the principal provides a pointer, or it finds the information through external means.  Again, the only issues in this case are whether the IdP is providing some sort of surety, and whether it can be assumed that there is a trust relationship between the RP and the attribute provider.  That latter one is a much bigger deal, IMHO!

Regards,

Eliot
--------------080403070403000002060300-- From cantor.2@osu.edu Mon Jan 10 12:16:54 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8555E28C136; Mon, 10 Jan 2011 12:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, 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 vjzBEqbn8eSu; Mon, 10 Jan 2011 12:16:53 -0800 (PST) Received: from defang16.it.ohio-state.edu (defang16.it.ohio-state.edu [128.146.216.130]) by core3.amsl.com (Postfix) with ESMTP id 8CE9128C12F; Mon, 10 Jan 2011 12:16:53 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu ([164.107.81.172]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p0AKIjWR017425; Mon, 10 Jan 2011 15:18:45 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Mon, 10 Jan 2011 15:15:45 -0500 From: "Cantor, Scott E." To: Eliot Lear , Sam Hartman Thread-Topic: [abfab] Multiple attribute providers in an authentication Thread-Index: AQHLsPqpupjdQ+ISDUWABPRpdmimLpPK8qeA//+xKoA= Date: Mon, 10 Jan 2011 20:18:46 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100320BB@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D2B644D.9090201@cisco.com> In-Reply-To: <4D2B644D.9090201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.172; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.130 Cc: "kitten@ietf.org" , "abfab@ietf.org" Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:16:54 -0000 PiBZb3UgbWVhbiBpcyB0aGF0IHRoZSBzZWN1cml0eSBtb2RlbCB5b3UgaGF2ZSBpbiBtaW5kIGRv ZXMgbm90IHJlcXVpcmUgdGhhdA0KPiBTQU1MIGFzc2VydGlvbnMgYmUgc2lnbmVkPyAgV2UgbWF5 IGhhdmUgYW4gYWRkaXRpb25hbCBzb2Z0d2FyZSBsYXllcmluZw0KPiBwcm9ibGVtLSBzcGVjaWZp Y2FsbHksIGlmIHRoZXkgYXJlIHByZXNlbnQsIGFuZCB5b3UncmUgdXNpbmcgYSBTQU1MIGxpYnJh cnkgdG8NCj4gcGFyc2UgdGhlIG1lc3NhZ2VzLCBmcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQs IGFuIGVycm9yIG1heSBiZSByZXR1cm5lZC4NCg0KVGhhdCBzaG91bGRuJ3QgYmUgYSBjb25jZXJu LCBvciBpZiBpdCBpcyB5b3UndmUgZ290IG11Y2ggYmlnZ2VyIHByb2JsZW1zIGJlY2F1c2UgdGhl IGFzc3VtcHRpb25zIGFib3V0IHRydXN0IGFuZCBrZXkgbWFuYWdlbWVudCB0aGF0IHN1Y2ggYnJv a2VuIGNvZGUgd291bGQgbWFrZSB3aWxsIGJlIGEgcHJvYmxlbSBpbiB0aGVpciBvd24gcmlnaHQu DQoNCj4gSG93ZXZlciwgSSB0aGluayB3aGF0IHlvdSdyZSBhbGx1ZGluZyB0byBpcyB0aGF0IHRo ZSBsYWNrIG9mIGEgc2lnbmF0dXJlIGl0c2VsZiBpcw0KPiBwYXJ0IG9mIHRoZSBwcm9ibGVtIG9m IHJldHVybmluZyBhdHRyaWJ1dGVzIGZyb20gM3JkIHBhcnRpZXMsIHNpbmNlIHRoZQ0KPiBhc3Nv Y2lhdGVkIGNvbm5lY3Rpdml0eSBvZiB0aGUgQUFBIHRyYW5zcG9ydCBpcyBwcm92aWRpbmcgYXV0 aGVudGljaXR5IGFuZCBub3QNCj4gdGhlIHNpZ25hdHVyZS4NCg0KSSB0aGluayBpdCdzIG1vcmUg dGhhdCBpZiB5b3Ugc3RpY2sgd2l0aCB0aGUgc2ltcGxlIGNhc2UsIHlvdSBkb24ndCBuZWVkIHRo ZW0sIGFuZCBpZiB5b3UgZG8gbmVlZCB0aGVtLCAgYSBob3N0IG9mIG1vcmUgY29tcGxleCBjb25j ZXJucyBiZWNvbWUgaW1wb3J0YW50Lg0KDQo+IAlBbm90aGVyIHNvdXJjZSBvZiBjb21wbGV4aXR5 IHN1cnJvdW5kcyBob3cgYW4gSURQIGxpbmtzIGFuIGFzc2VydGlvbiB0bw0KPiAJYSBzdWJqZWN0 LiBXaGF0IGNvbmZpZGVuY2UgaXMgdGhlIFJQIGFzc2VydGluZyB0aGF0IHRoZSBhZGRpdGlvbmFs DQo+IAlhc3NlcnRpb24gZGVzY3JpYmVzIHRoZSBzYW1lIHByaW5jaXBhbCBhcyB0aGUgYWNjZXNz LWFjY2VwdCBtZXNzYWdlLg0KPiANCj4gT24gdGhpcyBwb2ludCAtIHRoZSBJZFAgZWl0aGVyIGlz IG9yIGlzIG5vdCBhdXRob3JpdGF0aXZlIGZvciBrbm93aW5nIGF0IHRoZSB2ZXJ5DQo+IGxlYXN0 IHdoZXJlIHRoZSBpbmZvcm1hdGlvbiBpcyBnb2luZyB0byBjb21lIGZyb20uICBUaGUgb25seSBx dWVzdGlvbiBoZXJlIGlzDQo+IHdoZXRoZXIgb3Igbm90IGl0IGlzIHdpbGxpbmcgdG8gdm91Y2gg Zm9yIHRoZSBpbmZvcm1hdGlvbiBpdHNlbGYuDQoNClNvbWUgcGVvcGxlIChJIHNob3VsZCBiZSBj bGVhciBJJ20gbm90IG9uZSBvZiB0aGVtKSBiZWxpZXZlIHRoYXQgd2l0aG91dCBhIHVuaWZvcm0g c3ViamVjdCBpZGVudGlmaWVyIGFjcm9zcyBhbGwgc3VjaCBhc3NlcnRpb25zLCB5b3UgbG9zZSBh bnkgaG9wZSBvZiBhdWRpdGluZyB0aGUgbGlua2FiaWxpdHkgb2YgdGhlIGlkZW50aWVzIGxhdGVy LiBBbmQgYWNoaWV2aW5nIHRoYXQgdW5pZm9ybWl0eSBkb2VzIHNvbWUgdG9ydHVvdXMgdGhpbmdz IHRvIHRoZSBTQU1MIGZsb3dzIG5lZWRlZCB0byBnZXQgdGhlIGFzc2VydGlvbnMgYnVpbHQuDQoN CkkgYWdyZWUgd2l0aCBFbGlvdCB0aGF0IHRoZSBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIGtub3dp bmcgd2hhdCBhdHRyaWJ1dGVzIHRvIGdldCwgd2hhdCBzb3VyY2VzIHRvIHVzZSwgZXRjLiwgYXJl IGdlbmVyYWwgcHJvYmxlbXMsIG5vdCBjb25maW5lZCB0byB0aGlzIHVzZSBvZiBTQU1MLCBvciB0 byBTQU1MIGl0c2VsZi4NCg0KQnV0IHVzdWFsbHkgd2hlbiBhZ2dyZWdhdGlvbiBpcyBpbnZvbHZl ZCwgdGhlcmUgaXMgbGVzcyBuZWVkIGZvciBhIGZ1bGx5IGR5bmFtaWMgc3lzdGVtIHdpdGhvdXQg YWRtaW5pc3RyYXRpdmUgaW50ZXJ2ZW50aW9uLCBpbiBteSBleHBlcmllbmNlLg0KDQotLSBTY290 dA0KDQo= From hartmans@painless-security.com Mon Jan 10 12:20:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1AA528C12D; Mon, 10 Jan 2011 12:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 ZtQ+QUY74Vml; Mon, 10 Jan 2011 12:20:57 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A55428C115; Mon, 10 Jan 2011 12:20:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D394620220; Mon, 10 Jan 2011 15:21:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E94A84228; Mon, 10 Jan 2011 15:23:10 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D2B644D.9090201@cisco.com> Date: Mon, 10 Jan 2011 15:23:10 -0500 In-Reply-To: <4D2B644D.9090201@cisco.com> (Eliot Lear's message of "Mon, 10 Jan 2011 20:55:57 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:20:58 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, Thanks for taking the time to describe the problem. You are welcome. I realized that I did not explicitly say it, but I think all these complexities are tractable. We will have to do work in order to support this use case. I think that work is not in scope for what we're signed up to do now, although if someone stepped forward and wanted to do the work, it could happen sooner. I think that some of this may require some work in kitten. > Today in ABFAB, we haven't done a great job of describing > what the trust semantics of the attribute in > draft-ietf-abfab-aaa-saml are. However what has been going > through at least Josh and my mind is that the RP SHOULD > assume that the AAA framework provides an integrity protected > channel for that SAML message. The message is actually issued > by the IDP corresponding to the NAI used to make the access > request. In addition, for the SAML assertions sent from the > IDP to the RP, the RP SHOULD assume that the IDP is asserting > those attributes about the subject. That is, the RP need not > perform any validation of the SAML assertion. The RP still > needs to validate whether the IDP is permitted to make the > claims it does. There's no requirement that these SAML > assertions be signed. The IDP MAY sign the assertion; the RP > MAY consider any signatures that are present. However in the > interoperable case, any signatures that are present are > ignored. Eliot> You mean is that the security model you have in mind does not Eliot> require that SAML assertions be signed? We may have an Eliot> additional software layering problem- specifically, if they Eliot> are present, and you're using a SAML library to parse the Eliot> messages, from a practical standpoint, an error may be Eliot> returned. Perhaps. With Shibboleth we certainly are no longer having issues with this. I'd be interested in hearing from other SAML implementeors. Note that you are equally likely to have trouble if the message is signed and you don't have metadata. So, you're going to have a better user experience if your SAML library does not require signatures. Eliot> However, I think what you're alluding to is that the lack of Eliot> a signature itself is part of the problem of returning Eliot> attributes from 3rd parties, since the associated Eliot> connectivity of the AAA transport is providing authenticity Eliot> and not the signature. No; you can always (as the issuer at least) add signatures. Supporting a case where the third party attributes are just carried and the RP is responsible for validation is fairly easy at the protocol level. It probably requires a different AAA attribute that doesn't imply the contents should be trusted. That is, the RP is free to ignore signatures on assertions in the current attribute, but would need to validate assertions from third parties. However that's one new AAA attribute, which is fairly simple. My personal opinion is that it's also fairly useless. We're assuming that the RP and IDP don't have any requirement for a trust relationship other than through the AAA fabric. Why is it more reasonable to assume a trust relationship with a third party. There are some situations where this model is exactly what you need. Complexity comes in if you want to offload more trust to the IDP. Eliot> [snip] > Another source of complexity surrounds how an IDP links > an assertion to a subject. What confidence is the RP > asserting that the additional assertion describes the same > principal as the access-accept message. Eliot> On this point - the IdP either is or is not authoritative for Eliot> knowing at the very least where the information is going to Eliot> come from. I agree with this sentence. I don't understand how it fits into the quoted paragraph above. Eliot> The only question here is whether or not it is Eliot> willing to vouch for the information itself. I agree that's a question. I'm again not sure that it fits into the question of subject linkage, except that one hopes the subject linkage is fairly good if the IDP does vouch for the information. > Another potential source of complexity is how does the > IDP know what information to gather? Does the IDP just know > somehow? Does the RP pass information back? Eliot> And this is a generic problem with attribute providers. The Eliot> general answer is either that the principal provides a Eliot> pointer, or it finds the information through external means. Sure. But we need to provide protocols and APIs to actually convey that throughout the system. It's real engineering that needs doing for things to work, but again is certainly something we can do. Eliot> Eliot> Again, the only issues in this case are whether the IdP is Eliot> providing some sort of surety, and whether it can be assumed Eliot> that there is a trust relationship between the RP and the Eliot> attribute provider. That latter one is a much bigger deal, Eliot> IMHO! I'm definitely missing how these relate to what information the RP wants. From lear@cisco.com Mon Jan 10 13:25:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391E03A6801; Mon, 10 Jan 2011 13:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.21 X-Spam-Level: X-Spam-Status: No, score=-110.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kK1GSsuBqhAt; Mon, 10 Jan 2011 13:25:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 00C5F3A6812; Mon, 10 Jan 2011 13:25:37 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsEAOwIK02Q/khMgWdsb2JhbACECKBDFQEBFiIkonuKU44BgSGDN3QEiwo Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 10 Jan 2011 21:27:52 +0000 Received: from ams3-vpn-dhcp5297.cisco.com (ams3-vpn-dhcp5297.cisco.com [10.61.84.176]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p0ALRpts029677; Mon, 10 Jan 2011 21:27:51 GMT Message-ID: <4D2B79DE.6080009@cisco.com> Date: Mon, 10 Jan 2011 22:27:58 +0100 From: Eliot Lear 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: Sam Hartman References: <4D2B644D.9090201@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 21:25:40 -0000 Hi Sam, Thanks for your response. Let me add that this is really not a big issue with me for now. I see some very interesting use cases that relate to liability concerns around certain attributes, and I consider this conversation useful just to the point of knowing whether we are able to accomplish the task of having attribute providers later, if and when demand warrants. Just on one point: >> Another source of complexity surrounds how an IDP links >> an assertion to a subject. What confidence is the RP >> asserting that the additional assertion describes the same >> principal as the access-accept message. > > Eliot> On this point - the IdP either is or is not authoritative for > Eliot> knowing at the very least where the information is going to > Eliot> come from. > > I agree with this sentence. I don't understand how it fits into the > quoted paragraph above. I may have misunderstood what you originally wrote. Perhaps what you are saying is that if there is absolutely no requirement that the IdP trust the attribute provider at all, that it simply passes bits, then there is a risk that the information returned might not be related to the principal. I would suggest that it is incumbent on the attribute provider to at least make an assurance that it won't happen, because you're right- the RP cannot be assured otherwise because it may not have sufficient information or even authorization to reference the principal to the RP. One other challenge here would be to consider whether it is permissible that the unique index or name of the principal in the context of the attribute provider could leak to the RP. If that name is covered by a signature, it cannot easily be removed. Eliot From hartmans@painless-security.com Mon Jan 10 15:51:50 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52AEB3A680E; Mon, 10 Jan 2011 15:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 zSuqRouy9CS8; Mon, 10 Jan 2011 15:51:49 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 988013A680B; Mon, 10 Jan 2011 15:51:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 92F312028C; Mon, 10 Jan 2011 18:52:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E7074228; Mon, 10 Jan 2011 18:54:03 -0500 (EST) From: Sam Hartman To: Eliot Lear References: <4D2B644D.9090201@cisco.com> <4D2B79DE.6080009@cisco.com> Date: Mon, 10 Jan 2011 18:54:03 -0500 In-Reply-To: <4D2B79DE.6080009@cisco.com> (Eliot Lear's message of "Mon, 10 Jan 2011 22:27:58 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 23:51:50 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Perhaps what you are saying is that if there is absolutely no Eliot> requirement that the IdP trust the attribute provider at all, Eliot> that it simply passes bits, then there is a risk that the Eliot> information returned might not be related to the principal. Eliot> I would suggest that it is incumbent on the attribute Eliot> provider to at least make an assurance that it won't happen, Eliot> because you're right- the RP cannot be assured otherwise Eliot> because it may not have sufficient information or even Eliot> authorization to reference the principal to the RP. That's one case. Another case is where say you are linking principals based on names and you have two principals with the same name. E.G. I want to provide an assertion about credit availability. My credit score attribute provider can linke based on SSN (in the US) or name. The IDP doesn't have the SSN, so it has to ask about the name. What happens if the linking is off. Eliot> One other challenge here would be to consider whether it is Eliot> permissible that the unique index or name of the principal in Eliot> the context of the attribute provider could leak to the RP. Eliot> If that name is covered by a signature, it cannot easily be Eliot> removed. O, thanks for enumerating this one! From gabilm@um.es Mon Jan 10 23:59:15 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49FB3A6941; Mon, 10 Jan 2011 23:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 tlveay-QxLX0; Mon, 10 Jan 2011 23:59:15 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by core3.amsl.com (Postfix) with ESMTP id ACBB83A69DC; Mon, 10 Jan 2011 23:59:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 5400E5D482; Tue, 11 Jan 2011 09:01:28 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g0bzr4X2woAY; Tue, 11 Jan 2011 09:01:27 +0100 (CET) Received: from inf-205-128.inf.um.es (inf-205-128.inf.um.es [155.54.205.128]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id 0E5B45D465; Tue, 11 Jan 2011 09:01:23 +0100 (CET) Message-ID: <4D2C0E57.2010302@um.es> Date: Tue, 11 Jan 2011 09:01:27 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 11 Jan 2011 00:03:29 -0800 Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 07:59:16 -0000 El 10/01/11 20:17, Sam Hartman escribió: > > Things get a lot more messy when assertions from multiple IDPs are > included. > What does it mean to include them in the AAA transport? I can think of > several trust models that are appropriate depending on deployment: > > * The IDP corresponding to the subject's NAI has validated these > additional assertions and wishes to assert that the attributes can be > trusted. "If you trust me then you should trust these." Here, the > assertions are being included either for convenience of packaging the > attributes into some form the RP can process or because it is possible > that the RP may be able to validate some signature and trust the > attribute source more than the IDP. It should require a trust relationship between attribute providers and idp, in order to validate attribute assertions before to sent them all together to the RP. I just want to remark the requirement of this trust relationship. > * The subject IDP has performed SAML validation on the > assertions. However the IDP is making no claims about how trusted the > attributes included in the additional assertions are. Even if the IDP > would be permitted to make a claim made in an additional assertion, > the RP needs to make an independent policy decision about whether the > actual issuer should be permitted to make that claim. > you could include here XACML > * Here are some assertions for the RP's convenience. The IDP makes no > claims about them; not even the implied claim that they have not been > modified in transit. They better be signed, the RP better have > metadata for their issuer, and the RP is more or less on its own. I'm not sure to understand this point. Do you need the trust relationship between RP and idP? > Another source of complexity surrounds how an IDP links an assertion to > a subject. What confidence is the RP asserting that the additional > assertion describes the same principal as the access-accept message. > > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? The RP could request specific attributes in a SAML Attribute Query. Beside, idP/attribute provider could decide what attributes be disclosed to the RP, by means of attribute release policies (XACML?) regards, Gabi. > How does the RP make the policy decisions it needs to make? How does it > get metadata that is needed? > > I think this sort of issue will also have impacts for kitten, because > we'll need to describe it in the naming extensions interface. It seems > like ABFAB is not going to be the only group facing these sorts of > discussions; Kerberos is in the middle of a similar discussion right > now. > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From hartmans@painless-security.com Wed Jan 19 17:15:35 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3119328C0FF; Wed, 19 Jan 2011 17:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 GwFxVKsAM-JG; Wed, 19 Jan 2011 17:15:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1D20F3A7200; Wed, 19 Jan 2011 17:15:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D34E52029B; Wed, 19 Jan 2011 20:16:28 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2C63432C; Wed, 19 Jan 2011 20:18:07 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <015601cbb83c$5a487e40$0ed97ac0$@augustcellars.com> Date: Wed, 19 Jan 2011 20:18:07 -0500 In-Reply-To: <015601cbb83c$5a487e40$0ed97ac0$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Jan 2011 16:06:01 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, abfab@ietf.org Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 01:15:35 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Would you consider it to be permissible for an intermediate to Jim> re-write the assertions to change the framework they are being Jim> made in from the IdP's home network to the federation network's Jim> framework? This would say that they may not have quite the Jim> same degree of integrity protection as might be initially Jim> assumed. AAA integrity is hop-by-hop. I don't think we'll have technical mechanisms in some deployments to prevent this. In some cases (draft-howlett-radsec-kmp springs to mind) it might be fairly tricky to do that. I don't think we've discussed the role of intermediates much. I can think of several models including: * Intermediates are good and need to be permitted to muck about. * When intermediates can muck about it's OK for them to do so. * Intermediates must not muck about; future deployment and other mechanisms may restrict their ability to do so more than is restricted today. We have not discussed a lot what the answer is. In some of the work Josh and I did we ran into a number of cases where having the intermediates be able to examine the information passing through has been quite valuable. (We typically found that out when we designed a mechanism to short-circuit some intermediate and then ended up adding a lot of complexity to get the intermediate some information.) Similarly in discussions at the Kerberos Consortium conference this fall, several people believed that having an organizational policy intermediate near the RP would be valuable. (In that community they believed a KDC would be a great place to put such an intermediate.) >> That is, the RP need not perform any validation of the SAML >> assertion. The RP still needs to validate whether the IDP is >> permitted to make the claims Jim> it >> does. There's no requirement that these SAML assertions be >> signed. The IDP MAY sign the assertion; the RP MAY consider any >> signatures that Jim> are >> present. However in the interoperable case, any signatures that >> are Jim> present >> are ignored. >> >> If there are multiple assertions from the same IDP it seems >> reasonable to treat them all the same. >> >> Things get a lot more messy when assertions from multiple IDPs >> are included. Jim> Are you saying that the principal has multiple names or that Jim> they are multiple assertions being made about a single name? Both. I'm assuming all the assertions are about the same subject/principal, but that entity may be known by multiple names. Someone needs to actually make sure that all the assertions are about the same subject. That is quite tricky. >> Another source of complexity surrounds how an IDP links an >> assertion to a subject. What confidence is the RP asserting that >> the additional assertion describes the same principal as the >> access-accept message. >> >> Another potential source of complexity is how does the IDP know >> what information to gather? Does the IDP just know somehow? Does >> the RP pass information back? Jim> What happens if the naming space of the claims is different Jim> between the IDP and the RP? To the extent that problem exists, I think it is independent of whether multiple attribute provders or one attribute provider is involved. I think we're defining the use of NAIs as a way to have a common name space between the RP and the first IDP. That is, the AAA federation substrate for abfab needs to provide some naming services to guarantee that we have a common namespace between the RP and IDP. Jim> What happens if the additional attributes need to come from a Jim> completely different fourth realm? I.e. my name comes from the Jim> country of issue, the RP is a bank and the attributes need to Jim> come from a university? *this* is the first point I was getting at in the paragraph from my original message. I consider this situation complicated. Jim> I completely agree this is a hard problem that we need to start Jim> writing down, if not answers then at least boundaries of the Jim> problem. Yes. I and as I understand it Moonshot don't need to solve this problem to make forward progress. I think building some walls around the problem and starting to understand where it is is valuable. However until someone steps forward and wants to spend (or fund) significant cycles on this, I don't think we will solve it. From wmills@yahoo-inc.com Wed Jan 19 18:44:57 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 936103A704A for ; Wed, 19 Jan 2011 18:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.552 X-Spam-Level: X-Spam-Status: No, score=-17.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] 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 qT42Qe0aWv4V for ; Wed, 19 Jan 2011 18:44:56 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 69C1C3A7047 for ; Wed, 19 Jan 2011 18:44:56 -0800 (PST) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0K2l613085320 for ; Wed, 19 Jan 2011 18:47:06 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Wed, 19 Jan 2011 18:47:06 -0800 From: William Mills To: "kitten@ietf.org" Date: Wed, 19 Jan 2011 18:47:05 -0800 Thread-Topic: Oauth SASL mechanism implentation Thread-Index: AcuY+k0jZSx8CLExSVeVCyiwnoYlHQfUMCHg Message-ID: References: <4D02AF81.6000907@stpeter.im> 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 Subject: [kitten] Oauth SASL mechanism implentation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 02:44:57 -0000 Greetings. Now that I've finally gotten permission to put my code out into open source= I have an implementation of a SASL mechanism in the Cyrus SASL framework. = The draft spec (about to expire) is=20 http://www.ietf.org/id/draft-mills-kitten-sasl-oauth-00.txt=20 and you can find the code at https://github.com/sweetums/SASL-OAuth Many warts, and lots to fix, but it's out there. TODO list includes: - work on channel binding with the newish Cyrus SASL source drop that inclu= des it. - update to conform with the -11 or later OAuth2 core spec and the bearer t= oken spec - update the draft spec to handle the above Regards, -bill From jehan.marmottard@gmail.com Wed Jan 19 19:14:41 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94B73A7097 for ; Wed, 19 Jan 2011 19:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QvLs8XSDe6FR for ; Wed, 19 Jan 2011 19:14:39 -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 92D623A7089 for ; Wed, 19 Jan 2011 19:14:39 -0800 (PST) Received: by wwa36 with SMTP id 36so171804wwa.13 for ; Wed, 19 Jan 2011 19:17:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Y3+1Hr0fLq0PvUgQdjXoFjrPYEsELe6aoSVgwHZ/uOk=; b=phX81Pn4vPyVdCxbo6NdZbP6JrHmjMfV91hNr9zSjNzgNJ9KA5qGn4kkeuJmDiln0K Z82h6EmodHzNHHittumEn+olQcaqyQfsagP5Bk3H4ZQ+OmH+IBEhKxm4gaoOQLy2Lo5B plCLiPWfCasydZA1PA+0YDSbWbAbsHF/x5pOg= 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=SpvsGYgScYOuEJbOe97L14aUckjajGqYmSz6Rdeo68eqbAVAEY4Ybx6AZr+38J8/U+ G8q7Ks3P9cE2BIoKuOfMDO5hq8eP6HjYkEqUqSAOGelMyO0OXw4pA9yjrIwNxkyBpD7o hhAt2b57tSIrNX57jzb4ekIIZJ9SASIymXjpg= MIME-Version: 1.0 Received: by 10.216.20.141 with SMTP id p13mr3260965wep.102.1295493440625; Wed, 19 Jan 2011 19:17:20 -0800 (PST) Received: by 10.216.122.213 with HTTP; Wed, 19 Jan 2011 19:17:20 -0800 (PST) In-Reply-To: <87lj47e60k.fsf@latte.josefsson.org> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> Date: Thu, 20 Jan 2011 12:17:20 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Simon Josefsson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:14:41 -0000 Hi, sorry I got caught up in several stuffs the whole month and left several stuffs unattended on a few topic. I am back on the horse. 2010/12/3 Simon Josefsson : > Jehan Pag=E8s writes: > >> Hi, >> >> On Fri, Dec 3, 2010 at 4:54 AM, Simon Josefsson wr= ote: >>> Chris Newman writes: >>> FWIW, my implementation GNU SASL checks that salt is at least non-empty= . >>> >> >> But that's exactly the point of my erratum. Currently SASL-SCRAM does >> not say that the salt must not be empty. And the base64's formal >> syntax currently authorizes it to be empty. Hence as the salt is >> passed base64-encoded, we could assume the RFC currently authorizes >> the salt to be empty. >> But as you say, your implementation checks a salt is not-empty for >> security reason. And this is exactly the point that I think is worth >> being added in the spec. > > It is already mentioned by the spec, see above (a randomly generated > salt is rarely empty), although I can certainly agree that it could be > re-inforced with stronger language and with a reference to 4086. =A0I > don't believe empty salts should be forbidden at the syntax level. > > Please propose updated text, and I'm sure it can be included in 5802bis. > > /Simon Ok so as we all (even me) agree that my approach to the problem was not right and that an updated security considerations section could be a better suited solution. So I propose to reject my errata, and propose this kind of update to be discussed on this list (I may not be the best RFC writer, so don't hesitate to heavily modify): After: ---------------------------------- 9. Security Considerations If an attacker obtains the authentication information from the authentication repository and either eavesdrops on one authentication exchange or impersonates a server, the attacker gains the ability to impersonate that user to all servers providing SCRAM access using the same hash function, password, iteration count, and salt. For this reason, it is important to use randomly generated salt values. ----------------------------------- Add the following paragraph: ----------------------------------- Though an empty string is theoretically a perfectly valid random value, as long as it has the same probability to be generated as any other string, in practice this special case may weaken the salted password. Consequently a server implementation should wisely check a newly generated salt for not being empty, and generate it again if necessary before any further step, whereas a client implementation might refuse to authenticate when an empty salt is received. ----------------------------------- And then move the following line from the end of the "Security Considerations" section to just after the previously written paragraph where it is more significant: ----------------------------------- See [RFC4086] for more information about generating randomness. ----------------------------------- Thanks. Jehan From jehan.marmottard@gmail.com Wed Jan 19 19:37:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D70028C0E3 for ; Wed, 19 Jan 2011 19:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 SGEjdOeOSa7T for ; Wed, 19 Jan 2011 19:37:22 -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 14B7B28B797 for ; Wed, 19 Jan 2011 19:37:21 -0800 (PST) Received: by wyf23 with SMTP id 23so171023wyf.31 for ; Wed, 19 Jan 2011 19:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lldDzDYP1QMy6xAfgxYrBZLUDpT7UBwzrarwSTEYNqM=; b=VUCCZyQmromh/WdBoVrYxzK5jJVFGD6xBU9jj7uUCqDb51hyReXmsub4w0d+Jln3kE nKMY3wtktf7Thyp4q+4oFAWjATMJOqL5L3zj1Vz3g4tQAh9DZ5OMODCxOvqvXRNuDUGp EVf0PEjtXs41VS0ph3M9Tbo+KqVfnXlpi40fg= 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=l7pdCplAUQg/nGgO0HCUvFb0ge/2imM5BXfuiL+C6w5ArNjop5tX69bSImTP0mvrBE Deapi7cLE/Q+ONbEtjwARer3cRnKCdx37WtQPQyWZMxM89jPV5WyeHdDEIgUJhwa8gNW JVeSuwXHD5ehMJIC7kzNOf7XAkxI4f5oZAWys= MIME-Version: 1.0 Received: by 10.216.55.145 with SMTP id k17mr3192321wec.48.1295494802879; Wed, 19 Jan 2011 19:40:02 -0800 (PST) Received: by 10.216.122.213 with HTTP; Wed, 19 Jan 2011 19:40:02 -0800 (PST) In-Reply-To: References: <4CF91652.2080104@googlemail.com> Date: Thu, 20 Jan 2011 12:40:02 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Chris Newman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:37:24 -0000 Hi, so I catch up on this topic as well. Sorry also for the late answer. On Sat, Dec 4, 2010 at 8:04 AM, Chris Newman wrot= e: > Not only do I disagree with your proposal to remove the no-such-user erro= r, > I consider it a useful capability for several use cases of a general-purp= ose > protocol. > > When it comes to a threat analysis of an entire system, sometimes hiding = the > no-such-user information has no security value at all and thus the > diagnostic/maintenance benefit of the error becomes important. > > For example, in SMTP servers, spam/virus/phishing is the #1 threat and th= e > related denial of service attacks are important. Since it's impossible to > detect spam/virus/phishing content until an after the DATA has been > transferred (costing a lot of Internet bandwidth), it's important to reje= ct > an email with all invalid mail addresses before the DATA in order to > minimize the denial-of-service impact on the mail server. So the ability = to > probe for valid mail addresses is present in a properly configured system= . > While administrators can choose to have mail addresses different from log= in > identities that has a usability impact some administrators find > unacceptable. So if they're the same, then on a properly configured mail > system, whether an account is valid or not is public information. So the > no-such-user error provides no additional information to attackers, but i= t > provides very useful information to end-users and service desk teams. If an attack intends to do a Denial of Service, they have many other ways. They don't need to have big DATA or whatever. They can just make many connections in the same time. At this point, refusing the email before the DATA does not protect at all against a DOS. On the other side, by giving away the information about which account are valid and which are not in your example (or through other ways, like through the SCRAM authentication), you enable the spammers/phishers/other malevolent people to know who are the real targets, hence to become more efficient and spare their resources: the next time, they won't spam the accounts they know don't exist (as anyway nobody will read the spams) but will spam much more the accounts which do exists. So this configuration you propose to "protect" your servers do indeed increase the effects of what you called yoursel the #1 threat in emails. > I could also argue that the actual security has to come from the password= , > since there are so many other ways that usernames can leak. So pretending > that usernames do not leak to attackers becomes a self-delusion that > prevents sysadmins from paying proper attention to password security. I do not say that usernames cannot leak otherwise. But that's not because they may leak by some other mean that we should become light headed on this matter. At the opposite, when we can protect this information, let's do it. For the rest when we have no control (like if users go and write everywhere their emails to be collected by bots, if we stay in the case of emails), well at least we made our part. Here we are discussing about a leak which gives full information on the server's usernames. This is different from many other kind of leaks (like the ones from the user itself, which gives leaks one at a time). Thanks. Jehan > That's not to say I entirely disagree with your concern. There are many, > perhaps the majority of use cases where obscuring username validity > increases the magnitude of the attacker's problem enough to have real-wor= ld > value. But SCRAM has sufficient provision for these cases already. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Chris > > --On December 4, 2010 1:53:39 +0900 Jehan Pag=E8s > wrote: > >> Hi, >> >> 2010/12/4 Tobias Markmann : >>> >>> On 03.12.10 15:36, Jehan Pag=E8s wrote: >>>> >>>> For me the current unknown-user error is a big security flaw. I would >>>> propose to remove this error, and add a security notice about this. >>>> Has this issue already been raised? >>> >>> Almost any information you return on failure, beside the failure itself= , >>> can be used by a malicious user against a server. I think that's why th= e >>> whole server-final-message is OPTIONAL in case of an error. >>> >> >> Most other error are far less usable for attack. They are rather >> syntax bugs, which are very useful for normal implementers and would >> only tell an attacker that he made a technical error in his own >> implementation. But it does not give away information about data >> stored by the server (like "does this username exist?"), other than >> what he would have known with a proper implementation. Those errors >> are for instance encoding issues, CB incompatibility, incompatibility >> of mandatory extensions (for the future when there will be some), etc. >> >>> Those error messages only seem useful for debugging purposed, since som= e >>> protocols using SASL, i.e. XMPP, provide SASL errors on that protocol >>> level [1]. >> >> Good example If you check the link you give (the last draft of the >> updated RFC has similar content as well: >> http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-19#section-6.5 ), >> in XMPP, we use only one error () whether you fail >> because of a wrong password or because your username does not exist, >> for instance. The attacker does not know if he is wasting his time on >> this attack, nor can he fill his db with any useful data on existence >> of a JID. >> >> So of course that's nice when the higher level protocol filters the >> SASL errors (in XMPP, we closed the leak created in some SASL >> mechanisms like SCRAM), but I don't see why it should prevent us from >> fixing this data leak on the SASL-SCRAM level as well. >> >>> >>> A security notice about this would be nice but actually the problem >>> isn't specific to SCRAM but to nearly all SASL mechanisms. >>> >> >> I agree about this, but first we can fix this in SCRAM by removing the >> unknown-user error; and then we can add a security notice in SASL, >> telling that SASL mechanisms should take care about this kind of leak. >> There are 2 levels of RFC changes here. >> >> Jehan >> >>> Cheers, >>> Tobi >>> >>> [1] http://tools.ietf.org/html/rfc3920#section-6.4 >>> >>> -- >>> Tobias Markmann >>> http://ayena.de >>> >>> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> > > > > > From jehan.marmottard@gmail.com Wed Jan 19 19:47:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE95128C0F6 for ; Wed, 19 Jan 2011 19:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Z4t7LvwD9ygO for ; Wed, 19 Jan 2011 19:47:37 -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 D249B28C0ED for ; Wed, 19 Jan 2011 19:47:36 -0800 (PST) Received: by wwa36 with SMTP id 36so190522wwa.13 for ; Wed, 19 Jan 2011 19:50:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EosB0UaQxTCrvjOyjjE+oX9z06c9kxMewNXgvupyH/s=; b=rL0aa2STkK8jWQT7I4jfRERZG8sUDsf18MTVyNXiOYTpq06hRiFuG7pNrqWL+fQY72 L6y9MwiDI6DgUu0d3v/DVTxF9rnUkLGAbMcTrgJb+KAFW2qZK3AG55g2J7Smo2fMPEdy WW20Jvamdqe/sZ2pRKBrPCxrd9FrQZ0enYYdQ= 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=cX2aJRV8Mj830c2zWqYLpC4svzxoL8KqbzzJS0mG4sJlzuNWO8+gEFkbXKZZCSCfDt bGmX5Nl1XFUnuP2n2BagNoG1y1T+v8qfCm5zz8BDzJE1a1NH5Ri1z+kII0iR1mRV8JaK O1Na30jHCguBeacrnu0kPd3zuWiiS4RoPMyPM= MIME-Version: 1.0 Received: by 10.216.55.145 with SMTP id k17mr3198815wec.48.1295495417904; Wed, 19 Jan 2011 19:50:17 -0800 (PST) Received: by 10.216.122.213 with HTTP; Wed, 19 Jan 2011 19:50:17 -0800 (PST) In-Reply-To: <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> References: <4CF91652.2080104@googlemail.com> <25128_1291395225_oB3Griia031936_AANLkTi=NnaG=a-CaiNKFVSsx=8tzKd_Q87wnAJ3CbuXY@mail.gmail.com> <5A6498C4F1AEDE3EC2DDB578@minbar.fac.cs.cmu.edu> Date: Thu, 20 Jan 2011 12:50:17 +0900 Message-ID: From: =?ISO-8859-1?Q?Jehan_Pag=E8s?= To: Jeffrey Hutzelman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] RFC5802: question about unknown-user error X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 03:47:38 -0000 Hi, On Tue, Dec 7, 2010 at 6:52 AM, Jeffrey Hutzelman wrote: > --On Saturday, December 04, 2010 01:53:39 AM +0900 Jehan Pag=E8s > wrote: > >> I agree about this, but first we can fix this in SCRAM by removing the >> unknown-user error > > No. =A0Not reporting unknown-user is a policy preference, and one which t= he > protocol already permits. =A0You now propose to encode your policy prefer= ence > into the protocol, thereby usurping the operator's authority to set polic= y. > > -- Jeff > This is why in the end, I was proposing not to modify the protocol but to make it a security note. I quote myself: =AB So I think this would deserve a security note telling implementers they can implement this way to avoid data leak. I will try to make a proposition later. =BB Then it is up to the implementers and/or the configuration of the server, then to the operators (for instance during installation, you may like to test with more informative errors, then once in production, you switch on "secure" configuration not to give away username's information with errors). So at least as a security note, expose this concern, give alternatives, and leave implementers/operators decide how they wish to do and what they set as higher importance. Without a security note about this, everybody would probably implement it exactly as it is currently, then there will be no different "policy preferences" to choose from by the operator. I will come later with a text proposition exposing both logics and their respective advantages as discussed on this thread, then you can tell me. Thanks. Jehan From ietf@augustcellars.com Wed Jan 19 16:31:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8707128C131; Wed, 19 Jan 2011 16:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 SJtHeQJ17r1v; Wed, 19 Jan 2011 16:31:45 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id A1F8028C130; Wed, 19 Jan 2011 16:31:44 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 61E3B6A46F; Wed, 19 Jan 2011 16:34:25 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , , References: In-Reply-To: Date: Wed, 19 Jan 2011 16:06:01 -0800 Message-ID: <015601cbb83c$5a487e40$0ed97ac0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEc8ihovdZ5DbuDGptHOYErkbr+GJU2gAiQ Content-Language: en-us X-Mailman-Approved-At: Wed, 19 Jan 2011 20:47:29 -0800 Subject: Re: [kitten] [abfab] Multiple attribute providers in an authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 00:31:46 -0000 Sam Comments in line. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, January 10, 2011 11:18 AM > To: abfab@ietf.org; kitten@ietf.org > Subject: [abfab] Multiple attribute providers in an authentication > > > Background: there was a discussion between authors of the abfab > architecture proposal about multiple attribute providers. > The idea is that you have an identity provider that is producing a set of > attributes about a subject. In the case of ABFAB we're mostly thinking of a > SAML IDP for this particular example. > > The IDP has some attributes it may be in a position to assert. > But the IDP may also want to gather attributes from other sources and pass > those along. > > One option it has is to simply pass the attributes along as if it issued them > itself. That option isn't really interesting from a protocol standpoint because > it is indistinguishable from the IDP actually issuing the attribute itself. That is > probably a fine thing to do in certain deployments but we don't need to > spend a lot of time on it. > > Another option is that the IDP can go actually get a SAML assertion (or > attribute certificate or the like) and include that in what is sent to the RP. > > At first glance, the protocol implications of doing this look simple. You just > stick the assertion in the existing bag of bits and move on. > > however, it's not that simple because of semantics. > > Today in ABFAB, we haven't done a great job of describing what the trust > semantics of the attribute in draft-ietf-abfab-aaa-saml are. However what > has been going through at least Josh and my mind is that the RP SHOULD > assume that the AAA framework provides an integrity protected channel for > that SAML message. The message is actually issued by the IDP corresponding > to the NAI used to make the access request. In addition, for the SAML > assertions sent from the IDP to the RP, the RP SHOULD assume that the IDP > is asserting those attributes about the subject. Would you consider it to be permissible for an intermediate to re-write the assertions to change the framework they are being made in from the IdP's home network to the federation network's framework? This would say that they may not have quite the same degree of integrity protection as might be initially assumed. > That is, the RP need not perform any validation of the SAML assertion. The > RP still needs to validate whether the IDP is permitted to make the claims it > does. > There's no requirement that these SAML assertions be signed. > The IDP MAY sign the assertion; the RP MAY consider any signatures that are > present. However in the interoperable case, any signatures that are present > are ignored. > > If there are multiple assertions from the same IDP it seems reasonable to > treat them all the same. > > Things get a lot more messy when assertions from multiple IDPs are > included. Are you saying that the principal has multiple names or that they are multiple assertions being made about a single name? > What does it mean to include them in the AAA transport? I can think of > several trust models that are appropriate depending on deployment: > > * The IDP corresponding to the subject's NAI has validated these > additional assertions and wishes to assert that the attributes can be > trusted. "If you trust me then you should trust these." Here, the > assertions are being included either for convenience of packaging the > attributes into some form the RP can process or because it is possible > that the RP may be able to validate some signature and trust the > attribute source more than the IDP. > > * The subject IDP has performed SAML validation on the > assertions. However the IDP is making no claims about how trusted the > attributes included in the additional assertions are. Even if the IDP > would be permitted to make a claim made in an additional assertion, > the RP needs to make an independent policy decision about whether the > actual issuer should be permitted to make that claim. > > * Here are some assertions for the RP's convenience. The IDP makes no > claims about them; not even the implied claim that they have not been > modified in transit. They better be signed, the RP better have > metadata for their issuer, and the RP is more or less on its own. > > Another source of complexity surrounds how an IDP links an assertion to a > subject. What confidence is the RP asserting that the additional assertion > describes the same principal as the access-accept message. > > Another potential source of complexity is how does the IDP know what > information to gather? Does the IDP just know somehow? Does the RP pass > information back? What happens if the naming space of the claims is different between the IDP and the RP? What happens if the additional attributes need to come from a completely different fourth realm? I.e. my name comes from the country of issue, the RP is a bank and the attributes need to come from a university? > > How does the RP make the policy decisions it needs to make? How does it > get metadata that is needed? > > I think this sort of issue will also have impacts for kitten, because we'll need > to describe it in the naming extensions interface. It seems like ABFAB is not > going to be the only group facing these sorts of discussions; Kerberos is in the > middle of a similar discussion right now. I completely agree this is a hard problem that we need to start writing down, if not answers then at least boundaries of the problem. Jim > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From simon@josefsson.org Thu Jan 20 01:50:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC7D28C11E for ; Thu, 20 Jan 2011 01:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 MgPd7aHsLPKq for ; Thu, 20 Jan 2011 01:50:11 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id F172B28C117 for ; Thu, 20 Jan 2011 01:50:10 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0K9qgMT007204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jan 2011 10:52:44 +0100 From: Simon Josefsson To: Jehan =?iso-8859-1?Q?Pag=E8s?= References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110120:jehan.marmottard@gmail.com::PTpkHFR749Or/0E+:4Bok X-Hashcash: 1:22:110120:kitten@ietf.org::ervvQ6DSNIjfwJhk:GErV Date: Thu, 20 Jan 2011 10:52:42 +0100 In-Reply-To: ("Jehan =?iso-8859-1?Q?Pag=E8s=22's?= message of "Thu, 20 Jan 2011 12:17:20 +0900") Message-ID: <87zkqv7vh1.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 09:50:12 -0000 Jehan Pagès writes: > After: > ---------------------------------- > 9. Security Considerations > > > > If an attacker obtains the authentication information from the > authentication repository and either eavesdrops on one authentication > exchange or impersonates a server, the attacker gains the ability to > impersonate that user to all servers providing SCRAM access using the > same hash function, password, iteration count, and salt. For this > reason, it is important to use randomly generated salt values. > ----------------------------------- > Add the following paragraph: > ----------------------------------- > Though an empty string is theoretically a perfectly valid random > value, as long as it has the same probability to be generated as any > other string, in practice this special case may weaken the salted > password. Consequently a server implementation should wisely check a > newly generated salt for not being empty, and generate it again if > necessary before any further step, whereas a client implementation > might refuse to authenticate when an empty salt is received. > ----------------------------------- I think we should add something that implementations should have a minimum accepted salt length, for security reasons. A 1 byte octet salt does not make sense. I don't think we want to say that all strings should have the same probability to be generated -- an implementation that picks good random 15 character strings for salt is OK but there is 0 probability for that implementation to generate a 14 character string, so it would fail your language. I suggest to add a sentence after If an attacker obtains the authentication information from the authentication repository and either eavesdrops on one authentication exchange or impersonates a server, the attacker gains the ability to impersonate that user to all servers providing SCRAM access using the same hash function, password, iteration count, and salt. For this reason, it is important to use randomly generated salt values. that says Further, implementations are RECOMMENDED to reject salt values shorter than 2 characters and MAY reject even longer salt values if they are considered to be insufficient. See [RFC4086] on generating randomness. /Simon From ghudson@mit.edu Thu Jan 20 08:35:05 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8983A713C for ; Thu, 20 Jan 2011 08:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.139 X-Spam-Level: X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-1.540, 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 b9CXAYPLC492 for ; Thu, 20 Jan 2011 08:35:03 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 20C1F3A713A for ; Thu, 20 Jan 2011 08:35:01 -0800 (PST) X-AuditID: 12074424-b7b0bae000000a05-07-4d3864d9104c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id BF.E3.02565.9D4683D4; Thu, 20 Jan 2011 11:37:45 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p0KGbiTR016990; Thu, 20 Jan 2011 11:37:44 -0500 Received: from [10.0.0.102] (c-24-61-11-81.hsd1.ma.comcast.net [24.61.11.81]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p0KGbetV007194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 11:37:43 -0500 (EST) From: Greg Hudson To: Simon Josefsson In-Reply-To: <87zkqv7vh1.fsf@latte.josefsson.org> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 20 Jan 2011 11:37:40 -0500 Message-ID: <1295541460.2456.520.camel@ray> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAARcyoW8= Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 16:35:05 -0000 On Thu, 2011-01-20 at 04:52 -0500, Simon Josefsson wrote: > Further, implementations are RECOMMENDED to reject salt values > shorter than 2 characters and MAY reject even longer salt values if > they are considered to be insufficient. See [RFC4086] on generating > randomness. Is it common to use language like this (RFC 2119 words) in a security considerations section? If you can only interoperate by using salts above a certain length, then it seems like that should be part of the syntactic or semantic constraints of the actual standard section describing salts. I continue to think it's pointless complexity for one side of a connection to police the other side's randomness. A zero-length salt could be the very uncommon output of a random-length salt generation process, and a 15-character salt could be a fixed string. But I seem to be in the rough. From simon@josefsson.org Thu Jan 20 12:48:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0E523A681E for ; Thu, 20 Jan 2011 12:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 yuz-Rz4PvtGb for ; Thu, 20 Jan 2011 12:48:22 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 905923A6810 for ; Thu, 20 Jan 2011 12:48:21 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0KKowoE013588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Jan 2011 21:51:00 +0100 From: Simon Josefsson To: Greg Hudson References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110120:kitten@ietf.org::81mMCeLg4koo0A7U:3Uz1 X-Hashcash: 1:22:110120:ghudson@mit.edu::OpTcZgR67+2pgbwv:04aX9 Date: Thu, 20 Jan 2011 21:50:58 +0100 In-Reply-To: <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> (Greg Hudson's message of "Thu, 20 Jan 2011 11:37:40 -0500") Message-ID: <87oc7b1eq5.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 20:48:22 -0000 Greg Hudson writes: > On Thu, 2011-01-20 at 04:52 -0500, Simon Josefsson wrote: >> Further, implementations are RECOMMENDED to reject salt values >> shorter than 2 characters and MAY reject even longer salt values if >> they are considered to be insufficient. See [RFC4086] on generating >> randomness. > > Is it common to use language like this (RFC 2119 words) in a security > considerations section? It is probably better to avoid it. > If you can only interoperate by using salts above a certain length, then > it seems like that should be part of the syntactic or semantic > constraints of the actual standard section describing salts. I don't think that conclusion follows -- there are many things permitted by syntax rules that are forbidden by semantic rules. Pushing all semantic rules down into syntax rules is not always a good thing. I wouldn't oppose doing so if others feel it is a better way. > I continue to think it's pointless complexity for one side of a > connection to police the other side's randomness. A zero-length salt > could be the very uncommon output of a random-length salt generation > process, and a 15-character salt could be a fixed string. But I seem to > be in the rough. Not necessarily. I don't see a serious problem with the current specification here, despite my proposal to add more text. The spec already says salts should be random. /Simon From ghudson@mit.edu Thu Jan 20 20:46:06 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3EE3A68B0 for ; Thu, 20 Jan 2011 20:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, 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 DmY87eIoTF2H for ; Thu, 20 Jan 2011 20:46:05 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 579883A6882 for ; Thu, 20 Jan 2011 20:46:05 -0800 (PST) X-AuditID: 12074425-b7c98ae000000a04-83-4d391031f681 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 48.4F.02564.130193D4; Thu, 20 Jan 2011 23:48:49 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p0L4mmSo004726; Thu, 20 Jan 2011 23:48:48 -0500 Received: from [10.0.0.102] (c-24-61-11-81.hsd1.ma.comcast.net [24.61.11.81]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p0L4miI0023086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jan 2011 23:48:45 -0500 (EST) From: Greg Hudson To: Simon Josefsson In-Reply-To: <87oc7b1eq5.fsf@latte.josefsson.org> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> <87oc7b1eq5.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 20 Jan 2011 23:48:43 -0500 Message-ID: <1295585323.2456.527.camel@ray> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAARcyoW8= Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 04:46:06 -0000 On Thu, 2011-01-20 at 15:50 -0500, Simon Josefsson wrote: > > If you can only interoperate by using salts above a certain length, then > > it seems like that should be part of the syntactic or semantic > > constraints of the actual standard section describing salts. > > I don't think that conclusion follows -- there are many things permitted > by syntax rules that are forbidden by semantic rules. Pushing all > semantic rules down into syntax rules is not always a good thing. I > wouldn't oppose doing so if others feel it is a better way. I said "syntactic or semantic constraints"; I wasn't advocating one or the other. I was just arguing that interoperability constraints should be documented in the appropriate section of the main RFC, not in security considerations text. From krithika.ssn@gmail.com Fri Jan 21 00:49:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA023A68F2 for ; Fri, 21 Jan 2011 00:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.740, 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 medfQfj+fFIi for ; Fri, 21 Jan 2011 00:49:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8031A3A68F0 for ; Fri, 21 Jan 2011 00:49:50 -0800 (PST) Received: by vws7 with SMTP id 7so676022vws.31 for ; Fri, 21 Jan 2011 00:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8S5dhwZDP5zu0nCpz0P0P63CUklkfxyH2RT3cSs+oDY=; b=TBrltxx/U6w/D5b34dR1CtOOA8eJNhoAODvePs2ZViSAW5M9cIiB13uYIjGXpte/3X FN/M0iPxM9lm4PHqPHU0hdFaT6ASIoB5u5z34d1aNVSAWazXh7eW8PBCKEHn0vgmdtrr gGa8JzCi2RoXAcmUhr8bYjFJmO9X7Np8c/Yv8= 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=E8/5qj8cmcLSRCIhsHLoQ1Qy+7fn1f+a09Fj4H5JU5G/UcADzPUMEJD+KXNSKeaBHz EHOvkEY5ExJuNuz1HQycQAk6ChoXWERfDCxCG6vrIGRaIBkwPHexuayZsN+HDElGXqPU iIrbVcAulT5koXown9bJozkhvGX0l8DmvyIbU= MIME-Version: 1.0 Received: by 10.220.176.12 with SMTP id bc12mr115705vcb.55.1295599954462; Fri, 21 Jan 2011 00:52:34 -0800 (PST) Received: by 10.220.52.204 with HTTP; Fri, 21 Jan 2011 00:52:34 -0800 (PST) In-Reply-To: <1295585323.2456.527.camel@ray> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> <87oc7b1eq5.fsf@latte.josefsson.org> <1295585323.2456.527.camel@ray> Date: Fri, 21 Jan 2011 14:22:34 +0530 Message-ID: From: krithika swaminathan To: Greg Hudson Content-Type: multipart/alternative; boundary=90e6ba53aeb60e8916049a575f50 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 08:49:51 -0000 --90e6ba53aeb60e8916049a575f50 Content-Type: text/plain; charset=ISO-8859-1 Hello All, Can you please unscubscribe me from this list Thanks Krithika S On Fri, Jan 21, 2011 at 10:18 AM, Greg Hudson wrote: > On Thu, 2011-01-20 at 15:50 -0500, Simon Josefsson wrote: > > > If you can only interoperate by using salts above a certain length, > then > > > it seems like that should be part of the syntactic or semantic > > > constraints of the actual standard section describing salts. > > > > I don't think that conclusion follows -- there are many things permitted > > by syntax rules that are forbidden by semantic rules. Pushing all > > semantic rules down into syntax rules is not always a good thing. I > > wouldn't oppose doing so if others feel it is a better way. > > I said "syntactic or semantic constraints"; I wasn't advocating one or > the other. I was just arguing that interoperability constraints should > be documented in the appropriate section of the main RFC, not in > security considerations text. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --90e6ba53aeb60e8916049a575f50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello All,=A0

Can you please unscubscribe me from this l= ist

Thanks
Krithika S

On Fri, Jan 21, 2011 at 10:18 AM, Greg Hudson <ghudson@mit.edu>= wrote:
On Thu, 2011-01-20 at 15:50 -0500, Simon Jo= sefsson wrote:
> > If you can only interoperate by using salts above a certain lengt= h, then
> > it seems like that should be part of the syntactic or semantic > > constraints of the actual standard section describing salts.
>
> I don't think that conclusion follows -- there are many things per= mitted
> by syntax rules that are forbidden by semantic rules. =A0Pushing all > semantic rules down into syntax rules is not always a good thing. =A0I=
> wouldn't oppose doing so if others feel it is a better way.

I said "syntactic or semantic constraints"; I wasn't advocati= ng one or
the other. =A0I was just arguing that interoperability constraints should be documented in the appropriate section of the main RFC, not in
security considerations text.


_______________________________________________
Kitten mailing list
Kitten@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten

--90e6ba53aeb60e8916049a575f50-- From simon@josefsson.org Fri Jan 21 05:17:10 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12123A696A for ; Fri, 21 Jan 2011 05:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 ask08ZWsXSdb for ; Fri, 21 Jan 2011 05:17:10 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A70623A6920 for ; Fri, 21 Jan 2011 05:17:08 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0LDJmxu002722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Jan 2011 14:19:49 +0100 From: Simon Josefsson To: Greg Hudson References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> <87oc7b1eq5.fsf@latte.josefsson.org> <1295585323.2456.527.camel__40021.5141744868$1295585343$gmane$org@ray> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110121:kitten@ietf.org::RwwRixzyuWh52t0g:NYy6 X-Hashcash: 1:22:110121:ghudson@mit.edu::o9J6hgZPD4fQER1L:PoWi Date: Fri, 21 Jan 2011 14:19:48 +0100 In-Reply-To: <1295585323.2456.527.camel__40021.5141744868$1295585343$gmane$org@ray> (Greg Hudson's message of "Thu, 20 Jan 2011 23:48:43 -0500") Message-ID: <87vd1i8kcr.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 13:17:10 -0000 Greg Hudson writes: > On Thu, 2011-01-20 at 15:50 -0500, Simon Josefsson wrote: >> > If you can only interoperate by using salts above a certain length, then >> > it seems like that should be part of the syntactic or semantic >> > constraints of the actual standard section describing salts. >> >> I don't think that conclusion follows -- there are many things permitted >> by syntax rules that are forbidden by semantic rules. Pushing all >> semantic rules down into syntax rules is not always a good thing. I >> wouldn't oppose doing so if others feel it is a better way. > > I said "syntactic or semantic constraints"; I wasn't advocating one or > the other. I was just arguing that interoperability constraints should > be documented in the appropriate section of the main RFC, not in > security considerations text. Oh, sorry. I agree. /Simon From hartmans@mit.edu Mon Jan 24 12:29:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89583A6922 for ; Mon, 24 Jan 2011 12:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=-0.488, 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 F4lnLZtio+d9 for ; Mon, 24 Jan 2011 12:29:47 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BC0883A6918 for ; Mon, 24 Jan 2011 12:29:46 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0B16520222 for ; Mon, 24 Jan 2011 15:30:48 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE8CA432C; Mon, 24 Jan 2011 15:32:21 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Mon, 24 Jan 2011 15:32:21 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Where is the host-based service registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 20:29:48 -0000 I recall that there is a registry of host-based services (things like host, imap, xmpp, ldap, etc) the service component of GSS_NT_HOSTBASED_SERVICE. Where is that registry? A quick google of IANA failed to find it. From simon@josefsson.org Mon Jan 24 13:28:25 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24F313A6B3F for ; Mon, 24 Jan 2011 13:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.657 X-Spam-Level: X-Spam-Status: No, score=-102.657 tagged_above=-999 required=5 tests=[AWL=-0.058, 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 zqZgHURyU9kG for ; Mon, 24 Jan 2011 13:28:23 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id DD5943A6B39 for ; Mon, 24 Jan 2011 13:28:22 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0OLVBlp021618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 24 Jan 2011 22:31:13 +0100 From: Simon Josefsson To: Sam Hartman References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110124:hartmans-ietf@mit.edu::9uDIfA7sjUw5DV1v:2ctd X-Hashcash: 1:22:110124:kitten@ietf.org::ebxKy547ATlq1SLI:LU9Z Date: Mon, 24 Jan 2011 22:31:11 +0100 In-Reply-To: (Sam Hartman's message of "Mon, 24 Jan 2011 15:32:21 -0500") Message-ID: <87zkqq3s68.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] Where is the host-based service registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 21:28:25 -0000 Sam Hartman writes: > I recall that there is a registry of host-based services (things like > host, imap, xmpp, ldap, etc) the service component of > GSS_NT_HOSTBASED_SERVICE. Where is that registry? A quick google of > IANA failed to find it. RFC 2743 says: Documents specifying means for GSS integration into a particular protocol should state either: (a) that a specific IANA-registered name associated with that protocol shall be used for the "service" element (this admits, if needed, the possibility that a single name can be registered and shared among a related set of protocols), or (b) that the generic name "host" shall be used for the "service" element, or (c) that, for that protocol, fallback in specified order (a, then b) or (b, then a) shall be applied. IANA registration of specific names per (a) should be handled in accordance with the "Specification Required" assignment policy, defined by BCP 26, RFC 2434 as follows: "Values and their meaning must be documented in an RFC or other available reference, in sufficient detail so that interoperability between independent implementations is possible." Possibly the registry was never created? One alternative could be to point at the IANA well-known port registry. /Simon From chris.newman@oracle.com Mon Jan 24 15:17:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054603A69BC for ; Mon, 24 Jan 2011 15:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.763 X-Spam-Level: X-Spam-Status: No, score=-105.763 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 60BnZkNHG62y for ; Mon, 24 Jan 2011 15:17:37 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id D4D0F3A69A5 for ; Mon, 24 Jan 2011 15:17:36 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p0ONKVKn023950 for ; Mon, 24 Jan 2011 23:20:32 GMT Received: from gotmail.sfbay.sun.com (gotmail.SFBay.Sun.COM [10.5.195.31]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id p0ONKTgY029875 for ; Mon, 24 Jan 2011 15:20:31 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.01 64bit (built Jan 5 2011)) with ESMTPSA id <0LFJ00E2SVI2SI00@gotmail.sfbay.sun.com> for kitten@ietf.org; Mon, 24 Jan 2011 15:20:29 -0800 (PST) Date: Mon, 24 Jan 2011 15:20:26 -0800 From: Chris Newman To: Sam Hartman , kitten@ietf.org Message-id: <48563EBF7B81C41358CD25BA@96B2F16665FF96BAE59E9B90> In-reply-to: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [kitten] Where is the host-based service registry X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 23:17:38 -0000 Is this what you're looking for: ? --On January 24, 2011 15:32:21 -0500 Sam Hartman wrote: > > I recall that there is a registry of host-based services (things like > host, imap, xmpp, ldap, etc) the service component of > GSS_NT_HOSTBASED_SERVICE. Where is that registry? A quick google of > IANA failed to find it. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From lear@cisco.com Mon Jan 31 04:47:36 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 643483A6BEC for ; Mon, 31 Jan 2011 04:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.238 X-Spam-Level: X-Spam-Status: No, score=-110.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 b9hbEKhwiRrm for ; Mon, 31 Jan 2011 04:47:35 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6912F3A696D for ; Mon, 31 Jan 2011 04:47:35 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgEAD8/Rk2Q/khNgWdsb2JhbACEFaBiFQEBFiIkoRuKYpAJgSODN3QEjCE Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 31 Jan 2011 12:50:49 +0000 Received: from dhcp-10-61-100-10.cisco.com (dhcp-10-61-100-10.cisco.com [10.61.100.10]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p0VCom4r032543 for ; Mon, 31 Jan 2011 12:50:49 GMT Message-ID: <4D46B01D.6090005@cisco.com> Date: Mon, 31 Jan 2011 13:50:37 +0100 From: Eliot Lear 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: "kitten@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] new version of draft-ietf-kitten-sasl-openid coming X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 12:47:36 -0000 Hi everyone, A new version is coming in time for IETF. There are several proposed changes: 1. Security considerations discussion updated based on discussion with Sam around potential improvements that could be made between the SASL application and the browser. 2. OpenID itself has no transaction id, and therefore there must be one for the relying party. The example had this already, but it wasn't mentioned clearly in the text. Please comment when you see it. Eliot From Internet-Drafts@ietf.org Mon Jan 31 05:00:04 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F603A6C09; Mon, 31 Jan 2011 05:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 o2VwHQXvyPSF; Mon, 31 Jan 2011 05:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18583A6BAB; Mon, 31 Jan 2011 05:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110131130001.20693.50352.idtracker@localhost> Date: Mon, 31 Jan 2011 05:00:01 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action:draft-ietf-kitten-sasl-openid-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 13:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : E. Lear, et al. Filename : draft-ietf-kitten-sasl-openid-01.txt Pages : 22 Date : 2011-01-31 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-sasl-openid-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-31045100.I-D@ietf.org> --NextPart--