From y.oiwa@aist.go.jp Tue Jul 5 07:10:42 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2808221F8575; Tue, 5 Jul 2011 07:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0eoV0qEBJGZ; Tue, 5 Jul 2011 07:10:38 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB721F8579; Tue, 5 Jul 2011 07:10:36 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EAXhe028839; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875034; bh=lWQopefAxXp1v8Gj10NThaRecdYPKaMpSBH//1Hj9CY=; h=From:Date:Message-ID; b=cv2SwYkrx+yiZFi+986DQbzMET2zsmeWCM1veVLdoZ0hQDC6fnA3RvDfipROq3SJo aVQ0QOPv/7n1Hz2EWGohSmuXFC2qcaEq/l1Jzn507NhTBbw3BSk3NRnvOTJ5ISn8UQ tFyQxXMK/khr8pqF/NHcxf2kbc6AI6aw45Y3KAJ8= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EAXhS002618; Tue, 5 Jul 2011 23:10:33 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EAWg1014010; Tue, 5 Jul 2011 23:10:32 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:10:32 +0900 Message-ID: <87box824yv.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [http-auth] http-auth problem statement draft X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:10:42 -0000 Dear all, I have just reformatted the problem statement document (previously put on IETF Wiki) to the I-D format. The draft is now available from: http://tools.ietf.org/html/draft-oiwa-http-auth-problem-statement-00 I've added categorization of use-cases to three groups (Section 4). I also added several references and other minor improvements. I'd like to add more topics and use cases here. Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From y.oiwa@aist.go.jp Tue Jul 5 07:17:53 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392911E80AB; Tue, 5 Jul 2011 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiwgka5xyqtU; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 44BA221F858D; Tue, 5 Jul 2011 07:17:52 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p65EHowH000254; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1309875470; bh=oGEyCnG3lyoDz1cydQMKppf/N7+0bxcT6RXYlSRAlQk=; h=From:Date:Message-ID; b=RZV9ehmEFqApeDSxnRRKhyH4XdahyyF6mXUzo2rRB24GHFmOsz0I8noEZ+WMIEUZ+ UEBwNBPs1qIIph+O5uOVGxNeWJ+kkh3p9f4+e3mmqwKhe3IKu6f0W0nSzgnZHDiskw cxmgqZMMKZphXqNB2LtM0nE3M1I+mpbD/sVYSqoE= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p65EHoYa003048; Tue, 5 Jul 2011 23:17:50 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p65EHnVF015625; Tue, 5 Jul 2011 23:17:49 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: IETF HTTP-auth Mailing List From: Yutaka OIWA Date: Tue, 05 Jul 2011 23:17:49 +0900 Message-ID: <877h7w24mq.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: saag , apps-discuss Subject: [http-auth] Updated HTTP Mutual authentication draft X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF HTTP-auth Mailing List List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:17:53 -0000 I've updated the http Mutual authentication proposal draft. As suggested at Prague Bar-BoF, now I split out the cryptography part from the core protocol part. Current status of separation is a bit technical and sloppy, I will improve some non-technical sections such as introduction to make it more natural in the future. In the next stage I'd also like to re-examine the http-auth extension (optional auth and detailed auth control) part and separate it to another draft, possibly after Quebec. The drafts are now available at http://tools.ietf.org/html/draft-oiwa-http-mutualauth-09 http://tools.ietf.org/html/draft-oiwa-http-mutualauth-algo-00 Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From asteingruebl@paypal-inc.com Tue Jul 5 08:42:11 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C54C21F8718 for ; Tue, 5 Jul 2011 08:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awl1HRetBIdj for ; Tue, 5 Jul 2011 08:42:10 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 45DED21F8707 for ; Tue, 5 Jul 2011 08:41:54 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=JgT45UAQmvApvv8q0DZTlC0Jv5QwfZ6/QG9r/GXigrAsA9vy+XJ2pgYf tnG81TGLZIoJ4NFZkiz1u44t0PQT9cfDMXzcDhURSLfFfz3Z2rXNSfyeG nyHBhdF+gc83XLf; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1309880514; x=1341416514; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TJopGcn7XLbSnkB4j7/qR8nnjzKRec+z8o2pT8GMXDw=; b=Nr9xG8dWZwv04joDsBse0aOrneIsymYHC7sPyhWfpD9aRI72C+CPpESk zZJ57q8nskpmEL/U3037funukhXzQntuS1N/tPnuJkIjCaPvDiHYFWHlq gf8scJdfqUqNJEc; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,479,1304319600"; d="scan'208";a="3088813" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 05 Jul 2011 08:41:54 -0700 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 5 Jul 2011 09:41:53 -0600 From: "Steingruebl, Andy" To: Tim , "http-auth@ietf.org" Date: Tue, 5 Jul 2011 09:41:51 -0600 Thread-Topic: [http-auth] CSRF Prevention Thread-Index: AcwyvAwAjLb+0t+sS8i62z7Jhu+ozgIbZtzw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> References: <20110624221315.GF1542@sentinelchicken.org> In-Reply-To: <20110624221315.GF1542@sentinelchicken.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: r6ID2dfofNcx3JVWUdOCCw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 15:42:11 -0000 > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On B= ehalf Of Tim > Failing that, as a final possibility (and the reason I am posting this > here) is that we could rely on a better HTTP authentication mechanism to > help us enforce CSRF protections. Since Referer logic is already baked i= n to > browsers, and any HTTP authentication mechanism would also need to be > baked in to browsers, why not bake something like Referer into the HTTP > authentication mechansim to help application developers validate the orig= in > of requests? Essentially, make Referer information more reliable and mor= e > privacy sensitive. >=20 > The most obvious approach would be to require an origin domain parameter > in the HTTP authentication mechanism, have it signed, and then let > application developers check that upon receipt. Several people have in the past proposed an "Origin" header. Among them Adam Barth, Collin Jackson, and even folks at Mozilla who have a= nice write-up here: https://wiki.mozilla.org/Security/Origin I haven't seen your "ACTION" verb proposal before, but others here may have= pointers to similar previous research. Other ideas proposed in this space have been cookies that aren't sent cross= -domain. So, a website can choose whether certain cookies are sent on cross= -site requests. =20 - Andy From nico@cryptonector.com Tue Jul 5 14:17:19 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F421F8989 for ; Tue, 5 Jul 2011 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKGACJGJA9VD for ; Tue, 5 Jul 2011 14:17:18 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0363321F8822 for ; Tue, 5 Jul 2011 14:16:54 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id B03B66B007D for ; Tue, 5 Jul 2011 14:16:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=YV/ZG5gaNKmJVH6qC4t0i ulhzkxrWuOJYegY0iIcgR+j+IkUj3tKjp8S7XAtOU+6JknOFHVucxcvBJl94u7Wt TbHC89RaYSoj/W/7St0LhBCdOzWci+DBkiMu+kp7crSv3SsKC0rAnNV31Xgkt2BR 2z0VLPXAtfd8OHv/ssmJIA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6CCrevoN0ydgdIAS6K4w twLIcyk=; b=Mg0xJ+jk39qxdoAO2XRgg9ruqH4GSFPl7Nmj2CnvYUBytRy5aNyT YKqzRfJ147iRsKnfLazThyxlAGFS+rW2pNKP06Gz2rNrwpMvbj0Gxluj0SN/nHiD qe61xKOyi9UcJsVebO2j9LmuWhBzFk6Ce8BfjwqFMWuZniEwv5q3KKo= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 93C406B0014 for ; Tue, 5 Jul 2011 14:16:54 -0700 (PDT) Received: by pvh18 with SMTP id 18so8433878pvh.31 for ; Tue, 05 Jul 2011 14:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.2 with SMTP id d2mr9122336pbj.454.1309900614215; Tue, 05 Jul 2011 14:16:54 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 14:16:54 -0700 (PDT) In-Reply-To: <20110624221315.GF1542@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> Date: Tue, 5 Jul 2011 16:16:54 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 21:17:19 -0000 I believe authentication is orthogonal to CSRF. It would be nice to have what you might call stronger type and semantic safety. An IMG tag should refer to images, thus a header that indicates the type of data expected in the response might help. Moreover, an IMG should never do anything other than a GET (or HEAD -- and any other non-data-modifying verbs), and the GET is expected to have no side effects (other than updating atime on a filesystem, perhaps). The browser knows these details, so it could tell the server "don't do anything, just give me back an image", and the server could respond with some error indicating that the browser is likely being subjected to a CSRF attach. The proposed Origin header would fall into the category of improvements that add stronger type and/or semantic safety. It'd be nice to have response headers by which the server can indicate that it did perform the requested type/semantic checking. Also, it'd be nice to have a way to add "critical" headers -- headers that servers are supposed to understand else they must reject the request. Nico -- From tim-research@sentinelchicken.org Tue Jul 5 15:11:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30C221F8968 for ; Tue, 5 Jul 2011 15:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNNU0vA5ih-Y for ; Tue, 5 Jul 2011 15:11:50 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2345821F8819 for ; Tue, 5 Jul 2011 15:11:43 -0700 (PDT) Received: (qmail 21506 invoked from network); 5 Jul 2011 22:11:41 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jul 2011 22:11:41 -0000 Received: (qmail 4049 invoked from network); 5 Jul 2011 22:11:14 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 5 Jul 2011 22:11:14 -0000 Received: (nullmailer pid 660 invoked by uid 1000); Tue, 05 Jul 2011 22:11:40 -0000 Date: Tue, 5 Jul 2011 15:11:40 -0700 From: Tim To: "Steingruebl, Andy" Message-ID: <20110705221140.GA25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:11:50 -0000 Hi Andy, Thanks for taking the time to read my monologue. > > The most obvious approach would be to require an origin domain parameter > > in the HTTP authentication mechanism, have it signed, and then let > > application developers check that upon receipt. > > Several people have in the past proposed an "Origin" header. > > Among them Adam Barth, Collin Jackson, and even folks at Mozilla who have a nice write-up here: > https://wiki.mozilla.org/Security/Origin I have no doubt this has been covered before. The Origin header seems pretty straight-forward, though it doesn't attempt to provide privacy if users don't want to expose what sites they are coming from. Since Origin it doesn't include the full URI, it isn't as bad as Referer, but still, there are many instances where users have interal web servers pointing out to the Internet and would rather their internal host names be kept private. So one approach to achieve what I'm am proposing is to have the HTTP authentication mechanism authenticate an Origin header. Changing Origin to a salted hash of the Origin might be a nice upgrade. > I haven't seen your "ACTION" verb proposal before, but others here may have pointers to similar previous research. Well, I'm only now mentioning it. =) I've floated the idea to a couple of security people, but haven't tried to write anything up. The insecurity of the Internet keeps me so busy that I can't find time to sharpen the axe and propose formal fixes, let alone see them through to standardization. > Other ideas proposed in this space have been cookies that aren't sent cross-domain. So, a website can choose whether certain cookies are sent on cross-site requests. Not sure I understand how this would help. tim From tim-research@sentinelchicken.org Tue Jul 5 15:25:40 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C450021F88E7 for ; Tue, 5 Jul 2011 15:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7u303o+VERn for ; Tue, 5 Jul 2011 15:25:40 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD0421F888F for ; Tue, 5 Jul 2011 15:25:40 -0700 (PDT) Received: (qmail 21560 invoked from network); 5 Jul 2011 22:25:40 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jul 2011 22:25:40 -0000 Received: (qmail 4067 invoked from network); 5 Jul 2011 22:25:12 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 5 Jul 2011 22:25:12 -0000 Received: (nullmailer pid 718 invoked by uid 1000); Tue, 05 Jul 2011 22:25:39 -0000 Date: Tue, 5 Jul 2011 15:25:39 -0700 From: Tim To: Nico Williams Message-ID: <20110705222539.GB25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:25:40 -0000 Hi Nico, > I believe authentication is orthogonal to CSRF. I don't agree. The reason why CSRF works is because we're using broken, layered authentication systems that assume any request at one layer (HTTP) is ok to embed in a secure stream at the lower layer (SSL/TLS). Essentially, CSRF can be seen as a spoofed request within the encrypted channel. Notice how similar it is, in exploitation, to the TLS renegotiation flaw? You're just issuing a blind request. The layer that makes requests needs to be tying the source origin in with the layer doing authentication. By doing so, you'd be preventing problems like what we had with (old) Flash's ability to forge headers in a cross-origin way. While I don't think it is reasonable to support that kind of behavior in client-side technologies, preventing this will also make the protocols much more resilient in the face of other attacks. > It would be nice to have what you might call stronger type and > semantic safety. An IMG tag should refer to images, thus a header > that indicates the type of data expected in the response might help. > Moreover, an IMG should never do anything other than a GET (or HEAD -- > and any other non-data-modifying verbs), and the GET is expected to > have no side effects (other than updating atime on a filesystem, > perhaps). The browser knows these details, so it could tell the > server "don't do anything, just give me back an image", and the server > could respond with some error indicating that the browser is likely > being subjected to a CSRF attach. It would be nice if browser implementors considered these problems when they added gobs and gobs of features into HTML, JavaScript and other client-side technologies. Unfortunately, they didn't, and going back to fix them doesn't seem tractable to me. Restricting requests that come out of IMG tags might be somehow possible, but doing that for JavaScript form submission is a different beast. So when it comes to client-side enforcement, this is where a different, restricted, HTTP method (ACTION/PUT) could come in. This would be far easier to implement in browsers since IMG/LINK/other tags already only do GET, forms can only do GET/POST, and XMLHttpRequest is already same-origin. I'm not against client-side enforcement, but I don't think it is reasonable to try and enforce new restrictions on existing cross-origin requests. Trying to prevent things like JSON data theft might also be difficult if protection is only offered client-side. Thanks, tim From asteingruebl@paypal-inc.com Tue Jul 5 15:37:19 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8021F8831 for ; Tue, 5 Jul 2011 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX7SWU1t6pmK for ; Tue, 5 Jul 2011 15:37:19 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id ED7E621F85DE for ; Tue, 5 Jul 2011 15:37:18 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:Received: From:To:CC:Date:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path:X-EMS-Proccessed:X-EMS-STAMP:X-CFilter; b=JriDtDFP4d7nBHk/C6LMHnKAe4K5jkjBEpnizWfiMAi1qaRxwmZwow5B s5UuFENOgP7pyODX6cJPq6EsTnr53nLpD7Wf0a+4gV197LzX7upPxDFCW FxXuAN8TiXObvRs; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1309905439; x=1341441439; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=99EITKmqIArtHkRtKC0gVm8ahDz8AZSIGTTt5FTp5cw=; b=t0k4u2Bagy3OVseCrLrtiNyiLeFL7MrGwmENThoUUFRSuTDJhzqex4KR wTm4MCzeikkobCxbiAyyMyAt8rV84Qc7/0ZIxDdk2vRuNsWZAOBhFOdvf omcpEWT1ZB0tP2n; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.65,481,1304319600"; d="scan'208";a="2613239" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 05 Jul 2011 15:37:18 -0700 Received: from DEN-MEXHT-004.corp.ebay.com (10.241.17.60) by DEN-MEXHT-003.corp.ebay.com (10.241.17.54) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 5 Jul 2011 16:37:18 -0600 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-004.corp.ebay.com ([10.241.17.60]) with mapi; Tue, 5 Jul 2011 16:37:17 -0600 From: "Steingruebl, Andy" To: Tim Date: Tue, 5 Jul 2011 16:37:16 -0600 Thread-Topic: [http-auth] CSRF Prevention Thread-Index: Acw7YKjByhOQYZIgRjq8pCwBG4TCHAAAw0Gw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD609@DEN-MEXMS-001.corp.ebay.com> References: <20110624221315.GF1542@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> <20110705221140.GA25355@sentinelchicken.org> In-Reply-To: <20110705221140.GA25355@sentinelchicken.org> 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 X-EMS-Proccessed: 10SqDH0iR7ekR7SRpKqm5A== X-EMS-STAMP: 3jMqRMARaGBACHd2/yCK2Q== X-CFilter: Scanned Cc: "http-auth@ietf.org" Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:37:19 -0000 > -----Original Message----- > From: Tim [mailto:tim-research@sentinelchicken.org] >=20 > > Other ideas proposed in this space have been cookies that aren't sent > cross-domain. So, a website can choose whether certain cookies are sent o= n > cross-site requests. >=20 > Not sure I understand how this would help. A site would set its authentication cookies such that the browser will only= send them when the referrer is the same site. As a consequence, CSRF att= acks can't happen if the "source page" isn't on the domain of the cookie. = It will prevent cross-domain actions because the browser won't send the nec= essary authentication data. In some sense similar to what Microsoft has done with XDR so that one can s= till build unauthenticated mashups, but the control would be under the doma= in setting the cookies. - Andy From tim-research@sentinelchicken.org Tue Jul 5 15:41:20 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306B421F865D for ; Tue, 5 Jul 2011 15:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt-2rG4BcGCa for ; Tue, 5 Jul 2011 15:41:19 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0F621F8646 for ; Tue, 5 Jul 2011 15:41:19 -0700 (PDT) Received: (qmail 21596 invoked from network); 5 Jul 2011 22:41:19 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jul 2011 22:41:19 -0000 Received: (qmail 4107 invoked from network); 5 Jul 2011 22:40:52 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 5 Jul 2011 22:40:52 -0000 Received: (nullmailer pid 812 invoked by uid 1000); Tue, 05 Jul 2011 22:41:18 -0000 Date: Tue, 5 Jul 2011 15:41:18 -0700 From: Tim To: "Steingruebl, Andy" Message-ID: <20110705224118.GD25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> <20110705221140.GA25355@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD609@DEN-MEXMS-001.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD609@DEN-MEXMS-001.corp.ebay.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:41:20 -0000 > > > Other ideas proposed in this space have been cookies that aren't sent > > cross-domain. So, a website can choose whether certain cookies are sent on > > cross-site requests. > > > > Not sure I understand how this would help. > > A site would set its authentication cookies such that the browser will only send them when the referrer is the same site. As a consequence, CSRF attacks can't happen if the "source page" isn't on the domain of the cookie. It will prevent cross-domain actions because the browser won't send the necessary authentication data. Ok, that makes more sense. Of course, this wouldn't protect sites using HTTP authentication. Since using cookies for authentication comes with so many other problems, a mechanism that isn't tied to cookies makes more sense to me. tim From nico@cryptonector.com Tue Jul 5 15:49:03 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA9321F885C for ; Tue, 5 Jul 2011 15:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEOrwhJ2LYxf for ; Tue, 5 Jul 2011 15:49:03 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 063AE21F883A for ; Tue, 5 Jul 2011 15:49:03 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id C27F71F007C for ; Tue, 5 Jul 2011 15:49:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=OicHuuK8WAvju4Ex+Gu7OqjL7+v+ohhED7ar2pEWJ2GL ngToyAjrOx6QQgdORpMbWHtb9iXZ3zUyCS6UsaSf8rn+c5lC8bIYgAicz+ZCW8le hoTlGmX+2kOK4BTku/IeJUjdyWFR1cwvk8LpnO5FjnSxXbcTDcvWdr8DR9s1WlM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=enICXl8oZLNVTTJtmq4+sF0PlaQ=; b=VTV0RySmw3M /4DEdEPlW98ih52H3RQyRBYvALHpvSwHZj85xaiAwKpUXdLlK/Y5GsxjvrdVo4VH BNxcy8GgrdYvKsZTIC6oriQA18KlRoIPk8Ne86fhiffZdfpu6agFeLaxyCV5psOd 3O9mFOUEEe7y/gYbIzAp9NM3f4ghqk3Q= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 9F0AB1F0078 for ; Tue, 5 Jul 2011 15:49:02 -0700 (PDT) Received: by pvh18 with SMTP id 18so8508153pvh.31 for ; Tue, 05 Jul 2011 15:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.52.197 with SMTP id v5mr9528041pbo.387.1309906142269; Tue, 05 Jul 2011 15:49:02 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 15:49:02 -0700 (PDT) In-Reply-To: <20110705222539.GB25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> Date: Tue, 5 Jul 2011 17:49:02 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:49:03 -0000 On Tue, Jul 5, 2011 at 5:25 PM, Tim wrot= e: >> I believe authentication is orthogonal to CSRF. > > I don't agree. =C2=A0The reason why CSRF works is because we're using > broken, layered authentication systems that assume any request at one > layer (HTTP) is ok to embed in a secure stream at the lower layer > (SSL/TLS). =C2=A0Essentially, CSRF can be seen as a spoofed request withi= n > the encrypted channel. =C2=A0Notice how similar it is, in exploitation, t= o > the TLS renegotiation flaw? =C2=A0You're just issuing a blind request. But this is a confused deputy problem. The problem is not how to authenticate the deputy, but how to prevent its confusion. As for TLS renegotiation, there we had two cryptographic channels where one needed to bind to the other. But what would we have to bind here? Crypto at the HTTP layer to the TLS channel? Sure, but how would crypto at the HTTP layer prevent the deputy from getting confused? Also, the problem isn't that HTTPS is used without HTTP-layer authentication. The problem is that the browser stupidly performs a request in one context that was given to it by a malicious site in another context. Suppose we have HTTP-layer authentication. How does that help the browser prevent that attack? Having a referrer in the HTTP-layer authentication would be no different than having a Referrer header in the first place. >> It would be nice to have what you might call stronger type and >> semantic safety. =C2=A0An IMG tag should refer to images, thus a header >> that indicates the type of data expected in the response might help. >> Moreover, an IMG should never do anything other than a GET (or HEAD -- >> and any other non-data-modifying verbs), and the GET is expected to >> have no side effects (other than updating atime on a filesystem, >> perhaps). =C2=A0The browser knows these details, so it could tell the >> server "don't do anything, just give me back an image", and the server >> could respond with some error indicating that the browser is likely >> being subjected to a CSRF attach. > > It would be nice if browser implementors considered these problems > when they added gobs and gobs of features into HTML, JavaScript and > other client-side technologies. =C2=A0Unfortunately, they didn't, and goi= ng > back to fix them doesn't seem tractable to me. =C2=A0Restricting requests > that come out of IMG tags might be somehow possible, but doing that > for JavaScript form submission is a different beast. I don't see a good alternative. The problem is a confused deputy problem. We must either provide it with enough information that it cannot be confused or we must have another party check that the deputy is not doing something indicative of confusion. If we stop thinking about authentication and crypto for a minute, and think strictly about the confused deputy problem in the abstract, what else can we do? > So when it comes to client-side enforcement, this is where a > different, restricted, HTTP method (ACTION/PUT) could come in. =C2=A0This > would be far easier to implement in browsers since IMG/LINK/other tags > already only do GET, forms can only do GET/POST, and XMLHttpRequest is > already same-origin. Note that same-origin restrictions are the sort of safety device that I was talking about. That doesn't work in the case of links embedded in HTML because... well, because cross-domain links are exactly what gives the web so much power, what distinguishes the web from all other applications. Now, we can't get rid of cross-domain links because we'd not want to do that. But we can add methods by which to constrain the kinds of actions that a user agent will take when following cross-domain links. For example, we could say that cross-domain links are followed outside the context of logged-in sessions (i.e., without cookies or whatever HTTP authentication methods and session material might have been used otherwise), instantly stopping CSRF without breaking the vast majority of cross-domain links. Indeed, we might say that if a page wishes the browser to follow a cross-domain reference *within* an authenticated session, then the browser must first determine that the target site allows the remote origin to do this. > I'm not against client-side enforcement, but I don't think it is > reasonable to try and enforce new restrictions on existing > cross-origin requests. =C2=A0Trying to prevent things like JSON data thef= t > might also be difficult if protection is only offered client-side. Well, the vast majority of legitimate cross-domain references are not intended to be executed in the context of logged-in sessions. If that's true then we might well want to break all cross-domain references that are intended to be executed in the context of logged-in sessions. Nico -- From nico@cryptonector.com Tue Jul 5 15:51:41 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A90421F8906 for ; Tue, 5 Jul 2011 15:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM5oCkpFrqmq for ; Tue, 5 Jul 2011 15:51:40 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id AD8EF21F88F3 for ; Tue, 5 Jul 2011 15:51:40 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 6FD7577805F for ; Tue, 5 Jul 2011 15:51:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Lvdli5sUh3/Wpi4rDgTsSOGgXgcLWFTaLVZ9Lwyi2BNV c62bv3KOX2VocJE1e6dhi006KqHoww3qUw74FeNnrDZEdN56aVX9/snIviRPzkWt 7hKIlBBKDIl0la7IsKyCk36w1hKFTDsxAJDECFebIKhjaeOo4PXcxFPzw8mdeF4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=1uOIj9h5qOE3apahTtdfJzurlbM=; b=ngm7dGwuauW 9B9W78V8sE57Ge/XZOwiwED+W/DQuNHVEkJNzj8L+KaBWPzLCSh3nDiABE7Jekrr fzn+CRKmaok33MVeCJsSvspPFqIcsgnlHWtnha2ZWQTQyDDMXdB5aFuOw0Un/yij 8PMKXZX0+dWFpy9uBWdQFMtDqHRVA5nM= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 4D53477805B for ; Tue, 5 Jul 2011 15:51:40 -0700 (PDT) Received: by pvh18 with SMTP id 18so8510205pvh.31 for ; Tue, 05 Jul 2011 15:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.2 with SMTP id d2mr9205973pbj.454.1309906299931; Tue, 05 Jul 2011 15:51:39 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 15:51:39 -0700 (PDT) In-Reply-To: <20110705224118.GD25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD15D@DEN-MEXMS-001.corp.ebay.com> <20110705221140.GA25355@sentinelchicken.org> <5EE049BA3C6538409BBE6F1760F328ABEB8FBAD609@DEN-MEXMS-001.corp.ebay.com> <20110705224118.GD25355@sentinelchicken.org> Date: Tue, 5 Jul 2011 17:51:39 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 22:51:41 -0000 On Tue, Jul 5, 2011 at 5:41 PM, Tim wrot= e: >> > > Other ideas proposed in this space have been cookies that aren't sen= t >> > cross-domain. So, a website can choose whether certain cookies are sen= t on >> > cross-site requests. >> > >> > Not sure I understand how this would help. >> >> A site would set its authentication cookies such that the browser will o= nly send them when the referrer is the same site. =C2=A0 As a consequence, = CSRF attacks can't happen if the "source page" isn't on the domain of the c= ookie. =C2=A0It will prevent cross-domain actions because the browser won't= send the necessary authentication data. > > Ok, that makes more sense. > > Of course, this wouldn't protect sites using HTTP authentication. > Since using cookies for authentication comes with so many other > problems, a mechanism that isn't tied to cookies makes more sense to > me. No, the browser has to know not to follow cross-domain references in any logged-in session context. Whether the session be identified by cookies or by something else (e.g., a session ID in HTTP authentication) is irrelevant, as long as the browser knows to not use any of it when following cross-domain references. Nico -- From tim-research@sentinelchicken.org Tue Jul 5 16:55:43 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269BD21F8889 for ; Tue, 5 Jul 2011 16:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tCmHLop1nDq for ; Tue, 5 Jul 2011 16:55:42 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5F34921F8897 for ; Tue, 5 Jul 2011 16:55:42 -0700 (PDT) Received: (qmail 21912 invoked from network); 5 Jul 2011 23:55:39 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 5 Jul 2011 23:55:39 -0000 Received: (qmail 4543 invoked from network); 5 Jul 2011 23:55:12 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 5 Jul 2011 23:55:12 -0000 Received: (nullmailer pid 1134 invoked by uid 1000); Tue, 05 Jul 2011 23:55:39 -0000 Date: Tue, 5 Jul 2011 16:55:39 -0700 From: Tim To: Nico Williams Message-ID: <20110705235539.GG25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 23:55:43 -0000 > But this is a confused deputy problem. The problem is not how to > authenticate the deputy, but how to prevent its confusion. Sure. > As for TLS renegotiation, there we had two cryptographic channels > where one needed to bind to the other. But what would we have to bind > here? Crypto at the HTTP layer to the TLS channel? Sure, but how > would crypto at the HTTP layer prevent the deputy from getting > confused? My proposal, in this context, was not to have the deputy try to prevent it, but merely to include authenticated information about who the requestor was so the server can decide if it is ok. > Also, the problem isn't that HTTPS is used without HTTP-layer > authentication. The problem is that the browser stupidly performs a > request in one context that was given to it by a malicious site in > another context. Suppose we have HTTP-layer authentication. How does > that help the browser prevent that attack? It doesn't help the browser/deputy, it helps the server. > Having a referrer in the > HTTP-layer authentication would be no different than having a Referrer > header in the first place. Right. This isn't a major leap away from Referer. It's just that Referer is unreliable for privacy(/other?) reasons, so we need a more reliable way to indicate to servers what the requesting origin was. While we're going through the trouble of adding a variant of Referer, why not also provide: A. Authenticity of this new origin mechanism, because in the past, it was possible to forge the Referer header with Flash* B. Additional privacy of this origin to protect the paranoid and improve adoption * In security circles, it is still "best practice" to avoid using Referer as CSRF protection even though it should be relatively safe now that Flash isn't (as) broken. I don't think anyone has conducted a comprehensive survey of other client-side scripting languages to see if it is possible to forge Referer cross-origin in some other way. > If we stop thinking > about authentication and crypto for a minute, and think strictly about > the confused deputy problem in the abstract, what else can we do? Sure. So we can either have the deputy (browser) prevent CSRF, or we can have it attach enough information to requests to allow the server to handle it when it makes sense. > Note that same-origin restrictions are the sort of safety device that > I was talking about. That doesn't work in the case of links embedded > in HTML because... well, because cross-domain links are exactly what > gives the web so much power, what distinguishes the web from all other > applications. > > Now, we can't get rid of cross-domain links because we'd not want to > do that. But we can add methods by which to constrain the kinds of > actions that a user agent will take when following cross-domain links. Exactly. So if we try to have the deputy prevent CSRF, which is admittedly attractive from a technical standpoint, then we have to have some way to allow all old cross-origin request types that we want. This is where a new HTTP method could come in to play, as I've alluded to. Let browsers enforce a simple rule that ACTION(/PUT?) can only be sent same-origin (or perhaps cross-origin if the server explicitly allows it), and then have applications require ACTION be used on any sensitive pages. ADVANTAGES: - We don't worry about sending any extra info to servers about the origin, which avoids potential privacy issues. - Simpler implementation for web applications (don't need to validate one or more whitelisted origins with every request) Or, using an Origin-like mechanism, we can enforce the fix on the server. ADVANTAGES: - Simpler implementation for browsers - Allows web applications to make more complex decisions about whether or not pages can be accessed cross-origin Feel free to add to the list of advantages/disadvantages. Clearly, taking the first approach means we don't need to talk about this on http-auth. =) I think if we're inclined to take the second, then it makes sense to include Origin information in an authenticated context to make the system more resilient. > Well, the vast majority of legitimate cross-domain references are not > intended to be executed in the context of logged-in sessions. If > that's true then we might well want to break all cross-domain > references that are intended to be executed in the context of > logged-in sessions. I don't think it is worth trying to mess with any existing cross-origin behavior. There would just be too much resistance, legacy, and complexity which begets implementation flaws. cheers, tim From nico@cryptonector.com Tue Jul 5 17:10:48 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC3221F88C4 for ; Tue, 5 Jul 2011 17:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUVgW9Ks5x9z for ; Tue, 5 Jul 2011 17:10:48 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7421F88C9 for ; Tue, 5 Jul 2011 17:10:48 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 0E52E508078 for ; Tue, 5 Jul 2011 17:10:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=giRcxDODJMUAJ84G4YJFw0qPMjCeOEk5p7fiLyflE60x lXVDcDfSSPa4Oim7uw3UWmihBBtBZHUehVKkExc/Zt+CPFq731dayIolOVa0d004 BlkJF4fYaE7J4lANIkDwQaRPdw2Gb0eRb/FUJuDN/52iHUG4RRBSna7VBqbc3Iw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UIPWU7iY+j2on1vQjFEqDOAw6eM=; b=yv/3u52MUwI H6XpNVPFRKaaMATzv8E2VEtyQEzcxBN0hH2hB8caofjYa3Tgmk0x0Mnnpck0sUxl 2FiroMYGyDZ5U8ePlgzdJKlYQh5v2oii6Yp8RyZw0hw1U8Hr0cykRlVEchxlbQL2 yHCpc+uLkVd5LcJDAgWKfXU12z9MXZDM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id EF58B508063 for ; Tue, 5 Jul 2011 17:10:39 -0700 (PDT) Received: by pzk5 with SMTP id 5so2775112pzk.31 for ; Tue, 05 Jul 2011 17:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.161 with SMTP id f1mr9753244pbm.186.1309911039593; Tue, 05 Jul 2011 17:10:39 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 17:10:39 -0700 (PDT) In-Reply-To: <20110705235539.GG25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> Date: Tue, 5 Jul 2011 19:10:39 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:10:48 -0000 On Tue, Jul 5, 2011 at 6:55 PM, Tim wrot= e: >> But this is a confused deputy problem. =C2=A0The problem is not how to >> authenticate the deputy, but how to prevent its confusion. > > Sure. > >> As for TLS renegotiation, there we had two cryptographic channels >> where one needed to bind to the other. =C2=A0But what would we have to b= ind >> here? =C2=A0Crypto at the HTTP layer to the TLS channel? =C2=A0Sure, but= how >> would crypto at the HTTP layer prevent the deputy from getting >> confused? > > My proposal, in this context, was not to have the deputy try to > prevent it, but merely to include authenticated information about who > the requestor was so the server can decide if it is ok. The fact that you'd have HTTP authentication (when that is in use) transport this information does not mean that CSRF and authentication are tightly coupled. They're not. The point of contact between CSRF and authentication lies in whether a cross-domain reference can be followed within the context of a logged-in session, and if so what is conveyed to the server about the origin. Assuming a sufficiently abstracted interface to authentication the browser's job is to either a) use a non-authenticated session/channel to follow the reference, and/or b) to convey the origin of the reference to the server (whether via an HTTP request header or as an input to whatever authentication facility that might be in use). If it wouldn't break much to insist that cross-domain references be followed outside the context of authenticated sessions, then that seems like the best option as the _default_ behavior for browsers, with any switches to change that behavior resulting in the origin always being sent to the server and/or the use of a critical facility to decide whether to follow the reference in authenticated channel. Nico -- From nico@cryptonector.com Tue Jul 5 17:23:46 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8A21F88E8 for ; Tue, 5 Jul 2011 17:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udVMbpkazkgS for ; Tue, 5 Jul 2011 17:23:45 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4021F888E for ; Tue, 5 Jul 2011 17:23:45 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 871107E4062 for ; Tue, 5 Jul 2011 17:23:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ET+N+WI0K1N6kvX3mYXNZhY85NdkQhoiTIL2sBYTq/nG nQXiiHXIXD8vh6VZLHO8GajxO1hbFlzHTJ6cjW7yC9O/Ly/Xqzc2V/AyzUE97OPl poQX6Xr3ymtouugIutGOyzt798/QYfpgvz3ir1cZtfw0jXAnXRaQ+ajsBJCN/Kg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=AzhFAu/E5seubrcgeZQgGeUQ+eA=; b=Yu3dQrgl5Bi ncfSwCtaiukb9c8s2Sn3u66dddO2YvaWlce/1A0anHNzsA+R3ERmlMnnBPK5gAKg PwWAWdjHA8lfSbRs8CQ2V9PLrKGagc6Mc54E6aim/za+rRa1GYjJsbOphoV9m18O a8MNzyzJjJ1KebOin6y3iwuZqsL0pFLM= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 6D70A7E405D for ; Tue, 5 Jul 2011 17:23:45 -0700 (PDT) Received: by pvh18 with SMTP id 18so8581112pvh.31 for ; Tue, 05 Jul 2011 17:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.2 with SMTP id d2mr9285420pbj.454.1309911824873; Tue, 05 Jul 2011 17:23:44 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Tue, 5 Jul 2011 17:23:44 -0700 (PDT) In-Reply-To: <20110705235539.GG25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> Date: Tue, 5 Jul 2011 19:23:44 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 00:23:46 -0000 On Tue, Jul 5, 2011 at 6:55 PM, Tim wrot= e: > While we're going through the trouble of adding a variant of Referer, > why not also provide: > > =C2=A0A. Authenticity of this new origin mechanism, because in the past, = it > =C2=A0 =C2=A0was possible to forge the Referer header with Flash* So... every time some implementor screws up we need to introduce a new thing instead of saying "just upgrade already"? I don't see how this approach scales. Also, given that most web sites don't use HTTP authentication, and will continue not using it for years even if we agreed to a new HTTP authentication method that solves all our problems, I don't think this helps as much as any solution that the browser can implement locally to either prevent CSRF altogether or help the server do so. > =C2=A0B. Additional privacy of this origin to protect the paranoid and > =C2=A0 =C2=A0improve adoption I don't see how this helps: the server gets to see the origin anyways. You could hash the origin, I suppose, and then the server could check the hash against a table of trusted domainname hashes -- that would help w.r.t privacy, but this could be done in HTTPS without any resort to HTTP authentication. >> If we stop thinking >> about authentication and crypto for a minute, and think strictly about >> the confused deputy problem in the abstract, what else can we do? > > Sure. > > So we can either have the deputy (browser) prevent CSRF, or we can > have it attach enough information to requests to allow the server to > handle it when it makes sense. Right. Two types of solutions then. The "don't use an authenticated session to follow references from other origins" falls into the locally-prevent-CSRF bucket. The "send origin information" solution falls into the give-the-server-more-info bucket. >> Note that same-origin restrictions are the sort of safety device that >> I was talking about. =C2=A0That doesn't work in the case of links embedd= ed >> in HTML because... well, because cross-domain links are exactly what >> gives the web so much power, what distinguishes the web from all other >> applications. >> >> Now, we can't get rid of cross-domain links because we'd not want to >> do that. =C2=A0But we can add methods by which to constrain the kinds of >> actions that a user agent will take when following cross-domain links. > > Exactly. =C2=A0So if we try to have the deputy prevent CSRF, which is > admittedly attractive from a technical standpoint, then we have to > have some way to allow all old cross-origin request types that we > want. Right. The way I would do that is to have the server provide a list of trusted origins for cross-domain references. This could be in the form of a simple file at the top-level of the site, like robots.txt, or it could be an HTTP verb to check whether an origin is trusted to issue a given reference, OR, it could be a 'critical' HTTP request extension to convey the origin in such a way that the server will not execute the request unless the origin is allowed to have the deputy issue that request. I'm thinking that the only way to add critical HTTP extensions must be through new verbs, which must be why you mention a new "ACTION" verb. Would you agree that what you're looking for is a critical HTTP extension? It's so much what that extension does, as that it's critical. (Of course, the browser would have to use HTTPS if on-path active attackers are an issue. Attackers mount CSRF attacks only because they are not on-path active attackers, but we should assume there will be other active attackers on the wire.) Nico -- From tim-research@sentinelchicken.org Wed Jul 6 08:41:32 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADD421F860E for ; Wed, 6 Jul 2011 08:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O3Brh6Ye4JI for ; Wed, 6 Jul 2011 08:41:30 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 19B5C21F8539 for ; Wed, 6 Jul 2011 08:41:27 -0700 (PDT) Received: (qmail 30117 invoked from network); 6 Jul 2011 15:41:23 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jul 2011 15:41:23 -0000 Received: (qmail 21672 invoked from network); 6 Jul 2011 15:40:53 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jul 2011 15:40:53 -0000 Received: (nullmailer pid 5276 invoked by uid 1000); Wed, 06 Jul 2011 15:41:22 -0000 Date: Wed, 6 Jul 2011 08:41:22 -0700 From: Tim To: Nico Williams Message-ID: <20110706154122.GI25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 15:41:32 -0000 > >  A. Authenticity of this new origin mechanism, because in the past, it > >    was possible to forge the Referer header with Flash* > > So... every time some implementor screws up we need to introduce a new > thing instead of saying "just upgrade already"? > > I don't see how this approach scales. Where is it written in any standard, IETF, W3C, or otherwise, that client-side technologies like Flash should not allow cross-origin specification (forgery) of HTTP headers? Origins for JavaScript don't match Origins for cookies. Rules for communication between Java and web servers are quite different from rules for XMLHttpRequest. The web is a mess. It is incredibly fragile with layers of bad assumptions piled higher and deeper. I think providing some integrity, via HTTP authentication, for something like an Origin header is worth the expense, even though we haven't yet thought of the next attack scenario to forge it. Of course that all assumes that the best fix is by providing more information to the server so the server can prevent CSRF. > >  B. Additional privacy of this origin to protect the paranoid and > >    improve adoption > > I don't see how this helps: the server gets to see the origin anyways. > You could hash the origin, I suppose, and then the server could check > the hash against a table of trusted domainname hashes -- that would > help w.r.t privacy, but this could be done in HTTPS without any resort > to HTTP authentication. How does HTTPS help with privacy for Origins? The privacy I'm talking about here is hiding third-party Origins from the receiving server, unless it is in a white list of domains the server trusts. > The way I would do that is to have the server provide a list of > trusted origins for cross-domain references. This could be in the > form of a simple file at the top-level of the site, like robots.txt, > or it could be an HTTP verb to check whether an origin is trusted to > issue a given reference, OR, it could be a 'critical' HTTP request > extension to convey the origin in such a way that the server will not > execute the request unless the origin is allowed to have the deputy > issue that request. Right, so the way I had envisioned it is that by default, a new HTTP method would be restricted to same-origin unless something like CORS was provided to allow additional origins to send it. > I'm thinking that the only way to add critical HTTP extensions must be > through new verbs, which must be why you mention a new "ACTION" verb. > Would you agree that what you're looking for is a critical HTTP > extension? It's so much what that extension does, as that it's > critical. I honestly haven't put a lot of thought into alternative ways to achieve the same thing. A new HTTP method would work, for this purpose, given that the current ways to send cross-origin requests are pretty much restricted in browsers to GET and POST. Adding a new, restricted method is an easy way to provide backward compatibility. However, a similar thing could be accomplished with a special header, so long as it is well defined that such a header can only be sent according to certain rules. I kind of get the heebee geebees when thinking about that though, given the frequency with which I find various injection flaws in HTTP headers. A new method would likely be less susceptible to that. There is also this issue of Java applets, which I think can be used to bypass any of these protections on sites that have multiple virtual hosts. (Correct me if I am wrong, but I believe Java allows arbitrary control of a TCP stream back to the serving host's IP address, without regard to the host name in the origin.) This is where tying an origin into the authentication process provides better protection. > (Of course, the browser would have to use HTTPS if on-path active > attackers are an issue. Attackers mount CSRF attacks only because > they are not on-path active attackers, but we should assume there will > be other active attackers on the wire.) Of course. tim From nico@cryptonector.com Wed Jul 6 09:28:58 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D019021F884C for ; Wed, 6 Jul 2011 09:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=-0.913, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xy40XTfsR57 for ; Wed, 6 Jul 2011 09:28:56 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id BA00921F84DA for ; Wed, 6 Jul 2011 09:28:56 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1EF2320203C for ; Wed, 6 Jul 2011 09:28:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=H1oHqn4FBhQR8sON7dBw4k/5/f4XpvFjhKZ7jzCMIxbN KnzrzflgKqKy3FfolkwDHmtcYbv1Z1Mbl1IpDULgCiSKYl543RbxCEoLjgk7Ha7h DwuvUjl9xwY/vNSll75rKGLeCxbL/gcCbOrkBqWfA5ayRHk9tmlqbHKmUfK2hjU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8ASnYQ04JSVsEms5ceNMnDuVguI=; b=LThNkzVzvJh esIX6uELWZZlssotOrtvtzyfz59oL9hNZUaCzpv71qFsKk+bczbPr3Wesl6OMtpz O7MtJvE0s51v2i+aWGSwegHICxPln3wrnGganMJyfiO6P3XTaUAAAuyfZBk2AtXw nMVkTd9Gx7hdnF8yEH7EisE2k7qo/dAI= Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id AF63C202022 for ; Wed, 6 Jul 2011 09:28:55 -0700 (PDT) Received: by iye7 with SMTP id 7so92390iye.31 for ; Wed, 06 Jul 2011 09:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.2 with SMTP id g2mr3623069pbo.253.1309969734755; Wed, 06 Jul 2011 09:28:54 -0700 (PDT) Received: by 10.68.50.231 with HTTP; Wed, 6 Jul 2011 09:28:54 -0700 (PDT) In-Reply-To: <20110706154122.GI25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> Date: Wed, 6 Jul 2011 11:28:54 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 16:28:58 -0000 On Wed, Jul 6, 2011 at 10:41 AM, Tim wro= te: >> > =C2=A0A. Authenticity of this new origin mechanism, because in the pas= t, it >> > =C2=A0 =C2=A0was possible to forge the Referer header with Flash* >> >> So... every time some implementor screws up we need to introduce a new >> thing instead of saying "just upgrade already"? >> >> I don't see how this approach scales. > > Where is it written in any standard, IETF, W3C, or otherwise, that > client-side technologies like Flash should not allow cross-origin > specification (forgery) of HTTP headers? Some things aren't written down that should be. Figuring out which headers can be set by the script in cross-origin cases is going to be tricky, unless we say none of them can be, or unless we wrap all those headers with a prefix that the script can't avoid. > I think providing some integrity, via HTTP authentication, for > something like an Origin header is worth the expense, even though we > haven't yet thought of the next attack scenario to forge it. Sure, but the web is built on HTTPS + username&password form POSTing + cookies. HTTP authentication will not be deployed fast enough to make a dent in CSRF. > Of course that all assumes that the best fix is by providing more > information to the server so the server can prevent CSRF. Well, no, it's one approach. The other approach is for the browser to apply the local solution we've been discussing: do not follow cross-origin references in the context of authenticated sessions (which means: don't use HTTP auth and don't use cookies when following cross-origin references). >> The way I would do that is to have the server provide a list of >> trusted origins for cross-domain references. =C2=A0This could be in the >> form of a simple file at the top-level of the site, like robots.txt, >> or it could be an HTTP verb to check whether an origin is trusted to >> issue a given reference, OR, it could be a 'critical' HTTP request >> extension to convey the origin in such a way that the server will not >> execute the request unless the origin is allowed to have the deputy >> issue that request. > > Right, so the way I had envisioned it is that by default, a new HTTP > method would be restricted to same-origin unless something like CORS > was provided to allow additional origins to send it. Right, applying a CORS-like approach to cross-origin references in HTML is what I had in mind as one option. This requires no additional HTTP methods. What I have in mind is a new HTTP method(s) intended solely to add criticality such that the client can be assured that the server will not process the request unless the server understands some critical element. In this case the critical element would be the information about the origin of the reference. We'd actually have to wrap most existing HTTP methods this way. I still have no clue exactly what you had in mind regarding new HTTP method= s :) >> I'm thinking that the only way to add critical HTTP extensions must be >> through new verbs, which must be why you mention a new "ACTION" verb. >> Would you agree that what you're looking for is a critical HTTP >> extension? =C2=A0It's so much what that extension does, as that it's >> critical. > > I honestly haven't put a lot of thought into alternative ways to > achieve the same thing. =C2=A0A new HTTP method would work, for this > purpose, given that the current ways to send cross-origin requests are > pretty much restricted in browsers to GET and POST. =C2=A0Adding a new, > restricted method is an easy way to provide backward compatibility. I think it's criticality that you're looking for in your new HTTP method idea. Criticality is a well-understood concept (see RFC5280, for an example, search for "critical"). It'd be useful to at least agree that criticality is or is not of interest here. > However, a similar thing could be accomplished with a special header, > so long as it is well defined that such a header can only be sent > according to certain rules. =C2=A0I kind of get the heebee geebees when > thinking about that though, given the frequency with which I find > various injection flaws in HTTP headers. =C2=A0A new method would likely = be > less susceptible to that. The problem with criticality is that it's not enough to declare a new protocol element to be critical if *existing* implementations would ignore it. In HTTP the only critical protocol elements that I know of is the HTTP method, and the authentication method (since the web server will fail to complete authentication for an auth method it doesn't support). But I'm not re-reading the HTTP spec as I write this, so I might have missed another element. Perhaps this is why you're focused on HTTP auth and/or HTTP methods as a solution to CSRF, because you understood the need for criticality and how to get it without knowing what to call it? If we call this out explicitly then we can see what to do: leverage *existing* critical elements of HTTP. Right? Nico -- From stpeter@stpeter.im Wed Jul 6 18:25:30 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01421F89EB for ; Wed, 6 Jul 2011 18:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEQVw44QNYjk for ; Wed, 6 Jul 2011 18:25:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BCFB321F89E8 for ; Wed, 6 Jul 2011 18:25:29 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9871740F84 for ; Wed, 6 Jul 2011 19:25:34 -0600 (MDT) Message-ID: <4E150B07.6080908@stpeter.im> Date: Wed, 06 Jul 2011 19:25:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [http-auth] BoF chairs X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 01:25:30 -0000 I'm happy to announce that Mark Nottingham and Alexey Melnikov have agreed to chair the BoF in Quebec City. If you would like to make a presentation at the BoF (e.g., an analysis of the problem space or a history of thinking about the topic), please contact Mark and Alexey directly or post to the list. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Fri Jul 8 08:51:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1C021F87C6 for ; Fri, 8 Jul 2011 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRJ0YkXl8hjy for ; Fri, 8 Jul 2011 08:51:50 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 206CB21F87C2 for ; Fri, 8 Jul 2011 08:51:47 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (unknown [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 909BD40FFF for ; Fri, 8 Jul 2011 09:51:56 -0600 (MDT) Message-ID: <4E172791.9000609@stpeter.im> Date: Fri, 08 Jul 2011 09:51:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:51:51 -0000 And now a word from your sponsor... :) I think it would be productive to chat about the goals of this BoF. As I see it, the primary and perhaps only goal is to come to a common understanding of the problem space so we can figure out if we might be able to scope important and realistic work in the future. The goal is not to discuss the technical details of Technology X or the relative merits of Technology X and Technology Y. It makes little sense to have presentations along the lines of "I can fix this with Technology Z" if we don't yet know what "this" is. Therefore, I'd like to see discussion about topics like these: - real-world problems with existing HTTP authentication methods, important features that such methods don't provide, etc. - lessons learned from non-HTTP authentication mechanisms (e.g., SASL) and how they might apply to the web - pain points currently being experienced those who use and deploy different kinds of web-based applications (as Jeff Hodges points out, "the web" consists of many different kinds of applications) - challenges to adoption of whatever new HTTP authentication method we might develop (e.g., mobile devices), types of web applications that might become early adopters (e.g., online payment systems), etc. - what's the killer app for improved HTTP authentication methods? Feel free to add to the foregoing list so we make sure that we're asking the right questions. And if you are able to make a presentation that will help us all clarify the problem, then by all means please contact the chairs. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From yutaka-oiwa-aist-temp@g.oiwa.jp Fri Jul 8 08:54:59 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA91021F8B51 for ; Fri, 8 Jul 2011 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV0xL0WT+d67 for ; Fri, 8 Jul 2011 08:54:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22D6721F8B40 for ; Fri, 8 Jul 2011 08:54:58 -0700 (PDT) Received: by gxk19 with SMTP id 19so350085gxk.31 for ; Fri, 08 Jul 2011 08:54:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.188.3 with SMTP id l3mr2062591ybf.352.1310140495423; Fri, 08 Jul 2011 08:54:55 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.107.17 with HTTP; Fri, 8 Jul 2011 08:54:55 -0700 (PDT) In-Reply-To: <4E150B07.6080908@stpeter.im> References: <4E150B07.6080908@stpeter.im> Date: Sat, 9 Jul 2011 00:54:55 +0900 X-Google-Sender-Auth: DWUUSMILnUuMUMaLh5hB_Atwu5s Message-ID: From: Yutaka OIWA To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF chairs X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 15:54:59 -0000 Very happy to hear it, and thank you very much for both cochairs! By the way, I'd like to explain about our current problem statements document to collect inputs for further improvements. Yutaka 2011/7/7 Peter Saint-Andre : > I'm happy to announce that Mark Nottingham and Alexey Melnikov have > agreed to chair the BoF in Quebec City. If you would like to make a > presentation at the BoF (e.g., an analysis of the problem space or a > history of thinking about the topic), please contact Mark and Alexey > directly or post to the list. > > Thanks! > > Peter From julian.reschke@gmx.de Fri Jul 8 09:09:07 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD32D21F8B7A for ; Fri, 8 Jul 2011 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.952 X-Spam-Level: X-Spam-Status: No, score=-104.952 tagged_above=-999 required=5 tests=[AWL=-2.353, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFTy-jdfsPGm for ; Fri, 8 Jul 2011 09:09:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C270221F8B59 for ; Fri, 8 Jul 2011 09:09:06 -0700 (PDT) Received: (qmail invoked by alias); 08 Jul 2011 16:09:04 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 08 Jul 2011 18:09:04 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+PbotO/3+PLpjlOm4ZjXrqr2yIIKYzTHO9wvaZVo HqvtJNHjiT9xtQ Message-ID: <4E172B9E.4010501@gmx.de> Date: Fri, 08 Jul 2011 18:09:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E172791.9000609@stpeter.im> In-Reply-To: <4E172791.9000609@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:09:07 -0000 On 2011-07-08 17:51, Peter Saint-Andre wrote: > And now a word from your sponsor... :) > > I think it would be productive to chat about the goals of this BoF. > > As I see it, the primary and perhaps only goal is to come to a common > understanding of the problem space so we can figure out if we might be > able to scope important and realistic work in the future. The goal is > not to discuss the technical details of Technology X or the relative > merits of Technology X and Technology Y. It makes little sense to have > presentations along the lines of "I can fix this with Technology Z" if > we don't yet know what "this" is. > > Therefore, I'd like to see discussion about topics like these: > > - real-world problems with existing HTTP authentication methods, > important features that such methods don't provide, etc. Web sites want to style the password entry screen. Web sites want to provide a "logout" button. > - lessons learned from non-HTTP authentication mechanisms (e.g., SASL) > and how they might apply to the web > > - pain points currently being experienced those who use and deploy > different kinds of web-based applications (as Jeff Hodges points out, > "the web" consists of many different kinds of applications) > > - challenges to adoption of whatever new HTTP authentication method we > might develop (e.g., mobile devices), types of web applications that > might become early adopters (e.g., online payment systems), etc. Broken UA behavior when they get challenges for both new and old authentication schemes. > - what's the killer app for improved HTTP authentication methods? For me: integrate what web sites do today, thus form-based authentication with cookies, so that sites can use the same authentication for browsers and programmatic clients. (-> ) > ... Best regards, Julian From tim-research@sentinelchicken.org Sun Jul 10 13:20:44 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7035221F877B for ; Sun, 10 Jul 2011 13:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNPeEy338SEz for ; Sun, 10 Jul 2011 13:20:43 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09EAD21F8776 for ; Sun, 10 Jul 2011 13:20:37 -0700 (PDT) Received: (qmail 16698 invoked from network); 10 Jul 2011 20:20:36 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Jul 2011 20:20:36 -0000 Received: (qmail 24935 invoked from network); 10 Jul 2011 20:19:50 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 10 Jul 2011 20:19:50 -0000 Received: (nullmailer pid 20146 invoked by uid 1000); Sun, 10 Jul 2011 20:20:35 -0000 Date: Sun, 10 Jul 2011 13:20:35 -0700 From: Tim To: Nico Williams Message-ID: <20110710202035.GS25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 20:20:44 -0000 Hi Nico, Sorry for the slow reply. Busy busy. > Sure, but the web is built on HTTPS + username&password form POSTing + > cookies. HTTP authentication will not be deployed fast enough to make > a dent in CSRF. Well, let's see, we've know about CSRF for about a decade. We've known about XSS for over a decade. Security people have been trying to help people fix both for almost that long, and yet 3/4s of applications I look at are vulnerable to CSRF. Maybe 2/3rds have XSS. Offering a drop-in solution to CSRF would create a strong incentive to adopt a new security technology. > >> The way I would do that is to have the server provide a list of > >> trusted origins for cross-domain references.  This could be in the > >> form of a simple file at the top-level of the site, like robots.txt, > >> or it could be an HTTP verb to check whether an origin is trusted to > >> issue a given reference, OR, it could be a 'critical' HTTP request > >> extension to convey the origin in such a way that the server will not > >> execute the request unless the origin is allowed to have the deputy > >> issue that request. > > > > Right, so the way I had envisioned it is that by default, a new HTTP > > method would be restricted to same-origin unless something like CORS > > was provided to allow additional origins to send it. > > Right, applying a CORS-like approach to cross-origin references in > HTML is what I had in mind as one option. This requires no additional > HTTP methods. But you can't just go back and add a restriction on existing uses of cross-origin access. Consistent deployment, for the purposes of security, will just be unworkable. Examples of this approach for "upgrading" security that have fallen flat on their face: - Secure cookie flag - STARTTLS - Multiple HTTP authentication methods offered at once All are vulnerable to downgrade attacks or are frequently not used because the desired support for legacy usage. We would be much better off, from a security standpoint, to offer a new mode for making requests that is restricted by default. > The problem with criticality is that it's not enough to declare a new > protocol element to be critical if *existing* implementations would > ignore it. Right, very good point. > In HTTP the only critical protocol elements that I know of > is the HTTP method, and the authentication method (since the web > server will fail to complete authentication for an auth method it > doesn't support). Unfortunately, many web applications don't actually check the request method, even though it may be considered critical (or equivalent) in the RFC. But still, it is easy enough to identify the lack of method validation and adding that validation is for web developers than asking them to implement crypto token systems. > But I'm not re-reading the HTTP spec as I write > this, so I might have missed another element. Perhaps this is why > you're focused on HTTP auth and/or HTTP methods as a solution to CSRF, > because you understood the need for criticality and how to get it > without knowing what to call it? Well, I guess I was mostly focused on the method since that fits the idea of what we're doing. Originally, POST requests were intended for sending information to servers whereas GET were supposed to be strictly for retrieving. This distinction has become fully blurred in modern web applications, partly because the HTTP definitions of these weren't strict or enforced. Also, this probably came about because GET and POST offer different modes of sending data to the server that you may want for different use cases: GET is limited in data size, but bookmarkable; POST is useful even without state change if you don't want users to bookmark parameters, etc. So in my mind, what we need is a narrower definition of what POST allows, with the original implied state-change transaction, but restricted to specific sending origins. > If we call this out explicitly then we can see what to do: leverage > *existing* critical elements of HTTP. Right? Perhaps another way to attempt to achieve criticality would be to define a separate content-type of parameters in an ACTION(/PUT) body. Web servers that don't understand the method might be tempted to treat those requests as POSTs, and but then would fail if the body isn't formatted in a way they expect. In any case, the body content-type does seem to be a critical element. tim From tim-research@sentinelchicken.org Sun Jul 10 16:36:11 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2D121F877A for ; Sun, 10 Jul 2011 16:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyDYq51+1yNg for ; Sun, 10 Jul 2011 16:36:10 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADFC21F874D for ; Sun, 10 Jul 2011 16:36:10 -0700 (PDT) Received: (qmail 17984 invoked from network); 10 Jul 2011 23:36:09 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Jul 2011 23:36:09 -0000 Received: (qmail 27584 invoked from network); 10 Jul 2011 23:35:23 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 10 Jul 2011 23:35:23 -0000 Received: (nullmailer pid 2036 invoked by uid 1000); Sun, 10 Jul 2011 23:36:18 -0000 Date: Sun, 10 Jul 2011 16:36:18 -0700 From: Tim To: Julian Reschke Message-ID: <20110710233618.GA1848@sentinelchicken.org> References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E172B9E.4010501@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 23:36:11 -0000 > >Therefore, I'd like to see discussion about topics like these: > > > >- real-world problems with existing HTTP authentication methods, > >important features that such methods don't provide, etc. > > Web sites want to style the password entry screen. Yes, with the caveat that: by providing a customizable login screen, you almost certainly leave your users open to phishing. Ideally, a new protocol should allow for both customizable login screens for sites that don't care about phishing, and "chrome"-based ones that behave somewhat like current HTTP auth ones do. The techniques I've described in the past allow for this. > Web sites want to provide a "logout" button. Yes, definitely. > Broken UA behavior when they get challenges for both new and old > authentication schemes. Yes! Downgrade attacks seem to be possible on nearly every TLS-related standard that comes out (STARTTLS, HTTP/HTTPS sslstrip attacks, etc). I'm not sure why so many standards efforts haven't bothered to address this most important security aspect of backward compatibility. > >- what's the killer app for improved HTTP authentication methods? > > For me: integrate what web sites do today, thus form-based > authentication with cookies, so that sites can use the same > authentication for browsers and programmatic clients. (-> > ) Instead of trying to throw good time and money after bad, I'd personnally prefer us: - Provide guidance for popular web frameworks how to track user sessions just like they are tracked today within their APIs. That is, make it easy for J2EE, .NET, PHP, etc, frameworks to provide better authentication "under the hood" without changing anything on web developers and users. - Work with browser vendors to get the new protocol implemented correctly with full features in all of them. Provide testing tools and other ways to minimize the implementation effort. Too many good standards don't get adopted, and I think it is in large part to a lack of follow-through in these areas. tim From ynir@checkpoint.com Sun Jul 10 21:10:38 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50921F85F8 for ; Sun, 10 Jul 2011 21:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.708 X-Spam-Level: X-Spam-Status: No, score=-10.708 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNSJWEU8MxxR for ; Sun, 10 Jul 2011 21:10:37 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F152D21F85F3 for ; Sun, 10 Jul 2011 21:10:36 -0700 (PDT) X-CheckPoint: {4E1A8574-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6B4AW14032563; Mon, 11 Jul 2011 07:10:32 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 11 Jul 2011 07:10:32 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 11 Jul 2011 07:10:31 +0300 From: Yoav Nir To: Tim Date: Mon, 11 Jul 2011 07:10:30 +0300 Thread-Topic: [http-auth] BoF goals Thread-Index: Acw/gHl3GS3pja0oQaaSTQl0qBdP2g== Message-ID: References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> <20110710233618.GA1848@sentinelchicken.org> In-Reply-To: <20110710233618.GA1848@sentinelchicken.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 04:10:38 -0000 On Jul 11, 2011, at 2:36 AM, Tim wrote: >>> Therefore, I'd like to see discussion about topics like these: >>>=20 >>> - real-world problems with existing HTTP authentication methods, >>> important features that such methods don't provide, etc. >>=20 >> Web sites want to style the password entry screen. >=20 > Yes, with the caveat that: by providing a customizable login screen, > you almost certainly leave your users open to phishing. =20 >=20 > Ideally, a new protocol should allow for both customizable login > screens for sites that don't care about phishing, and "chrome"-based > ones that behave somewhat like current HTTP auth ones do. The > techniques I've described in the past allow for this. I don't agree that you can't have both. Today, if I explicitly enter the UR= L for a site with Basic Auth, I still see the previous site or a blank scre= en behind a dialog box that says "To view this page, you must log in to are= a "www.example.com" on www.example.com:80 and asks for my name and password= . It may be enough that the username and password fields are in a special pla= ce that's not accessible to the web designer, as long as the web designer c= an do whatever HTML will allow on the canvas. I don't believe that Google h= ave to have the gmail login on the right side of the canvas. As long as the= y can make a "corporate" page, it's OK if the text fields are somewhere els= e. Something like the MutualAuth demo on Firefox could work for getting bot= h customizability and security. These are, of course, only my guesses. I wish we could hear from web design= ers whether this would be acceptable.= From yutaka-oiwa-aist-temp@g.oiwa.jp Mon Jul 11 03:00:59 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2321F87B6 for ; Mon, 11 Jul 2011 03:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipQNMAFKr-ht for ; Mon, 11 Jul 2011 03:00:59 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 028B021F8611 for ; Mon, 11 Jul 2011 03:00:58 -0700 (PDT) Received: by ywp31 with SMTP id 31so972564ywp.31 for ; Mon, 11 Jul 2011 03:00:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.21.6 with SMTP id y6mr3615961ybi.295.1310378458306; Mon, 11 Jul 2011 03:00:58 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.107.17 with HTTP; Mon, 11 Jul 2011 03:00:58 -0700 (PDT) In-Reply-To: References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> <20110710233618.GA1848@sentinelchicken.org> Date: Mon, 11 Jul 2011 19:00:58 +0900 X-Google-Sender-Auth: EfD096O7cjcDes9VHgJVMaFcYVo Message-ID: From: Yutaka OIWA To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 10:00:59 -0000 2011/7/11 Yoav Nir : > It may be enough that the username and password fields are in a special p= lace that's not accessible to the web designer, as long as the web designer= can do whatever HTML will allow on the canvas. I don't believe that Google= have to have the gmail login on the right side of the canvas. As long as t= hey can make a "corporate" page, it's OK if the text fields are somewhere e= lse. Something like the MutualAuth demo on Firefox could work for getting b= oth customizability and security. +1 I think there are actually two aspects of needs for UI customizability in log-on screen: visual design and functionality. For visual design, I believe that Web designers can (or, will have to) give up the "current" design for future, if we have either a good reason or a better alternative; the latter will be a win-win solution if possible. The set of our MutualAuth UI proposal and demo is one of (visually-ugly, quickly-made) proposals for possible future (*0), leaving Web designers to customize whatever in canvas. Another support for this direction is that browser vendors are currently trying to take ID management in their hands, using password/ID managers and browser-frame automatic handling; that will anyway take away from Web designers their control of visual designs. If they find some point of compromise, it can be applied to future HTTP-based secure authentications, too. On the other hand, I think that functionalities are unforgivable requirements for the Web system designers. They can't cope with current modal (locking) design of authentication behavior (*1), they really require log-out and timeout for visitors' security, they may need centralized log-in/log-out page for user accounting, and most of them need guest user support, etc. etc. I want and am going to investigate the precise set of such requirements, hopefully with all of IETF protocol designers, browser designers and Web designers. A partial answer of mine is included in our draft as an "HTTP auth control header", and I really appreciate to have feedbacks on that section of the draft (*2). *0: We hope browser designers in future for inventing more beautiful visual design in their products :-) *1: HTTP spec does not strictly require such semantics, though. *2: No cryptographic knowledge is required to read that section! :-) :-) Yutaka From dsr@w3.org Mon Jul 11 06:11:13 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3A21F8A66 for ; Mon, 11 Jul 2011 06:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52R7-KrzSdTl for ; Mon, 11 Jul 2011 06:11:12 -0700 (PDT) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3803F21F86A2 for ; Mon, 11 Jul 2011 06:11:12 -0700 (PDT) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.41]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QgGGK-0004im-Mx; Mon, 11 Jul 2011 13:11:00 +0000 Message-ID: <4E1AF662.5040200@w3.org> Date: Mon, 11 Jul 2011 14:10:58 +0100 From: Dave Raggett User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yoav Nir References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> <20110710233618.GA1848@sentinelchicken.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:11:13 -0000 We should aim to remove the need for users to type their user name and password into web page forms altogether. At the same time we should include anti-phishing measures such as mutual authentication, and privacy friendly authentication based upon zero knowledge proofs. It is unclear that this needs to be integrated as part of HTTP or layered above. I am involved in work on experimenting with these ideas as part of the Eurpean "webinos" project, see http://webinos.org On 11/07/11 05:10, Yoav Nir wrote: > On Jul 11, 2011, at 2:36 AM, Tim wrote: > >>>> Therefore, I'd like to see discussion about topics like these: >>>> >>>> - real-world problems with existing HTTP authentication methods, >>>> important features that such methods don't provide, etc. >>> Web sites want to style the password entry screen. >> Yes, with the caveat that: by providing a customizable login screen, >> you almost certainly leave your users open to phishing. >> >> Ideally, a new protocol should allow for both customizable login >> screens for sites that don't care about phishing, and "chrome"-based >> ones that behave somewhat like current HTTP auth ones do. The >> techniques I've described in the past allow for this. > I don't agree that you can't have both. Today, if I explicitly enter the URL for a site with Basic Auth, I still see the previous site or a blank screen behind a dialog box that says "To view this page, you must log in to area "www.example.com" on www.example.com:80 and asks for my name and password. > > It may be enough that the username and password fields are in a special place that's not accessible to the web designer, as long as the web designer can do whatever HTML will allow on the canvas. I don't believe that Google have to have the gmail login on the right side of the canvas. As long as they can make a "corporate" page, it's OK if the text fields are somewhere else. Something like the MutualAuth demo on Firefox could work for getting both customizability and security. > > These are, of course, only my guesses. I wish we could hear from web designers whether this would be acceptable. -- Dave Raggett http://www.w3.org/People/Raggett From nico@cryptonector.com Mon Jul 11 09:37:52 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AF411E80E2 for ; Mon, 11 Jul 2011 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7bKfbhWQtkf for ; Mon, 11 Jul 2011 09:37:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0244D11E80AF for ; Mon, 11 Jul 2011 09:37:52 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 7AB22438080 for ; Mon, 11 Jul 2011 09:37:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=QtD0s4bUAnCBE9Jqm3X7R2+zivHw8SfYahD4M6ZFN1Fk 1zH+RpZu46HP7Yv5IOWyp5qI8WpVjcBaDJwgwGZfVfU8bcrtHd2wZs25NLya9Ef6 mZUPlLTnjrbBOASP7Juy+jrwiTX8m1kL6sdPTGNMCSUU1Kkaxg+fBoCRxvBa/yA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=AZdMjLz2IgROyAq0RwFt3bEnHLg=; b=lYMqeP4BN2t uo2ea3GBC0DQ8p+1+UvC0M4Nf6spF4HfCPt+vxeRebOx53Gn9tcFkvxWP2NUKm1l S9IhNzD7ChFVOFIqe45AMzTNExcQ9mChKiivxLds9a6WEnbnZmATq+2Sw2vjWdJx RZEWRSjYUtlnf/NSqOoMy8vGW8JRzGFY= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 39E42438072 for ; Mon, 11 Jul 2011 09:37:51 -0700 (PDT) Received: by pvh18 with SMTP id 18so4203836pvh.31 for ; Mon, 11 Jul 2011 09:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.36 with SMTP id e4mr7371424pbj.320.1310402270639; Mon, 11 Jul 2011 09:37:50 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Mon, 11 Jul 2011 09:37:50 -0700 (PDT) In-Reply-To: <20110710202035.GS25355@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> Date: Mon, 11 Jul 2011 11:37:50 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:37:53 -0000 On Sun, Jul 10, 2011 at 3:20 PM, Tim wro= te: >> Sure, but the web is built on HTTPS + username&password form POSTing + >> cookies. =C2=A0HTTP authentication will not be deployed fast enough to m= ake >> a dent in CSRF. > > Well, let's see, we've know about CSRF for about a decade. =C2=A0We've > known about XSS for over a decade. =C2=A0Security people have been trying > to help people fix both for almost that long, and yet 3/4s of > applications I look at are vulnerable to CSRF. =C2=A0Maybe 2/3rds have XS= S. > > Offering a drop-in solution to CSRF would create a strong incentive to > adopt a new security technology. Look, I've nothing against what you propose as one alternative. But your proposal requires changes all around. Whereas one of the counter-proposals I made to yours requires only browser changes, not changes to how every site does authentication, nor any change to user credentials. This is important because changes to how we do authentication will take a long time to push out, whereas changes to browsers are much speedier thanks to automatic updates. Sure, some stubborn users (and IT departments who have legacy reasons for staying with old browsers) take a long time to upgrade, but they wouldn't be helped by your proposal either. >> Right, applying a CORS-like approach to cross-origin references in >> HTML is what I had in mind as one option. =C2=A0This requires no additio= nal >> HTTP methods. > > But you can't just go back and add a restriction on existing uses of > cross-origin access. =C2=A0Consistent deployment, for the purposes of > security, will just be unworkable. I think you can. The cross-origin restriction can be implemented in the browser or the services, and all it means is that cross-origin references that should be disallowed can only be evaluated outside the context of any authenticated sessions (i.e., anonymously). What's the problem with that? > We would be much better off, from a security standpoint, to offer a > new mode for making requests that is restricted by default. Which will take forever and a half to deploy. >> The problem with criticality is that it's not enough to declare a new >> protocol element to be critical if *existing* implementations would >> ignore it. > > Right, very good point. It's nothing new... We've faced this problem in Kerberos and PKIX before (and SSHv2, and...). It's important to always leave some sort of critical field somewhere, and preferably in all directions. >> In HTTP the only critical protocol elements that I know of >> is the HTTP method, and the authentication method (since the web >> server will fail to complete authentication for an auth method it >> doesn't support). > > Unfortunately, many web applications don't actually check the request > method, even though it may be considered critical (or equivalent) in > the RFC. =C2=A0But still, it is easy enough to identify the lack of metho= d > validation and adding that validation is for web developers than > asking them to implement crypto token systems. Surely web servers and applications do not treat GET and POST as synonyms -- otherwise the offenders would be famous for the offense. Also, presumably all web servers and applications fail to handle unknown HTTP methods as synonyms for some other existing method. If some small number of servers get this wrong, no sweat, but if a huge proportion of them get this wrong then there's nothing we can do on this end. >> But I'm not re-reading the HTTP spec as I write >> this, so I might have missed another element. =C2=A0Perhaps this is why >> you're focused on HTTP auth and/or HTTP methods as a solution to CSRF, >> because you understood the need for criticality and how to get it >> without knowing what to call it? > > Well, I guess I was mostly focused on the method since that fits the > idea of what we're doing. =C2=A0Originally, POST requests were intended f= or > [...] I'd like you to be more specific. Were you or were you not, consciously or otherwise, looking for some HTTP criticality mechanism? Or, now that we have the criticality concept clarified, is this what you're looking for? >> If we call this out explicitly then we can see what to do: leverage >> *existing* critical elements of HTTP. =C2=A0Right? > > Perhaps another way to attempt to achieve criticality would be to > define a separate content-type of parameters in an ACTION(/PUT) body. Ah, good one! I'd prefer a new method though, as otherwise we'd begin to explode the set of content-types, and I don't want to go down that road without a really good reason. > Web servers that don't understand the method might be tempted to treat > those requests as POSTs, and but then would fail if the body isn't > formatted in a way they expect. =C2=A0In any case, the body content-type > does seem to be a critical element. We could use both, in a pinch. I seriously doubt there exist web servers that mishandle unknown HTTP methods. Nico -- From nico@cryptonector.com Mon Jul 11 09:44:24 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEE111E80FB for ; Mon, 11 Jul 2011 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIBcbByJ9QNr for ; Mon, 11 Jul 2011 09:44:23 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 39DA411E80F3 for ; Mon, 11 Jul 2011 09:44:22 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 674E243807F for ; Mon, 11 Jul 2011 09:44:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Ep+oIL6JrZx+ESxAk6XWU T7sxgcB4jwkX/8hYLXR5CG9GTdZuWU6kaMHRvk9el1KwyhYGrVtZUXx4VntuRHJs rRk3WkUP45WemLi6M5OJlqsPjlFC+qgHhZ0oklP3+7WLVpbo1RbkEOk1Jc1gJL6k rWi1NNDN8w3yR0dPXNRX9o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=s41bpxzcuK7QqZH4xk2+ F9N0t9A=; b=qnDofluzUOa0ZTIPPDtlveLcKlj6W9qRhY4vyU1ccoLXuFQVseDa +49ceV6HW8nZz9Ilgw369eND+Yk0cQh0BuQ8bp7jvxaFsMaCgSMLyfbBKg+5wDSd NDbvVMOFBisuLkqlJJCrKFbNBOqxX91+c40KR/FlpHwpNTGGw2CmEUo= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 308B443807E for ; Mon, 11 Jul 2011 09:44:19 -0700 (PDT) Received: by pvh18 with SMTP id 18so4209951pvh.31 for ; Mon, 11 Jul 2011 09:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.2 with SMTP id g2mr7654829pbo.253.1310402659604; Mon, 11 Jul 2011 09:44:19 -0700 (PDT) Received: by 10.68.41.103 with HTTP; Mon, 11 Jul 2011 09:44:19 -0700 (PDT) In-Reply-To: References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> <20110710233618.GA1848@sentinelchicken.org> Date: Mon, 11 Jul 2011 11:44:19 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:44:24 -0000 On Sun, Jul 10, 2011 at 11:10 PM, Yoav Nir wrote: > On Jul 11, 2011, at 2:36 AM, Tim wrote: >>> Web sites want to style the password entry screen. >> >> Yes, with the caveat that: by providing a customizable login screen, >> you almost certainly leave your users open to phishing. I believe it should be possible to provide some customization, but the key is to make sure that users do NOT type passwords into a field that is available to an untrusted element (downloaded script, script embedded in the HTML, or a remote service). This kinda means that any would-be echo-off text input fields (or even echo-on password fields) need to be in the browser chrome, and that we need to educate users to not enter any text into non-chrome echo-off fields (we can ban such fields, but scripts could still emulate them). My proposal[0] is for a DOM "login" button. Sites could be allowed to prompt for a username, though this has unpalatable (to me) privacy implications that I could live with if it were the price of having decent web authentication. [0] http://www.w3.org/2011/identity-ws/slides/Williams.pdf Nico -- From tim-research@sentinelchicken.org Tue Jul 12 20:54:25 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC321F8B1D for ; Tue, 12 Jul 2011 20:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpFO5HS+kugI for ; Tue, 12 Jul 2011 20:54:24 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 322B521F8B14 for ; Tue, 12 Jul 2011 20:54:23 -0700 (PDT) Received: (qmail 10661 invoked from network); 13 Jul 2011 03:54:21 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Jul 2011 03:54:21 -0000 Received: (qmail 24992 invoked from network); 13 Jul 2011 03:53:26 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 13 Jul 2011 03:53:26 -0000 Received: (nullmailer pid 11321 invoked by uid 1000); Wed, 13 Jul 2011 03:54:20 -0000 Date: Tue, 12 Jul 2011 20:54:20 -0700 From: Tim To: Nico Williams Message-ID: <20110713035420.GQ1848@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 03:54:25 -0000 Nico, > > But you can't just go back and add a restriction on existing uses of > > cross-origin access.  Consistent deployment, for the purposes of > > security, will just be unworkable. > > I think you can. The cross-origin restriction can be implemented in > the browser or the services, and all it means is that cross-origin > references that should be disallowed can only be evaluated outside the > context of any authenticated sessions (i.e., anonymously). What's the > problem with that? The way I understand what you are proposing (and I could be mistaken), will likely cause existing applications to break. Web application developers abuse HTTP behavior in all *kinds* ways. Let me just assert this: If you propose a change to existing cross-origin behavior for browsers which: A. Breaks even a small percentage of existing applications. B. Requires any changes at all for non-broken applications to benefit from the new security protections Then you're in a catch-22 and it will never be deployed. Application developers won't bother to implement it until browsers support it and browsers won't support it until very few sites will break and lots of sites will benefit from it. This may or may not be what you're proposing. >From what you are saying, I have a problem with: "can only be evaluated outside the context of any authenticated sessions". The problem is, browsers don't currently have a way to know what an authenticated session is. Cookies are used for many things, some intended for cross-origin use. If you're intending your statement to apply only in HTTP authentication scenarios, then maybe that is workable... > > We would be much better off, from a security standpoint, to offer a > > new mode for making requests that is restricted by default. > > Which will take forever and a half to deploy. I disagree. All that it takes is for browsers to add support for the new restricted method (the hard part). Browsers wouldn't even need to implement CORS right away. This breaks nothing. Then the difficulty of fixing CSRF for developers becomes trivial: change a few HTML pages (method="POST" -> method="ACTION") and validate that this method is used server-side for sensitive pages. This is far easier than making developers invent a cryptographic protocol to protect themselves and it is even easier than expecting them to correctly parse an origin header (you'd be surprised at how easily they could screw this up). Note that for a significant portion of sensitive applications that I personally test (over half of them, at least), something like CORS for the new method wouldn't be a requirement. The details of an optional permissive mechanism could be worked out later. > > Unfortunately, many web applications don't actually check the request > > method, even though it may be considered critical (or equivalent) in > > the RFC.  But still, it is easy enough to identify the lack of method > > validation and adding that validation is for web developers than > > asking them to implement crypto token systems. > > Surely web servers and applications do not treat GET and POST as > synonyms -- otherwise the offenders would be famous for the offense. Yes, actually they do. The only difference being where they draw parameters from. Most modern web frameworks merge the variable name space for each of these request types (e.g. POST parameters and URL parameters in the same request get merged into one name space). They've been doing this for a decade at least. In most applications I test, one can easily convert a POST request in to a GET request and vice versa. If parameters are in the URL in both cases, there's effectively no difference in how they are handled. > Also, presumably all web servers and applications fail to handle > unknown HTTP methods as synonyms for some other existing method. Most application servers do check to make sure it is at least a GET, POST, or HEAD, etc, but some popular frameworks don't even bother to do that. > If > some small number of servers get this wrong, no sweat, but if a huge > proportion of them get this wrong then there's nothing we can do on > this end. Agreed, we can't account for application servers that don't even bother to enforce a set of valid methods. In the case of the ACTION approach, it doesn't matter either way. When a developer is ready to use it, they add it both in the pages that initiate requests and validate it upon receiving a request. > I'd like you to be more specific. Were you or were you not, > consciously or otherwise, looking for some HTTP criticality mechanism? > Or, now that we have the criticality concept clarified, is this what > you're looking for? I suppose so, but I won't testify to it, because I'm not sure how critical the method really is, based on real-world server implementations. It must be an element that browser can easily recognize and then initiate the cross-origin checking logic. This is most easily added to an element that is already sent in every request and can be controlled by developers initiating requests. Requiring it to be some special header that is added by developers in XHR requests is restrictive, since classic HTML can't benefit from it. > Ah, good one! I'd prefer a new method though, as otherwise we'd begin > to explode the set of content-types, and I don't want to go down that > road without a really good reason. Yeah, I agree. Here's another alternative that is effectively uses a critical element: Change URL syntax. Add a prefix/suffix/something to URL syntax that indicates to browsers that the request should follow restricted rules. Either a prefix before the first "/" that is pretty distinguishable (consider the special OPTION * HTTP/... syntax) or something similar to the "#..." syntax, but is instead carried on to the recipient. This might be harder to deploy though, since many web servers might validate URL syntax even more carefully than methods, depending on how you add the new syntax. In the web servers I know, methods are something that can be flexibly configured. A lot of applications are already using every ASCII character in the book already in their URLs, so backward compatibility would be more of an issue if it is used at the end. Just trying to brainstorm other ways to support even the most basic use cases (HTML forms). > We could use both, in a pinch. I seriously doubt there exist web > servers that mishandle unknown HTTP methods. Hahaha, if you only knew... But it doesn't really matter, since those sites/applications that do mishandle a new method right now are either vulnerable to CSRF now (and will be with a new method that isn't validated) or are protected by crypto cookies or referrer checks (and will continue to be protected if a new method isn't validated). tim From tim-research@sentinelchicken.org Wed Jul 13 08:22:17 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2B21F879F for ; Wed, 13 Jul 2011 08:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrC2lYJs2SAh for ; Wed, 13 Jul 2011 08:22:12 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B52611E811A for ; Wed, 13 Jul 2011 08:22:04 -0700 (PDT) Received: (qmail 15395 invoked from network); 13 Jul 2011 15:22:02 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Jul 2011 15:22:02 -0000 Received: (qmail 8790 invoked from network); 13 Jul 2011 15:21:06 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 13 Jul 2011 15:21:06 -0000 Received: (nullmailer pid 12992 invoked by uid 1000); Wed, 13 Jul 2011 15:22:01 -0000 Date: Wed, 13 Jul 2011 08:22:01 -0700 From: Tim To: Nico Williams Message-ID: <20110713152201.GT1848@sentinelchicken.org> References: <4E172791.9000609@stpeter.im> <4E172B9E.4010501@gmx.de> <20110710233618.GA1848@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:22:17 -0000 > I believe it should be possible to provide some customization, but the > key is to make sure that users do NOT type passwords into a field that > is available to an untrusted element (downloaded script, script > embedded in the HTML, or a remote service). This kinda means that any > would-be echo-off text input fields (or even echo-on password fields) > need to be in the browser chrome, and that we need to educate users to > not enter any text into non-chrome echo-off fields (we can ban such > fields, but scripts could still emulate them). Yeah, whatever it is, it needs to be visually very distinguishable from anything one can generate in HTML. It also needs to make the origin you are authenticating to very prominent. > My proposal[0] is for a DOM "login" button. Sites could be allowed to > prompt for a username, though this has unpalatable (to me) privacy > implications that I could live with if it were the price of having > decent web authentication. HTTP authentication + XmlHttpRequest already allows for fully customizable login pages[1] (assuming a standards-compliant browser) and of course safer authentication via the browser chrome. (Assuming we can convince browser developers to improve the UI elements.) I don't *like* fully customizable login pages, but many businesses will simply require them for some time, until security people convince them to switch to something safe. To be realistic, there are many sites that accept passwords and simply don't need to worry about phishing. In any case, all of the flexibility we could want is already available through the standards-based techniques I've described in the past. This approach is fully compatible with both complex UAs (browsers) and simple UAs (web crawlers, scripts, etc). All that is left on the standards side is to use an HTTP authentication mechanism that provides good mutual authentication and a standard way for server-initiated logout. tim 1. http://vsecurity.com/download/tools/fbha-poc_0.1.zip From stephen.farrell@cs.tcd.ie Fri Jul 15 07:49:51 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D8621F87A9 for ; Fri, 15 Jul 2011 07:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVFypdu0aB9d for ; Fri, 15 Jul 2011 07:49:47 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id AD26121F874F for ; Fri, 15 Jul 2011 07:49:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E1AF1171C05; Fri, 15 Jul 2011 15:49:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1310741383; bh=LmYtQhrRyuIE5f 3a986uADwIgXatTidQXP3nrSzOlcQ=; b=jhYRuD/Y1RVdzTI/YSNiykA/N40RkL zdtZeklLhG4CijOJvgZ8Jy1ToBaKTrnFiQ4OT/M/7Wm3J4ayBiPNGzYWtZvVxtUQ /gBQvwMN4/sVjViAtE44Or+GEStUxvmEJQJekLChxaXRpZlP2vp9T4r6CkF6MbGr irp90K05P8iS7xtLDn5IgOI30AlZm5iXIsj+uNmqcLRMDj+cpFuzfotaQLmnTkaF pZn1g+cySjgig3qyc+S6Va8qhgJdNalYokz2kHBb75f6FDKKORFvCLGBpCZb315X DLOEuCWVPOFZS6bxpI15WZu5TzyUFBvMwQ+k6Z+dbjIQdlBzCngMcq5A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ZZjep-zmeu9b; Fri, 15 Jul 2011 15:49:43 +0100 (IST) Received: from [10.87.48.7] (unknown [86.44.67.117]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 749A8171C04; Fri, 15 Jul 2011 15:49:43 +0100 (IST) Message-ID: <4E205386.80800@cs.tcd.ie> Date: Fri, 15 Jul 2011 15:49:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E172791.9000609@stpeter.im> In-Reply-To: <4E172791.9000609@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 14:49:51 -0000 AD hat off: The main problem I see with which we might try to help is the need for servers to store databases of passwords that inevitably leak out sometimes. So I'd like to see us develop something that gets rid of passwords entirely if possible. I also think its pointless to develop something that won't really be deployed and used. A similar, but not identical, goal might be to reduce the overall number of passwords, but I'd be fairly skeptical of SSO approaches with a password for the initial auth. S. On 08/07/11 16:51, Peter Saint-Andre wrote: > And now a word from your sponsor... :) > > I think it would be productive to chat about the goals of this BoF. > > As I see it, the primary and perhaps only goal is to come to a common > understanding of the problem space so we can figure out if we might be > able to scope important and realistic work in the future. The goal is > not to discuss the technical details of Technology X or the relative > merits of Technology X and Technology Y. It makes little sense to have > presentations along the lines of "I can fix this with Technology Z" if > we don't yet know what "this" is. > > Therefore, I'd like to see discussion about topics like these: > > - real-world problems with existing HTTP authentication methods, > important features that such methods don't provide, etc. > > - lessons learned from non-HTTP authentication mechanisms (e.g., SASL) > and how they might apply to the web > > - pain points currently being experienced those who use and deploy > different kinds of web-based applications (as Jeff Hodges points out, > "the web" consists of many different kinds of applications) > > - challenges to adoption of whatever new HTTP authentication method we > might develop (e.g., mobile devices), types of web applications that > might become early adopters (e.g., online payment systems), etc. > > - what's the killer app for improved HTTP authentication methods? > > Feel free to add to the foregoing list so we make sure that we're asking > the right questions. > > And if you are able to make a presentation that will help us all clarify > the problem, then by all means please contact the chairs. > > Thanks! > > Peter > From nico@cryptonector.com Fri Jul 15 16:35:03 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F154D21F8A7E for ; Fri, 15 Jul 2011 16:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hEIQCGEtWPN for ; Fri, 15 Jul 2011 16:35:03 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 74ED621F8AAC for ; Fri, 15 Jul 2011 16:35:00 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 123E66B0059 for ; Fri, 15 Jul 2011 16:35:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=EbyvY1SAoDPF8aipc48pG8VDkLHDtEJhiHZYX+kds5Nw 9Ua77bU/5OmM0TnlIFnsaFV0bn70DIZ3V5D8kuPjQtAD9fbBdrlsbUplwdcA0YCr W1KGgJEGvL293VK8C4Gjrs1Xszj7flUbYFYYQeuM/0CVmA0nAT3/e4at9nMReAo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=RXdRCj64M7syNZgm93nc9klswSU=; b=lahd9JlYifc /DDdEB0bjpftYUz2ivq8h8D/xxjd/mruvPY7OaQvWTU4/IrJQO0WjbvLeVcBU7RF hXUZRCsTeH7D/Wz9kON6TU/yjmvKYAIVGQZEOi5cLiEdAQszOLPsQNXJHHns8SxO ZONdIuRAZmYs996+jfiuCiJimm3zW2rE= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 005946B0014 for ; Fri, 15 Jul 2011 16:34:59 -0700 (PDT) Received: by pzd13 with SMTP id 13so2357000pzd.39 for ; Fri, 15 Jul 2011 16:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.21.5 with SMTP id r5mr1791596pbe.39.1310772899649; Fri, 15 Jul 2011 16:34:59 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 16:34:59 -0700 (PDT) In-Reply-To: <20110713035420.GQ1848@sentinelchicken.org> References: <20110624221315.GF1542@sentinelchicken.org> <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> Date: Fri, 15 Jul 2011 18:34:59 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 23:35:04 -0000 On Tue, Jul 12, 2011 at 10:54 PM, Tim wr= ote: >> > But you can't just go back and add a restriction on existing uses of >> > cross-origin access. =C2=A0Consistent deployment, for the purposes of >> > security, will just be unworkable. >> >> I think you can. =C2=A0The cross-origin restriction can be implemented i= n >> the browser or the services, and all it means is that cross-origin >> references that should be disallowed can only be evaluated outside the >> context of any authenticated sessions (i.e., anonymously). =C2=A0What's = the >> problem with that? > > The way I understand what you are proposing (and I could be mistaken), > will likely cause existing applications to break. =C2=A0Web application > developers abuse HTTP behavior in all *kinds* ways. I get that, but this can be addressed in ways which are less expensive than yours. Namely, via something like CORS. That said, I do think we're going to have to deploy new authentication schemes so as to defeat phishing, so maybe I'm barking up the wrong tree. I just think that it will take a long time to migrate to new authentication methods but it should be possible to do something about CSRF sooner. Does NoScript do anything about this? It does turn cross-site POSTs into data-less GETs. I wonder if it could be made to load cross-site images without cookies -- that would allow us to test this. Incidentally, I do run with NoScript's CSS/ABE protection enabled and I've yet to find a site that breaks because of it. I suspect, but can't prove, that nothing much depends on cross-site image references being loaded in the context of authenticated sessions. >> > We would be much better off, from a security standpoint, to offer a >> > new mode for making requests that is restricted by default. >> >> Which will take forever and a half to deploy. > > I disagree. =C2=A0All that it takes is for browsers to add support for th= e > new restricted method (the hard part). =C2=A0Browsers wouldn't even need = to Oh no, that's not the hard part. The hard part is getting user credentials migrated. Or are you simply talking about a new method that doesn't provide strong user authentication, just strong request/session binding? That is, the OAuth hammer HMAC draft? Ah, then I think I understand where you're coming from. And yes, that might not be so hard to deploy. Nico -- From tim-research@sentinelchicken.org Fri Jul 15 16:42:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8291721F8B17 for ; Fri, 15 Jul 2011 16:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONUo70itxBs9 for ; Fri, 15 Jul 2011 16:42:50 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id E436F21F8B15 for ; Fri, 15 Jul 2011 16:42:49 -0700 (PDT) Received: (qmail 8507 invoked from network); 15 Jul 2011 23:42:46 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 15 Jul 2011 23:42:46 -0000 Received: (qmail 10041 invoked from network); 15 Jul 2011 23:41:41 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 15 Jul 2011 23:41:41 -0000 Received: (nullmailer pid 25678 invoked by uid 1000); Fri, 15 Jul 2011 23:42:45 -0000 Date: Fri, 15 Jul 2011 16:42:45 -0700 From: Tim To: Nico Williams Message-ID: <20110715234245.GC1848@sentinelchicken.org> References: <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 23:42:50 -0000 > Or are you simply talking about a new method that doesn't provide > strong user authentication, just strong request/session binding? That > is, the OAuth hammer HMAC draft? Ah, then I think I understand where > you're coming from. And yes, that might not be so hard to deploy. Correct. Almost all of my recent blathering has been solely about using a new method to prevent CSRF. Nothing to do with HTTP auth. Initially I proposed the HTTP auth-based (basically just an integrity-protected Origin header) and alluded to this other idea of an HTTP method. Then you took me down the path of browser-based validation which is in line with a new HTTP method and doesn't involve authentication. Does that clarify the last few messages? tim From nico@cryptonector.com Fri Jul 15 17:09:02 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4721F8997 for ; Fri, 15 Jul 2011 17:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.823 X-Spam-Level: X-Spam-Status: No, score=-2.823 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhefNp7swWe8 for ; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id EB36521F8987 for ; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 88DF31B4059 for ; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=keC2LYDkoKg5TrK+jiZukASTkX9iceQvBHnpduKCHe26 atqUYPnn8/ykR9P49O4mdFFh4wuwNdBDsawU/47O5e/7JYxDVn3wTKBA+H+VOUIt 4pZVya2F9uN/EFhT7mxSvRy29pccpSPwZV7HgUdBQ4uSNFwc89uFR6Q7gP03wCg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/GTUxsoxio/PaZ+CsEHbslSnWjs=; b=bPPlyfWUnwk IXhNs+WBj/n6GsxJ/4vJ9Mc7ZHkzjpoBGjEuAM/q9teIUAt7L5Qym8GIOalV2CmT vl7gUu/RBhWzDEoHc0J2Dg5RGU9BP6UTVIPQAMdo1q+yaf83CLVzB+p9vSeriiuM RQxRnwOfwxRvUTG9eoYC+KK9ocryzGWs= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 6E7FE1B4058 for ; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) Received: by pzd13 with SMTP id 13so2379739pzd.39 for ; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.21.5 with SMTP id r5mr1825899pbe.39.1310774941066; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 17:09:01 -0700 (PDT) In-Reply-To: <20110715234245.GC1848@sentinelchicken.org> References: <20110705222539.GB25355@sentinelchicken.org> <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> <20110715234245.GC1848@sentinelchicken.org> Date: Fri, 15 Jul 2011 19:09:01 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 00:09:02 -0000 On Fri, Jul 15, 2011 at 6:42 PM, Tim wro= te: >> Or are you simply talking about a new method that doesn't provide >> strong user authentication, just strong request/session binding? =C2=A0T= hat >> is, the OAuth hammer HMAC draft? =C2=A0Ah, then I think I understand whe= re >> you're coming from. =C2=A0And yes, that might not be so hard to deploy. > > Correct. =C2=A0Almost all of my recent blathering has been solely about > using a new method to prevent CSRF. =C2=A0Nothing to do with HTTP auth. > Initially I proposed the HTTP auth-based (basically just an > integrity-protected Origin header) and alluded to this other idea of > an HTTP method. > > Then you took me down the path of browser-based validation which is in > line with a new HTTP method and doesn't involve authentication. > > Does that clarify the last few messages? Sure does. It should also clarify my earlier skepticism :) I'd still like at least a way to set *my* browser to never load x-origin references with cookies (or any other form of user authentication) unless the one site specifically allows the other to make x-site references. This sounds like an interesting possibility for NoScript. Nico -- From tim-research@sentinelchicken.org Fri Jul 15 17:17:17 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE97C21F87D3 for ; Fri, 15 Jul 2011 17:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIovHCH89ELQ for ; Fri, 15 Jul 2011 17:17:17 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAAB21F8733 for ; Fri, 15 Jul 2011 17:17:17 -0700 (PDT) Received: (qmail 8651 invoked from network); 16 Jul 2011 00:17:16 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 16 Jul 2011 00:17:16 -0000 Received: (qmail 10236 invoked from network); 16 Jul 2011 00:16:11 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 16 Jul 2011 00:16:11 -0000 Received: (nullmailer pid 25798 invoked by uid 1000); Sat, 16 Jul 2011 00:17:15 -0000 Date: Fri, 15 Jul 2011 17:17:15 -0700 From: Tim To: Nico Williams Message-ID: <20110716001715.GD1848@sentinelchicken.org> References: <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> <20110715234245.GC1848@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 00:17:17 -0000 > I'd still like at least a way to set *my* browser to never load > x-origin references with cookies (or any other form of user > authentication) unless the one site specifically allows the other to > make x-site references. This sounds like an interesting possibility > for NoScript. >From a standards perspective, that idea sounds reasonable way to mitigate CSRF with HTTP authentication. Perhaps it could be slipped into a new HTTP Auth spec. I'm not sure it would be so easy with cookies. Maybe it's just because I haven't put much thought into it. At this point I think trying to fix that mode of "authentication" is a lost cause. Cheers, tim From nico@cryptonector.com Fri Jul 15 17:33:21 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5365821F8560 for ; Fri, 15 Jul 2011 17:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQgV0eFbP3aM for ; Fri, 15 Jul 2011 17:33:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id C0B3B21F8537 for ; Fri, 15 Jul 2011 17:33:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 8E47F428072 for ; Fri, 15 Jul 2011 17:33:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=A/7PmjqhnqZZUiuCmdLjyvvg1qMKDKm6zqb99jeX8gck EMd8f16dwAO8b97e+F9fLW4+aI1CvTGDmvtTxIaif8ks8CbKl0IFwUAbnhbSgsVE bBUidmRtksZUL3mxvFuJMHEbhaay25PfXl/tD4/ItceS1d5M/SuV5ZD9vevLmp0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Rg73TD0hT5v9R06VCZD3dmxt7uU=; b=BWF6AM7f6+B W/WxKCbwVQC+X4ZTMwdQAScxfWRFrr/OsuF+hVOpU7LCpehgseDpP1sB7m4DbsFt p2BNAmllGYiX6Dd5RJY93ICNaeWrRchEjrGXZdHqLnLyf79UgnfvAMrC6dPHMnS4 5uCcOEzyXW7ellm7N4XUZ3kTM5OgxrbU= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 79ED242806E for ; Fri, 15 Jul 2011 17:33:20 -0700 (PDT) Received: by pzd13 with SMTP id 13so2395066pzd.39 for ; Fri, 15 Jul 2011 17:33:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.47.102 with SMTP id c6mr5169235pbn.441.1310776399931; Fri, 15 Jul 2011 17:33:19 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 17:33:19 -0700 (PDT) In-Reply-To: <20110716001715.GD1848@sentinelchicken.org> References: <20110705235539.GG25355@sentinelchicken.org> <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> <20110715234245.GC1848@sentinelchicken.org> <20110716001715.GD1848@sentinelchicken.org> Date: Fri, 15 Jul 2011 19:33:19 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 00:33:21 -0000 On Fri, Jul 15, 2011 at 7:17 PM, Tim wro= te: >> I'd still like at least a way to set *my* browser to never load >> x-origin references with cookies (or any other form of user >> authentication) unless the one site specifically allows the other to >> make x-site references. =C2=A0This sounds like an interesting possibilit= y >> for NoScript. > > From a standards perspective, that idea sounds reasonable way to > mitigate CSRF with HTTP authentication. =C2=A0Perhaps it could be slipped > into a new HTTP Auth spec. It's not that different from what you propose. You propose server-side control. Also having a client-side control would be a useful thing to do for at least power users (cue complaints about complexity, yet who here doesn't use NoScript, complex as it is?). > I'm not sure it would be so easy with cookies. Maybe it's just because > I haven't put much thought into it. =C2=A0At this point I think trying to > fix that mode of "authentication" is a lost cause. Why not? It's a small change to the browser (compared to everything else we're talking about). I'm not trying to fix the use of cookies. Besides, I think cookies can work fine *if* you pin certs and are careful not to use "secure" cookies outside TLS [with confidentiality protection], but as with any other form of authentication you'll want to do something about CSRF. From nico@cryptonector.com Fri Jul 15 19:18:15 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B521F8761 for ; Fri, 15 Jul 2011 19:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKhZhNuPMfYZ for ; Fri, 15 Jul 2011 19:18:14 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 79A9421F873E for ; Fri, 15 Jul 2011 19:18:14 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 37A0377805B for ; Fri, 15 Jul 2011 19:18:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=HRkweCHVuEx8X7CAyAuwZ bWYHWWNBqXh7ogMvHu3w36cokgr+llErllonUt1jS0mnOy0JHiGNoGmRCdu8wHco uyafIEpkFF/j9MB6TW2Fk0c0+bwUuMra34ukPipIzzreuFVeGtoF3fwcxagaRYEE HX0QTsg3JMbWg2zKPfbujE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=UvhQEcbR+l7q2Snl1DWs T+f/fG0=; b=hW/vVczdhEJYdk86xit3Gbx/ga1Ui4ejRNgaGfzSx3ricfW9JyaR B+4XtxRqK/rknAzS1YP0YiycYuXuc6HhR3C+id5dECMC/gc7C/swUpmHRldaPxVs nzxdaSK28TZ86I4oIU/aR8Ufn2WmtD/bgzRb0q1htiOUkTR3Uy1kQd8= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 1A427778057 for ; Fri, 15 Jul 2011 19:18:14 -0700 (PDT) Received: by pvh18 with SMTP id 18so2285198pvh.31 for ; Fri, 15 Jul 2011 19:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.33 with SMTP id f1mr4903126pbq.374.1310782693653; Fri, 15 Jul 2011 19:18:13 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 19:18:13 -0700 (PDT) In-Reply-To: <4E205386.80800@cs.tcd.ie> References: <4E172791.9000609@stpeter.im> <4E205386.80800@cs.tcd.ie> Date: Fri, 15 Jul 2011 21:18:13 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] BoF goals X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 02:18:15 -0000 On Fri, Jul 15, 2011 at 9:49 AM, Stephen Farrell wrote: > The main problem I see with which we might try to help > is the need for servers to store databases of passwords > that inevitably leak out sometimes. And credit card numbers. And all sorts of personal information... I don't think this is a fully solvable problem. Using memory-hard PBKDFs (e.g., scrypt) and augmented ZKPPs would mean that only password verifiers could leak, and those would be relatively hard to attack, and leakage relatively easy to mitigate. For things like credit personal information that's not needed when the user is not logged in one option is to store it encrypted in a user-agent-side key that the site doesn't know and let the user-agent decrypt and send the plaintext to the service as necessary. (This is an interesting use for JS crypto APIs in the browser.) > So I'd like to see us develop something that gets rid of > passwords entirely if possible. Agreed. I don't think we're going to get there in one day. Augmented ZKPPs are very tempting, even if that means that password verifiers can get stolen (see comments above). Federated authentication methods where *initial* authentication (i.e., at the IdP) uses augmented ZKPPs would be even better. User certs present cert/device management headaches, but if we can address them then user certs would work too (I'm afraid that the use of online CAs or SACRED-type protocols will be part of the end-result user cert mgmt solution). > I also think its pointless to develop something that > won't really be deployed and used. For some proposals we can tell if that's likely. For others it will be harder to tell. Also, something that can work on the Internet and the enterprise would have a higher probability of success. (This is why I'm proposing a pluggable solution, because I don't think we can produce one authentication solution that will have a high likelihood of wide adoption in all these case.) > A similar, but not identical, goal might be to reduce the > overall number of passwords, but I'd be fairly skeptical > of SSO approaches with a password for the initial auth. See comments above and below about user certs. Anyone proposing the use of user certs needs to make some convincing arguments about why user certs will not devolve into an SSO approach "with a password for the initial auth" :) It helps to think of PKIX w/ OCSP (or online CAs issuing short-lived certs) as a PK-based ticketing system, not unlike a PK-version of Kerberos. It is possible to bridge multiple authentication mechanisms by looking at them this way. In fact, there's two or three kerberized online CA solutions available, (kca, kx509, and Heimdal's version of kx509). And Kerberos can use PKIX for initial auth, via PKINIT. Another way to phrase the question: will browsers or the platforms they integrate well with, resort to these bridging solutions? If so, then what's the advantage of locking us into a PKIX (but not-PKI) solution? Yes, the fact that bridging authentication methods is possible means that the choice of one method doesn't preclude use of any others, but forcing people who have one infrastructure deployed to deploy another is going to have significant costs (this has been one the main arguments for pluggable authentication). Nico -- From tim-research@sentinelchicken.org Fri Jul 15 19:47:19 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B3621F8751 for ; Fri, 15 Jul 2011 19:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHDHty9KZ5p8 for ; Fri, 15 Jul 2011 19:47:19 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9621F8725 for ; Fri, 15 Jul 2011 19:47:19 -0700 (PDT) Received: (qmail 9639 invoked from network); 16 Jul 2011 02:47:17 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 16 Jul 2011 02:47:17 -0000 Received: (qmail 14439 invoked from network); 16 Jul 2011 02:46:12 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 16 Jul 2011 02:46:12 -0000 Received: (nullmailer pid 26229 invoked by uid 1000); Sat, 16 Jul 2011 02:47:17 -0000 Date: Fri, 15 Jul 2011 19:47:17 -0700 From: Tim To: Nico Williams Message-ID: <20110716024717.GE1848@sentinelchicken.org> References: <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> <20110715234245.GC1848@sentinelchicken.org> <20110716001715.GD1848@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 02:47:19 -0000 > Why not? It's a small change to the browser (compared to everything > else we're talking about). I'm not trying to fix the use of cookies. > Besides, I think cookies can work fine *if* you pin certs and are > careful not to use "secure" cookies outside TLS [with confidentiality > protection], but as with any other form of authentication you'll want > to do something about CSRF. Because I don't think it would get traction. Browsers can't distinguish between cookies used in non-authentication scenarios and scenarios where they are used in authentication. The non-authentication scenario has business drivers for use in cross-domain settings. Forcing the world to add a CORS rule to satisfy a backward-incompatible browser change doesn't seem like it could work. But then, I don't work in advertising or in areas where cookies are used for non-authentication scenarios, so I don't really know what the issues would be. Also, any encouragement of people to stick with cookies for authentication is encouragement to stay insecure. Few people, including security consultants, realize just how easy it is to hijack sessions if you can conduct a MitM attack against HTTPS+cookies. Forget to set the secure flag? Session can be hijacked. Forget to refresh session cookies during login? Session can be hijacked. This is true even if you don't even provide an HTTP interface and assume users/browsers properly validate certificates. Between just these two common flaws, I would bet close to 40-50% of sites I personally test are vulnerable to MitM. In these cases, why bother running SSL? These are just two of many flaws an attacker has to work with. tim From nico@cryptonector.com Fri Jul 15 22:38:00 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8B21F876D for ; Fri, 15 Jul 2011 22:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEFAlLOhCQ0z for ; Fri, 15 Jul 2011 22:37:59 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4AF21F876A for ; Fri, 15 Jul 2011 22:37:59 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 05C6D35005B for ; Fri, 15 Jul 2011 22:37:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=SmnmjGT1fE5TZZLxzIce6 k90DFRYPOm+ztSEtxfHexAWVkFiGLVzrF6TMljZdtVuL8tM87ZGa5xiPKMWs39yM ZwbRGKc8e3IM/Nu1xFtC8jd/menPPzJeRdhxF8e4xK3Robb8XR984PJLESvN1wNB fB6NqSOq1XRpV2Bc1Qjr6Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1gXRDZ3rvdm+kCyDFRHw YN8elKY=; b=B3R4oK8VbB1jgC3EbbNVpWiKOIarTrS0hSeQQc31+TRrly/lNEUt 9AL4fB8/KxXQ2/oE3wVCOFp5SswPR7bUcrIzl3Bdt9p98TTVVFpCkstsVvyqllis 6xn77ah4/RUQ8NEOHufjwpIH9ew4j0vLbfQjmOzjbRHlBSXLWcHyuAQ= Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id DF900350058 for ; Fri, 15 Jul 2011 22:37:58 -0700 (PDT) Received: by pzd13 with SMTP id 13so2582445pzd.39 for ; Fri, 15 Jul 2011 22:37:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.66.133 with SMTP id f5mr4879980pbt.240.1310794678502; Fri, 15 Jul 2011 22:37:58 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 22:37:58 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Fri, 15 Jul 2011 22:37:58 -0700 (PDT) In-Reply-To: <20110716024717.GE1848@sentinelchicken.org> References: <20110706154122.GI25355@sentinelchicken.org> <20110710202035.GS25355@sentinelchicken.org> <20110713035420.GQ1848@sentinelchicken.org> <20110715234245.GC1848@sentinelchicken.org> <20110716001715.GD1848@sentinelchicken.org> <20110716024717.GE1848@sentinelchicken.org> Date: Sat, 16 Jul 2011 00:37:58 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: multipart/alternative; boundary=bcaec544eefc2f85c304a8292b74 Cc: http-auth@ietf.org Subject: Re: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 05:38:00 -0000 --bcaec544eefc2f85c304a8292b74 Content-Type: text/plain; charset=UTF-8 Ah, I'll admit I tend to not be conscious of advertising. --bcaec544eefc2f85c304a8292b74 Content-Type: text/html; charset=UTF-8

Ah, I'll admit I tend to not be conscious of advertising.

--bcaec544eefc2f85c304a8292b74-- From mnot@mnot.net Wed Jul 20 03:35:29 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B221F86D7; Wed, 20 Jul 2011 03:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.767 X-Spam-Level: X-Spam-Status: No, score=-105.767 tagged_above=-999 required=5 tests=[AWL=-3.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRT4e3BI8Lca; Wed, 20 Jul 2011 03:35:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id AF2EA21F86E0; Wed, 20 Jul 2011 03:35:28 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.98.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3388C509DB; Wed, 20 Jul 2011 06:35:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Mark Nottingham Date: Wed, 20 Jul 2011 20:35:18 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> To: http-auth@ietf.org, Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org Discuss" Subject: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:35:29 -0000 The BoF chairs, in consultation with Peter (the responsible AD), have = decided that it's best NOT to hold a BoF for HTTP authentication in = Quebec City, because the scope is still ill-defined, and the timing = prevents several stakeholders from participating.=20 Our hope is to be able to facilitate a BoF at an upcoming meeting, after = there has been more preparation and coordination, so as to enhance its = chance of success (i.e., identifying useful work for the IETF to do, in = coordination with implementers as well as other efforts). We encourage participants to continue discussing the various aspects of = the problems as well as potential solutions, both on the list and in = Quebec City (perhaps at an informal meeting). -- Mark Nottingham and Alexey Melnikov From yaronf@gmx.com Wed Jul 20 13:52:18 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5660721F899F for ; Wed, 20 Jul 2011 13:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyOvXheX1Wxz for ; Wed, 20 Jul 2011 13:52:16 -0700 (PDT) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by ietfa.amsl.com (Postfix) with SMTP id D964C21F8922 for ; Wed, 20 Jul 2011 13:52:14 -0700 (PDT) Received: (qmail invoked by alias); 20 Jul 2011 20:52:11 -0000 Received: from bzq-79-181-241-22.red.bezeqint.net (EHLO [10.0.0.5]) [79.181.241.22] by mail.gmx.com (mp-eu001) with SMTP; 20 Jul 2011 22:52:11 +0200 X-Authenticated: #63966379 X-Provags-ID: V01U2FsdGVkX19PIWU1VrhPeQJOBxzceGMpmZIxSUmAz6odIBDuaH 4p3n3JwZxzf6Oe Message-ID: <4E273FF6.9040705@gmx.com> Date: Wed, 20 Jul 2011 23:52:06 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: http-auth@ietf.org, Stephen Farrell References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 20:52:18 -0000 Hi Stephen, with the BOF (unfortunately) off, I'd like to go back to your assertion below. You say you're skeptical of SSO with initial auth using passwords. But (as far as I know), any of the alternatives require a somewhat trusted computing devices to be owned by the user. E.g. a smartcard or smartphone holding your private key. While with passwords, I can walk up to a friend's computer, enter my Google password and get OpenID access to "anywhere". Do you say that large ID providers are likely to give up on this feature (authentication *without* a personal device) in the next few years? Thanks, Yaron On 07/15/2011 10:00 PM, http-auth-request@ietf.org wrote: > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Jul 2011 15:49:42 +0100 > From: Stephen Farrell > To: Peter Saint-Andre > Cc: "http-auth@ietf.org" > Subject: Re: [http-auth] BoF goals > Message-ID:<4E205386.80800@cs.tcd.ie> > Content-Type: text/plain; charset=ISO-8859-1 > > > AD hat off: > > The main problem I see with which we might try to help > is the need for servers to store databases of passwords > that inevitably leak out sometimes. > > So I'd like to see us develop something that gets rid of > passwords entirely if possible. > > I also think its pointless to develop something that > won't really be deployed and used. > > A similar, but not identical, goal might be to reduce the > overall number of passwords, but I'd be fairly skeptical > of SSO approaches with a password for the initial auth. > > S. > From stephen.farrell@cs.tcd.ie Wed Jul 20 14:16:35 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4963F21F8555 for ; Wed, 20 Jul 2011 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaD8u4mDneDe for ; Wed, 20 Jul 2011 14:16:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C68F121F8546 for ; Wed, 20 Jul 2011 14:16:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 988FC171BFA; Wed, 20 Jul 2011 22:16:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311196586; bh=NH+/Sg62JIHRru EwXY7rOhZct4TqiVuZVnesnpEFgFA=; b=K82SuICAyHOTLmOgJE0KRZeYrbj5jo fDgz5C3XbK5FDqOSIqTwT+NKXBSGD9cy/sPQByag7jeT4vQ6rhvIEiNG5UxTegO6 bey5eIu+wE9m1495XDD/BL5PYXRZYL8Am7fHnTAr9BqUCWOJf5zvN/4tR2Z4DE8a HO5fQiW6Zg2LkvcumDC7XSYh28JGxbVt7eadD0+lqWWJ8ILkMa5+vit+y11W7xSV YTf1tsiHf2wBpxfXCp6UDmT08LEPn6lI6GhHtsJ9zfkTJHl/dFXzxoql6hpPoWcv uSo+2q7oU50brV+XguHJRrB+9L1fCFQREO3kHFnaRex2jDtMBeaEA5yw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id jP1WFXtuHlIr; Wed, 20 Jul 2011 22:16:26 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.19.35]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0142D171BF9; Wed, 20 Jul 2011 22:16:25 +0100 (IST) Message-ID: <4E27459E.4060308@cs.tcd.ie> Date: Wed, 20 Jul 2011 22:16:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yaron Sheffer References: <4E273FF6.9040705@gmx.com> In-Reply-To: <4E273FF6.9040705@gmx.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:16:35 -0000 Hiya, On 20/07/11 21:52, Yaron Sheffer wrote: > Hi Stephen, > > with the BOF (unfortunately) off, I'd like to go back to your assertion > below. > > You say you're skeptical of SSO with initial auth using passwords. Not in an absolute sense. I'm skeptical that SSO with initial passwords is the right answer everywhere all the time. I've no problem that some people might disagree nor that they work on that. Basically, we've had that technology for a long time and its not addressed the problem I see as the priority. Again, others may have different priorities. > But > (as far as I know), any of the alternatives require a somewhat trusted > computing devices to be owned by the user. E.g. a smartcard or > smartphone holding your private key. While with passwords, I can walk up > to a friend's computer, enter my Google password and get OpenID access > to "anywhere". True. However, I would suspect that fewer and fewer people will want to enter passwords into kiosks or equivalent over time, and properly so. If we can get a scheme deployed as I'd like to see, then I'd hope that that use-case would fade away. > Do you say that large ID providers are likely to give up on this feature > (authentication *without* a personal device) in the next few years? No I don't. But neither do I want us to end up with a technology that only makes sense with "large ID providers." S. > > Thanks, > Yaron > > On 07/15/2011 10:00 PM, http-auth-request@ietf.org wrote: >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 15 Jul 2011 15:49:42 +0100 >> From: Stephen Farrell >> To: Peter Saint-Andre >> Cc: "http-auth@ietf.org" >> Subject: Re: [http-auth] BoF goals >> Message-ID:<4E205386.80800@cs.tcd.ie> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> AD hat off: >> >> The main problem I see with which we might try to help >> is the need for servers to store databases of passwords >> that inevitably leak out sometimes. >> >> So I'd like to see us develop something that gets rid of >> passwords entirely if possible. >> >> I also think its pointless to develop something that >> won't really be deployed and used. >> >> A similar, but not identical, goal might be to reduce the >> overall number of passwords, but I'd be fairly skeptical >> of SSO approaches with a password for the initial auth. >> >> S. >> From nico@cryptonector.com Wed Jul 20 14:21:37 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB1E21F869D for ; Wed, 20 Jul 2011 14:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.905 X-Spam-Level: X-Spam-Status: No, score=-2.905 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HREphdbwzIx for ; Wed, 20 Jul 2011 14:21:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE621F8559 for ; Wed, 20 Jul 2011 14:21:33 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4282E35008A for ; Wed, 20 Jul 2011 14:21:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yTCNiPMf3N9yTQcPAOJR5 zJKmnggKqbPPCBrjHpeMFGdloGATGQSL+A+I77m9hpqRF4Y0m7Vj451fREUGpYoe 2Rn4BOJN3Hsmi8hxCalhoQQQuDP6TzjiMGmDmaZfNVceJI50uvz8x1CClYCkhRcS us2B5LRlk5N7i69PD9Lw18= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=qPWaiXNGYlLxAYqfQC2f VGcuZLw=; b=AqwRFCSv+Xwpj2pPUK98hZAhgJApM0CR1kGwR3xtajuo+oZ362P7 GTEkSQnBZTaqWdSFsBn5n14iTr49gHIQkSUBt0nQJeo332tW8/Vum5U24vvkdm0/ bQF+jg4UvzmJzSCoENhY60t9pNB30Ge2HilOEa5YkmN/rxeDmhP4aEw= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 28E2D350058 for ; Wed, 20 Jul 2011 14:21:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so861206pzk.26 for ; Wed, 20 Jul 2011 14:21:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.41.167 with SMTP id g7mr11746856pbl.173.1311196892669; Wed, 20 Jul 2011 14:21:32 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Wed, 20 Jul 2011 14:21:32 -0700 (PDT) In-Reply-To: <4E273FF6.9040705@gmx.com> References: <4E273FF6.9040705@gmx.com> Date: Wed, 20 Jul 2011 16:21:32 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 21:21:38 -0000 On Wed, Jul 20, 2011 at 3:52 PM, Yaron Sheffer wrote: > Hi Stephen, > with the BOF (unfortunately) off, I'd like to go back to your assertion > below. I second both sentiments. First, I think we'll need passwords for a long time yet. This doesn't scare me. Augmented ZKPPs with memory-hard PBKDFs and SSO (which enables stronger password policies because the user gets to get by with fewer passwords to remember) would be a very strong method of using passwords -- it can't be strong enough because in the event of a password verifier DB compromise users will have to change their passwords, and an estimate of off-line dictionary attack success rate will have to inform any grace period for password changes to be easy. Second, most cryptographic authentication protocol mechanisms' fundamental credentials will be subject to both of: a) strong constructions (e.g., large randomly-generated passwords stored in password wallets), b) password-based acquisition (e.g., SACRED and online CAs for PKI). Properties (a) and (b) tell me that a TLS user cert approach is not inherently superior to options such as, for example, ABFAB WG's mechanism. Nor are any of those other options inherently superior to user certs, though they might well be superior to using TLS for user authentication. One mechanism might turn out to be universally (or close enough) good enough that we should pick just that one. I doubt this, but I don't reject this possibility out of hand. I do think it's too soon to reach a conclusion about that, but also we may have to reach a conclusion about that soon. It is because I doubt the feasibility of one mechanism being universally sufficient that I prefer a pluggable approach. Nico -- From ynir@checkpoint.com Wed Jul 20 23:03:11 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A5021F85AC for ; Wed, 20 Jul 2011 23:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.665 X-Spam-Level: X-Spam-Status: No, score=-10.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq4kBDyo93rH for ; Wed, 20 Jul 2011 23:03:10 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3F521F85AB for ; Wed, 20 Jul 2011 23:03:09 -0700 (PDT) X-CheckPoint: {4E27CEBD-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6L631Ed013897; Thu, 21 Jul 2011 09:03:01 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jul 2011 09:03:01 +0300 From: Yoav Nir To: Nico Williams Date: Thu, 21 Jul 2011 09:03:01 +0300 Thread-Topic: [http-auth] SSO with or without passwords Thread-Index: AcxHa9ioU4xjeTLoQAeYQF8s+f09XQ== Message-ID: <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> References: <4E273FF6.9040705@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Yaron Sheffer Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 06:03:11 -0000 Hi I actually don't like the direction this thread is going. It looks to me li= ke user certificates all over again. Both Nico and Yaron are talking about solutions that involve a third party = to the authentication. This could be keys stored on a device such as a phon= e, or stored on some cloud-based service, but it's a third party, and it ad= ds complexity to any solution. It completely fails if my password wallet is= inaccessible, and regardless of the technology this is going to happen. The beauty of passwords is that they're always with me. Wherever I find any= browser that's connected to the Internet, I can log in to gmail whether I = have my phone with me or not, and whether the cloud-based wallet service is= online or "experiencing technical difficulty". Weak passwords and overly re-used passwords are a real problem, and it shou= ld be solved, but we should not lose sight of the fact that the convenience= of user-remembered passwords is such a huge advantage, that they are here = to stay for the foreseeable future. IMO the issue that the group needs to deal with now is that the only user a= uthentication method defined for HTTP is to send the password to the server= . We know this can be fixed in protocol (whether HTML, HTTP, or TLS) and ma= ybe, just maybe we can do it in such a way that web designers actually use = it. This is what I think the (future) group should be dealing with first. The issue of getting better passwords through RNGs and storing and accessin= g them through fancy cryptography is orthogonal, and the failure of OpenID = makes me pessimistic about it.=20 Yoav From stephen.farrell@cs.tcd.ie Thu Jul 21 00:28:52 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0407B21F86E9 for ; Thu, 21 Jul 2011 00:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bK0+Pah5hrab for ; Thu, 21 Jul 2011 00:28:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E626821F86BB for ; Thu, 21 Jul 2011 00:28:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id ED2E2171C19; Thu, 21 Jul 2011 08:28:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1311233316; bh=fZS/WyXMyg7IoG wva4b7TJRUr7rUSeF6iAQyXuK2U34=; b=yEYZHdfvNaVgrqnaL8ZuMGEXDaF+5s BRAlCcD3tK/HLLfCP2P33Y81Onp5wiQYINlq7pNzSzeh/MJEOndVQiuDNJaKQeC2 CwQlJG2tRRDH8HggqzuSLIXSyMUa3Os4SFSgxG8ubO46cwyNtRubh/YZbH9qQNX2 aABdefvxfq6wmwMkGyErnLhikhWZV8aMzgfHVA2svW6Jsx2a4/ChFOftfhPVbaJK VG4gEUmNh5uZkTAHtdrImX3spUheEYOoTYtiRXGv5RqsZudVc78rI4eB14o3yp6K 1Qc7NOaiHIIbWoFJhChw4fG83f4i0nI8VqF2HDOjrkdWYSUHLJqk3yJw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Xjt-blyiLTSk; Thu, 21 Jul 2011 08:28:36 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.25.6]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63709171C04; Thu, 21 Jul 2011 08:28:34 +0100 (IST) Message-ID: <4E27D522.7070708@cs.tcd.ie> Date: Thu, 21 Jul 2011 08:28:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yoav Nir References: <4E273FF6.9040705@gmx.com> <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> In-Reply-To: <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Yaron Sheffer Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:28:52 -0000 Hi Yoav, On 21/07/11 07:03, Yoav Nir wrote: > The beauty of passwords is that they're always with me. Wherever I find any browser that's connected to the Internet, I can log in to gmail whether I have my phone with me or not, and whether the cloud-based wallet service is online or "experiencing technical difficulty". Up to the limit of your memory that is. Last time I counted a few years ago I had about 60 passwords varying from important to not-quite trivial and an uncounted number of trivial ones. Of those I remembered about 20. I'd also note that the most likely browser to work for an awful lot of people is on their phone. That's a change from 10 years ago. > Weak passwords and overly re-used passwords are a real problem, and it should be solved, but we should not lose sight of the fact that the convenience of user-remembered passwords is such a huge advantage, that they are here to stay for the foreseeable future. User-chosen passwords that need to be remembered will be weak. I can't see a way around that. (Passwords policies won't solve it.) > IMO the issue that the group needs to deal with now is that the only user authentication method defined for HTTP is to send the password to the server. We know this can be fixed in protocol (whether HTML, HTTP, or TLS) and maybe, just maybe we can do it in such a way that web designers actually use it. This is what I think the (future) group should be dealing with first. But the BIG problem with passwords is that the databases get stolen and passwords leak out in the millions, affecting other sites with those same users to an unknown extent. That won't be solved via changes in how passwords are handled in protocols, even though those changes are well worthwhile making. (ZKPP do help but don't fix all problems.) S. > > The issue of getting better passwords through RNGs and storing and accessing them through fancy cryptography is orthogonal, and the failure of OpenID makes me pessimistic about it. > > Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From ynir@checkpoint.com Thu Jul 21 01:16:09 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC4A21F850F for ; Thu, 21 Jul 2011 01:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.659 X-Spam-Level: X-Spam-Status: No, score=-10.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEYQ8u36CP00 for ; Thu, 21 Jul 2011 01:16:05 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B4F2B21F889F for ; Thu, 21 Jul 2011 01:16:03 -0700 (PDT) X-CheckPoint: {4E27EDE4-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6L8FtW4005396; Thu, 21 Jul 2011 11:15:56 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jul 2011 11:15:56 +0300 From: Yoav Nir To: Stephen Farrell Date: Thu, 21 Jul 2011 11:15:55 +0300 Thread-Topic: [http-auth] SSO with or without passwords Thread-Index: AcxHfmnTH/j4dKLUSJ+te8dvj/T4Cw== Message-ID: In-Reply-To: <4E27D522.7070708@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Yaron Sheffer Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 08:16:09 -0000 On 7/21/11 10:28 AM, "Stephen Farrell" wrote: > >Hi Yoav, > >On 21/07/11 07:03, Yoav Nir wrote: >> The beauty of passwords is that they're always with me. Wherever I find >>any browser that's connected to the Internet, I can log in to gmail >>whether I have my phone with me or not, and whether the cloud-based >>wallet service is online or "experiencing technical difficulty". > >Up to the limit of your memory that is. Last time I counted a few >years ago I had about 60 passwords varying from important to >not-quite trivial and an uncounted number of trivial ones. Of those >I remembered about 20. > >I'd also note that the most likely browser to work for an awful >lot of people is on their phone. That's a change from 10 years >ago. Only for those who browse the Internet with a phone. Not that many despite the hype: http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-201104-201106-bar Most browsing is done with a computer. Counting on your phone to keep or access your passwords is risky because phones can be lost, forgotten, stolen, or broken. I've done two of these with my phone in the last month. > >> Weak passwords and overly re-used passwords are a real problem, and it >>should be solved, but we should not lose sight of the fact that the >>convenience of user-remembered passwords is such a huge advantage, that >>they are here to stay for the foreseeable future. > >User-chosen passwords that need to be remembered will be >weak. I can't see a way around that. (Passwords policies >won't solve it.) Yes, they will. But they're so convenient that we're stuck with them anyway. Might as well make presenting them to the server more secure. > >> IMO the issue that the group needs to deal with now is that the only >>user authentication method defined for HTTP is to send the password to >>the server. We know this can be fixed in protocol (whether HTML, HTTP, >>or TLS) and maybe, just maybe we can do it in such a way that web >>designers actually use it. This is what I think the (future) group >>should be dealing with first. > >But the BIG problem with passwords is that the databases >get stolen and passwords leak out in the millions, affecting >other sites with those same users to an unknown extent. >That won't be solved via changes in how passwords are >handled in protocols, even though those changes are well >worthwhile making. (ZKPP do help but don't fix all >problems.) I agree that something like OpenID would have been great. So are user certificates. The market voted against both. From yaronf@gmx.com Thu Jul 21 02:42:30 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D461E21F8B6B for ; Thu, 21 Jul 2011 02:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu2vuCBK4ptk for ; Thu, 21 Jul 2011 02:42:26 -0700 (PDT) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by ietfa.amsl.com (Postfix) with SMTP id DFF8C21F8B56 for ; Thu, 21 Jul 2011 02:42:25 -0700 (PDT) Received: (qmail invoked by alias); 21 Jul 2011 09:42:23 -0000 Received: from 93-173-6-225.bb.netvision.net.il (EHLO [10.0.0.6]) [93.173.6.225] by mail.gmx.com (mp-eu004) with SMTP; 21 Jul 2011 11:42:23 +0200 X-Authenticated: #63966379 X-Provags-ID: V01U2FsdGVkX1/UxrZLqknUIpuLN94fjUbm4c9ZScXCboTTXI/CR8 cLO11IPhlqk9RM Message-ID: <4E27F477.6010908@gmx.com> Date: Thu, 21 Jul 2011 12:42:15 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:42:30 -0000 Hi Yoav, why do you keep saying that OpenID has failed? Do you have a reference for that? While people are not using the OpenID *brand*, they are using the standard. Take a look at the semi-transparent band at the bottom of http://openid.net/. Or try to login to e.g. Flickr. Thanks, Yaron On 07/21/2011 11:15 AM, Yoav Nir wrote: > > On 7/21/11 10:28 AM, "Stephen Farrell" wrote: > >> Hi Yoav, >> >> On 21/07/11 07:03, Yoav Nir wrote: >>> The beauty of passwords is that they're always with me. Wherever I find >>> any browser that's connected to the Internet, I can log in to gmail >>> whether I have my phone with me or not, and whether the cloud-based >>> wallet service is online or "experiencing technical difficulty". >> Up to the limit of your memory that is. Last time I counted a few >> years ago I had about 60 passwords varying from important to >> not-quite trivial and an uncounted number of trivial ones. Of those >> I remembered about 20. >> >> I'd also note that the most likely browser to work for an awful >> lot of people is on their phone. That's a change from 10 years >> ago. > Only for those who browse the Internet with a phone. Not that many despite > the hype: > http://gs.statcounter.com/#mobile_vs_desktop-ww-monthly-201104-201106-bar > > Most browsing is done with a computer. Counting on your phone to keep or > access your passwords is risky because phones can be lost, forgotten, > stolen, or broken. I've done two of these with my phone in the last month. > >>> Weak passwords and overly re-used passwords are a real problem, and it >>> should be solved, but we should not lose sight of the fact that the >>> convenience of user-remembered passwords is such a huge advantage, that >>> they are here to stay for the foreseeable future. >> User-chosen passwords that need to be remembered will be >> weak. I can't see a way around that. (Passwords policies >> won't solve it.) > Yes, they will. But they're so convenient that we're stuck with them > anyway. Might as well make presenting them to the server more secure. > >>> IMO the issue that the group needs to deal with now is that the only >>> user authentication method defined for HTTP is to send the password to >>> the server. We know this can be fixed in protocol (whether HTML, HTTP, >>> or TLS) and maybe, just maybe we can do it in such a way that web >>> designers actually use it. This is what I think the (future) group >>> should be dealing with first. >> But the BIG problem with passwords is that the databases >> get stolen and passwords leak out in the millions, affecting >> other sites with those same users to an unknown extent. >> That won't be solved via changes in how passwords are >> handled in protocols, even though those changes are well >> worthwhile making. (ZKPP do help but don't fix all >> problems.) > I agree that something like OpenID would have been great. So are user > certificates. The market voted against both. > From ynir@checkpoint.com Thu Jul 21 03:17:53 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6521F88B7 for ; Thu, 21 Jul 2011 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.654 X-Spam-Level: X-Spam-Status: No, score=-10.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWcqUHiLykD5 for ; Thu, 21 Jul 2011 03:17:49 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 03ED221F86DF for ; Thu, 21 Jul 2011 03:17:44 -0700 (PDT) X-CheckPoint: {4E280A68-A-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6LAHZbS030148; Thu, 21 Jul 2011 13:17:35 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 21 Jul 2011 13:17:36 +0300 From: Yoav Nir To: Yaron Sheffer Date: Thu, 21 Jul 2011 13:17:36 +0300 Thread-Topic: [http-auth] SSO with or without passwords Thread-Index: AcxHj2jLoK9E3q7nSnGvImyxXFUvYA== Message-ID: In-Reply-To: <4E27F477.6010908@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 10:17:53 -0000 On 7/21/11 12:42 PM, "Yaron Sheffer" wrote: >Hi Yoav, > >why do you keep saying that OpenID has failed? Do you have a reference >for that? While people are not using the OpenID *brand*, they are using >the standard. Take a look at the semi-transparent band at the bottom of >http://openid.net/. Or try to login to e.g. Flickr. > >Thanks, > Yaron Just did. I can login with a Yahoo! ID, and also allows me to log in with Facebook or Google Tried Facebook, and I get a page where Yahoo! (not Flickr, and I don't care that they own Flickr) asks for permission to do lots of things on Facebook. This is not OpenID. For Google, I get a message saying "Yahoo! is asking for some information from your Google Account..." Kind of cryptic, but I guess this is OpenID. So how many people are actually using this rather than creating new accounts everywhere? I don't have any statistics, but I'm guessing most people have a different password for every site. From tim-research@sentinelchicken.org Thu Jul 21 08:57:36 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DE121F891D for ; Thu, 21 Jul 2011 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BvPF3ZlO6Kb for ; Thu, 21 Jul 2011 08:57:35 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id A726621F88A5 for ; Thu, 21 Jul 2011 08:57:35 -0700 (PDT) Received: (qmail 6813 invoked from network); 21 Jul 2011 15:57:33 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 21 Jul 2011 15:57:33 -0000 Received: (qmail 29357 invoked from network); 21 Jul 2011 15:56:07 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 21 Jul 2011 15:56:07 -0000 Received: (nullmailer pid 23468 invoked by uid 1000); Thu, 21 Jul 2011 15:57:32 -0000 Date: Thu, 21 Jul 2011 08:57:32 -0700 From: Tim To: Yoav Nir Message-ID: <20110721155732.GK1848@sentinelchicken.org> References: <4E273FF6.9040705@gmx.com> <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 15:57:36 -0000 > IMO the issue that the group needs to deal with now is that the only > user authentication method defined for HTTP is to send the password to > the server. We know this can be fixed in protocol (whether HTML, HTTP, > or TLS) and maybe, just maybe we can do it in such a way that web > designers actually use it. This is what I think the (future) group > should be dealing with first. I agree with this. While I would love to see seemless integration of client certificates in web applications, I just can't see how passwords will go away until there is truly a universal way to use your certificates no matter where you are (think: chip implanted on body). Right now, if users forget their passwords, what do web sites do? They send a new password via email after may be asking users to type in poorly-chosen answers to questions about themselves. I find this design really weak and in many cases the implementations of these forgotten password systems are very unsafe. Perhaps in the future, web sites could ask users to install a client certificate and use it for most sessions, but fall back on a user-chosen password (with the usual complexity requirements) in the event they don't have their certificate in hand. This seems to me like a step up from what we're currently doing. So even in a world where certificates are used in most cases, password authentication still needs to be there. I don't think we should take on too much. I think it is better to build standards that are simple, versatile building blocks that can be reused in multiple contexts. Keeping new systems simple reduces barriers to adoption. So I agree we should stick with improving the state of password authentication, while keeping in mind the direction things ought to be headed. tim From nico@cryptonector.com Thu Jul 21 09:02:48 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C0921F8A30 for ; Thu, 21 Jul 2011 09:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=-0.903, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b6YH1IkxyQI for ; Thu, 21 Jul 2011 09:02:44 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9621F874A for ; Thu, 21 Jul 2011 09:02:44 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id E13E57E4072 for ; Thu, 21 Jul 2011 09:02:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=o7G1xgYuY5ZbvFhVXPuDq1CBEcAWrp0No0eBzStq1zZv 28sCreNYAHgF21mHK7e42exgeSOYEMI/H5PIuLPYgrchhBjO6r6PKkrveJXH+5KV LcZa59NBEv0VHyXST57wupUriUNPeND5C39f/059ycKZJEGOu6ytVYs9SzNdrIo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0kGb6zYhCsnxKQiupMQndhClCUk=; b=OhQm55HCVJm e+T3SdYSfVkgFOW7OdwyUNuL87/9ay2FtLxKXiNWtsr0ljPfn2GrGHjzxJt+cD1F wVAr6WO0r661Kv6rI9hN/T/WP7BtTN7wQpndT/8gQRoiyjPDmlsbiehHtDy8WCmO /GoJLSk0mGmxqIi4/5oQRJaTsR2E2A6g= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id C53B67E406F for ; Thu, 21 Jul 2011 09:02:43 -0700 (PDT) Received: by pzk6 with SMTP id 6so1985936pzk.26 for ; Thu, 21 Jul 2011 09:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.47.102 with SMTP id c6mr496877pbn.441.1311264163376; Thu, 21 Jul 2011 09:02:43 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Thu, 21 Jul 2011 09:02:43 -0700 (PDT) In-Reply-To: <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> References: <4E273FF6.9040705@gmx.com> <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> Date: Thu, 21 Jul 2011 11:02:43 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" , Yaron Sheffer Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 16:02:48 -0000 On Thu, Jul 21, 2011 at 1:03 AM, Yoav Nir wrote: > I actually don't like the direction this thread is going. It looks to me = like user certificates all over again. > > Both Nico and Yaron are talking about solutions that involve a third part= y to the authentication. This could be keys stored on a device such as a ph= one, or stored on some cloud-based service, but it's a third party, and it = adds complexity to any solution. It completely fails if my password wallet = is inaccessible, and regardless of the technology this is going to happen. Actually, I'm not talking about trusted third parties as a necessary part of any solution. I'm saying we need to allow for more than one mechanism. Some will be distributed third-party systems, some will not be. > The beauty of passwords is that they're always with me. Wherever I find a= ny browser that's connected to the Internet, I can log in to gmail whether = I have my phone with me or not, and whether the cloud-based wallet service = is online or "experiencing technical difficulty". Agreed. And if they're too hard to remember you'll just write them down. And you can always get tmp ones SMSed to your phone. Augmented ZKPPs get us to a good level of security, but they're not essential to this. Nico -- From marsh@extendedsubset.com Thu Jul 21 11:48:22 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DF621F87C9 for ; Thu, 21 Jul 2011 11:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahSjKWzkNTA0 for ; Thu, 21 Jul 2011 11:48:21 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD0021F856D for ; Thu, 21 Jul 2011 11:48:21 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QjyID-000AtF-VO; Thu, 21 Jul 2011 18:48:18 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 90CC7608C; Thu, 21 Jul 2011 18:48:15 +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: U2FsdGVkX18aC+sLZ+9JGKxk9Wu8Gok2tFAg4PVg8xg= Message-ID: <4E28746A.3020007@extendedsubset.com> Date: Thu, 21 Jul 2011 13:48:10 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yoav Nir References: <4E273FF6.9040705@gmx.com> <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> In-Reply-To: <155CDD74-3EFB-4362-B2CE-AAAB9101400B@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Yaron Sheffer Subject: Re: [http-auth] SSO with or without passwords X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 18:48:22 -0000 On 07/21/2011 01:03 AM, Yoav Nir wrote: > Hi > > I actually don't like the direction this thread is going. It looks to > me like user certificates all over again. [...] we should not lose > sight of the fact that the convenience of user-remembered passwords > is such a huge advantage, that they are here to stay for the > foreseeable future. With apologies to JC, "Passwords ye will have with you always". They're just too fundamental - they're the obvious implementation of "something you know" for anything with a keyboard. Which is why *everyone* uses them. I think they're so entrenched at this point that only solutions which build and improve upon such the established base are going to have a chance of widespread uptake. Now there's nothing wrong with designing a niche protocol feature as long as you're clear in advance that that's what you're doing. But I don't think that's the case here because there's such a huge need for a substantial improvement in web authentication. We'd be doing a disservice to design an ideal authentication framework from first principles if we forget the main requirement that it's something that people will actually use. > Both Nico and Yaron are talking about solutions that involve a third > party to the authentication. This could be keys stored on a device > such as a phone, or stored on some cloud-based service, but it's a > third party, and it adds complexity to any solution. [disclaimer] I work for a third-party authentication provider (PhoneFactor). Introducing a third-party *requirement* into the protocol will be a big obstacle for many (if not most) sites. Third-party relationships get formed at the business level with (literal) handshakes, signatures, auditing, etc. Business people/C?Os understand this type of dependency quite well and rightly insist on being the ones to drive its adoption. It's not as easy a sell (internally, by the guys who work directly on site security) as a pure technical feature. On the other hand, a protocol feature that provided better integration with third-party auth providers (particularly second factor solutions like the one I work on) could be a big win. There is a large and growing number of industries being pushed to adopt 2FA by regulation and informal standards of due care. 2FA has some special requirements that are not necessarily addressed by some third-party auth schemes. For example, whereas some schemes seem to poll multiple providers and succeed the auth if *any* provider allows it, a second-factor provider needs an absolutely reliable way to retroactively deny the auth after a preliminary primary auth success. If the protocol feature specifically enabled this integration you would have 2FA providers driving its deployment. > IMO the issue that the group needs to deal with now is that the only > user authentication method defined for HTTP is to send the password > to the server. Well there's also digest and MS integrated auth and TLS client certs, which I think does not make your point any less valid. > We know this can be fixed in protocol (whether HTML, HTTP, or TLS) > and maybe, just maybe we can do it in such a way that web designers > actually use it. This is what I think the (future) group should be > dealing with first. Maybe somebody ought to ask the web designers how we can help them? Certainly many feel like the security stuff is not their favorite part of the trade and would jump at the opportunity to get some professional protocol support. > The issue of getting better passwords through RNGs and storing and > accessing them through fancy cryptography is orthogonal, and the > failure of OpenID makes me pessimistic about it. We've all seen crypto-nerds go off the deep end fantasizing that certain mathematical properties will translate into real world security. I know I've been guilty of it myself. We need to be careful about it. Nevertheless, we shouldn't be so conservative that we shy away from using all the skills and tools we have available, which are actually quite considerable. This is a really hard problem and the solution may involve reaching farther than the previous attempts. - Marsh From ynir@checkpoint.com Sun Jul 24 12:28:33 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF921F8AEA; Sun, 24 Jul 2011 12:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xn-2g7raZCS; Sun, 24 Jul 2011 12:28:32 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6E21F8AEC; Sun, 24 Jul 2011 12:28:30 -0700 (PDT) X-CheckPoint: {4E2C7FF6-7-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6OJSS1Q019872; Sun, 24 Jul 2011 22:28:28 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 24 Jul 2011 22:28:28 +0300 From: Yoav Nir To: "http-auth@ietf.org" Date: Sun, 24 Jul 2011 22:28:26 +0300 Thread-Topic: [http-auth] HTTP-Auth BoF in Quebec City Postponed Thread-Index: AcxKN91vdUxZLA9RQZ2riV+CEgkXsw== Message-ID: <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> In-Reply-To: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-4-368541076"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 19:28:33 -0000 --Apple-Mail-4-368541076 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi. Would the people interested in http-auth like to hold an informal = meeting sometime during the week? If we don't want to have future BoFs canceled again, we should have a = more clear definition of what problem we are trying to solve. The first thing is to define what is bad in the current situation. I = think we've seen two claims about this: - Authentication to a web site means sending a password in the clear to = some web site that may or may not be the correct site. - A website that requires log-ins has to either store passwords or = password verifiers. A compromise of that database is disastrous, because = users re-use passwords for other sites. After deciding which issue we would like to address, we can decide if = the direction we would like to take is a more secure password protocol, = or whether we would like to go to some solution that does away with = passwords altogether. I think there has been some meaningful discussion = on the mailing list, but I don't see those discussions converging. Do you think meeting face-to-face can help us move forward? Yoav =20= --Apple-Mail-4-368541076 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNDE5MjgyNlowIwYJKoZIhvcNAQkEMRYEFLbubqHxZHSID5vnBEbk hR+HZur8MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAMMK0ogZ0eShZRqPk0Dbs6uQkW4sPVM28sH3cwBrU8uluIgBTciwiqtuPZrH5sJSOxDruYeG 0iH3M4/vmjx55+WER2WhZksledzCd8Ip35eYZ+YrRedH2j5RFYLSncyQE5abPTUOmwYJ980hNT75 00ailRTX0+zaC2nvKUk/HscDPvpXt2x8l5lOrqChlkdg4UooDvLijXV4W/BlT4/99ckO67m0GLSB 1TUwYJBJyZt1p36A9r7U0XcbkKxb0Qimtfjkiq+io0jIV2dnkEHbsJpdoY3fbbwwGdyFw6TwJk9D emelA/Jpa6qA2XLYlnUIk9qJRbhaHY1KOoU/vuyYoEQAAAAAAAA= --Apple-Mail-4-368541076-- From nico@cryptonector.com Sun Jul 24 12:37:31 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5A21F86EC; Sun, 24 Jul 2011 12:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.856 X-Spam-Level: X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a58GCl58PEXa; Sun, 24 Jul 2011 12:37:31 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 457B821F84CE; Sun, 24 Jul 2011 12:37:31 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 1A1FC6B0070; Sun, 24 Jul 2011 12:37:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=JJXrOsCKbSwPcTFyGQ+Bi lIubNSPdlfaZpqhuL/ECQuA49x249IOwkkJu4Xt/ABrXqUBGOAZkPygnIKeRZNG4 OGtriJJYNZ8rFnpIrDWdnOoUJXkQ5IlGrVbcmqWi2smfDco6tobcuSAN3GVwucS4 gtHwrWBRiKVrszPdjCqJpw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=6K6jxXGkbBcrfFfzhMpi RdtGGJQ=; b=yhCyCljSsXhoCdjiy4lLVB2EqWO6StKli7FJv6Ev1ab920ZdUfGr GcEN3gTYPxd05bkCI0YB5fTaP32zDiJ8KhF3Evj9d88hxHdMAoi4psqAkm0S6nac ZxJM2fwfnLZ+v7y9hAtPwDp2rPBmSCdy48eSKU2bJAOhsRz1XAfPhD4= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 026AE6B0014; Sun, 24 Jul 2011 12:37:30 -0700 (PDT) Received: by pzk6 with SMTP id 6so6872398pzk.26 for ; Sun, 24 Jul 2011 12:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.41.167 with SMTP id g7mr6502420pbl.173.1311536250672; Sun, 24 Jul 2011 12:37:30 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Sun, 24 Jul 2011 12:37:30 -0700 (PDT) In-Reply-To: <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> Date: Sun, 24 Jul 2011 14:37:30 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" , "apps-discuss@ietf.org Discuss" Subject: Re: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 19:37:31 -0000 Sadly I cannot attend. I planned my travel schedule for this week around the original BoF, and so I depart Quebec in the afternoon. I look forward to the notes from any bar BoF :) Nico -- From stpeter@stpeter.im Sun Jul 24 15:54:13 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9674921F877F; Sun, 24 Jul 2011 15:54:13 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXicsWNRUKDl; Sun, 24 Jul 2011 15:54:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABCB21F877D; Sun, 24 Jul 2011 15:54:13 -0700 (PDT) Received: from dhcp-13ac.meeting.ietf.org (unknown [130.129.19.172]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E831D4120F; Sun, 24 Jul 2011 16:55:06 -0600 (MDT) Message-ID: <4E2CA293.70603@stpeter.im> Date: Sun, 24 Jul 2011 18:54:11 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Nico Williams References: <5FA6AD59-7570-4A85-B6D1-3DC8E42688F1@mnot.net> <234F16BC-9875-474B-95B3-D61E8BE5A6E0@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , "apps-discuss@ietf.org Discuss" Subject: Re: [http-auth] HTTP-Auth BoF in Quebec City Postponed X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 22:54:13 -0000 On 7/24/11 3:37 PM, Nico Williams wrote: > Sadly I cannot attend. I planned my travel schedule for this week > around the original BoF, and so I depart Quebec in the afternoon. I > look forward to the notes from any bar BoF :) A few of us got together just now in a side room to chat informally. We'll post further about some actions sometime soon. :) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Jul 25 06:36:05 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB28D21F8AC9 for ; Mon, 25 Jul 2011 06:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1aT7JwCZjIj for ; Mon, 25 Jul 2011 06:36:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6F21F8AB9 for ; Mon, 25 Jul 2011 06:36:05 -0700 (PDT) Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CC4C4411C7 for ; Mon, 25 Jul 2011 07:37:00 -0600 (MDT) Message-ID: <4E2D7143.9010202@stpeter.im> Date: Mon, 25 Jul 2011 09:36:03 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <4E2D5C63.3000408@telia.com> In-Reply-To: <4E2D5C63.3000408@telia.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <4E2D5C63.3000408@telia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [http-auth] Fwd: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:36:05 -0000 Might be of interest here... -------- Original Message -------- Subject: [TLS] HTTPS client-certificate-authentication in browsers Date: Mon, 25 Jul 2011 14:06:59 +0200 From: Anders Rundgren To: tls@ietf.org Hi Guys, I don't really know who "owns" this question but presumably you do... HTTPS client-certificate-authentication in browsers =================================================== I don't believe that TLS CCA (Client Certificate Authentication) in the form of HTTPS as implemented in current browsers has much of a future. In fact, quite a bunch of the entities in the EU working with consumer PKI have replaced HTTPS CCA with an application level scheme which wasn't such a big deal since they anyway were forced writing a browser PKI client more or less from scratch since the ones shipped with browsers doesn't support PKI as defined by banks and government (like mandatory PIN codes also for on-line enrolled keys). That the TLS CCA protocol doesn't even support "Logout" haven't made it a logical choice for web developers either. Well, there are some workarounds but they are by no means straightforward, supported out-of-the-box by server authentication schemes, and are (of course) entirely undocumented. The button "Clear SSL state" in MSIE is an indication how horribly bad it can go when security experts design systems for "people". There's no way you can hide the fact that TLS CCA is only truly useful securing tunnels between "boxes". Anders _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From ynir@checkpoint.com Mon Jul 25 09:05:43 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2B721F8B0E for ; Mon, 25 Jul 2011 09:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.456 X-Spam-Level: X-Spam-Status: No, score=-10.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgXoWznhRjVv for ; Mon, 25 Jul 2011 09:05:43 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8963721F8BA8 for ; Mon, 25 Jul 2011 07:05:40 -0700 (PDT) X-CheckPoint: {4E2D8500-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6PE2BMt012370; Mon, 25 Jul 2011 17:02:11 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 25 Jul 2011 17:02:11 +0300 From: Yoav Nir To: Peter Saint-Andre Date: Mon, 25 Jul 2011 17:01:51 +0300 Thread-Topic: [http-auth] Fwd: [TLS] HTTPS client-certificate-authentication in browsers Thread-Index: AcxK03MKt9VJp+fLThablSOOugZyIQ== Message-ID: References: <4E2D5C63.3000408@telia.com> <4E2D7143.9010202@stpeter.im> In-Reply-To: <4E2D7143.9010202@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-435346331"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:05:44 -0000 --Apple-Mail-1-435346331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm pretty sure that if client certificates worked for HTTPS, we would = not have an HTTP-AUTH initiative. But the biggest thing working against certificates is that they identify = a device, not a user. If I have several devices then I either have to = have multiple copies of my cert and private key, or several different = certificates, one for each device, or an n+1-th device (such as a USB = token) that contains the private key and can be connected to any = browser, and there's no technology now that would work with all = browsers. It's little wonder that all the big services prefer to use passwords. Yoav On Jul 25, 2011, at 9:36 AM, Peter Saint-Andre wrote: > Might be of interest here... >=20 > -------- Original Message -------- > Subject: [TLS] HTTPS client-certificate-authentication in browsers > Date: Mon, 25 Jul 2011 14:06:59 +0200 > From: Anders Rundgren > To: tls@ietf.org >=20 > Hi Guys, > I don't really know who "owns" this question but presumably you do... >=20 > HTTPS client-certificate-authentication in browsers > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > I don't believe that TLS CCA (Client Certificate Authentication) in = the > form of HTTPS as implemented in current browsers has much of a future. >=20 > In fact, quite a bunch of the entities in the EU working with consumer = PKI > have replaced HTTPS CCA with an application level scheme which wasn't = such > a big deal since they anyway were forced writing a browser PKI client = more > or less from scratch since the ones shipped with browsers doesn't = support > PKI as defined by banks and government (like mandatory PIN codes also > for on-line enrolled keys). >=20 > That the TLS CCA protocol doesn't even support "Logout" haven't made > it a logical choice for web developers either. Well, there are some > workarounds but they are by no means straightforward, supported > out-of-the-box by server authentication schemes, and are (of course) > entirely undocumented. >=20 > The button "Clear SSL state" in MSIE is an indication how horribly bad = it > can go when security experts design systems for "people". >=20 > There's no way you can hide the fact that TLS CCA is only truly useful > securing tunnels between "boxes". >=20 > Anders --Apple-Mail-1-435346331 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNTE0MDE1MlowIwYJKoZIhvcNAQkEMRYEFPjS6Vja2a4G8h6pKfNM uSGMnNxbMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBABYnVXq87e15GwRQlXwJ8NJKRr1/7gT+QeDYCv9Bh1XbeV8S3UmRy+O1dHVEr2IrseAFG5e5 8Sxa9ubmfQcub28gOiBE30FQbqPTrZEvK1LM66WfBTyP4Z+dQHro9uNRFhscHyHhhVo4FGM5I8+e DmisXTci4oIPBvrRq5fzE8EOTCLlMxlTm8S8U2+oUxAs182AeXfi+/Yxn+elIZwfLmhrlP1guE4N g0B6TlofrIIjpSPEeIcgFRPbx6+jj3WUkT5MthnghH6k1T9nR0A6L4eC2dm6g3P9diI1TVySHn8o igrkzBnT9w2z0OZfuzjnWye09NeXCFije4OYXEj53kUAAAAAAAA= --Apple-Mail-1-435346331--