Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A708A80B2A for ; Thu, 29 Nov 2007 13:59:16 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85C4E142206 for ; Thu, 29 Nov 2007 13:59:17 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+Fae1g3N6ET for ; Thu, 29 Nov 2007 13:59:12 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by laweleka.osafoundation.org (Postfix) with ESMTP id 321AA142204 for ; Thu, 29 Nov 2007 13:59:12 -0800 (PST) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 29 Nov 2007 13:59:11 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lATLxABw018037; Thu, 29 Nov 2007 13:59:10 -0800 Received: from dhcp-171-69-132-128.cisco.com (dhcp-171-69-132-128.cisco.com [171.69.132.128]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lATLxA1f006366; Thu, 29 Nov 2007 21:59:10 GMT Message-ID: <474F362E.9070706@cisco.com> Date: Thu, 29 Nov 2007 13:59:10 -0800 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> In-Reply-To: <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=163; t=1196373550; x=1197237550; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-http-auth]=20Bar=20BoF=20in=20Vancouver? |Sender:=20; bh=NxD0iNeJJATlhpLxabSlV/6LOpwRU9xWaJOdInKE7QE=; b=QQQuenKJlA++j9lf0ZfJB9V/ZB3pYU6ZuzoZRR+xRb/s3duC+BIscPzdUobW9Ng3+hiD88iM /TlIkkQPk7boZRgNxi3ZTpK86mgURHqz60SI6XzQrrkm7pQqLsnxWyrg46mkJK6IebdM/Sx1wJ syA0CDab4QT+Y610sSl2GNNCo=; Authentication-Results: sj-dkim-1; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 21:59:16 -0000 Mark Nottingham wrote: > > How about Tuesday 6pm (unless ltans a potential conflict)? Unfortunately everyone else wants to meet for a bar bof at that time :-( Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 99FC180BE8 for ; Thu, 29 Nov 2007 13:32:10 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 791BD14220F for ; Thu, 29 Nov 2007 13:32:11 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -17.116 X-Spam-Level: X-Spam-Status: No, score=-17.116 tagged_above=-50 required=4 tests=[AWL=0.483, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7ERKDOrxavx for ; Thu, 29 Nov 2007 13:32:06 -0800 (PST) Received: from rsmtp2.corp.yahoo.com (rsmtp2.corp.yahoo.com [207.126.228.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 2294B142207 for ; Thu, 29 Nov 2007 13:32:06 -0800 (PST) Received: from [172.21.222.42] (snvvpn1-10-72-73-c53.corp.yahoo.com [10.72.73.53]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lATLVou1027957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Nov 2007 13:31:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=Xv2jtWZyp5XltKlL78FNF++Q8TKEdHFkylDc8AFhgWKmgJtLolkbiv+pKWiGv2gF In-Reply-To: <474F1896.2080804@cisco.com> References: <474F1896.2080804@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? Date: Thu, 29 Nov 2007 13:31:46 -0800 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 21:32:10 -0000 How about Tuesday 6pm (unless ltans a potential conflict)? On 2007/11/29, at 11:52 AM, Eliot Lear wrote: > Mark Nottingham wrote: >> With draft-hartman-06 out, and the new discussion around draft-oiwa, >> is anyone interested in an informal discussion in Vancouver? >> > > Absolutely!! -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 83AE780BCA for ; Thu, 29 Nov 2007 11:53:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 617C0142204 for ; Thu, 29 Nov 2007 11:53:01 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhXOu1pIPuWi for ; Thu, 29 Nov 2007 11:52:56 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0611A142203 for ; Thu, 29 Nov 2007 11:52:55 -0800 (PST) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 11:52:55 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lATJqsuh000687; Thu, 29 Nov 2007 11:52:54 -0800 Received: from dhcp-171-69-132-128.cisco.com (dhcp-171-69-132-128.cisco.com [171.69.132.128]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lATJqsqZ009204; Thu, 29 Nov 2007 19:52:54 GMT Message-ID: <474F1896.2080804@cisco.com> Date: Thu, 29 Nov 2007 11:52:54 -0800 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=179; t=1196365974; x=1197229974; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-http-auth]=20Bar=20BoF=20in=20Vancouver? |Sender:=20; bh=tNQdEp0s+EHSn6EEtkphIxj5KMjKmJQQywR6WOZ5DQY=; b=SriXa6fLuJyu8bOmK9H3zO1p57X6j/bR/79UsbFUNZhxeIbXaw/LN3Ri73ogyOnKCOjrVJ7p 2Vjgx86c4JnnHo2K7nB1dAd7ftgXaueMUgpJtqXOituT0HjZaTGh6CUz; Authentication-Results: sj-dkim-4; header.From=lear@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 19:53:01 -0000 Mark Nottingham wrote: > With draft-hartman-06 out, and the new discussion around draft-oiwa, > is anyone interested in an informal discussion in Vancouver? > Absolutely!! Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9AD2F80BCA for ; Thu, 29 Nov 2007 11:42:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7774C142207 for ; Thu, 29 Nov 2007 11:42:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK30NfbvoyIi for ; Thu, 29 Nov 2007 11:41:57 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by laweleka.osafoundation.org (Postfix) with ESMTP id 381FD142203 for ; Thu, 29 Nov 2007 11:41:57 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id lATJfkGA025818; Fri, 30 Nov 2007 04:41:46 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id lATJfkfA006260; Fri, 30 Nov 2007 04:41:46 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id lATJffcG014486; Fri, 30 Nov 2007 04:41:41 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: Eric Rescorla Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053105.380CE33C21@delta.rtfm.com> From: Yutaka OIWA Date: Fri, 30 Nov 2007 04:41:41 +0900 In-Reply-To: <20071127053105.380CE33C21@delta.rtfm.com> (Eric Rescorla's message of "Mon, 26 Nov 2007 21:31:04 -0800") Message-ID: <87ve7khma2.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 19:42:02 -0000 Dear Eric and other people discussing the issue recently, Thank you very much for the comment. Eric Rescorla writes: > A few questions/comments: > > 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't > it be more straightforward to do this in TLS rather than adapting > Digest? I also would note that TLS-SRP has already been approved > by the IESG. In short, We found that TLS-SRP is not well suited for web applications. Web authentications are basically application-layer issues. In real web sites like Google or Yahoo!, there are both unauthenticated contents and authenticated contents on one server, and also there are many independent "authentication realms" which request different sets of authentication credentials. One of these realms (including "no-authentication" realm) are assigned for each requested Web resource, which is determined by the HTTP-layer request URI and other headers. When TLS-SRP is used, however, the authentication starts before the client tells the server what resource are requested. This gives great difficulty for designing web sites and inapplicability for many existing systems. Actually, when we started discussing the extension, we did discuss about applying TLS-SRP protocol to the current Web systems. However, we found that TLS-SRP is not suitable for this purpose in some reasons described here. This was the first motivating period that we need to develop a new HTTP-layer protocol. (Of course, I think that TLS-SRP is useful for the protocols which requires only simple and uniform patterns of password-based authentications, like IPP/HTTPS, IMAP/TLS or POP3/TLS. In those cases, authentications in transport-layer are sufficient.) One might also think that combination of TLS-SRP and TLS renegotiation can be useful to solve the issue. But it is very unlikely to specify and implement correctly an appropriate mechanism for Web authentication using some kinds of tricky "authentication tunneling" behaviors. The simple HTTP-layer authentication is much clearer and better. Furthermore, introduced in HTTP/1.1, there is HTTP Keep-alive feature that allows more than one HTTP-layer requests on one TLS (or TCP) transport-layer connections. This adds further complexity for such specifications. > 2. Do you have a pointer to a complete description of the crypto > protocol this is based on? A little searching didn't turn > up anything non-free. We would add the detail of the crypto in the next draft. > 3. There are a large number of PAKE/ZKPP protocols. Can you please > explain why one would want this protocol versus others? There are some criteria which are required for use in our Mutual Authentication Protocol: (1) There are only four messages for one authentication (including key sharing confirmation). (2) Among those, key sharing is done in first two messages, and final two messages are only for lightweight key confirmation. This is required because our scheme uses one shared key for several requests by re-sending final two messages only. This reduces overhead for repeatedly performing public-key cryptographic operations. (3) Those final two messages must be able to be extended so that we can put additional confirmation data such as nonces and validation tokens (v) into that messages. Note that this is very important point: in our scheme, this modification to the messages are important to prevent man-in-the-middle attacks. In addition to this, In KAM3 required secret is asymmetric: the server only needs "encrypted" (or "hashed") password, and does not need having the real password value (pi) itself. These are the reasons we chose ISO-defined variant as a basis. If there is a PAKE/ZKPP protocol which meets all of those criteria and has some advantages over KAM3, we think that such a protocol should be used. > 4. I see you've filed an IPR disclosure on this technique. Is your > own IPR the only IPR which you're aware of? First, we can guarantee that the disclosed patents are the only patent that the authors (Oiwa, Watanabe, Takagi and Suzuki) have submitted or even concerned which affect the protocol. (Of course, the patent is only for the modification of the protocol from ISO specification and the application to HTTP authentication. The original ISO KAM3 protocol is out of the patent's scope for the obvious reason.) Second, there are well-known, very fundamental patents about elliptic curve cryptography which the people think (or at least worry) that the patents are effectively valid. Those patents may have relation with this protocol, as stated in the draft. Third, it is known that the original inventor of the KAM3 PAKE variant is not claiming any patent over the (original) protocol. It can be confirmed in http://grouper.ieee.org/groups/1363/WorkingGroup/presentations/p1363_200403.ppt . Finally, we currently think that, as far as we know, other patents on related fields are not applicable for this technique either because it is out of the claim or there are prior arts (as far as our protocol is concerned). -- 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[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1] Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D1AEB80B87 for ; Thu, 29 Nov 2007 10:54:01 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AE8FF142203 for ; Thu, 29 Nov 2007 10:54:02 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -17.02 X-Spam-Level: X-Spam-Status: No, score=-17.02 tagged_above=-50 required=4 tests=[AWL=0.579, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd916z4GY7fr for ; Thu, 29 Nov 2007 10:53:57 -0800 (PST) Received: from rsmtp1.corp.yahoo.com (rsmtp1.corp.yahoo.com [207.126.228.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 65CF51421FC for ; Thu, 29 Nov 2007 10:53:57 -0800 (PST) Received: from [172.21.222.42] (snvvpn1-10-72-73-c53.corp.yahoo.com [10.72.73.53]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lATIroZg065663 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 29 Nov 2007 10:53:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=mime-version:content-transfer-encoding:message-id: content-type:to:from:subject:date:x-mailer; b=mWcWKEm29yl5werSSFt9rhXAYV6LD56ae1Ykf8d7ZWK8QHacOAKzMyv8P+0clVLd Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ietf-http-auth@lists.osafoundation.org From: Mark Nottingham Date: Thu, 29 Nov 2007 10:53:45 -0800 X-Mailer: Apple Mail (2.752.3) Subject: [Ietf-http-auth] Bar BoF in Vancouver? X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 18:54:01 -0000 With draft-hartman-06 out, and the new discussion around draft-oiwa, is anyone interested in an informal discussion in Vancouver? Cheers, -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 31D1180B2A for ; Thu, 29 Nov 2007 02:24:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E558142206 for ; Thu, 29 Nov 2007 02:24:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-50 required=4 tests=[AWL=0.015, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDbZPAzLBMwn for ; Thu, 29 Nov 2007 02:24:47 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by laweleka.osafoundation.org (Postfix) with ESMTP id 11111142203 for ; Thu, 29 Nov 2007 02:24:46 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATAOj9o002050 for ; Thu, 29 Nov 2007 10:24:45 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS900301JKBT700@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for ietf-http-auth@osafoundation.org; Thu, 29 Nov 2007 03:24:45 -0700 (MST) Received: from [10.1.110.5] (24-205-138-209.dhcp.psdn.ca.charter.com [24.205.138.209]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS900DHOJL6EW50@mail-amer.sun.com>; Thu, 29 Nov 2007 03:24:45 -0700 (MST) Date: Thu, 29 Nov 2007 02:24:48 -0800 From: Chris Newman Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-reply-to: <20071127053105.380CE33C21@delta.rtfm.com> Sender: Chris.Newman@Sun.COM To: Eric Rescorla , Yutaka OIWA Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053105.380CE33C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 10:24:52 -0000 Eric Rescorla wrote on 11/26/07 21:31 -0800: > A few questions/comments: > > 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't > it be more straightforward to do this in TLS rather than adapting > Digest? I also would note that TLS-SRP has already been approved > by the IESG. Some people believe stuffing user authentication into the TLS layer to be bad design. Here's the text from my IESG abstain vote when TLS-SRP went informational: --- This is a weak abstain (I'm not asking other area directors to join my position). If the target were standards track, this would be a strong abstain. This a matter of application software architecture that applies to any user-based authentication mechanism embedded in TLS that involves or may involve unspecified server storage of per-user credential information. TLS stacks and the APIs to TLS stacks have started to ossify into operating systems, mobile devices and shipping application software. Such stacks are absolutely critical to application security, and are already so complex that they are the cause of a significant number of software defects and security updates. I am very concerned about adding unnecessary complexity to such a critical software component. There is already a great deal of flux upgrading the cipher suites, cipher modes and hash functions in these stacks. Meanwhile, all the software infrastructure in applications surrounding user identity, server credential repositories for users, and identity federation is highly complex and in a great deal of flux. If one looks at the amount of complexity in the GSSAPI or deployed general purpose SASL APIs and imagines the complexity of a software stack including all those APIs blended with a TLS API, I find the prospect daunting. Indeed the complexity is sufficiently great that I consider it bad architecture. Meanwhile, there's a viable alternative. If TLS and an authentication framework such as GSSAPI, EAP or SASL are loosely bound using a mechanism such as TLS channel bindings (TLS negotiates the security layer which is subsequently bound to a completely separate user authentication), then there is a very simple and clean boundary between the two software stacks, leading to a much more pragmatic real-world architecture. --- - Chris Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E1B780BE6 for ; Wed, 28 Nov 2007 16:37:54 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 07522142207 for ; Wed, 28 Nov 2007 16:37:55 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-50 required=4 tests=[AWL=0.892, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKbpuk09M8q8 for ; Wed, 28 Nov 2007 16:37:49 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5BE0E142206 for ; Wed, 28 Nov 2007 16:37:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAT0be7N024579 for ; Thu, 29 Nov 2007 00:37:47 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT0bdNq022241 for ; Wed, 28 Nov 2007 17:37:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT0bcjZ002627; Wed, 28 Nov 2007 18:37:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT0bcEB002626; Wed, 28 Nov 2007 18:37:38 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Nov 2007 18:37:38 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Message-ID: <20071129003738.GA2589@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129003519.GF2540@Sun.COM> User-Agent: Mutt/1.5.7i Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 00:37:54 -0000 [re-send without my slides attached, so it makes it to the list faster.] On Wed, Nov 28, 2007 at 06:35:19PM -0600, Nicolas Williams wrote: > On Wed, Nov 28, 2007 at 07:22:41PM -0500, Sam Hartman wrote: > > He's attempting to take advantage of membership in a federation to > > avoid dependence on CAs. I.E. section 4.6 of my draft. > > > > My text in this regard needs to be improved significantly. Nico > > Williams managed to state it much more clearly in a presentation he > > gave to Liberty and I need to incorporate his restatements. > > My presentation to the Liberty Staff is attached. See also my blog: > > http://blogs.sun.com/nico > > The short version is this: Ha! Not so short I guess. It's hard to summarize this, I'm afraid. > - we need to mutually authenticate users and servers > > - there must be a link between the authentication of users to servers > and servers to users > > - this link must be such that users can determine whether to trust the > server according to what "federation" was used to authenticate the > user to the server > > - "federation" matters because federations are (must) be smaller than > the capital-I Internet and, therefore, are able to effectively > white-/black-list member sites. > > I.e., a "Bank of Foo" federation should only allow my identity in > that federation to be used to authenticate to sites that the "Bank of > Foo" federation administrators trust. The "Bank of Foo" federation > can check for confusables, etc... in applicant members because they > have few members compared to the number of domains that exist in each > TLD (say). > > A "Bloggers Union of Foobar" federation might have many, many more > members, and thus be less able to keep out phishers, but users would > know not to trust, with important non-blogging data, sites to which > they authenticate with "Bloggers Union of Foobar" identities. > > - That last point brings up something important: UIs matter. The UI > in this proposal *must* make it clear to the user not just the name > of the site (think: status bar) but the identity/federation used to > authenticate the user. > > - The binding/mutuality of user<->server authentication is necessary to > prevent MITM attacks. > > Nico > -- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 42BA480B1F for ; Wed, 28 Nov 2007 16:22:50 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1BC53142213 for ; Wed, 28 Nov 2007 16:22:51 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-50 required=4 tests=[AWL=1.032, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRmMfihEvLHR for ; Wed, 28 Nov 2007 16:22:45 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by laweleka.osafoundation.org (Postfix) with ESMTP id 71B7A142206 for ; Wed, 28 Nov 2007 16:22:45 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A29EA4815; Wed, 28 Nov 2007 19:22:41 -0500 (EST) From: Sam Hartman To: Eliot Lear Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> Date: Wed, 28 Nov 2007 19:22:41 -0500 In-Reply-To: <474BDEED.9050809@cisco.com> (Eliot Lear's message of "Tue, 27 Nov 2007 10:10:05 +0100") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2007 00:22:50 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Roy T. Fielding wrote: >> Perhaps. I don't believe that CAs are careful enough in >> issuing certificates, and it is certainly the case that not all >> TLS sites bother to pay the tax for CA-signed certs. This >> algorithm should not be dependent on them. Perhaps what I am >> looking for is a mechanism that doesn't require Mutual Auth >> (aside from proving knowledge of a shared secret), but can >> still detect MITM. Eliot> Fundamentally phishing is possible because of an absence of Eliot> mutual authentication. I guess I don't understand what Eliot> problem you are attempting to solve. He's attempting to take advantage of membership in a federation to avoid dependence on CAs. I.E. section 4.6 of my draft. My text in this regard needs to be improved significantly. Nico Williams managed to state it much more clearly in a presentation he gave to Liberty and I need to incorporate his restatements. --Sam Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DBB4780AF7 for ; Tue, 27 Nov 2007 18:18:16 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B297A142203 for ; Tue, 27 Nov 2007 18:18:17 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-50 required=4 tests=[AWL=0.752, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yS+CrP5lka4t for ; Tue, 27 Nov 2007 18:18:11 -0800 (PST) Received: from spaceymail-a2.g.dreamhost.com (sd-green-bigip-145.dreamhost.com [208.97.132.145]) by laweleka.osafoundation.org (Postfix) with ESMTP id B6BEB1421EC for ; Tue, 27 Nov 2007 18:18:11 -0800 (PST) Received: from [10.2.8.60] (wsip-70-183-62-251.oc.oc.cox.net [70.183.62.251]) by spaceymail-a2.g.dreamhost.com (Postfix) with ESMTP id 572D8EE387; Tue, 27 Nov 2007 18:18:08 -0800 (PST) In-Reply-To: <87hcj8nosh.fsf@bluewind.rcis.aist.go.jp> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <87hcj8nosh.fsf@bluewind.rcis.aist.go.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <711BCB09-4EFC-44E7-A910-C3AE41ADF798@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Tue, 27 Nov 2007 18:18:07 -0800 To: Yutaka OIWA X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 02:18:20 -0000 On Nov 26, 2007, at 11:14 PM, Yutaka OIWA wrote: > Please allow me to answer some of your questions (simple to answer) > first. > > "Roy T. Fielding" writes: > >> The equations for J, w_A, T, z, K_i, and w_B are those >> specified for >> KAM3 in [ISO.11770-4.2006], given that pi is derived in the above >> equation. >> >> should be replaced by the actual equations, with only an informative >> reference to [ISO.11770-4.2006]. > > I see. As I am not expert of the exact requirements for IETF > standardization processes, this kind of suggestions are very > helpful. Maybe I could include the full equation in the next > draft. Please do. I do not think that it is a formal requirement for IETF, since the IETF would only need a stable reference (ISO is good for that). However, none of my projects would allow a "standard" for the web to be defined by a pay-per-view spec. >> [I don't understand the reasoning behind >> tls-cert being used at all, since in actual practice "certificate >> verification" is a waste of time (CAs are not secure). What >> matters is that the server reject a channel binding that >> would indicate a MITM attack, for which the tls-key should >> be sufficient. However, I am not a crypto expert.] > > This is because I am worrying about that forcing tls-key > authentication would cause some implementation difficulty > where black-box TLS implementations are used. > Tls-keys are usually hidden inside TLS modules, but > certs must be (in some way) available to the browser layer. > We are asking our implementation people under collaboration > to find out how exactly difficult to implement the tls-key, > so if the answer is "easy", we think we can safely drop the > tls-cert entirely. Ah, okay. That would be a nice "use case" to add to the draft to describe why each of these choices have been made. > In security, tls-cert itself can ensure safety even if self-signed > certificate is used, because the tls-cert validation effectively > checks matching of used secret key. When the server secret key paired > with the certificate is leaked, tls-cert will become vulnerable. Okay, my mistake. I thought that the tls-cert check was limited to CA-signed keys. In that case, I would suggest not having the tls-key option. ... > Actually, "sid" correspond to "server nonce" in Digest authentication > which must be kept in server-side. The name differs because > in Digest "nonce" is both a session identifier and an encryption > key at > the same time, but in Mutual authentication it is just an identifier. > > We carefully designed the protocol so that servers can be implemented > without having complex state managements. Server-side session caches > can be erased at any time after one request is served, this is just > the same as Digest does. Yes, but Digest was only implemented after a long period of failed attempts, MD5-sess only works on shared memory platforms, and even then the implementation we provide is at best a dummy implementation that needs to be hand-tweaked by real sites. None of that complexity was necessary for the original purpose of Digest to be a replacement for sending passwords. >> I think that the nonce and nc mechanisms are far too complex >> and dependent on both server state and "remembering" previous >> nonce values. What goals do these mechanisms serve? I suspect >> they can be accomplished by a single fixed server-provided >> nonce (64 bit server timestamp of nonce generation) and a simple >> client-provided nonce (counter). These values do not need to be >> "remembered" by the server -- the client is responsible for its >> own increments and the server can reject a returned server-nonce >> if its value is outside the TTL range of its own timestamp. > > Actually, nc mechanism seems to be complex in the specification, but > the requirements are very simple to implement. The purpose of the > nonce specification in the draft is to make Mutual authentication > secure against passive eavesdropping and limited replay attacks, to > the same level proper implementations of Digest authentication > provides. (Of course we recommend to use TLS for complete protection.) > > Seeing the real implementation of Digest mechanism, duplication check > of cnonce value is usually omitted. I observe that one reason for > this is that clients can choose whatever cnonces of their favorite, > and the server must remember all of those received cnonces for the > lifetime of the server nonce. This makes impossible to implement > servers to handle one session (specified by a server nonce) in fixed > amount of memory and makes it unscalable. The key point of our nc > specification is that server is explicitly allowed to reject any nc > values which are "old" (as defined by nc-window) as invalid requests, > and makes possible to check nc duplication in fixed amount of memory. > > > To answer auth-domain issue, we have to describe requirements to us > from > web-application designer's side, as I said, our proposal is to replace > flexible form-based authentication at the same time. Please let me > have > some minutes to assemble those up. Thanks, but there is no rush -- I will be in Vancouver and maybe that will give me a chance to understand the Apache module implementation. ....Roy Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A52697F777 for ; Tue, 27 Nov 2007 16:37:18 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7ACB31421FB for ; Tue, 27 Nov 2007 16:37:19 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOp1SuMxn7RQ for ; Tue, 27 Nov 2007 16:37:13 -0800 (PST) Received: from ro-out-1112.google.com (ro-out-1112.google.com [72.14.202.176]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C9601421F2 for ; Tue, 27 Nov 2007 16:37:13 -0800 (PST) Received: by ro-out-1112.google.com with SMTP id h4so2086688roe for ; Tue, 27 Nov 2007 16:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7NiQpv1+SD6PwLwamCrefU/S/Cj1ZydDqhkbALP5mc8=; b=hhELKBk4Eb9oIMcz5MXWRzG+YUoCai+mQybRmcEX5g9TKg4sYqz8mabdGw5a/30KcWWjR4qqe56M1cFqrlG4MZaWTQ1BQjwYmYMUlOHzDP6D8oSOGKXgBsEJQPE/00tdAQGdARyDOydgxYPeDMIBC3TkkHbms/HSnq3+Ic/53PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DpSMmUfORX1fQfSnePul6i//g2NqdJTKC3Hs6PLbGLnXxZGFmVN0gt9nFTQsEJSdJdNe8tCV/aOQINI7JVefREw9XaXn7qrTV+d5XDb1DhEV8NRFTz+7FqQkMdpFvBgrOb1n7WvoToTpSZXwimCsQmzHkVPmuiJ83wyrtbKhgJM= Received: by 10.114.137.2 with SMTP id k2mr377870wad.1196210231449; Tue, 27 Nov 2007 16:37:11 -0800 (PST) Received: by 10.114.27.9 with HTTP; Tue, 27 Nov 2007 16:37:11 -0800 (PST) Message-ID: <68fba5c50711271637p7ec52fdbj6cd80f6fe0dce63b@mail.gmail.com> Date: Tue, 27 Nov 2007 19:37:11 -0500 From: "Robert Sayre" To: "Eric Rescorla" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <20071127233659.6EDCF33C28@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> <20071127145817.64A9133C21@delta.rtfm.com> <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> <20071127220945.9079D33C23@delta.rtfm.com> <68fba5c50711271516v35232df2j203612a88aea5677@mail.gmail.com> <20071127233659.6EDCF33C28@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2007 00:37:18 -0000 On Nov 27, 2007 6:36 PM, Eric Rescorla wrote: > At Tue, 27 Nov 2007 18:16:51 -0500, > Robert Sayre wrote: > > > > On Nov 27, 2007 5:09 PM, Eric Rescorla wrote: > > > > > > In my experience, the content for which phishing is a real concern > > > is mostly dynamic and therefore is extremely difficult to cache. > > > > This is true of the HTML content, but not necessarily for the rest of > > the resources on the page, like images. Mixing HTTPS and HTTP > > resources results in warnings, display failures, etc in most modern > > browsers. > > Yes, as it should. Integrity of the images is important. Of course, > since what we're doing is talking about changing the client, > there are ways to solve this problem. The most obvious is to > attach a digest of the expected content to the link. Then it > would be safe to serve over HTTP. > > > > This is the reason well-funded sites like banks still serve > > forms over HTTP on their homepages (one exception I know of is > > bankofamerica.com). > > Hmm... Wells Fargo is also an exception. TLS is getting cheaper, > so I expect this to be near universal relatively soon. Counterexamples: http://wachovia.com, http://chase.com, http://gmail.com (though you can force https here) > > Serving non-cached ancillary resources over TLS > > connections to every unauthenticated client is expensive. > > I agree that it's more expensive than not doing so. I don't agree > that it's really prohibitively expensive. Depends how big your site is, and how bursty the traffic is. It seems hard to make the claim ahead of the requirements. > > > > > TLS is an appropriate solution for some authentication use cases, but > > > > certainly not all. > > > > > > Hmm... So there are a number of different security aspects to > > > disentangle here, but fundamentally, if you're going to bother with > > > mutual authentication, you probably need to provide message integrity > > > for the server's response. Otherwise, the attacker can simply proxy > > > your authentication handshake and then rewrite the pages to suit > > > himself, including attacking your authentication tokens (remember, > > > same site policy doesn't apply here). And once you're doing that, it's > > > really not much easier or proxy friendly to provide auth at the HTTP > > > layer than the TLS layer. If you think I'm wrong on this, I'd > > > love to see your protocol design. > > > > There is a desirable property concerning both request and response > > bodies that we're glossing over. The message recipient should be able > > to authenticate the message before processing the body. > > I agree that this is nice. I don't agree that it's critical. > Mostly, having to do the integrity check at the end > allows a sort of lame DoS attack. That seems irritating, but > not critical to fix. The importance varies with expected payloads. For form submissions, I agree it's probably not a big deal. Counterexample: The Content-MD5 approach is required by Amazon AWS. > Moreover, you still need an integrity check over the entire > message. This calls for some sort of chunked integrity. Luckily, TLS > has this. Could you explain further here? > > Even ignoring this issue, I'm not sure I understand what you are > proposing: when I fetch data out of the proxy cache, how do you > envision me getting message integrity. Ah, this is a good point, and maybe fatal if the cost of TLS approaches the cost of regular HTTP traffic. I was thinking of the text dealing with this issue in RFC 2617 (section 3.2.2.5), but it looks like that won't be sufficient, because it seems to rely on the proxy cache acting in good faith. A big underspecification in 2617, I think. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7C9E080AE6 for ; Tue, 27 Nov 2007 15:42:05 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 525601421FD for ; Tue, 27 Nov 2007 15:42:06 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-50 required=4 tests=[AWL=0.074, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlH+krnbbVZG for ; Tue, 27 Nov 2007 15:42:00 -0800 (PST) Received: from delta.rtfm.com (unknown [209.213.211.195]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3867A1421FC for ; Tue, 27 Nov 2007 15:42:00 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6EDCF33C28; Tue, 27 Nov 2007 15:36:59 -0800 (PST) Date: Tue, 27 Nov 2007 15:36:58 -0800 From: Eric Rescorla To: "Robert Sayre" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <68fba5c50711271516v35232df2j203612a88aea5677@mail.gmail.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> <20071127145817.64A9133C21@delta.rtfm.com> <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> <20071127220945.9079D33C23@delta.rtfm.com> <68fba5c50711271516v35232df2j203612a88aea5677@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127233659.6EDCF33C28@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 23:42:06 -0000 At Tue, 27 Nov 2007 18:16:51 -0500, Robert Sayre wrote: > > On Nov 27, 2007 5:09 PM, Eric Rescorla wrote: > > > > In my experience, the content for which phishing is a real concern > > is mostly dynamic and therefore is extremely difficult to cache. > > This is true of the HTML content, but not necessarily for the rest of > the resources on the page, like images. Mixing HTTPS and HTTP > resources results in warnings, display failures, etc in most modern > browsers. Yes, as it should. Integrity of the images is important. Of course, since what we're doing is talking about changing the client, there are ways to solve this problem. The most obvious is to attach a digest of the expected content to the link. Then it would be safe to serve over HTTP. > This is the reason well-funded sites like banks still serve > forms over HTTP on their homepages (one exception I know of is > bankofamerica.com). Hmm... Wells Fargo is also an exception. TLS is getting cheaper, so I expect this to be near universal relatively soon. > Serving non-cached ancillary resources over TLS > connections to every unauthenticated client is expensive. I agree that it's more expensive than not doing so. I don't agree that it's really prohibitively expensive. > > > TLS is an appropriate solution for some authentication use cases, but > > > certainly not all. > > > > Hmm... So there are a number of different security aspects to > > disentangle here, but fundamentally, if you're going to bother with > > mutual authentication, you probably need to provide message integrity > > for the server's response. Otherwise, the attacker can simply proxy > > your authentication handshake and then rewrite the pages to suit > > himself, including attacking your authentication tokens (remember, > > same site policy doesn't apply here). And once you're doing that, it's > > really not much easier or proxy friendly to provide auth at the HTTP > > layer than the TLS layer. If you think I'm wrong on this, I'd > > love to see your protocol design. > > There is a desirable property concerning both request and response > bodies that we're glossing over. The message recipient should be able > to authenticate the message before processing the body. I agree that this is nice. I don't agree that it's critical. Mostly, having to do the integrity check at the end allows a sort of lame DoS attack. That seems irritating, but not critical to fix. Moreover, you still need an integrity check over the entire message. This calls for some sort of chunked integrity. Luckily, TLS has this. > That is, > message integrity is only checked once credentials have been verified. > There are three distinct situations the scheme needs to check for: > > 1.) Request bodies > 2.) Cacheable response bodies > 3.) Non-cacheable response bodies > > 1 and 2 can be handled by including the value of a Content-MD5 > header as part of the digest. This allows servers to ignore message > bodies and skip integrity checks of client requests (e.g. video > uploads). The client must calculate the hash ahead of the request > for POST/PUT, but this burden is small for all but the most > write-heavy clients. It's also not much of a burden for servers to > calculate Content-MD5 once, in the case of cacheable resources. It's > the third situation that makes TLS message integrity more > appealing. One solution is to require either Content-MD5 (and thus > buffering of the full response) or a multipart response where the > second part contains the hash of the first part. For the latter, the > client would have to process the body, of course. Yes, one could optimize the situation beyond what TLS currently does, but the result is that one is forced to force-fit an authentication/handshake system that TLS already has (and is expensive to design and maintain) into the not particularly congenial HTTP dataflow. If you trust the cache and are just trying to avoid warnings from the browser (and are willing to change the browser) there are more attractive options, especially since there are plenty of settings where the page containing the media MUST be confidential, which means TLS. Even ignoring this issue, I'm not sure I understand what you are proposing: when I fetch data out of the proxy cache, how do you envision me getting message integrity. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7D1A680B40 for ; Tue, 27 Nov 2007 15:17:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 50FC11421FC for ; Tue, 27 Nov 2007 15:17:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-50 required=4 tests=[AWL=1.552, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruCp1D7s6SWd for ; Tue, 27 Nov 2007 15:16:57 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3C97614220F for ; Tue, 27 Nov 2007 15:16:53 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j40so1619721wah for ; Tue, 27 Nov 2007 15:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=S9aksCVb+5xe8AVKLKFlO5/26R1JYyHMhHiaeotvL/4=; b=X3zxdBL993o1nib1xXZfT63tgyhbcz2FLSiIBD67UJz9L922qEKtKTBuT0FDhcynAMRkE5lWicF2BqG2pxzcOe5Y4duz39BQpfQ8CIq+fD32+YyDF65f1tCcic5DzlPbF6rh1XhiWkM6ntcqCiV++qgKHhCFM8meXSGeZ9nKD3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QJbNYY5YeFU1fggxELl+c1tOCtnINabRTT0edDuPQDNEyIMm+55nW2w1CcO2WfSQ+36lCJH88MWNl204yUfsA9Acmni9rWo62NhxQrdfJ1NA65BnGyxnA4piA0ouiF96//swfZoDTYCfXgay4j5gYPSax4E1eTwqLwvQLTO/bp0= Received: by 10.115.54.1 with SMTP id g1mr76607wak.1196205411759; Tue, 27 Nov 2007 15:16:51 -0800 (PST) Received: by 10.114.27.9 with HTTP; Tue, 27 Nov 2007 15:16:51 -0800 (PST) Message-ID: <68fba5c50711271516v35232df2j203612a88aea5677@mail.gmail.com> Date: Tue, 27 Nov 2007 18:16:51 -0500 From: "Robert Sayre" To: "Eric Rescorla" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <20071127220945.9079D33C23@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> <20071127145817.64A9133C21@delta.rtfm.com> <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> <20071127220945.9079D33C23@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 23:17:03 -0000 On Nov 27, 2007 5:09 PM, Eric Rescorla wrote: > > In my experience, the content for which phishing is a real concern > is mostly dynamic and therefore is extremely difficult to cache. This is true of the HTML content, but not necessarily for the rest of the resources on the page, like images. Mixing HTTPS and HTTP resources results in warnings, display failures, etc in most modern browsers. This is the reason well-funded sites like banks still serve forms over HTTP on their homepages (one exception I know of is bankofamerica.com). Serving non-cached ancillary resources over TLS connections to every unauthenticated client is expensive. > > > TLS is an appropriate solution for some authentication use cases, but > > certainly not all. > > Hmm... So there are a number of different security aspects to > disentangle here, but fundamentally, if you're going to bother with > mutual authentication, you probably need to provide message integrity > for the server's response. Otherwise, the attacker can simply proxy > your authentication handshake and then rewrite the pages to suit > himself, including attacking your authentication tokens (remember, > same site policy doesn't apply here). And once you're doing that, it's > really not much easier or proxy friendly to provide auth at the HTTP > layer than the TLS layer. If you think I'm wrong on this, I'd > love to see your protocol design. There is a desirable property concerning both request and response bodies that we're glossing over. The message recipient should be able to authenticate the message before processing the body. That is, message integrity is only checked once credentials have been verified. There are three distinct situations the scheme needs to check for: 1.) Request bodies 2.) Cacheable response bodies 3.) Non-cacheable response bodies 1 and 2 can be handled by including the value of a Content-MD5 header as part of the digest. This allows servers to ignore message bodies and skip integrity checks of client requests (e.g. video uploads). The client must calculate the hash ahead of the request for POST/PUT, but this burden is small for all but the most write-heavy clients. It's also not much of a burden for servers to calculate Content-MD5 once, in the case of cacheable resources. It's the third situation that makes TLS message integrity more appealing. One solution is to require either Content-MD5 (and thus buffering of the full response) or a multipart response where the second part contains the hash of the first part. For the latter, the client would have to process the body, of course. - Rob Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 11E4880B20 for ; Tue, 27 Nov 2007 14:14:51 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DACE4142207 for ; Tue, 27 Nov 2007 14:14:51 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-50 required=4 tests=[AWL=0.076, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xtMFFS3lRMf for ; Tue, 27 Nov 2007 14:14:46 -0800 (PST) Received: from delta.rtfm.com (unknown [209.213.211.195]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54604142203 for ; Tue, 27 Nov 2007 14:14:46 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9079D33C23; Tue, 27 Nov 2007 14:09:45 -0800 (PST) Date: Tue, 27 Nov 2007 14:09:44 -0800 From: Eric Rescorla To: "Robert Sayre" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> <20071127145817.64A9133C21@delta.rtfm.com> <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127220945.9079D33C23@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 22:14:51 -0000 At Tue, 27 Nov 2007 13:48:19 -0500, Robert Sayre wrote: > > On Nov 27, 2007 9:58 AM, Eric Rescorla wrote: > > > > Again, support for this is ALREADY IN TLS, which solves all the > > relevant channel security issues. > > Unfortunately, HTTP scalability relies on caching by intermediaries. I'm not sure I believe this, but let's stipulate that it's true. In my experience, the content for which phishing is a real concern is mostly dynamic and therefore is extremely difficult to cache. If you have extensive static content, you can do TLS for the initial authentication and then use cookies over HTTP for continuing authentication to allow caching. > TLS is an appropriate solution for some authentication use cases, but > certainly not all. Hmm... So there are a number of different security aspects to disentangle here, but fundamentally, if you're going to bother with mutual authentication, you probably need to provide message integrity for the server's response. Otherwise, the attacker can simply proxy your authentication handshake and then rewrite the pages to suit himself, including attacking your authentication tokens (remember, same site policy doesn't apply here). And once you're doing that, it's really not much easier or proxy friendly to provide auth at the HTTP layer than the TLS layer. If you think I'm wrong on this, I'd love to see your protocol design. Now, one *could* argue that one's only concern was dictionary attack and that therefore mutual auth wasn't needed, but I think that's wrong for the reasons Chris alluded to earlier. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0C07480B3F for ; Tue, 27 Nov 2007 10:48:27 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CB5161421FD for ; Tue, 27 Nov 2007 10:48:27 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-50 required=4 tests=[AWL=1.598, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40eNaoIo1QG9 for ; Tue, 27 Nov 2007 10:48:22 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4F7611421F1 for ; Tue, 27 Nov 2007 10:48:22 -0800 (PST) Received: by an-out-0708.google.com with SMTP id d30so239598and for ; Tue, 27 Nov 2007 10:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qPCstOgB5ht/vP89AVjHDzeCd6QhMWjjs2s4WKGESH4=; b=aRiiQWas+LJX+i2rLWbFR9rTW0Lf5Ww0VFjHLDQLadwiX8vv+zBosJAtA64kwdRWGe1XoNBnCLCiAWgZ+YX04wiSfJcxj2UMS3A8JJGcGaHF3/E1ZFtYeTzQDckZrqda+EZNdz7XlpXhpTzxPN4Ta2GJvg+D+vOkBlhRt3eU6NA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A52R/iF6B6MYy0Sv/jaGmyfSFrQbLck2yAcjbAMHW+rZFlorGa8BrODT4lXW56XC/TxXNaieZgyymGt8ipvpwR+YgrLjV+ggWywmgu+hbZQVfxFeSDhiY/4c5xKej4bk/3INuGfnBdvfibU8dtUqZkeLFY7O/cqq9JDbyVu0XEQ= Received: by 10.115.90.1 with SMTP id s1mr47162wal.1196189299250; Tue, 27 Nov 2007 10:48:19 -0800 (PST) Received: by 10.114.27.9 with HTTP; Tue, 27 Nov 2007 10:48:19 -0800 (PST) Message-ID: <68fba5c50711271048r1fe5af41m684b9c5e0f4e66c4@mail.gmail.com> Date: Tue, 27 Nov 2007 13:48:19 -0500 From: "Robert Sayre" To: "Eric Rescorla" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <20071127145817.64A9133C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> <20071127145817.64A9133C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 18:48:27 -0000 On Nov 27, 2007 9:58 AM, Eric Rescorla wrote: > > Again, support for this is ALREADY IN TLS, which solves all the > relevant channel security issues. Unfortunately, HTTP scalability relies on caching by intermediaries. TLS is an appropriate solution for some authentication use cases, but certainly not all. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E16E3809D5 for ; Tue, 27 Nov 2007 07:03:21 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B3EBD1421FD for ; Tue, 27 Nov 2007 07:03:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-50 required=4 tests=[AWL=0.071, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 139DQc3qM8Z6 for ; Tue, 27 Nov 2007 07:03:17 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3EA961421FC for ; Tue, 27 Nov 2007 07:03:17 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 64A9133C21; Tue, 27 Nov 2007 06:58:17 -0800 (PST) Date: Tue, 27 Nov 2007 06:58:17 -0800 From: Eric Rescorla To: "Robert Sayre" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127145817.64A9133C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 15:03:22 -0000 At Tue, 27 Nov 2007 05:35:42 -0500, Robert Sayre wrote: > > On Nov 27, 2007 5:25 AM, Chris Drake wrote: > > Hi Roy, > > > > While it may be cool to deny phishers access to passwords - that's not > > really solving the whole underlying problem. Look-alike sites can and > > do exist for other reasons, and if a potential victim entered their > > password, which was then scrambled and sent to the wrong place > > (phisher), but the phisher ignored it and displayed the expected > > "next page", that's giving the user false confidence that they're on > > some trusted site now... > > It is the first, easier step needed to solve the problem. Mutual > authentication combined new browser UI would be needed to combat the > problem you're describing. > > FWIW, I got pretty far with a Firefox patch for a Digest variant that > uses SRP. I had to shelve it in Firefox 3 for scheduling reasons. > > https://bugzilla.mozilla.org/show_bug.cgi?id=356855 > > The scheme in the bug and linked drafts might invest too much effort > in message integrity. It is easy to go too far there in an effort to > prevent MITM attacks. Unfortunately, I don't think that's true. Unless you provide server->client message integrity, you're extremely susceptible to "mafia fraud/bucket brigade" type attacks. And of course, unless you tie this to the TLS connection somehow you've still got confidentiality issues for any data passed over the connection. Again, support for this is ALREADY IN TLS, which solves all the relevant channel security issues. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B5226809C0 for ; Tue, 27 Nov 2007 07:00:21 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 88E551421FC for ; Tue, 27 Nov 2007 07:00:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-50 required=4 tests=[AWL=0.071, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5el7UEW84xs3 for ; Tue, 27 Nov 2007 07:00:17 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id F1FEC1421FB for ; Tue, 27 Nov 2007 07:00:16 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2344033C21; Tue, 27 Nov 2007 06:55:17 -0800 (PST) Date: Tue, 27 Nov 2007 06:55:16 -0800 From: Eric Rescorla To: Chris Drake Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <1714480656.20071127202508@pobox.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127145517.2344033C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 15:00:21 -0000 At Tue, 27 Nov 2007 20:25:08 +1000, Chris Drake wrote: > > Hi Roy, > > While it may be cool to deny phishers access to passwords - that's not > really solving the whole underlying problem. Look-alike sites can and > do exist for other reasons, and if a potential victim entered their > password, which was then scrambled and sent to the wrong place > (phisher), but the phisher ignored it and displayed the expected > "next page", that's giving the user false confidence that they're on > some trusted site now Yes, this is exactly why techniques that use the password to establish a secure channel are attractive: if the phisher doesn't know the password then you can't establish a connection with them at all. There are actually two issues getting conflated here: 1. The current HTTP authentication techniques involve the client proving to the server that they share a secret, but not vice versa. There are a variety of solutions that fix this problem, but the general idea is to use the shared secret to form a cryptographic key which is used to encipher/MAC/whatever the messages flowing between client and server so that the phisher can't impersonate the server using the attack you suggest. 2. There are at least two basic techniques for building a protocol of type (1) above. The first is to use the password directly, e.g., key = Hash(Password). The difficulty here is that an exhaustive search of the password space can be used to recover the key based on a single recorded transaction. The second is to use what's called Password Authenticated Key Agreement (PAKE) or Zero Knowledge Password Proof (ZKPP). These are public key based schemes that have the interesting property that they bootstrap a password up to a key in such a way that you can't do dictionary search. The simplest of these schemes is EKE. The difficulty here is that most of these schemes have an uh, interesting IPR story. The attack you're discussing is actually stopped by (1). The phisher then has to do a dictionary attack on your password to impersonate the server. Obviously, (2) is more secure. Again, I want to stress that TLS *already has* support for both kinds of schemes in TLS-PSK (RFC 4279) and in TLS-SRP (draft-ietf-tls-srp-14, currently in RFC Ed queue.) If this is the path you want to go down, there is with high probability no need to invent anything new, and almost certainly no need to put it in HTTP. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CE37280B25 for ; Tue, 27 Nov 2007 06:44:50 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A189B1421FB for ; Tue, 27 Nov 2007 06:44:51 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-50 required=4 tests=[AWL=0.072, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xSXDXVqHMMs for ; Tue, 27 Nov 2007 06:44:46 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 30A421421F2 for ; Tue, 27 Nov 2007 06:44:46 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E4DA033C33; Tue, 27 Nov 2007 06:39:45 -0800 (PST) Date: Tue, 27 Nov 2007 06:39:45 -0800 From: Eric Rescorla To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127143945.E4DA033C33@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 14:44:50 -0000 At Tue, 27 Nov 2007 00:28:14 -0800, Roy T. Fielding wrote: > > On Nov 26, 2007, at 9:37 PM, Eric Rescorla wrote: > >> IMO, auth-domain needs to be the entire URI prefix for the area > >> over which the same authentication applies (scheme, authority, > >> and path-prefix [what the draft calls host + path]), what I > >> would call the auth-prefix, and should be required as a field > >> value on all requests in addition to being included within > >> the hash. The validation would always include this auth-prefix > >> for unencrypted channels, and *both* the auth-prefix and tls-key > >> for TLS channels. [I don't understand the reasoning behind > >> tls-cert being used at all, since in actual practice "certificate > >> verification" is a waste of time (CAs are not secure). > > > > As a side note, this claim strikes me as substantially too > > strong. > > Perhaps. I don't believe that CAs are careful enough in issuing > certificates, and it is certainly the case that not all TLS sites > bother to pay the tax for CA-signed certs. This algorithm should > not be dependent on them. Perhaps what I am looking for is a > mechanism that doesn't require Mutual Auth (aside from proving > knowledge of a shared secret), but can still detect MITM. I agree with all of this. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7A03C7F586 for ; Tue, 27 Nov 2007 04:24:29 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4085E142204 for ; Tue, 27 Nov 2007 04:24:30 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-50 required=4 tests=[AWL=0.504, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ib4WlMo2tw3 for ; Tue, 27 Nov 2007 04:24:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76DA7142202 for ; Tue, 27 Nov 2007 04:24:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.23,219,1194217200"; d="scan'208";a="158883779" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 13:24:22 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lARCOMTQ011393; Tue, 27 Nov 2007 13:24:22 +0100 Received: from Macintosh.local (ams3-vpn-dhcp195.cisco.com [10.61.64.195]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lARCOLZZ007782; Tue, 27 Nov 2007 12:24:21 GMT Message-ID: <474C0C74.40709@cisco.com> Date: Tue, 27 Nov 2007 13:24:20 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chris Drake Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> In-Reply-To: <1714480656.20071127202508@pobox.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=700; t=1196166262; x=1197030262; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-http-auth]=20submitted=20draft-oiwa-http-mutual auth-01.txt |Sender:=20; bh=Qgqwgq6S21cWJHQAMFokLFDoKJidPS3jrxELzLL5Gog=; b=Ol3zXMFToFINimxmXVQLVsNo0hcgT2rzTKzGGVp2ACTF72S9xyLY1vx2QUt/S69Mun7H5eTd vb3ikd8916iF8sIY/Imu0AGrtYlsECFnsabIZCVcpcCKLGo3aDasnKYJ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 12:24:29 -0000 Chris Drake wrote: > Hi Roy, > > While it may be cool to deny phishers access to passwords - that's not > really solving the whole underlying problem. Look-alike sites can and > do exist for other reasons, and if a potential victim entered their > password, which was then scrambled and sent to the wrong place > (phisher), but the phisher ignored it and displayed the expected > "next page", that's giving the user false confidence that they're on > some trusted site now [...] So what you want is some proof that this site X is the same site X with which you previously registered. You actually don't care if anyone else is asserting that Site X is actually THE Site X. Eliot Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 65AFD80AB3 for ; Tue, 27 Nov 2007 03:40:38 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 394E61421FC for ; Tue, 27 Nov 2007 03:40:39 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-50 required=4 tests=[AWL=0.153, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY1jRAvUxOMd for ; Tue, 27 Nov 2007 03:40:33 -0800 (PST) Received: from srve.com (srve.com [208.69.183.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 98A631421FD for ; Tue, 27 Nov 2007 03:40:31 -0800 (PST) Received: from localhost (www.hunneypocketed.emsvr.com [203.206.137.129] (may be forged)) (authenticated bits=0) by srve.com (8.13.8/8.13.8/CWT/DCE) with ESMTP id lARBe68E016843 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 11:40:09 GMT Date: Tue, 27 Nov 2007 21:40:15 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1804247030.20071127214015@pobox.com> To: "Robert Sayre" Subject: Re[4]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 11:40:38 -0000 Hi Robert, Congrats on your initial solution. I would have thought thought, that after coding this, you'd have realized that the problem of phishing obsoletes the paradigm of solution "components" - it's just not possible to solve the problem in pieces. You need to start with a "blank page" and a complete understanding of what you want to fix, then devise the whole solution. If you just fix one bit - you'll quickly discover that the "before and after" components that you were hoping someone else might do one day will never "fit" - if they're even possible to do at all, and if anyone ever does them anyhow... Kind Regards, Chris Drake Tuesday, November 27, 2007, 8:35:42 PM, you wrote: RS> On Nov 27, 2007 5:25 AM, Chris Drake wrote: >> Hi Roy, >> >> While it may be cool to deny phishers access to passwords - that's not >> really solving the whole underlying problem. Look-alike sites can and >> do exist for other reasons, and if a potential victim entered their >> password, which was then scrambled and sent to the wrong place >> (phisher), but the phisher ignored it and displayed the expected >> "next page", that's giving the user false confidence that they're on >> some trusted site now... RS> It is the first, easier step needed to solve the problem. Mutual RS> authentication combined new browser UI would be needed to combat the RS> problem you're describing. RS> FWIW, I got pretty far with a Firefox patch for a Digest variant that RS> uses SRP. I had to shelve it in Firefox 3 for scheduling reasons. RS> https://bugzilla.mozilla.org/show_bug.cgi?id=356855 RS> The scheme in the bug and linked drafts might invest too much effort RS> in message integrity. It is easy to go too far there in an effort to RS> prevent MITM attacks. Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3687380AF8 for ; Tue, 27 Nov 2007 02:35:49 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 087AE1421FF for ; Tue, 27 Nov 2007 02:35:50 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-50 required=4 tests=[AWL=1.647, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmFOVSrpOuGb for ; Tue, 27 Nov 2007 02:35:44 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C2971421F2 for ; Tue, 27 Nov 2007 02:35:44 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j40so1307567wah for ; Tue, 27 Nov 2007 02:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=LIgCGusHEOakY7OgrEO3mLkn/mdcSE0QazLA5/4bmQo=; b=ucKY/AcicD1m8fL1m+FB44qWMiYySgwyetuOna789paSlttH5tKb4hqH4a9BBvQfcW8/gPaX7k1RQhkhNbhpTkzCpqGJ1+nuv2v2wJk7eKX9QyH29cuV1X8QN+eL6OSdVv8AfNgrJjkO/KLYQIFkc4iHLXzJYiVp66+TwKwsXvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W7X/MreVmGdjWTWVTyi61s8bxWNS14s//LoX4OimIG2VTIkhHoEEpJDfS8cx8AOtXgtqXS8fxjv+2ssztzQ1BXcHjHZCF42QVirPxc1TKl3YsjM04ov0xgpmI4eKaL3ISH8kl+jx2b9Ahnd4QGeevGZP0ZddmIxvLxbZtc5qF6w= Received: by 10.114.196.1 with SMTP id t1mr467474waf.1196159743023; Tue, 27 Nov 2007 02:35:43 -0800 (PST) Received: by 10.114.27.9 with HTTP; Tue, 27 Nov 2007 02:35:42 -0800 (PST) Message-ID: <68fba5c50711270235q7b68372bgcd1f6d25948d01f5@mail.gmail.com> Date: Tue, 27 Nov 2007 05:35:42 -0500 From: "Robert Sayre" To: "Chris Drake" Subject: Re: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <1714480656.20071127202508@pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> <1714480656.20071127202508@pobox.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 10:35:49 -0000 On Nov 27, 2007 5:25 AM, Chris Drake wrote: > Hi Roy, > > While it may be cool to deny phishers access to passwords - that's not > really solving the whole underlying problem. Look-alike sites can and > do exist for other reasons, and if a potential victim entered their > password, which was then scrambled and sent to the wrong place > (phisher), but the phisher ignored it and displayed the expected > "next page", that's giving the user false confidence that they're on > some trusted site now... It is the first, easier step needed to solve the problem. Mutual authentication combined new browser UI would be needed to combat the problem you're describing. FWIW, I got pretty far with a Firefox patch for a Digest variant that uses SRP. I had to shelve it in Firefox 3 for scheduling reasons. https://bugzilla.mozilla.org/show_bug.cgi?id=356855 The scheme in the bug and linked drafts might invest too much effort in message integrity. It is easy to go too far there in an effort to prevent MITM attacks. -- Robert Sayre "I would have written a shorter letter, but I did not have the time." Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7205B80AF7 for ; Tue, 27 Nov 2007 02:25:22 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E82261421FF for ; Tue, 27 Nov 2007 02:25:22 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-50 required=4 tests=[AWL=0.167, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeJiskLIvOZf for ; Tue, 27 Nov 2007 02:25:17 -0800 (PST) Received: from srve.com (srve.com [208.69.183.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 29AF2142204 for ; Tue, 27 Nov 2007 02:25:17 -0800 (PST) Received: from localhost (www.hunneypocketed.emsvr.com [203.206.137.129] (may be forged)) (authenticated bits=0) by srve.com (8.13.8/8.13.8/CWT/DCE) with ESMTP id lARAP6ZY015673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 10:25:10 GMT Date: Tue, 27 Nov 2007 20:25:08 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1714480656.20071127202508@pobox.com> To: "Roy T. Fielding" Subject: Re[2]: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 10:25:22 -0000 Hi Roy, While it may be cool to deny phishers access to passwords - that's not really solving the whole underlying problem. Look-alike sites can and do exist for other reasons, and if a potential victim entered their password, which was then scrambled and sent to the wrong place (phisher), but the phisher ignored it and displayed the expected "next page", that's giving the user false confidence that they're on some trusted site now - thus they're highly susceptible to all kinds of subsequent attacks - "click here to install our new banking access security component", or, "your password has expired - please choose a new one", or, "we need to verify your account - please enter your phone-number/social-security-number/password-again/credit-card/..."; the brazen could even phone the victim in real-time, and ask for their password. I recall listening to my Dad taking a (legit) call from his phone company - they asked for his date of birth, full name, and account PIN - all of which he gave without questioning. After the call, I told him he was mad for giving some random stranger all that info, and he called me an idiot - "Who else would ever need to ask me that information" he snapped. Phishers are not stupid. If you plug only one hole, they'll just switch to another. Only a holistic solution is worthwhile. If you don't 100% protect stupid users against smart phishers, you're just wasting everyone's time and potentially making things worse. Kind Regards, Chris Drake Tuesday, November 27, 2007, 7:37:18 PM, you wrote: RTF> On Nov 27, 2007, at 1:10 AM, Eliot Lear wrote: >> Roy T. Fielding wrote: >>> Perhaps. I don't believe that CAs are careful enough in issuing >>> certificates, and it is certainly the case that not all TLS sites >>> bother to pay the tax for CA-signed certs. This algorithm should >>> not be dependent on them. Perhaps what I am looking for is a >>> mechanism that doesn't require Mutual Auth (aside from proving >>> knowledge of a shared secret), but can still detect MITM. >> >> Fundamentally phishing is possible because of an absence of mutual >> authentication. RTF> They may not be mutually exclusive -- it is possible to defeat phishing RTF> by proving that the server knows the same secret that the client knows RTF> (usually a password) in a way that can't be relayed/mirrored by a MITM. RTF> Exchanging that proof without actually exchanging the secret and RTF> without enclosing the entire session in TLS is what I want. RTF> I would call that a form of mutual authentication, whereas RTF> I think others tend to assume that Mutual Auth has to include RTF> domain/ownership association as well. YMMV. I don't know what RTF> is included in the "real" definition of mutual auth, or even if RTF> there is one such definition that security folks prefer. RTF> ....Roy RTF> _______________________________________________ RTF> Ietf-http-auth mailing list RTF> Ietf-http-auth@osafoundation.org RTF> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1AEA67F556 for ; Tue, 27 Nov 2007 01:37:29 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E00F9142202 for ; Tue, 27 Nov 2007 01:37:29 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-50 required=4 tests=[AWL=0.276, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME11EbjA59Qa for ; Tue, 27 Nov 2007 01:37:24 -0800 (PST) Received: from spaceymail-a2.g.dreamhost.com (sd-green-bigip-66.dreamhost.com [208.97.132.66]) by laweleka.osafoundation.org (Postfix) with ESMTP id 655D91421FD for ; Tue, 27 Nov 2007 01:37:24 -0800 (PST) Received: from [192.168.0.160] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a2.g.dreamhost.com (Postfix) with ESMTP id 0F37DEE3C9; Tue, 27 Nov 2007 01:37:22 -0800 (PST) In-Reply-To: <474BDEED.9050809@cisco.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <64ED1D49-8D15-418B-AAC3-BF51F185B1FA@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Tue, 27 Nov 2007 01:37:18 -0800 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 09:37:29 -0000 On Nov 27, 2007, at 1:10 AM, Eliot Lear wrote: > Roy T. Fielding wrote: >> Perhaps. I don't believe that CAs are careful enough in issuing >> certificates, and it is certainly the case that not all TLS sites >> bother to pay the tax for CA-signed certs. This algorithm should >> not be dependent on them. Perhaps what I am looking for is a >> mechanism that doesn't require Mutual Auth (aside from proving >> knowledge of a shared secret), but can still detect MITM. > > Fundamentally phishing is possible because of an absence of mutual > authentication. They may not be mutually exclusive -- it is possible to defeat phishing by proving that the server knows the same secret that the client knows (usually a password) in a way that can't be relayed/mirrored by a MITM. Exchanging that proof without actually exchanging the secret and without enclosing the entire session in TLS is what I want. I would call that a form of mutual authentication, whereas I think others tend to assume that Mutual Auth has to include domain/ownership association as well. YMMV. I don't know what is included in the "real" definition of mutual auth, or even if there is one such definition that security folks prefer. ....Roy Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BD02A80AC1 for ; Tue, 27 Nov 2007 01:10:12 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8F7C71421FD for ; Tue, 27 Nov 2007 01:10:13 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-50 required=4 tests=[AWL=0.507, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+J5KgdnF8H9 for ; Tue, 27 Nov 2007 01:10:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id D08FA1421FC for ; Tue, 27 Nov 2007 01:10:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.23,218,1194217200"; d="scan'208";a="158854579" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 27 Nov 2007 10:10:06 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAR9A5S8004898; Tue, 27 Nov 2007 10:10:05 +0100 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp501.cisco.com [10.61.65.245]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAR9A5ZZ014608; Tue, 27 Nov 2007 09:10:05 GMT Message-ID: <474BDEED.9050809@cisco.com> Date: Tue, 27 Nov 2007 10:10:05 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> In-Reply-To: <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=589; t=1196154605; x=1197018605; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Ietf-http-auth]=20submitted=20draft-oiwa-http-mutual auth-01.txt |Sender:=20; bh=St5ovFwDurmap0DBJj/w6gfeKw20a9vibQgDG26vXc0=; b=Gi6rnKHJU0U0EYxVkvabDaDeFbbaB1W4di5zaRsTX7XyWUO+XZeINgWRmnG+xdek+5RYGE6A KqkQra1RHmNwz0yMpWzPoYCpT5kFvDtNzA5AW1pU4XUnTmguH2RnIi1b; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 09:10:12 -0000 Roy T. Fielding wrote: > Perhaps. I don't believe that CAs are careful enough in issuing > certificates, and it is certainly the case that not all TLS sites > bother to pay the tax for CA-signed certs. This algorithm should > not be dependent on them. Perhaps what I am looking for is a > mechanism that doesn't require Mutual Auth (aside from proving > knowledge of a shared secret), but can still detect MITM. Fundamentally phishing is possible because of an absence of mutual authentication. I guess I don't understand what problem you are attempting to solve. Eliot Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E494080AB3 for ; Tue, 27 Nov 2007 00:28:22 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B59081421FD for ; Tue, 27 Nov 2007 00:28:23 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-50 required=4 tests=[AWL=0.283, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75RH-q7kjEt3 for ; Tue, 27 Nov 2007 00:28:18 -0800 (PST) Received: from spaceymail-a2.g.dreamhost.com (sd-green-bigip-66.dreamhost.com [208.97.132.66]) by laweleka.osafoundation.org (Postfix) with ESMTP id 42AFB1421FC for ; Tue, 27 Nov 2007 00:28:18 -0800 (PST) Received: from [192.168.0.160] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a2.g.dreamhost.com (Postfix) with ESMTP id E5730EE3D2; Tue, 27 Nov 2007 00:28:18 -0800 (PST) In-Reply-To: <20071127053732.075BC33C21@delta.rtfm.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Tue, 27 Nov 2007 00:28:14 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 08:28:23 -0000 On Nov 26, 2007, at 9:37 PM, Eric Rescorla wrote: >> IMO, auth-domain needs to be the entire URI prefix for the area >> over which the same authentication applies (scheme, authority, >> and path-prefix [what the draft calls host + path]), what I >> would call the auth-prefix, and should be required as a field >> value on all requests in addition to being included within >> the hash. The validation would always include this auth-prefix >> for unencrypted channels, and *both* the auth-prefix and tls-key >> for TLS channels. [I don't understand the reasoning behind >> tls-cert being used at all, since in actual practice "certificate >> verification" is a waste of time (CAs are not secure). > > As a side note, this claim strikes me as substantially too > strong. Perhaps. I don't believe that CAs are careful enough in issuing certificates, and it is certainly the case that not all TLS sites bother to pay the tax for CA-signed certs. This algorithm should not be dependent on them. Perhaps what I am looking for is a mechanism that doesn't require Mutual Auth (aside from proving knowledge of a shared secret), but can still detect MITM. ....Roy Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B38C880AE6 for ; Mon, 26 Nov 2007 23:48:09 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7E0E21421FF for ; Mon, 26 Nov 2007 23:48:10 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-50 required=4 tests=[AWL=0.291, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4DwzHnYkKA1 for ; Mon, 26 Nov 2007 23:48:05 -0800 (PST) Received: from spaceymail-a3.g.dreamhost.com (balanced.mail.policyd.dreamhost.com [208.97.132.119]) by laweleka.osafoundation.org (Postfix) with ESMTP id F3E3A1421FB for ; Mon, 26 Nov 2007 23:48:04 -0800 (PST) Received: from [192.168.0.160] (ip72-211-200-45.oc.oc.cox.net [72.211.200.45]) by spaceymail-a3.g.dreamhost.com (Postfix) with ESMTP id 4F750195355; Mon, 26 Nov 2007 23:48:03 -0800 (PST) In-Reply-To: <20071127054104.EE0BF33C21@delta.rtfm.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <20071127054104.EE0BF33C21@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Mon, 26 Nov 2007 23:47:58 -0800 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 07:48:10 -0000 On Nov 26, 2007, at 9:41 PM, Eric Rescorla wrote: > At Mon, 26 Nov 2007 21:37:31 -0800, > Eric Rescorla wrote: >> >> At Mon, 26 Nov 2007 20:36:59 -0800, >> Roy T. Fielding wrote: >>> should be replaced by the actual equations, with only an informative >>> reference to [ISO.11770-4.2006]. I suspect these are just a >>> variation >>> of the SRP or PwdHash techniques that have been published before, >>> but >>> I have no access to the ISO document to verify. >> >> It's important to note that PwdHash and SRP really are quite >> qualitatively different. >> >> - SRP is a mechanism for a pair of agents to derive a strong >> shared key starting with only a weak shared secret. >> - PwdHash is purely a password diversification technique: it >> allows you to use a single memorized password to produce >> different passwords for each server you communicate with. >> >> These really aren't the same thing at all. In the context of > > Oops. Hit send too early. > > In the setting we're talking about here, the major differences > include: > > - PwdHash is subject to offline dictionary attacks. SRP is not. > - SRP is designed to be used to key a data security protocol. > PwdHash is designed to simply give you a new password you > feed into the ordinary password mechanisms. Yeah, I meant to delete that reference to PwdHash but forgot in my rush to get home for dinner -- it's been at least 18 months since I read those papers and others on EKE, SAKA, PAKE (Katz/Ostrovsky/Yung 2001), IEEE P1363.2/D23, ... and it is all a blur at this point. ....Roy Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ECE0B8077D for ; Mon, 26 Nov 2007 23:14:38 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BD7241421FF for ; Mon, 26 Nov 2007 23:14:39 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpZY-vwbKMEu for ; Mon, 26 Nov 2007 23:14:33 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by laweleka.osafoundation.org (Postfix) with ESMTP id E9CC21421FB for ; Mon, 26 Nov 2007 23:14:28 -0800 (PST) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id lAR7E7Ja010865; Tue, 27 Nov 2007 16:14:11 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id lAR7E7MZ012823; Tue, 27 Nov 2007 16:14:07 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id lAR7E6pn015904; Tue, 27 Nov 2007 16:14:06 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> From: Yutaka OIWA Date: Tue, 27 Nov 2007 16:14:06 +0900 In-Reply-To: (Roy T. Fielding's message of "Mon, 26 Nov 2007 20:36:59 -0800") Message-ID: <87hcj8nosh.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 07:14:39 -0000 Dear Roy, Thank you very much for very prompt reply. Please allow me to answer some of your questions (simple to answer) first. "Roy T. Fielding" writes: > The equations for J, w_A, T, z, K_i, and w_B are those specified for > KAM3 in [ISO.11770-4.2006], given that pi is derived in the above > equation. > > should be replaced by the actual equations, with only an informative > reference to [ISO.11770-4.2006]. I see. As I am not expert of the exact requirements for IETF standardization processes, this kind of suggestions are very helpful. Maybe I could include the full equation in the next draft. > [I don't understand the reasoning behind > tls-cert being used at all, since in actual practice "certificate > verification" is a waste of time (CAs are not secure). What > matters is that the server reject a channel binding that > would indicate a MITM attack, for which the tls-key should > be sufficient. However, I am not a crypto expert.] This is because I am worrying about that forcing tls-key authentication would cause some implementation difficulty where black-box TLS implementations are used. Tls-keys are usually hidden inside TLS modules, but certs must be (in some way) available to the browser layer. We are asking our implementation people under collaboration to find out how exactly difficult to implement the tls-key, so if the answer is "easy", we think we can safely drop the tls-cert entirely. In security, tls-cert itself can ensure safety even if self-signed certificate is used, because the tls-cert validation effectively checks matching of used secret key. When the server secret key paired with the certificate is leaked, tls-cert will become vulnerable. > "logout-timeout" should be named "ttl" (bits matter) and its > expiration MUST result in clearing the authentication state > unless updated by a later ttl. In addition, clients should > be reminded (again) that any login UI should have a > corresponding client-side logout UI, even though that logout > is not communicated via the protocol. I agree. For the UI matter, please let me think again what amount of requirements to be stated "REQUIRED" in protocol specification, and what kind of issues are kept to be informational. > I don't think it is necessary to have a sid -- that adds > session state to the protocol, for no apparent reason, and > thus greatly reduces the scalability of servers. Actually, "sid" correspond to "server nonce" in Digest authentication which must be kept in server-side. The name differs because in Digest "nonce" is both a session identifier and an encryption key at the same time, but in Mutual authentication it is just an identifier. We carefully designed the protocol so that servers can be implemented without having complex state managements. Server-side session caches can be erased at any time after one request is served, this is just the same as Digest does. > I think that the nonce and nc mechanisms are far too complex > and dependent on both server state and "remembering" previous > nonce values. What goals do these mechanisms serve? I suspect > they can be accomplished by a single fixed server-provided > nonce (64 bit server timestamp of nonce generation) and a simple > client-provided nonce (counter). These values do not need to be > "remembered" by the server -- the client is responsible for its > own increments and the server can reject a returned server-nonce > if its value is outside the TTL range of its own timestamp. Actually, nc mechanism seems to be complex in the specification, but the requirements are very simple to implement. The purpose of the nonce specification in the draft is to make Mutual authentication secure against passive eavesdropping and limited replay attacks, to the same level proper implementations of Digest authentication provides. (Of course we recommend to use TLS for complete protection.) Seeing the real implementation of Digest mechanism, duplication check of cnonce value is usually omitted. I observe that one reason for this is that clients can choose whatever cnonces of their favorite, and the server must remember all of those received cnonces for the lifetime of the server nonce. This makes impossible to implement servers to handle one session (specified by a server nonce) in fixed amount of memory and makes it unscalable. The key point of our nc specification is that server is explicitly allowed to reject any nc values which are "old" (as defined by nc-window) as invalid requests, and makes possible to check nc duplication in fixed amount of memory. To answer auth-domain issue, we have to describe requirements to us from web-application designer's side, as I said, our proposal is to replace flexible form-based authentication at the same time. Please let me have some minutes to assemble those up. -- 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[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1] Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6EBB0809D5 for ; Mon, 26 Nov 2007 21:46:10 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B08ED1421FD for ; Mon, 26 Nov 2007 21:46:10 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-50 required=4 tests=[AWL=0.072, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z15mG5tkErRX for ; Mon, 26 Nov 2007 21:46:05 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3971C1421FB for ; Mon, 26 Nov 2007 21:46:05 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id EE0BF33C21; Mon, 26 Nov 2007 21:41:04 -0800 (PST) Date: Mon, 26 Nov 2007 21:41:04 -0800 From: Eric Rescorla To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <20071127053732.075BC33C21@delta.rtfm.com> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127054104.EE0BF33C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 05:46:11 -0000 At Mon, 26 Nov 2007 21:37:31 -0800, Eric Rescorla wrote: > > At Mon, 26 Nov 2007 20:36:59 -0800, > Roy T. Fielding wrote: > > should be replaced by the actual equations, with only an informative > > reference to [ISO.11770-4.2006]. I suspect these are just a variation > > of the SRP or PwdHash techniques that have been published before, but > > I have no access to the ISO document to verify. > > It's important to note that PwdHash and SRP really are quite > qualitatively different. > > - SRP is a mechanism for a pair of agents to derive a strong > shared key starting with only a weak shared secret. > - PwdHash is purely a password diversification technique: it > allows you to use a single memorized password to produce > different passwords for each server you communicate with. > > These really aren't the same thing at all. In the context of Oops. Hit send too early. In the setting we're talking about here, the major differences include: - PwdHash is subject to offline dictionary attacks. SRP is not. - SRP is designed to be used to key a data security protocol. PwdHash is designed to simply give you a new password you feed into the ordinary password mechanisms. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F15E0809D5 for ; Mon, 26 Nov 2007 21:42:36 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2550142202 for ; Mon, 26 Nov 2007 21:42:37 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-50 required=4 tests=[AWL=0.073, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPzMwDVqC+Ak for ; Mon, 26 Nov 2007 21:42:32 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 441331421FD for ; Mon, 26 Nov 2007 21:42:32 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 075BC33C21; Mon, 26 Nov 2007 21:37:32 -0800 (PST) Date: Mon, 26 Nov 2007 21:37:31 -0800 From: Eric Rescorla To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127053732.075BC33C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 05:42:37 -0000 At Mon, 26 Nov 2007 20:36:59 -0800, Roy T. Fielding wrote: > should be replaced by the actual equations, with only an informative > reference to [ISO.11770-4.2006]. I suspect these are just a variation > of the SRP or PwdHash techniques that have been published before, but > I have no access to the ISO document to verify. It's important to note that PwdHash and SRP really are quite qualitatively different. - SRP is a mechanism for a pair of agents to derive a strong shared key starting with only a weak shared secret. - PwdHash is purely a password diversification technique: it allows you to use a single memorized password to produce different passwords for each server you communicate with. These really aren't the same thing at all. In the context of > IMO, auth-domain needs to be the entire URI prefix for the area > over which the same authentication applies (scheme, authority, > and path-prefix [what the draft calls host + path]), what I > would call the auth-prefix, and should be required as a field > value on all requests in addition to being included within > the hash. The validation would always include this auth-prefix > for unencrypted channels, and *both* the auth-prefix and tls-key > for TLS channels. [I don't understand the reasoning behind > tls-cert being used at all, since in actual practice "certificate > verification" is a waste of time (CAs are not secure). As a side note, this claim strikes me as substantially too strong. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 14DC88092B for ; Mon, 26 Nov 2007 21:36:13 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D89BD1421FF for ; Mon, 26 Nov 2007 21:36:13 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-50 required=4 tests=[AWL=0.073, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8IXu5Sr+bfh for ; Mon, 26 Nov 2007 21:36:08 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 018BC1421FD for ; Mon, 26 Nov 2007 21:36:05 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 380CE33C21; Mon, 26 Nov 2007 21:31:05 -0800 (PST) Date: Mon, 26 Nov 2007 21:31:04 -0800 From: Eric Rescorla To: Yutaka OIWA Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127053105.380CE33C21@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 05:36:14 -0000 At Tue, 27 Nov 2007 05:26:10 +0900, Yutaka OIWA wrote: > We have recently submitted an Internet-Draft named > draft-oiwa-http-mutualauth-01.txt. > > This memo proposes a method for strong password-based mutual > authentication on HTTP. It is an intermediate result of the joint > research project between Yahoo! Japan, Inc and us (Research Center for > Information Security (RCIS), National Institute of Advanced Industrial > Science and Technology (AIST)). > > Main idea behind the proposal is that when user-memorable passwords > are used with existing protocols, phishing attacks are very effective > to steal both user passwords and other private information. When > either Basic or form-based authentication are used, it is trivial to > steal the passwords, and furthermore, it is very easy to convince > (phish) users that they have been successfully logged into the > original site. Digest authentication also does not solve the problem: > the server can blindly accept the clients without knowing the correct > passwords, and by using recent powerful CPU, it is easy to reverse the > simple MD5 hashes unless the passwords are significantly long (such as > 25+ characters). Other hash-based protocols are also vulnerable for > similar offline attacks by its nature. > > Our proposal prevents all of those attacks. By using a (modified) > variant of PAKE cryptographic authentication protocol, fake servers > can't forge authentication success unless the correct passwords are > known to them. Furthermore, even if clients have negotiated with > phishing servers, the phishers can't acquire user's password even if > offline blute-force attacks are performed. It means that it is "safe" > to perform authentication with phishing servers, and users can check > whether they have contacted with genuine hosts by simply checking the > result of the authentication. > > For further information, please refer to the draft, or our > presentation materials at recent APWG '07 eCrime Workshop on > > http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth-Abstract.pdf > http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth.pdf > > > We intend to supersede both current HTTP header-based authentications > and form-based authentications by our proposal. To achieve this goal, > some extensions to current HTTP Authorization mechanism are also > proposed. We will research further possibilities and requirements for > replacing form-based authentication by HTTP authentications, and > we will incorporate it in future revisions of the draft. > > Currently, we have implemented a preliminary version of this protocol > to both Apache and Mozilla Firefox. Both implementations will be > available to public once the implementation and testing are finished. > We are also preparing to have some public field experiments on some > part of the Yahoo! Japan website in 1Q or 2Q in the next year, > hopefully. > > Comments are always welcome. > If you visit IETF 70, we look forward to seeing you at Vancouver. A few questions/comments: 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't it be more straightforward to do this in TLS rather than adapting Digest? I also would note that TLS-SRP has already been approved by the IESG. 2. Do you have a pointer to a complete description of the crypto protocol this is based on? A little searching didn't turn up anything non-free. 3. There are a large number of PAKE/ZKPP protocols. Can you please explain why one would want this protocol versus others? 4. I see you've filed an IPR disclosure on this technique. Is your own IPR the only IPR which you're aware of? -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E1B917F5C2 for ; Mon, 26 Nov 2007 20:37:12 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B2CA61421FF for ; Mon, 26 Nov 2007 20:37:13 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-50 required=4 tests=[AWL=0.763, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPN3F+bzkIG8 for ; Mon, 26 Nov 2007 20:37:08 -0800 (PST) Received: from spaceymail-a2.g.dreamhost.com (sd-green-bigip-202.dreamhost.com [208.97.132.202]) by laweleka.osafoundation.org (Postfix) with ESMTP id EB42F1421FD for ; Mon, 26 Nov 2007 20:37:05 -0800 (PST) Received: from [10.2.8.60] (wsip-70-183-62-251.oc.oc.cox.net [70.183.62.251]) by spaceymail-a2.g.dreamhost.com (Postfix) with ESMTP id A3271EE397; Mon, 26 Nov 2007 20:37:04 -0800 (PST) In-Reply-To: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Mon, 26 Nov 2007 20:36:59 -0800 To: Yutaka OIWA X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 04:37:14 -0000 On Nov 26, 2007, at 12:26 PM, Yutaka OIWA wrote: > We have recently submitted an Internet-Draft named > draft-oiwa-http-mutualauth-01.txt. Dear Yutaka, I think that something like this proposal is capable of being deployed on a fairly rapid basis. However, the draft needs to disclose all of the details of the algorithms -- it can't rely on reference to [ISO.11770-4.2006] because that document is not readily available and may be subject to additional intellectual property disclaimers that would hinder adoption. In particular The equations for J, w_A, T, z, K_i, and w_B are those specified for KAM3 in [ISO.11770-4.2006], given that pi is derived in the above equation. should be replaced by the actual equations, with only an informative reference to [ISO.11770-4.2006]. I suspect these are just a variation of the SRP or PwdHash techniques that have been published before, but I have no access to the ISO document to verify. In addition, here are my suggestions for future drafts. Most are for the sake of reducing variants in how the algorithm is used to those actually necessary for interoperability. If you have use cases in mind that cannot be achieved without all of the variants, then we should include those use cases in the draft. IMO, auth-domain needs to be the entire URI prefix for the area over which the same authentication applies (scheme, authority, and path-prefix [what the draft calls host + path]), what I would call the auth-prefix, and should be required as a field value on all requests in addition to being included within the hash. The validation would always include this auth-prefix for unencrypted channels, and *both* the auth-prefix and tls-key for TLS channels. [I don't understand the reasoning behind tls-cert being used at all, since in actual practice "certificate verification" is a waste of time (CAs are not secure). What matters is that the server reject a channel binding that would indicate a MITM attack, for which the tls-key should be sufficient. However, I am not a crypto expert.] The server MUST validate that the request-URI matches the auth-prefix for all authenticated requests. Including the auth-prefix in the request allows the data for the hash to be communicated through gateways (which will have to perform their own validation of that data). "logout-timeout" should be named "ttl" (bits matter) and its expiration MUST result in clearing the authentication state unless updated by a later ttl. In addition, clients should be reminded (again) that any login UI should have a corresponding client-side logout UI, even though that logout is not communicated via the protocol. I don't think it is necessary to have a sid -- that adds session state to the protocol, for no apparent reason, and thus greatly reduces the scalability of servers. I think that the nonce and nc mechanisms are far too complex and dependent on both server state and "remembering" previous nonce values. What goals do these mechanisms serve? I suspect they can be accomplished by a single fixed server-provided nonce (64 bit server timestamp of nonce generation) and a simple client-provided nonce (counter). These values do not need to be "remembered" by the server -- the client is responsible for its own increments and the server can reject a returned server-nonce if its value is outside the TTL range of its own timestamp. Finally, please note that all of these concepts (except maybe optional mutual auth) have been discussed in public mailing lists in the past. Cheers, Roy T. Fielding Chief Scientist, Day Software Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 95AD380753 for ; Mon, 26 Nov 2007 12:26:23 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 62F94142202 for ; Mon, 26 Nov 2007 12:26:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTZAidzs0y4J for ; Mon, 26 Nov 2007 12:26:18 -0800 (PST) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6424E1421FD for ; Mon, 26 Nov 2007 12:26:18 -0800 (PST) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id lAQKQCAQ025212 for ; Tue, 27 Nov 2007 05:26:12 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id lAQKQBUR012945 for ; Tue, 27 Nov 2007 05:26:11 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id lAQKQAbo004593 for ; Tue, 27 Nov 2007 05:26:11 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: ietf-http-auth@osafoundation.org From: Yutaka OIWA Date: Tue, 27 Nov 2007 05:26:10 +0900 Message-ID: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 20:26:23 -0000 Dear Ietf-http-auth members, We have recently submitted an Internet-Draft named draft-oiwa-http-mutualauth-01.txt. This memo proposes a method for strong password-based mutual authentication on HTTP. It is an intermediate result of the joint research project between Yahoo! Japan, Inc and us (Research Center for Information Security (RCIS), National Institute of Advanced Industrial Science and Technology (AIST)). Main idea behind the proposal is that when user-memorable passwords are used with existing protocols, phishing attacks are very effective to steal both user passwords and other private information. When either Basic or form-based authentication are used, it is trivial to steal the passwords, and furthermore, it is very easy to convince (phish) users that they have been successfully logged into the original site. Digest authentication also does not solve the problem: the server can blindly accept the clients without knowing the correct passwords, and by using recent powerful CPU, it is easy to reverse the simple MD5 hashes unless the passwords are significantly long (such as 25+ characters). Other hash-based protocols are also vulnerable for similar offline attacks by its nature. Our proposal prevents all of those attacks. By using a (modified) variant of PAKE cryptographic authentication protocol, fake servers can't forge authentication success unless the correct passwords are known to them. Furthermore, even if clients have negotiated with phishing servers, the phishers can't acquire user's password even if offline blute-force attacks are performed. It means that it is "safe" to perform authentication with phishing servers, and users can check whether they have contacted with genuine hosts by simply checking the result of the authentication. For further information, please refer to the draft, or our presentation materials at recent APWG '07 eCrime Workshop on http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth-Abstract.pdf http://staff.aist.go.jp/y.oiwa/publications/2007-APWG-MutualAuth.pdf We intend to supersede both current HTTP header-based authentications and form-based authentications by our proposal. To achieve this goal, some extensions to current HTTP Authorization mechanism are also proposed. We will research further possibilities and requirements for replacing form-based authentication by HTTP authentications, and we will incorporate it in future revisions of the draft. Currently, we have implemented a preliminary version of this protocol to both Apache and Mozilla Firefox. Both implementations will be available to public once the implementation and testing are finished. We are also preparing to have some public field experiments on some part of the Yahoo! Japan website in 1Q or 2Q in the next year, hopefully. Comments are always welcome. If you visit IETF 70, we look forward to seeing you at Vancouver. Best Regards, -- 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[995DD3E1] fp[3C21 17D0 D953 77D3 02D7 4FEC 4754 40C1 995D D3E1] Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6DB31804FD for ; Sun, 25 Nov 2007 08:31:42 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33B8D142204 for ; Sun, 25 Nov 2007 08:31:43 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-50 required=4 tests=[AWL=0.081, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdlVbczRAw2u for ; Sun, 25 Nov 2007 08:31:37 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B831142203 for ; Sun, 25 Nov 2007 08:31:37 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id BACDA33C21; Sun, 25 Nov 2007 08:26:35 -0800 (PST) Date: Sun, 25 Nov 2007 08:26:35 -0800 From: Eric Rescorla To: Sam Hartman Subject: Re: [Ietf-http-auth] Submitted draft 06 In-Reply-To: References: <20071125034654.217BC33C21@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071125162635.BACDA33C21@delta.rtfm.com> Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 16:31:42 -0000 At Sun, 25 Nov 2007 07:35:50 -0500, Sam Hartman wrote: > > >>>>> "Eric" == Eric Rescorla writes: > > > Eric> - The coverage of the literature is still grossly deficient. > Eric> Seriously, there has been a lot of work on phishing > Eric> resistant authentication mechanisms and having a document > Eric> which doesn't credit any of it (a) isn't very useful and (b) > Eric> looks bad. I appreciate this isn't an academic paper, but > Eric> that doesn't mean it's OK to appear to neglect all the prior > Eric> work. > > We disagree on this point; it's my reading of the discussion during > the last call that people agreed adding some citations would be a good > idea but disagreed with your claim here. Yes, I appreciate that, but you asked people to read and comment on this document. I did. > I do not intend to fix this > to your satisfaction unless directed to do so by ALexey or lisa. Again, I'd like to make the procedural point that this document is not with the IESG and Alexey is not the shepherd, so he can't direct you do to anything. For that matter, since this is an individual submission, neither can Lisa. > Eric> At an even higher level, I also find myself pretty puzzled > Eric> by the putative purpose of this document. (1) It's destined > Eric> for informational (2) it says that it doesn't levy > Eric> requirements on WGs and yet (3) it's represented as the > Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119 > Eric> normative language. This seems odd. > > I think the use of RFC 2119 languague is consistent with a lot of > informational documents I've reviewed for the IESG. > > Section 1.1 is a new section and I may have gotten it wrong. I > certainly don't know that we have agreement to that text; we > definitely need to discuss that section. > > However if section 1.1 claims that there is an IETF consensus behind > this document then I didn't say what I intended to say and would > appreciate help saying it more clearly. What I intended to say (and > hope to achieve) is that the IETF has consensus that working on authentication systems that meet these requirements is a useful step. Well, I don't agree with that statement either. -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 91E9F7F635 for ; Sun, 25 Nov 2007 04:53:52 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 557D71421FD for ; Sun, 25 Nov 2007 04:53:53 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-50 required=4 tests=[AWL=0.184, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q84iJ4d9r+-T for ; Sun, 25 Nov 2007 04:53:47 -0800 (PST) Received: from srve.com (srve.com [208.69.183.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6DA53142204 for ; Sun, 25 Nov 2007 04:53:47 -0800 (PST) Received: from localhost (www.hunneypocketed.emsvr.com [203.206.137.129] (may be forged)) (authenticated bits=0) by srve.com (8.13.8/8.13.8/CWT/DCE) with ESMTP id lAPCrdJc019316 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 25 Nov 2007 12:53:42 GMT Date: Sun, 25 Nov 2007 22:53:43 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <225808630.20071125225343@pobox.com> To: Sam Hartman Subject: Re[2]: [Ietf-http-auth] Submitted draft 06 In-Reply-To: References: <20071125034654.217BC33C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 12:53:52 -0000 Hi, I don't think the document does what it claims - ie: to represent "Requirements for Web Authentication Resistant to Phishing"). Please don't be offended - I'm only stating my opinion here - but it appears to spell out one (Sams?) solution and the requirements for it, while discrediting or ignoring everything else. Yes - there are a lot of useful "Requirements" - but if a document seriously wanted to live up to that title - it would need to be a comprehensive study of existing art, categorized into existing and theoretical solutions, with each having it's own set of requirements. One set of requirements is simply not suitable for all solutions, and only one solution is not really suitable for an IETF document with this title. Kind Regards, Chris Drake Sunday, November 25, 2007, 10:35:50 PM, you wrote: >>>>>> "Eric" == Eric Rescorla writes: SH> Eric> - The coverage of the literature is still grossly deficient. SH> Eric> Seriously, there has been a lot of work on phishing SH> Eric> resistant authentication mechanisms and having a document SH> Eric> which doesn't credit any of it (a) isn't very useful and (b) SH> Eric> looks bad. I appreciate this isn't an academic paper, but SH> Eric> that doesn't mean it's OK to appear to neglect all the prior SH> Eric> work. SH> We disagree on this point; it's my reading of the discussion during SH> the last call that people agreed adding some citations would be a good SH> idea but disagreed with your claim here. I do not intend to fix this SH> to your satisfaction unless directed to do so by ALexey or lisa. I'd SH> assume that they would direct me to do so if they believe the SH> consensus of the ietf or this list is that doing so would be a useful investment in SH> time and would improve the document. SH> Eric> - The document still focuses on cryptographic mutual SH> Eric> authentication mechanisms. Given that there are mechanisms SH> Eric> (e.g., PwdHash) which provide substantial phishing SH> Eric> resistance without modifying the server and that the mutual SH> Eric> auth mechanisms do, rejecting them without even discussing SH> Eric> them (see S 4.3) seems quite inappropriate. SH> True; this is not within the scope of the changes I claimed to make SH> for 06 and I agree it is still an open issue. SH> Eric> - The document mentions ZKPP/PAKE systems (twice) but SH> Eric> somehow omits TLS-PSK. I understand that there are technical SH> Eric> reasons why one might prefer ZKPPs--though TLS-PSK is an SH> Eric> enormous improvement over the current systems--but you need SH> Eric> to explain it, not just assert it. SH> I agree this has not been dealt with and should be. SH> Eric> At a higher level, if you're going to levy requirements, you SH> Eric> need to actually explain what they are, not just levy SH> Eric> them. This document does a quite inadequate job of that. SH> I'm not sure I agree with this claim. I think I understand what you SH> are saying but I'm not sure I think the document strikes the wrong SH> balance here. I'd appreciate input from others besides Eric as I SH> suspect the two of us would quickly spin on this issue. SH> Eric> At an even higher level, I also find myself pretty puzzled SH> Eric> by the putative purpose of this document. (1) It's destined SH> Eric> for informational (2) it says that it doesn't levy SH> Eric> requirements on WGs and yet (3) it's represented as the SH> Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119 SH> Eric> normative language. This seems odd. SH> I think the use of RFC 2119 languague is consistent with a lot of SH> informational documents I've reviewed for the IESG. SH> Section 1.1 is a new section and I may have gotten it wrong. I SH> certainly don't know that we have agreement to that text; we SH> definitely need to discuss that section. SH> However if section 1.1 claims that there is an IETF consensus behind SH> this document then I didn't say what I intended to say and would SH> appreciate help saying it more clearly. What I intended to say (and SH> hope to achieve) is that the IETF has consensus that working SH> on authentication systems that meet these requirements is a useful SH> step. SH> I'd appreciate comments both on whether we're trying to do that with SH> this document and on whether I successfully say that in section 1.1. SH> Eric> I don't agree that this SH> Eric> document has the consensus of the IETF (it doesn't have SH> Eric> mine) and don't think it should be represented as such. SH> I believe that section 1.1 will need to be explicitly included in an SH> ietf last call and that section 1.1 is not a true statement until such SH> a last call succeeds. SH> Eric> I've SH> Eric> got no problem with it being published and represented as SH> Eric> Sam Hartman's opinion. SH> If I just wanted to publish my opinion I'd long ago have written a SH> blong entry or published an independent submission. If we (meaning SH> the community, probably not you and I) cannot reach agreement I may SH> well submit the resulting draft to the rfc editor (obviously without SH> section 1.1). However I think the document will be far more valuable SH> if we can get to a point where something like section 1.1 is SH> appropriate. SH> _______________________________________________ SH> Ietf-http-auth mailing list SH> Ietf-http-auth@osafoundation.org SH> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 70EDB805EB for ; Sun, 25 Nov 2007 04:35:58 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3678714220D for ; Sun, 25 Nov 2007 04:35:59 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-50 required=4 tests=[AWL=1.052, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8tdEjs13+O6 for ; Sun, 25 Nov 2007 04:35:53 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by laweleka.osafoundation.org (Postfix) with ESMTP id 27DD614220C for ; Sun, 25 Nov 2007 04:35:53 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 106F14818; Sun, 25 Nov 2007 07:35:50 -0500 (EST) From: Sam Hartman To: Eric Rescorla Subject: Re: [Ietf-http-auth] Submitted draft 06 References: <20071125034654.217BC33C21@delta.rtfm.com> Date: Sun, 25 Nov 2007 07:35:50 -0500 In-Reply-To: <20071125034654.217BC33C21@delta.rtfm.com> (Eric Rescorla's message of "Sat, 24 Nov 2007 19:46:53 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 12:35:58 -0000 >>>>> "Eric" == Eric Rescorla writes: Eric> - The coverage of the literature is still grossly deficient. Eric> Seriously, there has been a lot of work on phishing Eric> resistant authentication mechanisms and having a document Eric> which doesn't credit any of it (a) isn't very useful and (b) Eric> looks bad. I appreciate this isn't an academic paper, but Eric> that doesn't mean it's OK to appear to neglect all the prior Eric> work. We disagree on this point; it's my reading of the discussion during the last call that people agreed adding some citations would be a good idea but disagreed with your claim here. I do not intend to fix this to your satisfaction unless directed to do so by ALexey or lisa. I'd assume that they would direct me to do so if they believe the consensus of the ietf or this list is that doing so would be a useful investment in time and would improve the document. Eric> - The document still focuses on cryptographic mutual Eric> authentication mechanisms. Given that there are mechanisms Eric> (e.g., PwdHash) which provide substantial phishing Eric> resistance without modifying the server and that the mutual Eric> auth mechanisms do, rejecting them without even discussing Eric> them (see S 4.3) seems quite inappropriate. True; this is not within the scope of the changes I claimed to make for 06 and I agree it is still an open issue. Eric> - The document mentions ZKPP/PAKE systems (twice) but Eric> somehow omits TLS-PSK. I understand that there are technical Eric> reasons why one might prefer ZKPPs--though TLS-PSK is an Eric> enormous improvement over the current systems--but you need Eric> to explain it, not just assert it. I agree this has not been dealt with and should be. Eric> At a higher level, if you're going to levy requirements, you Eric> need to actually explain what they are, not just levy Eric> them. This document does a quite inadequate job of that. I'm not sure I agree with this claim. I think I understand what you are saying but I'm not sure I think the document strikes the wrong balance here. I'd appreciate input from others besides Eric as I suspect the two of us would quickly spin on this issue. Eric> At an even higher level, I also find myself pretty puzzled Eric> by the putative purpose of this document. (1) It's destined Eric> for informational (2) it says that it doesn't levy Eric> requirements on WGs and yet (3) it's represented as the Eric> opinion of the IETF (see S 1.1.) and (4) uses RFC 2119 Eric> normative language. This seems odd. I think the use of RFC 2119 languague is consistent with a lot of informational documents I've reviewed for the IESG. Section 1.1 is a new section and I may have gotten it wrong. I certainly don't know that we have agreement to that text; we definitely need to discuss that section. However if section 1.1 claims that there is an IETF consensus behind this document then I didn't say what I intended to say and would appreciate help saying it more clearly. What I intended to say (and hope to achieve) is that the IETF has consensus that working on authentication systems that meet these requirements is a useful step. I'd appreciate comments both on whether we're trying to do that with this document and on whether I successfully say that in section 1.1. Eric> I don't agree that this Eric> document has the consensus of the IETF (it doesn't have Eric> mine) and don't think it should be represented as such. I believe that section 1.1 will need to be explicitly included in an ietf last call and that section 1.1 is not a true statement until such a last call succeeds. Eric> I've Eric> got no problem with it being published and represented as Eric> Sam Hartman's opinion. If I just wanted to publish my opinion I'd long ago have written a blong entry or published an independent submission. If we (meaning the community, probably not you and I) cannot reach agreement I may well submit the resulting draft to the rfc editor (obviously without section 1.1). However I think the document will be far more valuable if we can get to a point where something like section 1.1 is appropriate. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 727338092B for ; Sat, 24 Nov 2007 19:52:01 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33F64142203 for ; Sat, 24 Nov 2007 19:52:02 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-50 required=4 tests=[AWL=0.083, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXDhP3qCDHfv for ; Sat, 24 Nov 2007 19:51:56 -0800 (PST) Received: from delta.rtfm.com (unknown [74.95.2.169]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C0F21421FD for ; Sat, 24 Nov 2007 19:51:56 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 217BC33C21; Sat, 24 Nov 2007 19:46:54 -0800 (PST) Date: Sat, 24 Nov 2007 19:46:53 -0800 From: Eric Rescorla To: Sam Hartman Subject: Re: [Ietf-http-auth] Submitted draft 06 In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071125034654.217BC33C21@delta.rtfm.com> Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Nov 2007 03:52:01 -0000 $Id: draft-hartman-webauth-phishing-06-rev.txt,v 1.1 2007/11/25 03:43:56 ekr Exp $ Sam, I've just finished reading draft-hartman-webauth-phishing-06-rev. There are some areas in which it's improved, but generally it suffers from most of the same deficiencies I identified in my review of version -05. In particular (but not exhaustively): - The coverage of the literature is still grossly deficient. Seriously, there has been a lot of work on phishing resistant authentication mechanisms and having a document which doesn't credit any of it (a) isn't very useful and (b) looks bad. I appreciate this isn't an academic paper, but that doesn't mean it's OK to appear to neglect all the prior work. - The document still focuses on cryptographic mutual authentication mechanisms. Given that there are mechanisms (e.g., PwdHash) which provide substantial phishing resistance without modifying the server and that the mutual auth mechanisms do, rejecting them without even discussing them (see S 4.3) seems quite inappropriate. - The document mentions ZKPP/PAKE systems (twice) but somehow omits TLS-PSK. I understand that there are technical reasons why one might prefer ZKPPs--though TLS-PSK is an enormous improvement over the current systems--but you need to explain it, not just assert it. At a higher level, if you're going to levy requirements, you need to actually explain what they are, not just levy them. This document does a quite inadequate job of that. At an even higher level, I also find myself pretty puzzled by the putative purpose of this document. (1) It's destined for informational (2) it says that it doesn't levy requirements on WGs and yet (3) it's represented as the opinion of the IETF (see S 1.1.) and (4) uses RFC 2119 normative language. This seems odd. I don't agree that this document has the consensus of the IETF (it doesn't have mine) and don't think it should be represented as such. I've got no problem with it being published and represented as Sam Hartman's opinion. Reviewing the diffs it seems that this version principally adds some explanatory text, but the problem is that much of the text needs rewriting. So, no, I don't really think this is headed in the right direction. Or rather, the magnitude of the vector is so small it's hard to tell if it's in the right direction. -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9EBBB80A7C for ; Sun, 18 Nov 2007 19:44:50 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 39047142212 for ; Sun, 18 Nov 2007 19:44:51 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz2MUOWDayME for ; Sun, 18 Nov 2007 19:44:45 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-76-19-66-159.hsd1.ma.comcast.net [76.19.66.159]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA79514220D for ; Sun, 18 Nov 2007 19:44:45 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 29BEF46A9; Sun, 18 Nov 2007 22:44:44 -0500 (EST) From: Sam Hartman To: ietf-http-auth@lists.osafoundation.org Date: Sun, 18 Nov 2007 22:44:44 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Ietf-http-auth] Submitted draft 06 X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2007 03:44:50 -0000 Hi. I've submitted draft 06. This includes changes up through the threat model. I may not have addressed all comments; I still need to finish making the first pass through the entire document and then go back over reviewer comments. However I'd appreciate it if you would review the changes I've made and see if you think I'm heading ithe right direction. If so, please let me know. If not, please explain why not. Thanks, --Sam Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6021280CF8 for ; Fri, 16 Nov 2007 01:41:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DC2AD14220D for ; Fri, 16 Nov 2007 01:41:00 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV67npH6TY20 for ; Fri, 16 Nov 2007 01:39:31 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by laweleka.osafoundation.org (Postfix) with ESMTP id B100F142207 for ; Fri, 16 Nov 2007 01:39:30 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EB5411F132C for ; Fri, 16 Nov 2007 11:39:27 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id A6D3B1F132B for ; Fri, 16 Nov 2007 11:39:27 +0200 (EET) Resent-From: Christian Vogt Resent-To: ietf-http-auth@lists.osafoundation.org Resent-Date: Fri, 16 Nov 2007 11:39:20 +0200 Resent-Message-Id: <473D6548.3090603@nomadiclab.com> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 Message-ID: <473C6445.5070807@nomadiclab.com> Date: Thu, 15 Nov 2007 17:22:45 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eliot Lear References: <473323D6.2060502@cisco.com> In-Reply-To: <473323D6.2060502@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: Gen-ART Mailing List , ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] Re: draft-hartman-webauth-phishing Section 3.1 X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 09:41:00 -0000 Hi Eliot - I think we are actually on the same page regarding section 3.1, and this is just a terminology question. What you consider "private" is the personal data desired by the attacker, whereas I was considering this to be the user's username and password. >> Mechanisms attackers use to accomplish this include links with a >> misleading name or URI, which they may distribute in emails; >> attacks against DNS; and man-in-the-middle attacks against a TLS >> handshake. The former two attacks allow the attacker to pass >> authentication because the victim user can be tricked into >> accepting the attacker's certificate. The latter attack will >> typically create a warning on the victim user's side, but many >> users cannot make informed decisions on how to respond to such a >> warning, making them inclined to accept the bogus certificate. > > I do like this text, with the exception that I would replace "cannot > make informed decisions" with "do not make informed decisions". And > indeed you have hit the nail on the head here IMHO. Yes, that replacement makes sense. Alright, take care, - Christian Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7588A809B3 for ; Thu, 8 Nov 2007 06:59:00 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF218142210 for ; Thu, 8 Nov 2007 06:58:05 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-50 required=4 tests=[AWL=0.523, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135, SPF_PASS=-0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax-6z5hICoMD for ; Thu, 8 Nov 2007 06:57:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8EFA11421F6 for ; Thu, 8 Nov 2007 06:57:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.21,389,1188770400"; d="scan'208";a="157183747" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2007 15:57:58 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA8EvwdH022186; Thu, 8 Nov 2007 15:57:58 +0100 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp752.cisco.com [10.61.66.240]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA8Evm8i015578; Thu, 8 Nov 2007 14:57:52 GMT Message-ID: <473323D6.2060502@cisco.com> Date: Thu, 08 Nov 2007 15:57:26 +0100 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Christian Vogt X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3511; t=1194533878; x=1195397878; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20draft-hartman-webauth-phishing=20Section=203.1 |Sender:=20; bh=Lciov8hb13sXimlUgDTCL4isWrC/bd9XjjRLbpxRu4Q=; b=kpWx260pZe5II/D3AqHfmiMVFtc6D/IbRUZzJCV3KRqpw+SYePhcCSi+z5fcoWSgtD6JhVx9 UDYrUJrluzIl+5g1ongdd3Lqz9tdOjt4gB8O4mAgs/v/hvQlYPzjWdxx; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); Cc: ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] draft-hartman-webauth-phishing Section 3.1 X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 14:59:00 -0000 Hello Christian, Some time ago, you had sent Sam text regarding draft-hartman-webauth-phishing, Section 3.1. I understand this may have been part of a GenArt review (thank you for taking the time). As I am the instigator of some of that text (and quite honestly I don't recall which part - too many cobwebs upstairs), let me see if we can go through your comments. Starting with this: > Alright, I see that the intent of section 3.1 is actually to describe > capabilities that an attacker will *always* have, i.e., even in case it > does not know (and cannot acquire) a username/password from a victim > user. Maybe you can clarify this by changing the latter part of paragraph > 2 of section 3.1 like this: > > OLD > > However the > attacker probably could not replicate the account summary page until > the attacker learned the user name and password because the attacker > would not know what accounts to list or approximate balances that > will look convincing to a user. Of course attackers may know some > personal information about a user. Websites that want to rely on > attackers not knowing certain information need to maintain the > privacy of that information. > > NEW > > However the > attacker probably could not replicate the account summary page > until the attacker learned the user name and password because the > attacker would not know what accounts to list or approximate > balances that will look convincing to a user. Preventing the > attacker from acquiring a victim's user name and password would thus > make it impossible for an attacker to spoof a user interface that > shows such individual data. > What I did is replacing the last two existing sentences with a new > one. Would you agree? I believe the intent here is to say that whatever private data a web site maintains, REGARDLESS OF THE FORM OF THAT DATA, need to go to great pains to keep that information private. The idea in this paragraph is that it should be difficult for a phisher to reproduce even an authentic-looking web page to the user. Put another way, the site should prove itself to the user. And so the private data may be account numbers and approximate value of those accounts or holdings. And so I don't believe the proposed changes above would be appropriate in this case. HOWEVER... > Here is some text that you could take to replace the currently last > sentence in paragraph 1 of section 3.1. If you wish, feel free to > copy and paste: > Mechanisms attackers use to accomplish this include links with a > misleading name or URI, which they may distribute in emails; > attacks against DNS; and man-in-the-middle attacks against a TLS > handshake. The former two attacks allow the attacker to pass > authentication because the victim user can be tricked into > accepting the attacker's certificate. The latter attack will > typically create a warning on the victim user's side, but many > users cannot make informed decisions on how to respond to such a > warning, making them inclined to accept the bogus certificate. I do like this text, with the exception that I would replace "cannot make informed decisions" with "do not make informed decisions". And indeed you have hit the nail on the head here IMHO. Regards, Eliot Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B6ACE808FA for ; Wed, 7 Nov 2007 07:39:18 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 10D00142210 for ; Wed, 7 Nov 2007 07:38:24 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-50 required=4 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TITLE_SUBJ_DIFF=0.266, SPF_SOFTFAIL=1.384, TW_FC=0.077] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R29f+85L9wNQ for ; Wed, 7 Nov 2007 07:38:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by laweleka.osafoundation.org (Postfix) with ESMTP id 76EC314220E for ; Wed, 7 Nov 2007 07:38:14 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C0684A45; Wed, 7 Nov 2007 10:38:09 -0500 (EST) From: Sam Hartman To: ietf-http-auth@lists.osafoundation.org Date: Wed, 07 Nov 2007 10:38:09 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Mailman-Approved-At: Wed, 07 Nov 2007 14:25:39 -0800 Subject: [Ietf-http-auth] Proposals for review X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2007 15:39:18 -0000 --=-=-= I've been quiet because I've been considering the review comments, doing some additional literature review based on Eric's comments and working on other projects. I had previously looked at the papers Eric cited, although especially in the case of "The Emperor's New Security Indicators," I had not integrated what's really an important paper for this work. I was well aware that the UI suggestions I'm making may not work and depend on finding a way to get people to take advantage of them in practice. That's not reflected in the current document at all. I still disagree with Eric that the references section of this draft should be a survey of the literature, but I do agree that citations need to be added and that the document needs significant rewording not to overstate the value of speculative claims and to make it clear assumptions that are necessary for the system to work. For a variety of reasons I've started a pass from the beginning of the document going through and rewording the text. Once I'm done with that, I'll make a pass through all the open reviews and propose changes. I've made it through the introduction and a good chunk of the threat model. I'd appreciate review of these proposed changes so far. More to follow. --=-=-= Content-Type: text/html Content-Disposition: inline; filename=draft-hartman-webauth-phishing-from--05.diff.html Content-Description: Diff of webauth phishing 05 to 06a Diff: draft-hartman-webauth-phishing-05.txt - draft-hartman-webauth-phishing.txt
 draft-hartman-webauth-phishing-05.txt   draft-hartman-webauth-phishing.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Internet-Draft MIT
Intended status: Informational July 25, 2007 Intended status: Informational November 7, 2007
Expires: January 26, 2008 Expires: May 10, 2008
Requirements for Web Authentication Resistant to Phishing Requirements for Web Authentication Resistant to Phishing
draft-hartman-webauth-phishing-05.txt draft-hartman-webauth-phishing-06a.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 26, 2008. This Internet-Draft will expire on May 10, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo proposes requirements for protocols between web identity This memo proposes requirements for protocols between web identity
providers and users and for requirements for protocols between providers and users and for requirements for protocols between
identity providers and relying parties. These requirements minimize identity providers and relying parties. These requirements minimize
skipping to change at page 2, line 24 skipping to change at page 2, line 24
as passwords that can be used to impersonate the user to third as passwords that can be used to impersonate the user to third
parties. Browsers should perform mutual authentication and flag parties. Browsers should perform mutual authentication and flag
situations when the target website is not authorized to accept the situations when the target website is not authorized to accept the
identity being offered as this is a strong indication of fraud. identity being offered as this is a strong indication of fraud.
These requirements may serve as a basis for requirements for These requirements may serve as a basis for requirements for
preventing fraud in environments other than the web. preventing fraud in environments other than the web.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose of this Memo . . . . . . . . . . . . . . . . . . . 4
1.2. Passwords and Interface . . . . . . . . . . . . . . . . . 4
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Capabilities of Attackers . . . . . . . . . . . . . . . . 6 3.1. Capabilities of Attackers . . . . . . . . . . . . . . . . 6
3.2. Attacks of Interest . . . . . . . . . . . . . . . . . . . 7 3.2. Attacks of Interest . . . . . . . . . . . . . . . . . . . 7
4. Requirements for Preventing Phishing . . . . . . . . . . . . . 9 4. Requirements for Preventing Phishing . . . . . . . . . . . . . 9
4.1. Support for Passwords and OTher Methods . . . . . . . . . 9 4.1. Support for Passwords and OTher Methods . . . . . . . . . 9
4.2. Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. No Password Equivelents . . . . . . . . . . . . . . . . . 10 4.3. No Password Equivelents . . . . . . . . . . . . . . . . . 10
4.4. Mutual Authentication . . . . . . . . . . . . . . . . . . 11 4.4. Mutual Authentication . . . . . . . . . . . . . . . . . . 11
4.5. Authentication Tied to Resulting Page . . . . . . . . . . 11 4.5. Authentication Tied to Resulting Page . . . . . . . . . . 11
skipping to change at page 2, line 45 skipping to change at page 2, line 47
4.7. Protecting Enrollment . . . . . . . . . . . . . . . . . . 13 4.7. Protecting Enrollment . . . . . . . . . . . . . . . . . . 13
5. Is it the right Server? . . . . . . . . . . . . . . . . . . . 14 5. Is it the right Server? . . . . . . . . . . . . . . . . . . . 14
6. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Iana Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Trusted UI Mechanisms . . . . . . . . . . . . . . . . 20 Appendix A. Trusted UI Mechanisms . . . . . . . . . . . . . . . . 20
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 21 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 21
B.1. Changes since 02 . . . . . . . . . . . . . . . . . . . . . 21 B.1. Changes since 05 . . . . . . . . . . . . . . . . . . . . . 21
B.2. Changes since 01 . . . . . . . . . . . . . . . . . . . . . 21 B.2. Changes since 02 . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 B.3. Changes since 01 . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
1. Introduction 1. Introduction
Typically, web sites ask users to send a user name and password in Typically, web sites ask users to send a user name and password in
order to log in and authenticate their identity to the website. The order to log in and authenticate their identity to the website. The
user name and plaintext password are often sent over a TLS [RFC4346] user name and plaintext password are often sent over a TLS [RFC4346]
encrypted connection. As a result of this, the server learns the encrypted connection. As a result of this, the server learns the
password and can pretend to be the user to any other system where the password and can pretend to be the user to any other system where the
user has used the same user name and password. The security of user has used the same user name and password. The security of
passwords over TLS depends on making sure that the password is sent passwords over TLS depends on making sure that the password is sent
to the right, trusted server. TLS implementations typically confirm to the right, trusted server. HTTPs [RFC2818] implementations
that the name entered by the user in the URL corresponds to the typically confirm that the name entered by the user in the URL
certificate as described in [RFC2818]. corresponds to the certificate.
One serious security threat on the web today is phishing. Phishing One serious security threat on the web today is phishing. Phishing
is a form of fraud where an attacker convinces a user to provide is a form of fraud where an attacker convinces a user to provide
confidential information to the attacker believing they are providing confidential information to the attacker believing they are providing
the information to a party they trust with that information. For the information to a party they trust with that information. For
example, an email claiming to be from a user's bank may direct the example, an email claiming to be from a user's bank may direct the
user to go to a website and verify account information. The attacker user to go to a website and verify account information. The attacker
captures the user name and password and potentially other sensitive captures the user name and password and potentially other sensitive
information. Domain names that look like target websites, links in information. Domain names that look like target websites, links in
email, and many other factors contribute to phishers' ability to email, and many other factors contribute to phishers' ability to
convince users to trust them. convince users to trust them.
Typically the user names and password are not directly valuable to
the phisher. However they can be used to access resources of value.
For example a bank password may permit money transfer or access to
information useful in identity theft.
It is useful to distinguish two targets of phishing. Sometimes It is useful to distinguish two targets of phishing. Sometimes
phishing is targeting web authentication credentials such as user phishing is targeting web authentication credentials such as user
name and password. Sometimes phishing is targeting other name and password. Sometimes phishing is targeting other
confidential information, such as bank account numbers. This memo confidential information, such as bank account numbers. This memo
presents requirements that significantly reduce the effectiveness of presents requirements that can be part of a solution to significantly
the first category of phishing: these requirements guarantee that reduce the effectiveness of the first category of phishing: provided
even if the user authenticates to the wrong server, that server that a user uses an authentication mechanism that meets these
cannot impersonate the user to a third party. However, to combat requirements, even if the user authenticates to the wrong server,
phishing targeted at other confidential information, the best we can that server cannot impersonate the user to a third party. However,
do is help the user detect fraud before they release confidential to combat phishing targeted at other confidential information, the
information. best we know how to do is help the user detect fraud before they
release confidential information.
The approach taken by this memo is to handle these two types of The approach taken by this memo is to handle these two types of
phishing differently. Users are given some trusted mechanism to phishing differently. The user is given new authentication
determine whether they are typing their password into a secure mechanisms. If the user uses these mechanisms,they have strong
component that will authenticate them to the server or whether they assurances that their password has not been disclosed and that the
are typing their password into an HTML form that will send their ensuing data returned from the server was generated by a party that
password to the server. If the user types a password into the either knows their password or who is authenticated by an identity
trusted component, they have strong assurances that their password provider who knows their password. The server can then use
has not been disclosed and that the ensuing data returned from the confidential information known to the user and server to enhance the
server was generated by a party that either knows their password or user's trust in its identity beyond what is available given the
who is authenticated by an identity provider who knows their social engineering attacks against TLS server authentication. If a
password. The server can then use confidential information known to user authenticates to the wrong server but discovers this before they
the user and server to enhance the user's trust in its identity give that server any other confidential information, then there
beyond what is available given the social engineering attacks against exposure is very limited. The success of this solution depends
TLS server authentication. If a user enters their password into the heavily on whether the user uses the new authentication mechanisms;
wrong server but discovers this before they give that server any designing ways for users to tell if they are using the authentication
other confidential information, then there exposure is very limited. mechanisms and encouraging users to use these mechanisms will be
critical to achieving any security benefit from these requirements.
The requirements presented in this memo are intended to be useful to The requirements presented in this memo are intended to be useful to
browser designers, designers of other HTTP applications and designers browser designers, designers of other HTTP applications and designers
of future HTTP authentication mechanisms. of future HTTP authentication mechanisms.
1.1. Purpose of this Memo
In publishing this memo, the IETF recommends the development of web
authentication mechanisms that meet the requirements outlined in
Section 4. It is hoped that developing these mechanisms will prove a
useful step in fighting phishing. However this memo does not
restrict work either in the IETF or any other organization. In
particular, new authentication efforts are not bound to meet the
requirements posed in this memo unless the charter for those efforts
chooses to make these binding requirements. Less formally, the IETF
presents this memo as an option to pursue while acknowledging that
there may be other promising paths both now and in the future.
1.2. Passwords and Interface
There are two related concepts: the user interface of passwords and
plaintext password protocols. A plaintext password protocol is a
protocol where the server receives credentials sufficient to
impersonate a user to third parties. A password interface provides a
user experience where a user types a password into any computer,
including one they have never used before and that is sufficient to
authenticate. The requirements in this memo require support for
password user interfaces as one option for authentication. The
requirements of this memo are incompatible with plaintext password
protocols.
2. Requirements notation 2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Threat Model 3. Threat Model
This section describes the assumed capabilities of phishers, This section describes the assumed capabilities of phishers,
describes assumptions about web security and describes what describes assumptions about web security and describes what
vulnerabilities exist. vulnerabilities exist. Human factors issues contribute significantly
to these vulnerabilities. For example, security information
dialogues in web browsers can provide information on the subject of a
certificate. However, users rarely examine this information, so an
attacker could be successful even if examining the security dialogue
would show an attack. This threat model is intended to include these
sorts of attacks and so it is broader than the technical threats
against protocols.
We assume that the implementations of authentication systems can be We assume that the implementations of authentication systems can be
trusted sufficiently to meet their design objectives. This does not trusted sufficiently to meet their design objectives. This does not
mean that the entire local system and browser need to be trusted. mean that the entire local system and browser need to be trusted.
However if there is a component that has access to users' passwords, However if there is a component that has access to users' passwords,
that component needs to be secure enough to be trusted not to divulge that component needs to be secure enough to be trusted not to divulge
passwords to attackers. Similarly in a system that used smart cards, passwords to attackers. Similarly in a system that used smart cards,
the smart cards would need to be trusted not to give attackers access the smart cards would need to be trusted not to give attackers access
to private keys or other authentication material. Designing to private keys or other authentication material. Designing
implementations to limit the size and complexity of the most trusted implementations to limit the size and complexity of the most trusted
skipping to change at page 6, line 47 skipping to change at page 7, line 5
different code points. different code points.
3.1. Capabilities of Attackers 3.1. Capabilities of Attackers
We assume attackers can convince the user to go to a website of their We assume attackers can convince the user to go to a website of their
choosing. Since the attacker controls the web site and since the choosing. Since the attacker controls the web site and since the
user chose to go to the website the TLS certificate will verify and user chose to go to the website the TLS certificate will verify and
the website will appear to be secure. The certificate will typically the website will appear to be secure. The certificate will typically
not be issued to the entity the user thinks they are communicating not be issued to the entity the user thinks they are communicating
with, but as discussed above, the user will not notice this. with, but as discussed above, the user will not notice this.
Mechanisms attackers use to accomplish this include links where the Mechanisms attackers use to accomplish this include links with a
link name and URI target are misleading; email with links; DNS misleading name or URI, which they may distribute in emails; attacks
attacks; and on-path network attacks. against DNS; and man-in-the-middle attacks against a TLS handshake.
The former two attacks allow the attacker to pass authentication
because the victim user can be tricked into accepting the attacker's
certificate. The latter attack will typically create a warning on
the victim user's side, but many users cannot make informed decisions
on how to respond to such a warning, making them inclined to accept
the bogus certificate.
The attacker can convincingly replicate any part of the UI of the The attacker can convincingly replicate any part of the UI of the
website being spoofed. The attacker can also spoof trust markers website being spoofed. The attacker can also spoof trust markers
such as the security lock, URL bar and other parts of the browser UI. such as the security lock, URL bar and other parts of the browser UI
There is one limitation to the attacker's ability to replicate UI. sufficiently that a significant class of users will not treat the
The attacker cannot replicate a UI that depends on information the spoofed security indicators as a problem. There is one limitation to
attacker does not know. For example, an attacker could generally the attacker's ability to replicate UI. The attacker cannot
replicate the UI of a banking site's login page. However the replicate a UI that depends on information the attacker does not
attacker probably could not replicate the account summary page until know. For example, an attacker could generally replicate the UI of a
the attacker learned the user name and password because the attacker banking site's login page. However the attacker probably could not
would not know what accounts to list or approximate balances that replicate the account summary page until the attacker learned the
will look convincing to a user. Of course attackers may know some user name and password because the attacker would not know what
personal information about a user. Websites that want to rely on accounts to list or approximate balances that will look convincing to
attackers not knowing certain information need to maintain the a user. Of course attackers may know some personal information about
privacy of that information. a user. Websites that want to rely on attackers not knowing certain
information need to maintain the privacy of that information.
The attacker can convince the user to do anything with the phishing The attacker can convince the user to do anything with the phishing
site that they would do with the real target site. As a consequence, site that they would do with the real target site. As a consequence,
when passwords are used, if we want to avoid the user giving the when passwords are used, if we want to avoid the user giving the
attacker their password, the web site must prove that it has an attacker their password, the web site must prove that it has an
established authentic relationship with the user without requiring a established authentic relationship with the user without requiring a
static password to do so, and in a way that cannot be visually static password to do so, and in a way that cannot be visually
mimicked so as to trick a user. One approach could be to transition mimicked so as to trick a user. One approach could be to transition
to a solution where the user could not give the real target site to a solution where the user could not give the real target site
their password if they are using a new mechanism. Instead they will their password if they are using a new mechanism. Instead they will
skipping to change at page 16, line 14 skipping to change at page 16, line 14
7. Acknowledgments 7. Acknowledgments
I'd like to thank Nicolas Williams, Matt Knopp and David Blumenthal I'd like to thank Nicolas Williams, Matt Knopp and David Blumenthal
for helping me walk through these requirements and make sure that if for helping me walk through these requirements and make sure that if
a solution met them it would actually protect against the real world a solution met them it would actually protect against the real world
attacks consumers of our technology are facing. I was particularly attacks consumers of our technology are facing. I was particularly
focusing on attacks that financial institutions are seeing and their focusing on attacks that financial institutions are seeing and their
help with this was greatly appreciated. help with this was greatly appreciated.
I'd like to thank Eric Rescorla and ben Laurie for their significant I'd like to thank Eric Rescorla and Ben Laurie for their significant
comments on this draft. comments on this draft.
Eliot Lear provided many last call comments and helped work through Eliot Lear provided many last call comments and helped work through
several long standing issues with the document. several long standing issues with the document.
Christian Vogt provided text and review comments.
8. Security Considerations 8. Security Considerations
This memo discusses the security of web authentication and how to This memo discusses the security of web authentication and how to
minimize the risk of phishing in web authentication systems. This minimize the risk of phishing in web authentication systems. This
section discusses the security of the overall system and discusses section discusses the security of the overall system and discusses
how components of the system that are not directly within the scope how components of the system that are not directly within the scope
of this document affect the security of web transactions. This of this document affect the security of web transactions. This
section also discusses residual risks that remain even when the section also discusses residual risks that remain even when the
requirements proposed here are implemented. requirements proposed here are implemented.
skipping to change at page 21, line 7 skipping to change at page 21, line 7
community has extensive research in designing UIs to display community has extensive research in designing UIs to display
classified, compartmentalized information. It is critical that these classified, compartmentalized information. It is critical that these
UIs be able to label information and that these labels not be UIs be able to label information and that these labels not be
spoofable. spoofable.
See Section 5 for another case where confidential information in a UI See Section 5 for another case where confidential information in a UI
can be used to build trust. can be used to build trust.
Appendix B. Change History Appendix B. Change History
B.1. Changes since 02 B.1. Changes since 05
Clarified introduction to distinguish what happens at the TLS
layer and what at the HTTP layer. Discuss motivation of phishing
more.
In the introduction, restate claims to be more accurate. These
requirements are useful if users actually use the authentication
mechanisms; convincing them to do so and making it obvious whether
they are is a significant risk. Also, we may give them the
theoretical information necessary to detect fraud, but whether
they act on that is open.
Add a purpose of this memo section. Whatever text ends up there
after community discussion needs to be called out in the last
call.
Add a section calling out the difference between plaintext
password protocols and password interface. This needs to be
worked into the rest of the document.
Update the threat model. Significant hopefully clarifying
changes.
B.2. Changes since 02
Updated discussion of TLS authentication to point out that it does Updated discussion of TLS authentication to point out that it does
meet the requirement of mutual authentication. meet the requirement of mutual authentication.
Added pointer to HTTP TLS channel bindings work Added pointer to HTTP TLS channel bindings work
B.2. Changes since 01 B.3. Changes since 01
Updated threat model to give examples of attacks that are in scope Updated threat model to give examples of attacks that are in scope
and to more clearly discuss host security based on comments from and to more clearly discuss host security based on comments from
Chris Drake. Chris Drake.
Clarify attacks of interest to be consistent with the Clarify attacks of interest to be consistent with the
introduction. introduction.
Fix ups regarding one-time passwords. I'm not sure that OTPs can Fix ups regarding one-time passwords. I'm not sure that OTPs can
meet all the requirements but clean things up where they clearly meet all the requirements but clean things up where they clearly
 End of changes. 

This html diff was produced by rfcdiff 1.26, available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--=-=-=--