or similar elements (eg: emulating an entire browser UI) 2. Remote Technical Tricks 2.1. spoof techniques 2.1.1. vanilla fake look-alike spoof web sites 2.1.2. CGI proxied look-alike web site (server CGI talks to real site in real time - "man in the middle attack") 2.1.3. popup windows hiding the address bar (3.4.1/3.4.2) 2.1.4.

simulated browsers (1.5.2) 2.2. iframe exploits (eg: 1.5.1/1.1.3) (spammers buy iframes to launch 1.5 and 1.4 attacks) 2.3. p2p filesharing publication of products modified to remove/limit protection - PGP, IE7, Mozilla, ... 2.4. DNS poisoning (causes correct URL to go to spoof server) 2.5. traffic sniffing (eg: at ISP, telco, WiFi, LAN, phone tap...) 2.6. proxy poisoning (correct URL returns incorrect HTML) 2.7. browser exploits (correct URL returns incorrect HTML) 2.8. targeted proxy attack 2.8.1. directs to vanilla spoof web site (2.1.1) 2.8.2. uses CGI re-writing to proxy legitimate site (eg: convert HTTPS into HTTP to activate traffic sniffing) (2.1.2) 2.8.3 activates 5.7 2.9. Authorized exploitation - see 3.5. 3. Local Technical Tricks 3.2. Software vulnerabilities (aka exploits - eg - 1.1.3) 3.1.1. Known 3.1.2. Unknown 3.2. Browser "toolbars" (grant unrestricted DOM access to SSL data) 3.3. Trojans 3.3.1. Standalone modified/hacked legitimate products (eg: PGP or a MSIE7) with inbuilt protection removed/modified. 3.3.2. Bogus products (eg: the anti-spyware tools manufactured by the Russian spam gangs) 3.3.3. Legitimate products with deliberate secret functionality (eg: warez keygens, sony/CD-Rom music piracy-block addins) 3.3.4. Backdoors (activate remote control and 3.4.1/3.4.2) 3.4. Viruses 3.4.1. General - keyloggers, mouse/screen snapshotters 3.4.2. Targeted - specifically designed for certain victim sites (eg paypal/net banking) or certain victim actions (eg: password entry, detecting typed credit card numbers) 3.5. Authorized exploitation (authority (eg: Microsoft WPA/GA, Police, ISP, MSS, FBI, CIA, MI5, Feds...) engineer a Trojan or Viral exploit to be shipped down the wire to local PC, potentially being legitimately signed/authenticated software.) 3.6. Visual tricks 3.6.1. browser address bar spoofing 3.6.2. address bar hiding 3.7. Hardware attacks 3.7.1. keylogger devices 3.7.2. TEMPEST 3.7.3. malicious hardware modification (token mods, token substitution, auth device substitution/emulation/etc) 3.8. Carnivore, DCS1000, Altivore, NetMap, Echelon, Magic Lantern, RIPA, SORM... 4. Victim Mistakes 4.1. writing down passwords 4.2. telling people passwords 4.2.1. deliberately (eg: friends/family) 4.2.2. under duress (see 4.7) 4.3. picking weak passwords 4.4. using same passwords in more than one place 4.5. inattentiveness when entering passwords 4.5.1. not checking "https" and padlock and URL 4.5.2. not preventing shoulder surfing 4.6. permitting accounts to be "borrowed" 4.7. physical attack (getting mugged) 4.7.1. to steal auth info 4.7.2. to acquire active session 4.7.3. to force victim to take action (eg: xfer money) 4.8. allowing weak lost-password "questions"/procedures 5. Implementation Oversights 5.1. back button 5.2. lost password procedures 5.3. confidence tricks against site (as opposed to user) 5.4. insecure cookies (non-SSL session usage) 5.5. identity theft? site trusts user's lies about identity 5.6. trusting form data 5.7. accepting auth info over NON-SSL (eg: forgetting to check $ENV{HTTPS} is 'on' when performing CGI password checks) 5.8. allowing weak lost-password "questions"/procedures 5.9. replay 5.10. robot exclusion (eg: block mass password guessing) 5.11. geographical exclusion (eg: block logins from Korea) 6.12. user re-identification - eg - "We've never seen you using Mozilla before" 6.13. site-to-user authentication 6.14. allowing users to "remember" auth info in browser (permits local attacks by unauthorised users) 6.15. blocking users from being allowed to "remember" auth info in browser (facilitates spoofing / keyloggers) 6.16. using cookies (may permit local attacks by unauthorised users) 6.17. not using cookies (blocks site from identifying malicious activity or closing co-compromised accounts) 6. Denial of Service attacks 6.1. deliberate failed logins to lock victim out of account 6.2. deliberate failed logins to acquire out-of-channel subsequent access (eg: password resets) 7. Please contribute to this document! 7.1. on-list - just reply 7.2. off-list - send to christopher@pobox.com Contributors: Chris Drake v.1.0 - July 2, 2006 ######################################### ### /Authentication Threat List 1.0 ### ######################################### Kind Regards, Chris Drake _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 01:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxGZf-00041x-O7; Mon, 03 Jul 2006 01:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxGZe-00041s-SP for dix@ietf.org; Mon, 03 Jul 2006 01:02:18 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxGZc-0004ch-IH for dix@ietf.org; Mon, 03 Jul 2006 01:02:18 -0400 Received: from [12.105.228.215] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d22) for ; Mon, 3 Jul 2006 00:02:13 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: X-Mailer: Eudora [Macintosh version 7.0a12] Date: Mon, 3 Jul 2006 00:02:11 -0500 To: dix@ietf.org From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [dix] Agenda bashing X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org So, from the conversation so far, these are the architectural/protocol issues I think need discussing at the BOF: - Discussion of the scope and number of the mechanisms. There seem to be desires for (1) the ability for the user to identify to the server (probably authenticating, preventing phishing as much as possible), (2) the ability to transfer user attributes to the server, (3) the ability to store user attributes remotely, and (4) the ability for a 3rd-party to warrant user attribute claims. - Discussion of the pros and cons of mechanisms that involve changes to the user agent versus mechanisms which rely on a separate identity server to do all of the work without changing the user agent (e.g., DIX). - Discussion of the types of authentication mechanisms to be used. (I read Ben as saying it should be a general mechanism not tied to HTTP, Eliot and Terry as saying that the underlying mechanism should be common but that there should be HTTP-specific protocol, and John as having no interest in solving that particular problem. :-) ) I don't think these discussions need to be spurred by presentations. Most of this is going to be a high-level discussion and should definitely not reference any particular mechanism. (If logistics permit, I'd like to do a "pass the mic" format instead of standing in a queue at the mics, and I will do floor control.) With that in mind, here's what I have in mind for a meeting agenda: (Pre-meeting: Find minutes and jabber people - volunteers NOW would be useful!!) - Start passing blue sheets, Agenda bash - 2 minutes - What problems are we trying to solve? - 1 hour - Discuss what sort of authentication/identification from user to server is desired - Anti-phishing discussion here - Discuss what sort of attribute info from user to server is desired - Discuss whether remote storage of attributes is desired - Discuss whether 3rd-party claims are desired - What sorts of mechanisms should we use? - 1 hour - Discuss downsides of using current web auth mechanisms (i.e., user-agent changes) - Discuss downsides of using mechanisms that include no user-agent changes - Discuss authentication mechanism in light of above discussions - What work items do we have? - 28 minutes - Enumerate work items - Enumerate documents (if different than above) - Enumerate editors - End I have posted this for the agenda web page, but we can always make changes. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 03:27:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIq7-0000Et-5V; Mon, 03 Jul 2006 03:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxIq5-0000Eo-TD for dix@ietf.org; Mon, 03 Jul 2006 03:27:25 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxIq4-0006nf-KP for dix@ietf.org; Mon, 03 Jul 2006 03:27:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Jul 2006 00:27:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k637ROto025550 for ; Mon, 3 Jul 2006 00:27:24 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k637RNke014122 for ; Mon, 3 Jul 2006 00:27:23 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp411.cisco.com [10.61.65.155]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k637M0cT032666 for ; Mon, 3 Jul 2006 00:22:01 -0700 Message-ID: <44A8C6D8.9010901@cisco.com> Date: Mon, 03 Jul 2006 09:27:20 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1550; t=1151911644; x=1152775644; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=cC/Z12RSjXVfOoWzeGUAtZfrr1niWLeb2z7VWmBtRK6wicQkmprUXSHN81qIpUvWuV5+Sy6p jOUuW12AJIOth2CJlYR+iQ5WQlOV9icwLcfC4ntBpmVAWQQ/COxmieow; X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Pete, > So, from the conversation so far, these are the architectural/protocol > issues I think need discussing at the BOF: > > - Discussion of the scope and number of the mechanisms. There seem to > be desires for (1) the ability for the user to identify to the server > (probably authenticating, preventing phishing as much as possible), > (2) the ability to transfer user attributes to the server, (3) the > ability to store user attributes remotely, and (4) the ability for a > 3rd-party to warrant user attribute claims. On point (1) in order to fix phishing it is the server that must properly authenticate to the user (e.g., other way round). > > > - Discussion of the pros and cons of mechanisms that involve changes > to the user agent versus mechanisms which rely on a separate identity > server to do all of the work without changing the user agent (e.g., DIX). > > - Discussion of the types of authentication mechanisms to be used. (I > read Ben as saying it should be a general mechanism not tied to HTTP, > Eliot and Terry as saying that the underlying mechanism should be > common but that there should be HTTP-specific protocol, and John as > having no interest in solving that particular problem. :-) ) The focus needs to be on commonality. We want to avoid having to do this for each and every protocol separately. Using something like SASL would be ideal. I will not be present in Montreal, but I am very interested in the problem space, and may propose solutions in the coming months. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 09:22:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxONt-0007uP-6K; Mon, 03 Jul 2006 09:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxONs-0007tw-8j for dix@ietf.org; Mon, 03 Jul 2006 09:22:40 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxONq-0002Ha-QM for dix@ietf.org; Mon, 03 Jul 2006 09:22:40 -0400 Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id k63DMOV5014758 for ; Mon, 3 Jul 2006 06:22:29 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=qGoWlF7ehU6v2ysrHM5cg+viZprmEKTEcNXSOz47UV+X3Zg/bBACppXSKctrj26Tu s0Ty5bmaN04dxVqN7cOrQ== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by lois.corp.google.com with ESMTP id k63DLpfu019633 for ; Mon, 3 Jul 2006 06:22:13 -0700 Received: by smtp-out2.google.com with SMTP id 33so431396fpx for ; Mon, 03 Jul 2006 06:22:07 -0700 (PDT) Received: by 10.253.15.18 with SMTP id 18mr454277fpo; Mon, 03 Jul 2006 06:22:07 -0700 (PDT) Received: by 10.253.14.2 with HTTP; Mon, 3 Jul 2006 06:22:07 -0700 (PDT) Message-ID: <1b587cab0607030622s1c9dbad5v5a0ede75454f09e@mail.google.com> Date: Mon, 3 Jul 2006 14:22:07 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Updated phishing requirements draft In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: dff86644adfd94a4a79427a3accd2986 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/28/06, Sam Hartman wrote: > > > Hi. I submitted a 01 version of my phishing requirements draft Sunday > evening, but it has not yet popped out the other side so I'm including > it below. > > I've tried to improve it based on review comments. I did not get a > chance to address everything; I was focusing on some obvious issues of > clarity and on refining my thoughts so that the draft reflects my > current understanding of the area. I do thank all those who sent > comments both on the list and privately. I also thank those who were > willing to walk through the requirements with me and help me confirm > that the requirements are sufficient for what I'm trying to achieve. > > > > > > > Network Working Group S. Hartman > Internet-Draft MIT > Expires: December 27, 2006 June 25, 2006 > > > Requirements for Web Authentication Resistant to Phishing > draft-hartman-webauth-phishing-01.txt > > Status of this Memo > > By submitting this Internet-Draft, each author represents that any > 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 > aware will be disclosed, in accordance with Section 6 of BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on December 27, 2006. > > Copyright Notice > > Copyright (C) The Internet Society (2006). > > Abstract > > This memo proposes requirements for protocols between web identity > providers and users and for requirements for protocols between > identity providers and relying parties. These requirements minimize > the likelihood that criminals will be able to gain the credentials > necessary to impersonate a user or be able to fraudulently convince > users to disclose personal information. To meet these requirements > browsers must change. Websites must never receive information such > as passwords that can be used to impersonate the user to third > parties. Browsers should perform mutual authentication and flag > > > > Hartman Expires December 27, 2006 [Page 1] > > Internet-Draft Web Phishing Requirements June 2006 > > > situations when the target website is not authorized to accept the > identity being offered as this is a strong indication of fraud. > > > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 > 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3.1. Capabilities of Attackers . . . . . . . . . . . . . . . . 6 > 3.2. Attacks of Interest . . . . . . . . . . . . . . . . . . . 7 > 4. Requirements for Preventing Phishing . . . . . . . . . . . . . 8 > 4.1. Support for Passwords . . . . . . . . . . . . . . . . . . 8 > 4.2. Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 8 > 4.3. No Password Equivelents . . . . . . . . . . . . . . . . . 9 > 4.4. Mutual Authentication . . . . . . . . . . . . . . . . . . 9 > 4.5. Authentication Tied to Resulting Page . . . . . . . . . . 10 > 4.6. Restricted Identity Providers . . . . . . . . . . . . . . 11 > 4.7. Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 > 5. Is it the right Server? . . . . . . . . . . . . . . . . . . . 13 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 > Intellectual Property and Copyright Statements . . . . . . . . . . 18 > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 2] > > Internet-Draft Web Phishing Requirements June 2006 > > > 1. Introduction > > 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 > user name and plaintext password is often sent over a TLS [RFC4346] > 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 > user has used the same password. The security of passwords over TLS > depends on making sure that the password is sent to the right, > trusted server. TLS implementations typically confirm that the name > entered by the user in the URL corresponds to the certificate as > described in [RFC2818]. > > One serious security threat on the web today is phishing. Phishing > is a form of fraud where an attacker convinces a user to provide > confidential information to the attacker believing they are providing > 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 > user to go to a website and verify account information. The attacker > captures the user name and password and potentially other sensitive > information. Domain names that look like target websites, links in > email, and many other factors contribute to phishers' ability to > convince users to trust them. > > It is useful to distinguish two targets of phishing. Sometimes > phishing is targeting web authentication credentials such as user > name and password. Sometimes phishing is targeting other > confidential information. This memo presents requirements that > significantly reduce the effectiveness of the first category of > phishing: these requirements guarantee that even if the user > authenticates to the wrong server, that server cannot impersonate the > user to a third party. However to combat phishing targeted at other > confidential information the best we can do is try to help the user > detect fraud before they release confidential information. > > So, the approach taken by these requirements is to handle these two > types of phishing differently. Users are given some trusted > mechanism to determine whether they are typing their password into a > secure browser component that will authenticate them to the web > server or whether they are typing their password into a legacy > mechanism that will send their password to the server. If the user > types a password into the trusted browser component, they have strong > assurances that their password has not been disclosed and that the > page returned from the web server was generated by a party that > either knows their password or who is authenticated by an identity > provider who knows their password. The web server can then use > confidential information known to the user and web server to enhance > the user's trust in its identity beyond what is available given the > > > > Hartman Expires December 27, 2006 [Page 3] > > Internet-Draft Web Phishing Requirements June 2006 > > > social engineering attacks against TLS server authentication. If a > user enters their password into the wrong server but discovers this > before they give that server any other confidential information, then > there exposure is very limited. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 4] > > Internet-Draft Web Phishing Requirements June 2006 > > > 2. Requirements notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 5] > > Internet-Draft Web Phishing Requirements June 2006 > > > 3. Threat Model > > This section describes the assumed capabilities of phishers, > describes assumptions about web security and describes what > vulnerabilities exist. > > We assume that the browser and operating system are secure and can be > trusted by the end user. There are many attacks against browsers and > operating systems. However without this assumption we cannot make > progress in securing web authentication. So we will assume that > browsers and operating systems are secure and note that other work to > improve the security of browsers and operating systems is critical to > the security of the entire web authentication system. > > We assume that users have limited motivation to combat phishing. > Users cannot be expected to read the source of web pages, understand > how DNS works well enough to look out for spoofed domains, or > understand URI encoding. Users do not typically understand > certificates and cannot make informed decisions about whether the > subject name in a certificate corresponds to the entity they are > attempting to communicate with. > > 3.1. Capabilities of Attackers > > Attackers can convince the user to go to a website of their choosing. > Since the attacker controls the web site and since the user chose to > go to the website the TLS certificate will verify and the website > will appear to be secure. The certificate will typically not be > issued to the entity the user thinks they are communicating with, but > as discussed above, the user will not notice this. > > The attacker can convincingly replicate any part of the UI of the > website being spoofed. The attacker can also spoof trust markers > 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. > The attacker cannot replicate a UI that depends on information the > attacker does not know. For example, an attacker could generally > replicate the UI of a banking site's login page. However the > attacker probably could not replicate the account summary page until > the attacker learned the user name and password. > > 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, > if we want to avoid the user giving the attacker their password, we > must transition to a solution where the user would not give the real > target site their password. Instead they will need to > cryptographically prove that they know their password without > revealing it. > > > > Hartman Expires December 27, 2006 [Page 6] > > Internet-Draft Web Phishing Requirements June 2006 > > > 3.2. Attacks of Interest > > The primary attack of interest is an attack in which the user sends > confidential information to an unintended recipient. This contradicts the introduction, which says you are only interested in authentication credentials. > Another significant attack is an attack in which a recipient gains > sufficient credentials to impersonate the user to other recipients. > The obvious version of this attack is when the recipient learns the > password of the user. However even giving the recipient a time- > limited token that can be used to impersonate the user would be an > instance of this attack. Note that some authentication systems such > as Kerberos [RFC4120] provide a facility to delegate the ability to > act as the user to the target of the authentication. Such a facility > when used with an inappropriately trusted target would be an instance > of this attack. > > Of less serious concerns at the present time are attacks on data > integrity where a phisher provides false or misleading information to > a user. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 7] > > Internet-Draft Web Phishing Requirements June 2006 > > > 4. Requirements for Preventing Phishing > > This section describes requirements for web authentication solutions. > These solutions are intended to prevent phishing targeted at > obtaining web authentication credentials. These requirements will > make it more difficult for phishers to target other confidential > information. > > The requirements discussed here are similar to the principles > outlined in "Limits to Anti-Phishing" [ANTIPHISHING]. Most of this > work was discovered independently but work from that paper has been > integrated where appropriate. Google's perspective on phishing is > very interesting because of their operational experience. > > 4.1. Support for Passwords > > The web authentication solution MUST support passwords and MUST be > secure even when passwords are commonly used. It seems to me you are presupposing the solution to your real requirement, which is that the user must be able to walk up to any machine and use it to log in. It is not obvious to me that this means it must support passwords (at least not to more than one site, say the one where I've stored all my credentials). > In many environments, > users need the ability to walk up to a computer they have never used > before and log in to a website. Carrying a smart card or USB token > significantly increases the deployment cost of the website and > decreases user convenience. The smart card is costly to deploy > because it requires a process for replacing smart cards, requires > support staff to be trained in answering questions regarding smart > cards and requires a smart card to be issued when an identity is > issued. Smart cards are less convenient because users cannot gain > access to protected resources without having their card physically > with them. Many public access computers do not have smart cards > available and do not provide access to USB ports; when they do they > tend not to support smart cards. It is important not to > underestimate the training costs (either in money or user > frustration) of teaching people used to remembering a user name and > password about a new security technology. > > IT is desirable that a solution support other forms of authentication > such as smart cards and one-time passwords as these are useful in > some environments. > > 4.2. Trusted UI > > Users need the ability to trust components of the UI in order to know > that the UI is being presented by a trusted component of the browser. > The primary concern is to make sure that the user knows the password > is being given to trusted software rather than being filled into an > HTML form element that will be sent to the server. > > There are three basic approaches to establishing a trusted UI. The > first is to use a dynamic UI based on a secret known by the UI; the > > > > Hartman Expires December 27, 2006 [Page 8] > > Internet-Draft Web Phishing Requirements June 2006 > > > Google paper [ANTIPHISHING] recommends this approach. A second > approach is to provide a UI action that highlights trusted or non- > trusted components in some way. This could work similarly to the > Expose feature in Apple's OS X where a keystroke visually > distinguishes structural elements of the UI. Of course such a > mechanism would only be useful if users actually used it. Finally, > the multi-level security community has extensive research in > designing UIs to display classified, compartmentalized information. > It is critical that these UIs be able to label information and that > these labels not be spoofable. > > See Section 5 for another case where confidential information in a UI > can be used to build trust. > > 4.3. No Password Equivelents > > A critical requirement is that when a user authenticates to a > website, the website MUST NOT receive a strong password equivalent > [IABAUTH]. A strong password equivalent is anything that would allow > a phisher to authenticate as a user with a different identity > provider. Weak password equivalents MAY only be sent when a new > identity is being enrolled or a password is changed. A weak password > equivalent allows a party to authenticate to a given identity > provider as the user. Again, you are presupposing the necessity of passwords. Surely this should be "no authentication credential equivalents". > There are two implications of this requirement. First, strong > cryptographic authentication protocol needs to be used instead of > sending the password encrypted over TLS. The zero-knowledge class of > password protocols such as those discussed in section 8 of the IAB > authentication mechanisms document [IABAUTH] seem potentially useful > in this case. Note that mechanisms in this space tend to have > significant deployment problems because of intellectual property > issues. > > The second implication of this requirement is that if an > authentication token is presented to a website, the website MUST NOT > be able to modify the token to authenticate as the user to a third > party. The party generating the token must cryptographically bind it > to either the website that will receive the token or to a key known > only to the user. Once more you are presupposing the solution. One-time passwords work find for this purpose but are not (necessarily) cryptographically bound to anything. > If tokens are bound to keys, the user MUST prove > knowledge of this key as part of the authentication process. The key > MUST not be disclosed to the server unless the token is bound to the > server and the key is only used with that token. > > 4.4. Mutual Authentication > > The Google paper [ANTIPHISHING] describes a requirement for mutual > authentication. A common phishing practice is to accept a user name > > > > Hartman Expires December 27, 2006 [Page 9] > > Internet-Draft Web Phishing Requirements June 2006 > > > and password as part of an attempt to make the phishing site > authentic. The real target is some other confidential information. > The user name and password are captured, but are not verified. After > the user name and password are entered, the phishing site collects > other confidential information. > > Authentication of the server at the TLS level and authentication of > the client within the TLS session is not sufficient. AS discussed > previously the attacker can direct the user to a site that the > attacker controls so the TLS authentication will succeed. So an > authentication solution for phishing MUST detect the situation where > the server ignores or does not participate in the authentication. This doesn't follow - the situation you have described is one where the server _does_ participate in authentication. The problem is that they are not the server the user thinks they are,. > If > authentication is based on a shared secret such as a password, then > the authentication protocol MUST prove that the secret or a suitable > verifier is known by both parties. Interestingly the existence of a > shared secret will provide better protection that the right server is > being contacted than if public key credentials are used. By their > nature, public key credentials allow parties to be contacted without > a prior security association. However if the public keys _are_ associated with the server, then they do provide an assurance (not, of course, that this is current practice, generally). > In protecting against phishing > targeted at obtaining other confidential information, this may prove > a liability. However public key credentials provide strong > protection against phishing targeted at obtaining authentication > credentials because they are not vulnerable to dictionary attacks. > Such dictionary attacks are a significant weakness of shared secrets > such as passwords intended to be remembered by humans. For public > key protocols, this requirement would mean that the server typically > needs to sign an assertion of what identity it authenticated. > > 4.5. Authentication Tied to Resulting Page > > Users expect that whatever party they authenticate to will be the > party that generates the content they see. One possible phishing > attack is to insert the phisher between the user and the real site as > a man-in-the-middle. On today's websites, the phisher typically > gains the user's user name and password. Even if the other > requirements of this specification are met, the phisher could gain > access to the user's session on the target site. This attack is of > particular concern to the banking industry. A man-in-the-middle may > gain access to the session which may give the phisher confidential > information or the ability to execute transactions on the user's > behalf. > > The authentication system MUST guarantee to the user and the target > server that the response is generated by the target server and will > only be seen by parties authorized by either the target server or the > user. The requirement, surely, is that the response is not _useful_ to eavesdroppers, rather than not seen. There are plenty of protcols that can be run totally in the clear that leave nothing useful for an observer (e.g. Diffie-Hellman key agreement). > This can be done in several ways: > > > > > > Hartman Expires December 27, 2006 [Page 10] > > Internet-Draft Web Phishing Requirements June 2006 > > > 1. Assuming that only certificates from trusted CAs are accepted and > the user has not bypassed certificate validation, it is > sufficient to confirm that the identity of the server at the TLS > level is the same at the HTTP authentication level. In the case > of TLS client authentication this is trivially true. > > 2. Another alternative is to bind the authentication exchange to the > channel created by the TLS session. The general concept behind > channel binding is discussed in section 2.2.2 of [BTNS]. This > paragraph needs to be expanded to point to proposals for doing > channel binding with TLS. xxx > > 3. Redirect based schemes in which the identity provider is told > what site to return the user to meets this requirement provided > again that certificate validation is done at the TLS layer. And, presumably, many, many others. > > 4.6. Restricted Identity Providers > > Some identity providers will allow anyone to accept their identity. > However particularly for financial institutions and large service > providers it will be common that only authorized business partners > will be able to accept the identity. The confirmation that the the > relying party is such a business partner will often be a significant > part of the value provided by the identity provider, so it is > important that the protocol enable this. For such identities, the > user MUST be assured that the target server is authorized by the > identity provider to accept identities from that identity provider. > Several mechanisms could be used to accomplish this: > > 1. The target server can provide a certificate issued by the > identity provider as part of the authentication. > > 2. The identity provider can explicitly approve the identity. For > example in a redirect-based scheme the identity provider knows > the identity of the relying party before providing claims of > identity to that party. A similar situation happens with > Kerberos. A general criticism, but particularly apropos in this section: you appear to have no concern for the privacy of the user. It should be possible to authenticate without revealing to the identity provider who you are authenticating to. Incidentally, you've suddenly started talking about identity providers without saying what they are. > > 4.7. Protecting Enrollment > > One area of particular vulnerability to phishing is enrollment of a > new identity in an identity provider. Protecting against phishing > targeted at obtaining other confidential information as a new service > is established is outside the scope of this document. If > confidential information such as credit card numbers are provided as > part of account setup, then this may be a target for phishing. > > However there is one critical aspect in which enrollment impacts the > > > > Hartman Expires December 27, 2006 [Page 11] > > Internet-Draft Web Phishing Requirements June 2006 > > > security of authentication. During enrollment, a password is > typically established for an account at an identity provider. The > process of establishing a password MUST NOT provide a strong password > equivalent to the identity provider. That is, the identity provider > MUST NOT gain enough information to impersonate the user to a third > party while establishing a password. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 12] > > Internet-Draft Web Phishing Requirements June 2006 > > > 5. Is it the right Server? > > In Section 4, requirements were presented for web authentication > solutions to minimize the risk of phishing targeted at web access > information. This section discusses in a non-normative manner > various mechanisms for determining that the right server has been > contacted. Authenticating to the right party is an important part of > reducing the risk of phishing targeted at other confidential > information. > > Validation of the certificates used in TLS and verification that the > name in the URI maps to these certificates can be useful. As > discussed in Section 3, attackers can spoof the name in the URI. > However the TLS checks do defeat some attacks. Also, as discussed in > Section 4.5, TLS validation may be important to higher-level checks. > > A variety of initiatives propose to assign trust to servers. This > includes proposals to allow users to indicate certain servers are > trusted based on information they enter. Also, proposals to allow > third parties including parties established for this purpose and > existing certificate authorities to indicate trust have been made. > These proposals will almost certainly make phishing more difficult. > > In the case where there is an existing relationship, these > requirements provide a way that information about the relationship > can be used to provide assurance that the right party has been > contacted. > > In Section 4.2, we discuss how a secret between the user and their > local computer can be used to let the user know when a password will > be handled securely. A similar mechanism can be used to help the > user once they are authenticated to the website. The website can > present information based on a secret shared between the user and > website to convince the user that they have authenticated to the > correct site. This depends critically on the requirements of > Section 4.5 to guarantee that the phisher cannot obtain the secret. > It is tempting to use this form of trusted UI before authentication. > For example, a website could request a user name and then display > information based on a secret for that user before accepting a > password. The problem with this approach is that phishers can obtain > this information, because it can be obtained without knowing the > password. However if the secret is displayed after authentication > then phishers could not obtain the secret. This is one of the many > reasons why it is important to prevent phishing targeted at > authentication credentials. > > > > > > > Hartman Expires December 27, 2006 [Page 13] > > Internet-Draft Web Phishing Requirements June 2006 > > > 6. Security Considerations > > This memo discusses the security of web authentication and how to > minimize the risk of phishing in web authentication systems. This > section discusses the security of the overall system and discusses > how components of the system that are not directly within the scope > of this document affect the security of web transactions. This > section also discusses residual risks that remain even when the > requirements proposed here are implemented. > > The approach taken here is to separate the problem of phishing into > phishing targeted at web authentication credentials and phishing > targeted at other information. Users are given some trusted > mechanism to determine whether they are typing their password into a > secure browser component that will authenticate them to the web > server or whether they are typing their password into a legacy > mechanism that will send their password to the server. If the user > types a password into the trusted browser component, they have strong > assurances that their password has not been disclosed and that the > page returned from the web server was generated by a party that > either knows their password or who is authenticated by an identity > provider who knows their password. The web server can then use > confidential information known to the user and web server to enhance > the user's trust in its identity beyond what is available given the > social engineering attacks against TLS server authentication. If a > user enters their password into the wrong server but discovers this > before they give that server any other confidential information, then > there exposure is very limited. > > This model assumes that the browser and operating system are a > trusted component. As discussed in Section 3, there are numerous > attacks against host security. Appropriate steps should be taken to > minimize these risks. If the host security is compromised, the > password can be captured as it is typed by the user. > > This model assumes that users will only enter their passwords into > trusted browser components. There are several potential problems > with this assumption. First, users need to understand the UI > distinction and know what it looks like when they are typing into a > trusted component and what a legacy HTML form looks like. Users must > care enough about the security of their passwords to only type them > into trusted components. The browser must be designed in such a way > that the server cannot create a UI component that appears to be a > trusted component but is actually a legacy HTML form; Section 4.2 > discusses this requirement. > > IN addition, a significant risk that users will type their password > into legacy HTML forms comes from the incremental deployment of any > > > > Hartman Expires December 27, 2006 [Page 14] > > Internet-Draft Web Phishing Requirements June 2006 > > > web authentication technology. Websites will need a way to work with > older web browsers that do not yet support mechanisms that meet these > requirements. Not all websites will immediately adopt these > mechanisms. Users will sometimes browse from computers that have > mechanisms meeting these requirements and sometimes from older > browsers. They only gain protection from phishing when they type > passwords into trusted components. If a password is sometimes used > with websites that meet these requirements and sometimes with legacy > websites, and if the password is captured by a phisher targeting a > legacy website, then that captured password can be used even on > websites meeting these requirements. Similarly, if a user is tricked > into using HTML forms when they should not, passwords can be exposed. > Users can significantly reduce this risk by using different passwords > for websites that use trusted browser authentication than for those > that still use HTML forms. > > The risk of dictionary attack is always a significant concern for > password systems. Users can (but typically do not) minimize this > risk by choosing long, hard to guess phrases for passwords. The risk > can be removed once a password is already established by using a > zero-knowledge password protocol. This just isn't true. An attacker can always assume the role of the client and try to authenticate using their dictionary of passwords. This works no matter what the authentication mechanism is. If the attacker is the server then they can do this very efficiently (since they do not have to do it over the network). The only defence against dictionary attacks is to use a strong password. > However the risk of dictionary > attack is always present when setting up a new password or changing a > password. Minimizing the number of services that use the same > password can minimize this risk. When zero-knowledge password > protocols are used, being extra careful to make sure the right server > is used when establishing a password can significantly reduce this > risk. > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 15] > > Internet-Draft Web Phishing Requirements June 2006 > > > 7. References > > 7.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > 7.2. Informative References > > [ANTIPHISHING] > Nelson, J. and D. Jeske, "Limits to Anti Phishing", > January 2006. > > Proceedings of the W3c Security and Usability Workshop; ht > tp://www.w3.org/2005/Security/usability-ws/papers/ > 37-google/' > > [BTNS] Touch, J., "Problem and Applicability Statement for Better > Than Nothing Security", > draft-ietf-btns-prob-and-applic-02.txt (work in progress), > February 2006. > > [IABAUTH] Rescorla, E., "A Survey of Authentication Mechanisms", > draft-iab-auth-mech-05.txt (work in progress), > February 2006. > > [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. > > [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The > Kerberos Network Authentication Service (V5)", RFC 4120, > July 2005. > > [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.1", RFC 4346, April 2006. > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 16] > > Internet-Draft Web Phishing Requirements June 2006 > > > Author's Address > > Sam Hartman > Massachusetts Institute of Technology > > Email: hartmans-ietf@mit.edu > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hartman Expires December 27, 2006 [Page 17] > > Internet-Draft Web Phishing Requirements June 2006 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Disclaimer of Validity > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Copyright Statement > > Copyright (C) The Internet Society (2006). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > Hartman Expires December 27, 2006 [Page 18] > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 09:42:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOge-0003Jn-3u; Mon, 03 Jul 2006 09:42:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOgd-0003H7-EN for dix@ietf.org; Mon, 03 Jul 2006 09:42:03 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOgc-0003wm-1u for dix@ietf.org; Mon, 03 Jul 2006 09:42:03 -0400 Received: from death.corp.google.com (death.corp.google.com [172.24.0.123]) by smtp-out.google.com with ESMTP id k63Dfr4o025354 for ; Mon, 3 Jul 2006 06:41:58 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=vwGsy0OA8I0rzdVWgqzDflhHEdygxgFogprXHStExQBNXMoMNwdXhUnBdOzO3kSOG QCOiXl7WoxFg9wH6Qdwmw== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by death.corp.google.com with ESMTP id k63DfoYa021958 for ; Mon, 3 Jul 2006 06:41:50 -0700 Received: by smtp-out2.google.com with SMTP id 33so431924fpx for ; Mon, 03 Jul 2006 06:41:50 -0700 (PDT) Received: by 10.253.15.18 with SMTP id 18mr456723fpo; Mon, 03 Jul 2006 06:41:50 -0700 (PDT) Received: by 10.253.14.2 with HTTP; Mon, 3 Jul 2006 06:41:50 -0700 (PDT) Message-ID: <1b587cab0607030641n3afa4a3y7c3e87d06f38a2c4@mail.google.com> Date: Mon, 3 Jul 2006 14:41:50 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Google Account Authorization - slightly off topic In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com>

X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: IETF HTTP Auth X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/29/06, Dick Hardt wrote: > Google rolled out some some APIs[1] to make it easier for rich clients > [2] and websites[3] to act on behalf of a Google user. Of course this > deepens the identity silo that is building at Google. [3] looks like > some concepts that ekr has been talking about. > > Ben: hate to put you on the spot, but is Google looking to > participate in WAE? I will be at the WAE BoF, so, to that extent, yes. Google is certainly interested in (some of) the problems WAE may work on. > [1] http://code.google.com/apis/accounts/Authentication.html > [2] http://code.google.com/apis/accounts/AuthForInstalledApps.html > [3] http://code.google.com/apis/accounts/AuthForWebApps.html > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 09:47:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOlc-0003mc-Jj; Mon, 03 Jul 2006 09:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOlb-0003mV-HJ for dix@ietf.org; Mon, 03 Jul 2006 09:47:11 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOlY-00057X-8F for dix@ietf.org; Mon, 03 Jul 2006 09:47:11 -0400 Received: from chris.corp.google.com (chris.corp.google.com [172.24.0.146]) by smtp-out.google.com with ESMTP id k63Dl3q9005781 for ; Mon, 3 Jul 2006 06:47:03 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=D1ovQVKZmSqyX6vD3Q8q8tBcqj8Vnqf7YZWhusElf4383xP7lUYpToirJurF7EKM+ nKFyc1GJHjtcWgzPjRs8Q== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by chris.corp.google.com with ESMTP id k63DjvoL029723 for ; Mon, 3 Jul 2006 06:46:57 -0700 Received: by smtp-out2.google.com with SMTP id 33so432045fpx for ; Mon, 03 Jul 2006 06:46:57 -0700 (PDT) Received: by 10.253.1.18 with SMTP id 18mr989442fpa; Mon, 03 Jul 2006 06:46:57 -0700 (PDT) Received: by 10.253.14.2 with HTTP; Mon, 3 Jul 2006 06:46:57 -0700 (PDT) Message-ID: <1b587cab0607030646kfcfeeau726596d097a55a5b@mail.google.com> Date: Mon, 3 Jul 2006 14:46:57 +0100 From: "Ben Laurie" To: "Sam Hartman" Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/29/06, Sam Hartman wrote: > Hi. > > First, I'd like to thank you for this excellent starting point for the > discussion. I do have a few comments, but this is a great taxonomy. > > > > Requirements > > 2. Hijack-Resistant Authentication (HRA) > An authentication system in which credentials which are bound to > protocol messages in such a way that attacker who observes the > credentials can't use them to authenticate messages of their > choice. The rationale for this feature is to make cut-and-paste > attacks difficult. > > > I think this description and the subsequent discussion in > transporting/binding credentials has some concepts I'd like to > distinguish muddled together. > > Some schemes will provide integrity: a man in the middle can observe > the conversation but cannot modify the content of the request or > response. > > Some schemes will provide confidentiality even given the practical > difficulties with server certificate validation. > > I argue in section 4.5 and 5 of version 01 of my phishing requirements > draft that providing confidentiality of the resulting page is > important even given these practical server certificate issues. So, > I'd like to ask you to add that as a potential requirement I might want so I can ask for it. > Also, let's be careful to distinguish this from HRA. > > > You don't seem to have a requirement that corresponds to section 4.6 > of 01 of my phishing requirements draft. This was one of the issues > muddled into the confusing mutual authentication section in 00 of my > draft. I contend that if there are a small number of RPs that by > policy should be allowed to accept a given identity,there is a > security benefit in restricting the identity to only those RPs. In > particular, if a user successfully authenticates the user knows that > because their identity was successfully accepted, they have > authenticated to one of the valid RPs. I'd be happy to discuss > specific customer deployments where this will be useful with you > off-list. I understand based on your review of my 00 draft that you > don't like this requirement. I still think it reasonable to discuss. > > > > TLS Client AUthentication > > Your taxonomy assumes that TLS is a valid approach to client > authentication. As I understand HTTP, that is only true assuming > there are no proxies between the user and the RP. HTTP proxies support the CONNECT method for this (all they do is copy the raw connection data in both directions). Note that if proxies didn't do this, then server authentication would also be impossible. > We could extend HTTP to allow a proxy to assert authentication > information it received via TLS to the next hop. It might be possible > but would be more challenging to extend HTTP so that a client could > give a proxy credentials to use for TLS client authentication outbound > from that proxy. I think these issues are important to consider when > comparing how credentials and authentication are transported. > (Personally, I wish we could just ignore the whole issue of proxies. > I don't think that will be acceptable to the market though.) > > > > Transporting and Binding Credentials > > > An additional issue is hijacking: without cryptographic > binding, an attacker who observes a request can make future > requests in the name of the user via a cut-and-paste attack > (remember, the token is bearer). If you take the threat of > this type of attack seriously, you need to run the traffic > over SSL/TLS. [1] > > > [1] Note that if you're worried about this class of attack, you need > *every* PDU to be cryptographically bound to the credential with > all designs. If, for instance, you use cert-based auth but then > transition to cookies over HTTP for state management, there's a > cut-and-paste attack there. > > > I think the primary paragraph is misleading. We've started from an > assumption that there are practical problems that prevent server certificates from being validated. Given this assumption I don't understand how TLS actually gives us protection against the hijacking. > > I also think the footnote ignores an important deployment model. I > may be concerned about whether I have reached the right RP while not > concerned about network level hijacking. So I'm not at all convinced > that you always need to protect every exchange if you are concerned > about hijacking in some situations. > > Thanks again for your excellent work and for your consideration of my > comments. > > --Sam > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 09:51:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOpf-00049v-H5; Mon, 03 Jul 2006 09:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxOpe-00049q-41 for dix@ietf.org; Mon, 03 Jul 2006 09:51:22 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxOpS-00069c-60 for dix@ietf.org; Mon, 03 Jul 2006 09:51:22 -0400 Received: from vegeta.corp.google.com (vegeta.corp.google.com [172.24.0.3]) by smtp-out.google.com with ESMTP id k63DotDY026181 for ; Mon, 3 Jul 2006 06:50:55 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=W9ePVZIR6z8vEJNMsDcXcMAaOwCaMCwRNM0GY35hEPCIUPlHjlUuQSfWOLSSwCZx0 XjHLY5isiFlgm55AjGYnw== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by vegeta.corp.google.com with ESMTP id k63DmK0t014366 for ; Mon, 3 Jul 2006 06:50:46 -0700 Received: by smtp-out2.google.com with SMTP id 33so432101fpx for ; Mon, 03 Jul 2006 06:50:46 -0700 (PDT) Received: by 10.253.14.20 with SMTP id 20mr1268262fpn; Mon, 03 Jul 2006 06:50:46 -0700 (PDT) Received: by 10.253.14.2 with HTTP; Mon, 3 Jul 2006 06:50:46 -0700 (PDT) Message-ID: <1b587cab0607030650r344ddd1w6d3171dbb331fb8e@mail.google.com> Date: Mon, 3 Jul 2006 14:50:46 +0100 From: "Ben Laurie" To: "thayes0993@aol.com" Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) In-Reply-To: <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/27/06, thayes0993@aol.com wrote: > > > I doubt it will be possible to use exactly the same methods for HTTP, XMPP, > SMTP and IMAP. The latter three (XMPP, SMTP and IMAP) are session based, > and might require authentication/authorization only once during a session. > HTTP is stateless (at least in general), so some thought needs to be given > to extending the auth across multiple requests. > > A method for HTTP will need to consider potential performance issues, > replay protection, and possible tie-in with other available session state > (such as a TLS channel), among other things. The others can generally get > away with a on-time verification step per session. > > > It may be possible to share portions of the mechanism. In fact, TLS/SSL > with client authentication supports all 4 protocols. However it seems to be > rejected because of other issues: PKI lifecycles, physical portability of > the key, trust management, etc. Assuming TLS is all about X.509 is completely missing the point. TLS supports several other authentication mechanisms, such as pre-shared secrets or Kerberos. There's nothing to stop us defining some new ones if we need them. > > Terry Hayes > AOL LLC > > > -----Original Message----- > From: lear@cisco.com > To: dix@ietf.org > Cc: ietf-http-auth@lists.osafoundation.org > Sent: Tue, 27 Jun 2006 9:57 AM > Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web > authentication enhancements) > > > > Ben Laurie wrote: >> >> - Does the mechanism use or extend currently > deployed web >> authentication mechanisms (client side and server side)? If > not, why >> not? > > No - because if you use web authentication, then it > will not work for > protocols that are not HTTP based - XMPP and IMAP are > obvious examples > that spring to mind. I'm not sure I'd go so far as No, > but the mechanism or an analog must be easily ported to other application > protocols such as XMPP, SMTP, or IMAP. I would think an existence proof of 2 > (one being HTTP; the other being IMAP) would be a very useful thing for any > WG. Eliot ______________________________ > _________________ Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > ________________________________ > Check out AOL.com today. Breaking news, video search, pictures, email and > IM. All on demand. Always Free. > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 10:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPH5-0003th-LX; Mon, 03 Jul 2006 10:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPH4-0003tZ-Ks for dix@ietf.org; Mon, 03 Jul 2006 10:19:42 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPH3-00007u-Vm for dix@ietf.org; Mon, 03 Jul 2006 10:19:42 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3F8C11E8C1C; Mon, 3 Jul 2006 07:19:41 -0700 (PDT) To: Sam Hartman Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> From: Eric Rescorla Date: Mon, 03 Jul 2006 07:19:41 -0700 In-Reply-To: (Sam Hartman's message of "Wed, 28 Jun 2006 23:39:55 -0400") Message-ID: <86mzbqbwjm.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: > Hi. > > First, I'd like to thank you for this excellent starting point for the > discussion. I do have a few comments, but this is a great taxonomy. Thanks. Sorry about the slow response here but I missed this message. > Requirements > > 2. Hijack-Resistant Authentication (HRA) > An authentication system in which credentials which are bound to > protocol messages in such a way that attacker who observes the > credentials can't use them to authenticate messages of their > choice. The rationale for this feature is to make cut-and-paste > attacks difficult. > > > I think this description and the subsequent discussion in > transporting/binding credentials has some concepts I'd like to > distinguish muddled together. > > Some schemes will provide integrity: a man in the middle can observe > the conversation but cannot modify the content of the request or > response. > > Some schemes will provide confidentiality even given the practical > difficulties with server certificate validation. Yes, I agree that these are separate services. I agree that confidentiality of information carried in the transaction important, but it's not in and of itself an *authentication* goal (though it may be used in the service of one if, for instance, the tokens used for authentication are bearer, like cookies.) > I argue in section 4.5 and 5 of version 01 of my phishing > requirements draft that providing confidentiality of the resulting > page is important even given these practical server certificate > issues. So, I'd like to ask you to add that as a potential > requirement I might want so I can ask for it. I'm not sure this is applicable, since I'm not really maintaining a document here. That was just a note to the list. > You don't seem to have a requirement that corresponds to section 4.6 > of 01 of my phishing requirements draft. This was one of the issues > muddled into the confusing mutual authentication section in 00 of my > draft. I contend that if there are a small number of RPs that by > policy should be allowed to accept a given identity,there is a > security benefit in restricting the identity to only those RPs. In > particular, if a user successfully authenticates the user knows that > because their identity was successfully accepted, they have > authenticated to one of the valid RPs. I'd be happy to discuss > specific customer deployments where this will be useful with you > off-list. I understand based on your review of my 00 draft that you > don't like this requirement. I still think it reasonable to discuss. I just forgot this one. My bad. That said, I think there are actually two security issues surrounding this: 1. Having the IdP perform some kind of secondary check on the identity of the RP. 2. Allowing the IdP to limit the use of credentials to selected RPs. These sound like the same thing but they're strictly speaking not. For example, consider a case where the IdP wants to charge RPs for access to their credentials. In order to do this, they encrypt the credentials with a fixed key that they send to subscribing RPs . This doesn't provide any assurance to the user unless the RP demonstrates knowledge of the credentials. The RP might just choose to pretend it had authenticated the user, if, for instance, it wants to induce the user to give up personal information. > TLS Client AUthentication > > Your taxonomy assumes that TLS is a valid approach to client > authentication. I'm not making a judgement about whether it's valid or not. I'm saying it's been proposed. It has. > As I understand HTTP, that is only true assuming > there are no proxies between the user and the RP. no trusted proxies, technically speaking. TLS accelerators aren't a problem. I certainly have seen this issue raised, but I'd like to observe that they also exist for TLS without client auth (it's one reason why we designed S-HTTP the way we did) but people seem willing to live with that. > An additional issue is hijacking: without cryptographic > binding, an attacker who observes a request can make future > requests in the name of the user via a cut-and-paste attack > (remember, the token is bearer). If you take the threat of > this type of attack seriously, you need to run the traffic > over SSL/TLS. [1] > > > [1] Note that if you're worried about this class of attack, you need > *every* PDU to be cryptographically bound to the credential with > all designs. If, for instance, you use cert-based auth but then > transition to cookies over HTTP for state management, there's a > cut-and-paste attack there. > > > I think the primary paragraph is misleading. We've started from an > assumption that there are practical problems that prevent server > certificates from being validated. Given this assumption I don't > understand how TLS actually gives us protection against the > hijacking. Imagine a case where you have credentials that have CRA but not HRA. A good example is Boneh's PwdHash, which includes the domain name of the server in the "password". If it's restricted to use with SSL/TLS then you know that each RP will have a unique domain name and therefore each "password" is unique to a single RP, so there's automatic CRA--if the user is phished the phisher must pose as a different RP because he has a different certificate. [0] Note, however, that if you use TLS in NULL mode so that the password can be captured by a passive attacker, then he can issue a new request to the same server, thus mounting cut-and-paste attacks. This isn't strictly hijacking, nbut it's effectively the same for our purposes, since HTTP is connectionless. (I'm not sure I got the terminology on this feature exactly right). > I also think the footnote ignores an important deployment model. I > may be concerned about whether I have reached the right RP while not > concerned about network level hijacking. So I'm not at all convinced > that you always need to protect every exchange if you are concerned > about hijacking in some situations. By hijacking, I mean network level hijacking. If you mean typos and phishing, then I think this is a different threat. -Ekr [0] Remember that phishing's attack on cert validation is at the interface between the user's intention and the domain name, not at the interface between the certificate name and the domain name. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 13:17:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS3M-0002EM-Jf; Mon, 03 Jul 2006 13:17:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS3L-0002EH-7p for dix@ietf.org; Mon, 03 Jul 2006 13:17:43 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxS3J-0003xw-Ug for dix@ietf.org; Mon, 03 Jul 2006 13:17:43 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id A182A222425 for ; Mon, 3 Jul 2006 10:25:50 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing In-reply-to: Your message of "Mon, 03 Jul 2006 09:27:20 +0200." <44A8C6D8.9010901@cisco.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 03 Jul 2006 10:17:41 -0700 From: Eric Rescorla Message-Id: <20060703172550.A182A222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eliot Lear wrote: > Pete, > > So, from the conversation so far, these are the architectural/protocol > > issues I think need discussing at the BOF: > > > > - Discussion of the scope and number of the mechanisms. There seem to > > be desires for (1) the ability for the user to identify to the server > > (probably authenticating, preventing phishing as much as possible), > > (2) the ability to transfer user attributes to the server, (3) the > > ability to store user attributes remotely, and (4) the ability for a > > 3rd-party to warrant user attribute claims. > > On point (1) in order to fix phishing it is the server that must > properly authenticate to the user (e.g., other way round). That's *one* way to attack phishing (at least the current form). There are others (cf. PwdHash) -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 13:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxSan-0005Vi-UT; Mon, 03 Jul 2006 13:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxSam-0005Vd-9C for dix@ietf.org; Mon, 03 Jul 2006 13:52:16 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxSak-00051S-UF for dix@ietf.org; Mon, 03 Jul 2006 13:52:16 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k63HqEqL019445 for ; Mon, 3 Jul 2006 10:52:14 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 10:52:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Agenda bashing Date: Mon, 3 Jul 2006 10:52:12 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD5E7C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Agenda bashing Thread-Index: AcaexJ1BAxpaNlj3QRKhpvFYkJkAfgAAO7yA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 03 Jul 2006 17:52:13.0883 (UTC) FILETIME=[6A7D00B0:01C69EC9] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 > That's *one* way to attack phishing (at least the current form). > There are others (cf. PwdHash) There are three basic approaches to defeat phishing. Phishing is an ATTACK where SOCIAL ENGINEERING designed to STEAL = CREDENTIALS 1) Defeat the infrastructure of a specific attack Here we have takedown services such as the VeriSign Anti-Phishing = solution, filtering of the phishing spam, blocking known phishing = capture sites, Fraud detection services &ct. 2) Defeat the social engineering attack using strong outbound = authentication This is the principle purpose of Secure Internet Letterhead: Use the = PKIX logotype extension in an EV X.509 certificate to provide a = trustworthy proof of legitimate use of the subject brand. Letterhead may = be used in conjunction with DKIM or S/MIME to provide trustworthy proof = of origin in the email channel or with SSL to provide trustworthy proof = of origin in the Web. 3) Defeat the theft of the credentials by making the credentials theft = resistant. The OATH consortium is working to provide an open, unencumbered = standard for strong authentication whether OTP or PKI based. The = algorithms for the OTP version have already been issued as informational = RFCs. Other necessary infrastructure is being built out. WAE does not fit into 1 or 2 and it does not directly address 3.=20 Where WAE fits in is that it facilitates the infrastructure changes = necessary to make widespread deployment of #3 solutions possible.=20 With WAE I can in theory go down to Frys, buy a token and then use it to = secure access to my bank account without the bank needing to support my = specific token technology. All they need to know is that I am using = something better than username and password and that the authentication = service provider will provide an acceptable SLA. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 13:54:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxSce-0005dz-BS; Mon, 03 Jul 2006 13:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxScd-0005du-9O for dix@ietf.org; Mon, 03 Jul 2006 13:54:11 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxScc-00056N-0i for dix@ietf.org; Mon, 03 Jul 2006 13:54:11 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 368B61E8C1F; Mon, 3 Jul 2006 10:54:09 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: <198A730C2044DE4A96749D13E167AD37BD5E7C@MOU1WNEXMB04.vcorp.ad.vrsn.com> From: Eric Rescorla Date: Mon, 03 Jul 2006 10:54:09 -0700 In-Reply-To: <198A730C2044DE4A96749D13E167AD37BD5E7C@MOU1WNEXMB04.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Mon, 3 Jul 2006 10:52:12 -0700") Message-ID: <86y7vabmm6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org "Hallam-Baker, Phillip" writes: > WAE does not fit into 1 or 2 and it does not directly address 3. I with I understood what WAE was well enough to say this confidently :( -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 15:45:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUMU-0004mp-3H; Mon, 03 Jul 2006 15:45:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUMT-0004mk-CY for dix@ietf.org; Mon, 03 Jul 2006 15:45:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxUMS-0001g4-2a for dix@ietf.org; Mon, 03 Jul 2006 15:45:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Jul 2006 12:45:35 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k63JjZdh025780 for ; Mon, 3 Jul 2006 12:45:35 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k63JjZ9s028913 for ; Mon, 3 Jul 2006 12:45:35 -0700 (PDT) Received: from [212.254.247.4] (ams3-vpn-dhcp4316.cisco.com [10.61.80.219]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k63JeA3r016563 for ; Mon, 3 Jul 2006 12:40:11 -0700 Message-ID: <44A973DC.9040801@cisco.com> Date: Mon, 03 Jul 2006 21:45:32 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> In-Reply-To: <20060703172550.A182A222425@laser.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1199; t=1151955935; x=1152819935; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=qDQJgJGd6ALb0U2KZO1YENTPTHL88f9EZl4ZBxrUvi1ENHzRSaqyKo9cpj+yJZrDXc1ecHLg mSDZuDUyKDsbcCFcvYl1LrZRzcm9HRMbIrekMxpvCZl6vs/EO8uylSNI; X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eric Rescorla wrote: > Eliot Lear wrote: > >> Pete, >> >>> So, from the conversation so far, these are the architectural/protocol >>> issues I think need discussing at the BOF: >>> >>> - Discussion of the scope and number of the mechanisms. There seem to >>> be desires for (1) the ability for the user to identify to the server >>> (probably authenticating, preventing phishing as much as possible), >>> (2) the ability to transfer user attributes to the server, (3) the >>> ability to store user attributes remotely, and (4) the ability for a >>> 3rd-party to warrant user attribute claims. >>> >> On point (1) in order to fix phishing it is the server that must >> properly authenticate to the user (e.g., other way round). >> > > That's *one* way to attack phishing (at least the current form). > There are others (cf. PwdHash) > I'm sorry, but PwdHash is not enough of a reference for me to understand, but I claim that the most *effective* way to prevent phishing is to demand that the server prove its identity enough to know the right question to ask of the client. If PwdHash covers this ground, then we agree. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 16:23:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUwe-0003mo-7M; Mon, 03 Jul 2006 16:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxUwc-0003mj-S2 for dix@ietf.org; Mon, 03 Jul 2006 16:22:58 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxUwa-00055a-K3; Mon, 03 Jul 2006 16:22:58 -0400 Received: from [12.105.228.215] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d22); Mon, 3 Jul 2006 15:22:51 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <44A8C6D8.9010901@cisco.com> References: <44A8C6D8.9010901@cisco.com> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Mon, 3 Jul 2006 11:18:27 -0400 To: Digital Identity Exchange From: Pete Resnick Subject: Re: [dix] Agenda bashing Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 7/3/06 at 9:27 AM +0200, Eliot Lear wrote: >On point (1) in order to fix phishing it is the server that must >properly authenticate to the user (e.g., other way round). Good point. That should be called out separately as a desirable item. >I will not be present in Montreal, but I am very interested in the >problem space, and may propose solutions in the coming months. We will hopefully have audio stream and jabber available, so if you (or anyone else) is computer-near, please do join us. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jul 03 16:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVEb-0007Zo-Nu; Mon, 03 Jul 2006 16:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxVEa-0007Zj-KK for dix@ietf.org; Mon, 03 Jul 2006 16:41:32 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxVEY-0006Y2-Ac for dix@ietf.org; Mon, 03 Jul 2006 16:41:32 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6DC8A1E8C1F; Mon, 3 Jul 2006 13:41:29 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> From: Eric Rescorla Date: Mon, 03 Jul 2006 13:41:29 -0700 In-Reply-To: <44A973DC.9040801@cisco.com> (Eliot Lear's message of "Mon, 03 Jul 2006 21:45:32 +0200") Message-ID: <86zmfqa0au.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eliot Lear writes: > Eric Rescorla wrote: >> That's *one* way to attack phishing (at least the current form). >> There are others (cf. PwdHash) >> > > I'm sorry, but PwdHash is not enough of a reference for me to > understand, http://crypto.stanford.edu/PwdHash/ It's the first hit in Google, FWIW. > but I claim that the most *effective* way to prevent > phishing is to demand that the server prove its identity enough to know > the right question to ask of the client. If PwdHash covers this ground, > then we agree. It doesn't. It uses an entirely different technique. I don't think it's profitable to argue about what "most effective" is, but I don't agree that the mechanism you describe is the only one. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jul 04 06:10:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxhr5-00066q-AK; Tue, 04 Jul 2006 06:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxhr4-00064M-4O for dix@ietf.org; Tue, 04 Jul 2006 06:10:06 -0400 Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fxhr1-0001Y7-P5 for dix@ietf.org; Tue, 04 Jul 2006 06:10:06 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Tue, 04 Jul 2006 04:09:57 -0600 Message-Id: <44AA8C35.A648.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Tue, 04 Jul 2006 04:11:40 -0600 From: "Haripriya S" To: "Digital Identity Exchange" , "EKR" Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com><44A973DC.9040801@cisco.com> (Eliot Lear's message of "Mon, 03 Jul 2006 21:45:32 +0200") <86zmfqa0au.fsf@raman.networkresonance.com> In-Reply-To: <86zmfqa0au.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org pwdHash can address two problems: a. theft of the passwords from one website and using the same at other websites b. theft of passwords for the target website by phishing But techniques like pwdHash cannot prevent phishing attacks where the phishing sites do not even validate the password from the user, but goes on to prompt and capture long-term credentials from the user like credit cards etc. As Eliot pointed out, in such cases it is the server which needs to be authenticated in a phish-proof way. Thanks and Regards, Haripriya >>> Eric Rescorla 07/04/06 2:11 AM >>> Eliot Lear writes: > Eric Rescorla wrote: >> That's *one* way to attack phishing (at least the current form). >> There are others (cf. PwdHash) >> > > I'm sorry, but PwdHash is not enough of a reference for me to > understand, http://crypto.stanford.edu/PwdHash/ It's the first hit in Google, FWIW. > but I claim that the most *effective* way to prevent > phishing is to demand that the server prove its identity enough to know > the right question to ask of the client. If PwdHash covers this ground, > then we agree. It doesn't. It uses an entirely different technique. I don't think it's profitable to argue about what "most effective" is, but I don't agree that the mechanism you describe is the only one. - Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jul 04 11:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxmhs-0001P1-Ox; Tue, 04 Jul 2006 11:20:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxmhs-0001Ow-4d for dix@ietf.org; Tue, 04 Jul 2006 11:20:56 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxlXS-0006ld-6C for dix@ietf.org; Tue, 04 Jul 2006 10:06:06 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxlRG-0006n0-TI for dix@ietf.org; Tue, 04 Jul 2006 09:59:44 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id B138B1E8C1F; Tue, 4 Jul 2006 06:59:39 -0700 (PDT) To: "Haripriya S" Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <44AA8C35.A648.00B6.0@novell.com> From: Eric Rescorla Date: Tue, 04 Jul 2006 06:59:39 -0700 In-Reply-To: <44AA8C35.A648.00B6.0@novell.com> (Haripriya S.'s message of "Tue, 04 Jul 2006 04:11:40 -0600") Message-ID: <864pxxa2t0.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org "Haripriya S" writes: > pwdHash can address two problems: > a. theft of the passwords from one website and using the same at other > websites > b. theft of passwords for the target website by phishing > But techniques like pwdHash cannot prevent phishing attacks where the > phishing sites do not even validate the password from the user, but goes > on to prompt and capture long-term credentials from the user like credit > cards etc. As Eliot pointed out, in such cases it is the server which > needs to be authenticated in a phish-proof way. That's one way to look at it. Another is that this is just another password and should be solved with the same approach. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jul 05 19:02:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGOC-000547-AB; Wed, 05 Jul 2006 19:02:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGOA-000542-Sk for dix@ietf.org; Wed, 05 Jul 2006 19:02:34 -0400 Received: from imo-m24.mx.aol.com ([64.12.137.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyGO9-00017l-Ea for dix@ietf.org; Wed, 05 Jul 2006 19:02:34 -0400 Received: from THayes0993@aol.com by imo-m24.mx.aol.com (mail_out_v38_r7.5.) id 9.426.58b9506 (60464); Wed, 5 Jul 2006 19:02:26 -0400 (EDT) Received: from FWM-D05 (fwm-d05.webmail.aol.com [205.188.160.197]) by ciaaol-m01.mx.aol.com (v109.13) with ESMTP id MAILCIAAOLM011-ec3044ac45022a9; Wed, 05 Jul 2006 19:02:26 -0400 Content-Transfer-Encoding: 7bit Date: Wed, 05 Jul 2006 19:02:26 -0400 Message-Id: <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> From: thayes0993@aol.com References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> Received: from 216.100.248.241 by FWM-D05.sysops.aol.com (205.188.160.197) with HTTP (WebMailUI); Wed, 05 Jul 2006 19:02:26 -0400 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <86zmfqa0au.fsf@raman.networkresonance.com> X-Mailer: AOL WebMail 18681 Subject: Re: [dix] Agenda bashing Content-Type: text/plain; charset="us-ascii"; format=flowed MIME-Version: 1.0 To: ekr@networkresonance.com, dix@ietf.org X-AOL-IP: 205.188.160.197 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I believe that PwdHash does rely on a certain level of proof of the server's identity. The browser needs to decide that the domain name that the server is presenting actually belongs to it. This is usually done by relying on SSL/TLS. If the false server can convince the browser that it is in fact the targeted domain, then the browser will happily transmit the full credential (H(password, domain)) to the server. PwdHash does NOT require that the proved domain match anything the user has in mind. That is, the identity does not need to be presented to the user, or compared against anything the user is doing. This seems to be the primary problem in phishing attacks (the last foot). That's where the real advantage of techniques like PwdHash are. Terry -----Original Message----- From: Eric Rescorla To: Digital Identity Exchange Sent: Mon, 3 Jul 2006 13:41:29 -0700 Subject: Re: [dix] Agenda bashing Eliot Lear writes: > but I claim that the most *effective* way to prevent > phishing is to demand that the server prove its identity enough to know > the right question to ask of the client. If PwdHash covers this ground, > then we agree. It doesn't. It uses an entirely different technique. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix ________________________________________________________________________ Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on demand. Always Free. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jul 05 19:07:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGSZ-0005Pd-Hc; Wed, 05 Jul 2006 19:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyGSZ-0005PY-1h for dix@ietf.org; Wed, 05 Jul 2006 19:07:07 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyGSW-0001Yj-Lq for dix@ietf.org; Wed, 05 Jul 2006 19:07:07 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BE3F31E8C1F; Wed, 5 Jul 2006 16:07:03 -0700 (PDT) To: thayes0993@aol.com Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> From: Eric Rescorla Date: Wed, 05 Jul 2006 16:07:03 -0700 In-Reply-To: <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> (thayes's message of "Wed, 05 Jul 2006 19:02:26 -0400") Message-ID: <86u05virc8.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: dix@ietf.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org thayes0993@aol.com writes: > I believe that PwdHash does rely on a certain level of proof of the > server's identity. The browser needs to decide that > the domain name that the server is presenting actually belongs to it. > This is usually done by relying on SSL/TLS. > If the false server can convince the browser that it is in fact the > targeted domain, then the browser will happily > transmit the full credential (H(password, domain)) to the server. > > PwdHash does NOT require that the proved domain match anything the > user has in mind. That is, the identity > does not need to be presented to the user, or compared against > anything the user is doing. This seems to be the > primary problem in phishing attacks (the last foot). That's where the > real advantage of techniques like PwdHash are. I think this is a fair summary. -Ekr > -----Original Message----- > From: Eric Rescorla > To: Digital Identity Exchange > Sent: Mon, 3 Jul 2006 13:41:29 -0700 > Subject: Re: [dix] Agenda bashing > > Eliot Lear writes: > >> but I claim that the most *effective* way to prevent >> phishing is to demand that the server prove its identity enough to > know >> the right question to ask of the client. If PwdHash covers this > ground, >> then we agree. > > It doesn't. It uses an entirely different technique. > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > > ________________________________________________________________________ > Check out AOL.com today. Breaking news, video search, pictures, email > and IM. All on demand. Always Free. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 02:12:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN6O-0004mN-1K; Thu, 06 Jul 2006 02:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyN6M-0004mC-E3 for dix@ietf.org; Thu, 06 Jul 2006 02:12:38 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyN6L-0008Hd-5G for dix@ietf.org; Thu, 06 Jul 2006 02:12:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2006 23:12:37 -0700 X-IronPort-AV: i="4.06,211,1149490800"; d="scan'208"; a="327441121:sNHT31001098" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k666Caif000390; Wed, 5 Jul 2006 23:12:36 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k666Ca9s026411; Wed, 5 Jul 2006 23:12:36 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp4298.cisco.com [10.61.80.201]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66672Pn028964; Wed, 5 Jul 2006 23:07:02 -0700 Message-ID: <44ACA9CF.7090605@cisco.com> Date: Thu, 06 Jul 2006 08:12:31 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> In-Reply-To: <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1433; t=1152166356; x=1153030356; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=divw/Esyn8UknmeQ7qXy9tcDTnRKOApOhKrukzcKkEm3OKpMLP8EN/oGAsDgDNfh72G3j0HA 1MOnUmpKi7dp50p2CRJa5ByuLa1ZGGmoudIpSAECZdCJObEI3Us2mDu6; X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org thayes0993@aol.com wrote: > I believe that PwdHash does rely on a certain level of proof of the > server's identity. The browser needs to decide that > the domain name that the server is presenting actually belongs to it. > This is usually done by relying on SSL/TLS. > If the false server can convince the browser that it is in fact the > targeted domain, then the browser will happily > transmit the full credential (H(password, domain)) to the server. > > PwdHash does NOT require that the proved domain match anything the > user has in mind. That is, the identity > does not need to be presented to the user, or compared against > anything the user is doing. This seems to be the > primary problem in phishing attacks (the last foot). That's where the > real advantage of techniques like PwdHash are. Pretty neat. There are two problems that still really need to be addressed. The first is that you need to manage a transition. It must be clearly visible to the user when PwdHash is used and when it is not. Otherwise someone just phishes the original password and that's the ball game. Second, PwdHash still relies on the underlying security of the user's computer. I don't know about you but that is a goal I would like to address. I want a means to have a secure opaque channel of communication between the server and the smart card. That's what I'm looking for from the IETF. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 08:11:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyShh-0005zw-RT; Thu, 06 Jul 2006 08:11:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyShf-0005qj-Kt for dix@ietf.org; Thu, 06 Jul 2006 08:11:31 -0400 Received: from smtp-out.google.com ([216.239.33.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyShe-0001Nm-6q for dix@ietf.org; Thu, 06 Jul 2006 08:11:31 -0400 Received: from brian.corp.google.com (brian.corp.google.com [172.24.0.122]) by smtp-out.google.com with ESMTP id k66CBMAt028074 for ; Thu, 6 Jul 2006 13:11:23 +0100 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=OB6N61vY7paFjdXmlIuwygDb5uJCg97wM2jkNMiguaiVZHvfa8o+QOs1j9V4biELj VpJ0jdCS+l17muxAkIIUA== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by brian.corp.google.com with ESMTP id k66C8EsH018177 for ; Thu, 6 Jul 2006 05:11:21 -0700 Received: by smtp-out2.google.com with SMTP id 33so576195fpx for ; Thu, 06 Jul 2006 05:11:21 -0700 (PDT) Received: by 10.253.1.18 with SMTP id 18mr1496651fpa; Thu, 06 Jul 2006 05:11:21 -0700 (PDT) Received: by 10.253.14.2 with HTTP; Thu, 6 Jul 2006 05:11:21 -0700 (PDT) Message-ID: <1b587cab0607060511l2a96a136vaebc5c116c6e02cb@mail.google.com> Date: Thu, 6 Jul 2006 13:11:21 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Agenda bashing In-Reply-To: <44ACA9CF.7090605@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> <44ACA9CF.7090605@cisco.com> X-Spam-Score: -4.3 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 7/6/06, Eliot Lear wrote: > thayes0993@aol.com wrote: > > I believe that PwdHash does rely on a certain level of proof of the > > server's identity. The browser needs to decide that > > the domain name that the server is presenting actually belongs to it. > > This is usually done by relying on SSL/TLS. > > If the false server can convince the browser that it is in fact the > > targeted domain, then the browser will happily > > transmit the full credential (H(password, domain)) to the server. > > > > PwdHash does NOT require that the proved domain match anything the > > user has in mind. That is, the identity > > does not need to be presented to the user, or compared against > > anything the user is doing. This seems to be the > > primary problem in phishing attacks (the last foot). That's where the > > real advantage of techniques like PwdHash are. > > Pretty neat. There are two problems that still really need to be > addressed. The first is that you need to manage a transition. It must > be clearly visible to the user when PwdHash is used and when it is not. > Otherwise someone just phishes the original password and that's the ball > game. > > Second, PwdHash still relies on the underlying security of the user's > computer. I don't know about you but that is a goal I would like to > address. I want a means to have a secure opaque channel of > communication between the server and the smart card. That's what I'm > looking for from the IETF. This seems like a worthy goal, but one that is perhaps orthogonal to other means of authenticating users. Certainly I'd be violently opposed to requiring users to have smartcards. > > Eliot > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 08:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySlW-0001Bk-Uz; Thu, 06 Jul 2006 08:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySlW-0001Bf-6b for dix@ietf.org; Thu, 06 Jul 2006 08:15:30 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySlU-0002A9-Uh for dix@ietf.org; Thu, 06 Jul 2006 08:15:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2006 05:15:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k66CFSeY025111 for ; Thu, 6 Jul 2006 05:15:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k66CFSke029270 for ; Thu, 6 Jul 2006 05:15:28 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp473.cisco.com [10.61.65.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66C9qM0004781 for ; Thu, 6 Jul 2006 05:09:53 -0700 Message-ID: <44ACFEDD.50507@cisco.com> Date: Thu, 06 Jul 2006 14:15:25 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> <44ACA9CF.7090605@cisco.com> <1b587cab0607060511l2a96a136vaebc5c116c6e02cb@mail.google.com> In-Reply-To: <1b587cab0607060511l2a96a136vaebc5c116c6e02cb@mail.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=333; t=1152188128; x=1153052128; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=jHr7b+RKRKlkVYH/pKoWs+/thehhgFralghNtskmeYzOL0BBt8423FlLX+Q+SA65xNi2jXrO HxVsvA9USGMtvj4MAJn7rwZAMQtduE2G+TxGkct41iW9Wzlvpnah9ErW; X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Ben Laurie wrote: > This seems like a worthy goal, but one that is perhaps orthogonal to > other means of authenticating users. Certainly I'd be violently > opposed to requiring users to have smartcards. Reiterating: the protocol MUST solve the problem for smart cards, but it MUST NOT require their implementation. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 08:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTPj-0006kU-F1; Thu, 06 Jul 2006 08:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTPh-0006kO-MJ for dix@ietf.org; Thu, 06 Jul 2006 08:57:01 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTPg-0000cw-BX for dix@ietf.org; Thu, 06 Jul 2006 08:57:01 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6F5BF1E8C1F; Thu, 6 Jul 2006 05:56:59 -0700 (PDT) To: Eliot Lear Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> <44ACA9CF.7090605@cisco.com> From: Eric Rescorla Date: Thu, 06 Jul 2006 05:56:59 -0700 In-Reply-To: <44ACA9CF.7090605@cisco.com> (Eliot Lear's message of "Thu, 06 Jul 2006 08:12:31 +0200") Message-ID: <86fyhej3hg.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eliot Lear writes: > thayes0993@aol.com wrote: >> I believe that PwdHash does rely on a certain level of proof of the >> server's identity. The browser needs to decide that >> the domain name that the server is presenting actually belongs to it. >> This is usually done by relying on SSL/TLS. >> If the false server can convince the browser that it is in fact the >> targeted domain, then the browser will happily >> transmit the full credential (H(password, domain)) to the server. >> >> PwdHash does NOT require that the proved domain match anything the >> user has in mind. That is, the identity >> does not need to be presented to the user, or compared against >> anything the user is doing. This seems to be the >> primary problem in phishing attacks (the last foot). That's where the >> real advantage of techniques like PwdHash are. > > Pretty neat. There are two problems that still really need to be > addressed. The first is that you need to manage a transition. It must > be clearly visible to the user when PwdHash is used and when it is not. > Otherwise someone just phishes the original password and that's the ball > game. Of course. Hence all my ranting about how this is a UI problem. > Second, PwdHash still relies on the underlying security of the user's > computer. I don't know about you but that is a goal I would like to > address. I want a means to have a secure opaque channel of > communication between the server and the smart card. That's what I'm > looking for from the IETF. Well, you could clearly use PwdHash this way. In fact, that's how your industry standard challenge-response token works. But it doesn't really help because you don't have HRA against an attacker who controls the victim's computer. So, they don't capture your authentication string but they capture the immediately following session. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 09:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTkv-0004mX-DT; Thu, 06 Jul 2006 09:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTku-0004ks-Bj for dix@ietf.org; Thu, 06 Jul 2006 09:18:56 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTkt-0004Ip-04 for dix@ietf.org; Thu, 06 Jul 2006 09:18:56 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k66DIshd023372 for ; Thu, 6 Jul 2006 06:18:54 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 06:18:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Agenda bashing Date: Thu, 6 Jul 2006 06:18:46 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD5F42@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Agenda bashing Thread-Index: Acag9Vglt2Pj+TTxTfm5hPCr/LUF+QAB9P9A From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 06 Jul 2006 13:18:53.0707 (UTC) FILETIME=[BA75FDB0:01C6A0FE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > From: Ben Laurie [mailto:benl@google.com]=20 > This seems like a worthy goal, but one that is perhaps=20 > orthogonal to other means of authenticating users. Certainly=20 > I'd be violently opposed to requiring users to have smartcards. Violently? The authentication infrastructure should enable use of any form of = authentication mechanism. SAML already supports this. It is clearly an = achievable goal that does not place an undue burden on the design. What we do not need to do is to support selection of selection = mechanisms so the user gets a choice of GSSAPI, SAML, WS-*, SASL which = in turn give a choice between every imaginable protocol. We need one way to authenticate via the common authentication = mechanisms: Passwords, Two Factor (OTP) Passwords, PKI signature, PKI = encryption, Passthrough of biometric data capture. All of these can be supported in a simple client - relying party - = authentication service scheme where the client never talks to the auth = server directly.=20 I do not think that we need to provide direct support multiple round = trip protocols such as some of the more complex zero knowledge schemes. = In those cases the simplest scheme is for the client to talk to the = authentication service directly.=20 It is in any case desirable to have direct contact between the user and = the auth-N service in the case of password schemes to prevent certain = forms of MIM attack. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 09:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTuP-0004z4-7P; Thu, 06 Jul 2006 09:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTuO-0004vz-2D for dix@ietf.org; Thu, 06 Jul 2006 09:28:44 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTuL-0004az-Nl for dix@ietf.org; Thu, 06 Jul 2006 09:28:44 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k66DSfSH024330 for ; Thu, 6 Jul 2006 06:28:41 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 06:28:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jul 2006 06:28:34 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD5F43@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some phishing perspective Thread-Index: Acag+7FRRdZVWYpIQy2hvUQknUgL3QAAyvsw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" X-OriginalArrivalTime: 06 Jul 2006 13:28:40.0795 (UTC) FILETIME=[186482B0:01C6A100] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [dix] Some phishing perspective X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org There has been some oblique discussion about phishing and MIM attacks. MIM attacks are a concern, in particular MIM attacks where the end user = machine is compromized through a trojan are a very big concern. There is = also concern about users typing passwords into entry forms presented by = a MIM (classic phishing). The use of dynamic credentials (One Time Passwords) does not protect = against a MIM entry form attack but it does have a major impact on the = criminals. Dynamic credentials can only be used once. That means that there is an = upper bound on the fraud loss when phishing takes place since the number = of transactions is limited.=20 It also means that it is much harder to resell the credentials on a = dumps market. A carder who buys 10,000 credit card numbers can test them = out in a low value transaction such as buying a domain name before they = go on to attempt a riskier high value transaction. Dynamic credentials = can only be used once, the perp is put at much greater risk. The other advantage of dymanic credentials is that they are self = healing. It is not necessary to reissue the token unless the customer = actually lost it. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 10:23:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUlH-0000W6-Km; Thu, 06 Jul 2006 10:23:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUlG-0000W1-V3 for dix@ietf.org; Thu, 06 Jul 2006 10:23:22 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUlE-0007BZ-Jz for dix@ietf.org; Thu, 06 Jul 2006 10:23:22 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D8B911E8C1F; Thu, 6 Jul 2006 07:23:19 -0700 (PDT) To: Eliot Lear Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> <44ACA9CF.7090605@cisco.com> <86fyhej3hg.fsf@raman.networkresonance.com> <44AD1A86.1050300@cisco.com> From: Eric Rescorla Date: Thu, 06 Jul 2006 07:23:19 -0700 In-Reply-To: <44AD1A86.1050300@cisco.com> (Eliot Lear's message of "Thu, 06 Jul 2006 16:13:26 +0200") Message-ID: <864pxuhkx4.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eliot Lear writes: > Eric Rescorla wrote: >> Well, you could clearly use PwdHash this way. In fact, that's how >> your industry standard challenge-response token works. But it doesn't >> really help because you don't have HRA against an attacker who >> controls the victim's computer. So, they don't capture your >> authentication string but they capture the immediately following >> session. >> > > PwdHash as an algorithm doesn't protect you from a host computer > compromise. For that you need architectural separation, which is why > smart cards etc exist. Yes, Eliot, I'm really quite familiar with the principle of two-factor authentication. My point was that the algorithm that PwdHash employs is basically the same one that your average challenge response token uses. It's purely a matter of location. > It remains up to the end server as to what > transactions might require additional authentication. So for instance, > a bank may choose to authenticate on new payees for online billing or > for particularly large transactions. Or not. The problem is that this only sort-of protects you against host computer compromise because the token that the user authenticates with generally isn't cryptographically bound to the request the user is making. This allows the crimeware to claim it's requesting you to use your token for innocuous purpose X (e.g, routine security check) but to actually be using it for malicious purpose Y. So, it's a liveness check, but not a misuse check. See also [BF99]. -Ekr [BF99] "Hand-Held Computers Can Be Better Smart Cards." Dirk Balfanz and Edward Felten. Proceedings of USENIX Security '99. Washington, DC. August 1999. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 13:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXM4-0002L5-UN; Thu, 06 Jul 2006 13:09:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXM3-0002Kq-CX for dix@ietf.org; Thu, 06 Jul 2006 13:09:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUkh-00079v-Hb for dix@ietf.org; Thu, 06 Jul 2006 10:22:47 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FyUbh-0006GS-8J for dix@ietf.org; Thu, 06 Jul 2006 10:13:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Jul 2006 07:13:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k66EDSnr025175; Thu, 6 Jul 2006 07:13:28 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k66EDS9s004031; Thu, 6 Jul 2006 07:13:28 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp473.cisco.com [10.61.65.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k66E7rmN007322; Thu, 6 Jul 2006 07:07:53 -0700 Message-ID: <44AD1A86.1050300@cisco.com> Date: Thu, 06 Jul 2006 16:13:26 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: EKR Subject: Re: [dix] Agenda bashing References: <20060703172550.A182A222425@laser.networkresonance.com> <44A973DC.9040801@cisco.com> <86zmfqa0au.fsf@raman.networkresonance.com> <8C86E9E37E4BD3C-1288-2A5B@FWM-D05.sysops.aol.com> <44ACA9CF.7090605@cisco.com> <86fyhej3hg.fsf@raman.networkresonance.com> In-Reply-To: <86fyhej3hg.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=786; t=1152195208; x=1153059208; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Agenda=20bashing; X=v=3Dcisco.com=3B=20h=3D6inNqoEUmFyA1l2ZAW91r5N7nQI=3D; b=JbE3FC67dZhgkg3x3g4Tj5TP2LDlcq7o+WSkxs/pd2c6B/Xv0B2It08Y0iQ+1GA300Xprx5A xejYPdv9ti69eOlJUZB+Cfp8DNCPl9HnLUwOPP54OzDeFRtQow+rvl50; X-Spam-Score: -2.3 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Eric Rescorla wrote: > Well, you could clearly use PwdHash this way. In fact, that's how > your industry standard challenge-response token works. But it doesn't > really help because you don't have HRA against an attacker who > controls the victim's computer. So, they don't capture your > authentication string but they capture the immediately following > session. > PwdHash as an algorithm doesn't protect you from a host computer compromise. For that you need architectural separation, which is why smart cards etc exist. It remains up to the end server as to what transactions might require additional authentication. So for instance, a bank may choose to authenticate on new payees for online billing or for particularly large transactions. Or not. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 14:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZ0g-0001S8-8I; Thu, 06 Jul 2006 14:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZ0f-0001Rx-4g for dix@ietf.org; Thu, 06 Jul 2006 14:55:33 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZ0d-0004W5-TQ for dix@ietf.org; Thu, 06 Jul 2006 14:55:33 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2B6E0E0079; Thu, 6 Jul 2006 14:55:56 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0607030646kfcfeeau726596d097a55a5b@mail.google.com> Date: Thu, 06 Jul 2006 14:55:56 -0400 In-Reply-To: <1b587cab0607030646kfcfeeau726596d097a55a5b@mail.google.com> (Ben Laurie's message of "Mon, 3 Jul 2006 14:46:57 +0100") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Ben" == Ben Laurie writes: >> TLS Client AUthentication >> >> Your taxonomy assumes that TLS is a valid approach to client >> authentication. As I understand HTTP, that is only true >> assuming there are no proxies between the user and the RP. Ben> HTTP proxies support the CONNECT method for this (all they do Ben> is copy the raw connection data in both directions). Note Ben> that if proxies didn't do this, then server authentication Ben> would also be impossible. I'm sorry, I mean no non-connect based proxies. I.E. proxies that are HTTP hops. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 15:07:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCJ-0000gJ-Hf; Thu, 06 Jul 2006 15:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZCI-0000eb-CY for dix@ietf.org; Thu, 06 Jul 2006 15:07:34 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZCG-00059n-W9 for dix@ietf.org; Thu, 06 Jul 2006 15:07:34 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 23EEBE0079; Thu, 6 Jul 2006 15:07:57 -0400 (EDT) From: Sam Hartman To: EKR Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <86mzbqbwjm.fsf@raman.networkresonance.com> Date: Thu, 06 Jul 2006 15:07:57 -0400 In-Reply-To: <86mzbqbwjm.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 03 Jul 2006 07:19:41 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: >> An additional issue is hijacking: without cryptographic >> binding, an attacker who observes a request can make future >> requests in the name of the user via a cut-and-paste attack >> (remember, the token is bearer). If you take the threat of this >> type of attack seriously, you need to run the traffic over >> SSL/TLS. [1] >> >> >> [1] Note that if you're worried about this class of attack, you >> need *every* PDU to be cryptographically bound to the >> credential with all designs. If, for instance, you use >> cert-based auth but then transition to cookies over HTTP for >> state management, there's a cut-and-paste attack there. >> >> >> I think the primary paragraph is misleading. We've started >> from an assumption that there are practical problems that >> prevent server certificates from being validated. Given this >> assumption I don't understand how TLS actually gives us >> protection against the hijacking. Eric> Imagine a case where you have credentials that have CRA but Eric> not HRA. A good example is Boneh's PwdHash, which includes Eric> the domain name of the server in the "password". If it's Eric> restricted to use with SSL/TLS then you know that each RP Eric> will have a unique domain name and therefore each "password" Eric> is unique to a single RP, so there's automatic CRA--if the Eric> user is phished the phisher must pose as a different RP Eric> because he has a different certificate. [0] This is not true of all credentials that have cra but not ha--or at least I don't see why it is. TLS only provides security because you bind the two authentication layers together by using the same naming for both the TLS authentication and the higher layer authentication. (It also assumes that your CA is trusted; that assumption seems consistent with our threat model.) I was explicitly trying to get at the fact that you needed to do something in addition to TLS. Here you've made the naming be the same. >> I also think the footnote ignores an important deployment >> model. I may be concerned about whether I have reached the >> right RP while not concerned about network level hijacking. So >> I'm not at all convinced that you always need to protect every >> exchange if you are concerned about hijacking in some >> situations. Eric> By hijacking, I mean network level hijacking. If you mean Eric> typos and phishing, then I think this is a different threat. Can we have a name for that threat, because I thought you were lumping the two together. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jul 06 15:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZXa-0000Ve-Mz; Thu, 06 Jul 2006 15:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZXZ-0000VU-W7 for dix@ietf.org; Thu, 06 Jul 2006 15:29:33 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZXY-0000AE-Fo for dix@ietf.org; Thu, 06 Jul 2006 15:29:33 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 064B21E8C1C; Thu, 6 Jul 2006 12:29:32 -0700 (PDT) To: Sam Hartman Subject: Re: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <86mzbqbwjm.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Thu, 06 Jul 2006 12:29:31 -0700 In-Reply-To: (Sam Hartman's message of "Thu, 06 Jul 2006 15:07:57 -0400") Message-ID: <86k66qwmzo.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: