From dix-bounces@ietf.org Mon May 01 17:49:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagGS-00026w-ST; Mon, 01 May 2006 17:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagGR-00026b-Bk for dix@ietf.org; Mon, 01 May 2006 17:49:07 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagGP-0006eN-Vk for dix@ietf.org; Mon, 01 May 2006 17:49:07 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k41Ln5ll014305 for ; Mon, 1 May 2006 17:49:05 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k41Ln5Nn262734 for ; Mon, 1 May 2006 15:49:05 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k41Ln58Z010080 for ; Mon, 1 May 2006 15:49:05 -0600 Received: from d03nm112.boulder.ibm.com (d03nm112.boulder.ibm.com [9.17.195.138]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k41Ln52P010071 for ; Mon, 1 May 2006 15:49:05 -0600 In-Reply-To: To: Digital Identity Exchange Cc: Digital Identity Exchange Subject: Re: [dix] Permanent IDs and how to obsolete an identity MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Charles Carrington Message-ID: Date: Mon, 1 May 2006 15:52:18 -0600 X-MIMETrack: Serialize by Router on D03NM112/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 05/01/2006 15:52:19, Serialize complete at 05/01/2006 15:52:19 X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Content-Type: multipart/mixed; boundary="===============0598179816==" Errors-To: dix-bounces@ietf.org This is a multipart message in MIME format. --===============0598179816== Content-Type: multipart/alternative; boundary="=_alternative 0077D47486257161_=" This is a multipart message in MIME format. --=_alternative 0077D47486257161_= Content-Type: text/plain; charset="US-ASCII" Lisa, I think its virtually impossible to remove anything completely from the Web. I think we should concentrate on expiring the credentials associated with IDs. Driver's licenses and passports have expiration dates. PKI certs have expiration dates and revocation lists. Most ID's do not, and I think this is a feature that is sorely needed. Thus "permanent IDs are not allowable" might be a better approach. Charles Carrington cdcarr@us.ibm.com Lisa Dusseault wrote on 04/28/2006 03:23:28 PM: > > Somebody was talking to me about how IDs similar to > "myname@serviceprovider.com" are useless because you can't trust the > ID when the service provider is gone. > > Isn't it the general expectation that these IDs are impermanent? > Just like when my email address at work becomes obsolete when I leave > the job -- I just stop using that ID. In fact it may be easier to > obsolete an ID than an email address. OTOH it might not be, there > might be permissions and preferences scattered about the Web, > associated with an ID that suddenly becomes useless. > > The statement that "permanent IDs are not required" might be useful > in the charter. There may also be interesting use cases about how to > obsolete an ID. > > Lisa > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix --=_alternative 0077D47486257161_= Content-Type: text/html; charset="US-ASCII"
Lisa,

I think its virtually impossible to remove anything completely from the Web.

I think we should concentrate on expiring the credentials associated with IDs.   Driver's licenses and passports
have expiration dates.  PKI certs have expiration dates and revocation lists.  Most ID's do not, and I think this is
a feature that is sorely needed.

Thus "permanent IDs are not allowable" might be a better approach.



Charles Carrington
cdcarr@us.ibm.com

Lisa Dusseault <lisa@osafoundation.org> wrote on 04/28/2006 03:23:28 PM:

>
> Somebody was talking to me about how IDs similar to  
> "myname@serviceprovider.com" are useless because you can't trust the  
> ID when the service provider is gone.
>
> Isn't it the general expectation that these IDs are impermanent?  
> Just like when my email address at work becomes obsolete when I leave  
> the job -- I just stop using that ID.  In fact it may be easier to  
> obsolete an ID than an email address.  OTOH it might not be, there  
> might be permissions and preferences scattered about the Web,  
> associated with an ID that suddenly becomes useless.
>
> The statement that "permanent IDs are not required" might be useful  
> in the charter.  There may also be interesting use cases about how to  
> obsolete an ID.
>
> Lisa
>
> _______________________________________________
> dix mailing list
> dix@ietf.org
> https://www1.ietf.org/mailman/listinfo/dix
 --=_alternative 0077D47486257161_=-- --===============0598179816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0598179816==-- From dix-bounces@ietf.org Tue May 02 11:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fawhb-0005hj-Mr; Tue, 02 May 2006 11:22:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fawha-0005ha-Hc for dix@ietf.org; Tue, 02 May 2006 11:22:14 -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 1Faw4Y-0006gW-IJ for dix@ietf.org; Tue, 02 May 2006 10:41:54 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Favn5-00024M-Og for dix@ietf.org; Tue, 02 May 2006 10:23:53 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k42ENpvO031649; Tue, 2 May 2006 14:23:51 GMT Received: from stntexch01.cis.neustar.com ([10.31.13.43]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 10:23:46 -0400 Received: from 156.154.4.153 ([156.154.4.153]) by stntexch01.cis.neustar.com ([10.31.13.43]) with Microsoft Exchange Server HTTP-DAV ; Tue, 2 May 2006 14:23:41 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 02 May 2006 10:23:59 -0400 Subject: Re: [dix] Permanent IDs and how to obsolete an identity From: Peter Davis To: "Digital Identity Exchange " , Charles Carrington Message-ID: Thread-Topic: [dix] Permanent IDs and how to obsolete an identity Thread-Index: AcZt9A1YS+KOHdnnEdqvFAANk3jHKA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 May 2006 14:23:46.0776 (UTC) FILETIME=[060F6D80:01C66DF4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 On 5/1/2006 5:52 PM, "Charles Carrington" wrote: > > I think its virtually impossible to remove anything completely from the Web. > > I think we should concentrate on expiring the credentials associated with IDs. > Driver's licenses and passports > have expiration dates. PKI certs have expiration dates and revocation lists. > Most ID's do not, and I think this is > a feature that is sorely needed. > > Thus "permanent IDs are not allowable" might be a better approach. Security tokens expire, true, and they should. Identifiers for such tokens should not be required to do so. DNS-based identifiers have an implicit expiration which is renewable. The challenge for many users, is that they do not control the DNS portion of their identifier today... So when their IDP changes (for example), generally, that requires a change of address. _THAT_, I think, is a true problem. =peterd (http://xri.net/=peterd) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 04 22:53:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbqRg-0004y8-1X; Thu, 04 May 2006 22:53:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbqRf-0004y0-7b for dix@ietf.org; Thu, 04 May 2006 22:53:31 -0400 Received: from smtpout10-04.prod.mesa1.secureserver.net ([64.202.165.238]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbqRe-0003VD-R5 for dix@ietf.org; Thu, 04 May 2006 22:53:31 -0400 Received: (qmail 23713 invoked from network); 5 May 2006 02:53:29 -0000 Received: from unknown (69.142.160.236) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 05 May 2006 02:53:29 -0000 Message-ID: <445ABE27.2090906@cequs.com> Date: Thu, 04 May 2006 22:53:27 -0400 From: Peter Bachman User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: dix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [dix] Re: Lightness 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 > > Perhaps another way of looking at this is to ask the following > questions: > > Why is SAML not widely adopted? Why is it not being used at Amazon, > Yahoo!, Google or MSN? It has been around long enough. > Why was SMTP standardized when X.400 was being worked on? > Why was LDAP created when X.500 was looming? > > My opinion is because X.400 and X.500 were too heavy and did not > easily solve the problems people wanted to solve. > > SAML solves some people's problems, but clearly is not solving a > bunch of other people's problems, or it would have been adopted by now. > > -- Dick > Dick, I think that depends on which community you are referring to. LDAP was not originally a standalone protocol and in the early 1990's people needed to run clients connected to larger and more capable servers that were directly connected to the Internet. Then there needed to be support for standalone LDAP servers that did not require connection to the X.500 infrastructure. That didn't stop major corporations from building large X.500/LDAP infrastructures, at the enterprise level. People did not ordinarily have their own domain names. Given the option of having better authenticated messages for the military, or easily spoofed SMTP, I would have chosen SMTP for myself, and left the military to deal with the intricate nature of X.400, which is also at the core of enterprise programs like Microsoft Exchange. Rapid growth and security are not always two dogs that you can keep on leash at the same pace. I think the stronger argument for X.500/LDAP is that it provides a fairly well known method of policy enforcement within a defined administrative domain. Whether one requires specific administrative domains that are at the Internet level is probably a dog that won't hunt, but when one drops down to an enterprise level, then it probably goes without saying. I think it depends on the services that people want to offer and what they require and the laws of identity. Current computers are so much more powerful and networks so much faster that the rules that governed adoption in the early 90's are not as relevant today. Even the idea of keeping a three headed dog on one's personal leash seems like an interesting idea, where a KDC is normally buried way back in the inner sanctum of a data center. People are adapting rapidly to a fairly brutal Internet with phishing websites, spam, and hostile code. In some instances they may want a company to proxy their identity information, because it works well, in other instances they may be at risk since they have no control over that company's back end operations, except in a general legal sense. The difference between an X.500 administrative domain is that one can insert legal requirements that are going to be out of scope in an IETF document. The beauty of that is "If you live here, and are a citizen of country, state, county, city, X, then these specific rights are embedded in the IT infrastructure, if you live within X." The beauty of the Internet is that it largely ignores what happens in X from a policy standpoint and thats not a bad thing. -pb peterb@cequs.com > > > ------------------------------ > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > > End of dix Digest, Vol 5, Issue 10 > ********************************** > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri May 05 20:26:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcAcn-0004Gv-6H; Fri, 05 May 2006 20:26:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcAcl-0004FM-O3 for dix@ietf.org; Fri, 05 May 2006 20:26:20 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcAcj-0000jk-Fr for dix@ietf.org; Fri, 05 May 2006 20:26:19 -0400 Received: from [192.168.1.106] (adsl-69-106-231-231.dsl.pltn13.pacbell.net [69.106.231.231]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k460Q2gb073228 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 5 May 2006 17:26:05 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v749.3) To: Digital Identity Exchange Message-Id: <0CB64389-7F9E-4768-AED3-5DB76826C868@sxip.com> Content-Type: multipart/mixed; boundary=Apple-Mail-3-1064228535 From: John Merrells Date: Fri, 5 May 2006 17:25:52 -0700 X-Mailer: Apple Mail (2.749.3) X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, URIBL_OB_SURBL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 15eb5e9da99dad697f5917aad29b5ea6 Subject: [dix] draft-merrells-use-cases-03 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 --Apple-Mail-3-1064228535 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, IIW in Mountain View proved to be very productive, with lots of positive feedback on the DIX work. I will be reflecting those comments into the drafts over the next few days. First up is the use cases. Changes: Split out the claims use cases from the browser use cases. Added C14 which motivates the separation between the issuer and the signer of a claim. ID at this URL... http://dixs.org/index.php/DIX_Protocol_Internet_Drafts ... and attached. John --Apple-Mail-3-1064228535 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; x-unix-mode=0644; name="draft-merrells-use-cases-03.txt" Content-Disposition: attachment; filename=draft-merrells-use-cases-03.txt Network Working Group J. Merrells Internet-Draft Sxip Identity Expires: November 6, 2006 May 5, 2006 Digital Identity Exchange - Use Cases draft-merrells-use-cases-03.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 November 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the motivating use cases for DIX, the Digital Identity Exchange protocol. Merrells Expires November 6, 2006 [Page 1] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Browser Based Use Cases . . . . . . . . . . . . . . . . . . . 8 5.1. B1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. B2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. B3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. B4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. B5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.6. B6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.7. B7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. B8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.9. B9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.10. B10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.11. B11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.12. B12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.13. B13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.14. B14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.15. B15 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.16. B16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.17. B17 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.18. B18 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.19. B19 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.20. B20 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.21. B21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Claims Use Cases . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. C1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. C2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. C3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. C5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.6. C6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.7. C7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.8. C8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.9. C9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.10. C10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.11. C11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.12. C12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.13. C13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.14. C14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Non Browser Based Use Cases . . . . . . . . . . . . . . . . . 16 7.1. NB1 - REST . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. NB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. NB3 - WebDAV . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. NB4 - AtomPub . . . . . . . . . . . . . . . . . . . . . . 16 Merrells Expires November 6, 2006 [Page 2] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 7.5. NB5 - XCAP and SIMPLE . . . . . . . . . . . . . . . . . . 16 7.6. NB6 - CalDAV . . . . . . . . . . . . . . . . . . . . . . . 17 7.7. NB7 - IMAP/POP3 and CalDAV . . . . . . . . . . . . . . . . 17 7.8. NB8 - RSS, Web, and CalDAV . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Merrells Expires November 6, 2006 [Page 3] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 1. 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]. Merrells Expires November 6, 2006 [Page 4] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 2. Introduction The use cases below describe various scenarios for the Digital Identity Exchnage (DIX) protocol [dmd1]. Merrells Expires November 6, 2006 [Page 5] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 3. Goals The goals of the protocol are: Identity Information Exchange: The primary goal of any DIX protocol is to automate the exchange of Identity Information over the Internet. Ease of Adoption: Any DIX protocol must provide the lowest possible barriers to adoption to ensure wide-spread usage of the protocol. Internet Scale: Any DIX protocol must provide an Internet scale solution to identity information exchange. Privacy: Any DIX protocol must ensure that all aspects of user privacy can be maintained. Merrells Expires November 6, 2006 [Page 6] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 4. Definitions The following terms and their definitions are drawn from the lexicon of 'The Identity gang', a community of thought leaders in the user- centric digital identity space. [identitygang]. Digital Identity - The transmission of digital representation of a set of Claims made by one Party about itself or another Digital Subject, to one or more other Parties. Identity Agent - An agent acting on behalf of the user. Identifier - An identifying attribute for a set of attributes. Identity Data / Identity Information - A set of attributes. Claim - An assertion made by a Claimant of the value or values of one or more attributes of a Digital Subject, typically an assertion which is disputed or in doubt. Merrells Expires November 6, 2006 [Page 7] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 5. Browser Based Use Cases Some use cases are dependent upon others, so should be perused in order. Beth is our protagonist throughout; a typical Internet user, but she's a bit of a geek. These use cases motivate a HTTP binding for a DIX protocol. 5.1. B1 Beth receives an email from a friend introducing her to a new website, geeknews.com, a techie news site. She wishes to sign up so that she can read some articles. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geeknews.com is requesting some data, her first name. She enters 'Beth' at the prompt, provides consent and the data is sent to the site. 5.2. B2 Beth browses to geekdate.com, she clicks an IN button. Her identity agent informs her that geekdate.com is requesting some data, her first name. Her agent already has this data. She provides consent and the data is sent to the site. 5.3. B3 Beth decides to create a profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an identifier. She provides consent and the identifier and identifier verification data is sent to the site. Geekdate.com uses the verification data to verify that Beth owns the identifier her agent provided. 5.4. B4 Beth decides to create a new profile at geekdate.com. She sees an IN button, which she clicks. Her identity agent displays a screen informing her that geekdate.com is requesting some data, an Identifier. She instructs her identity agent to create an identifier specific to her relationship with geekdate.com. She provides consent and the data is sent to the site. 5.5. B5 Beth decides to flesh out her profile at geekdate.com. Geekdate.com displays a registration form. One field requests a URL of a photo of her. Beside it is a SAVE button. She enters the URL and clicks the Merrells Expires November 6, 2006 [Page 8] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 button. Her identity agent displays a screen informing her that this data item can be stored. She decides that she wants to be able to provide that data to other sites. She provides consent and the data is stored by her agent. 5.6. B6 Geeknews.com offers Beth the option to build up a readership preferences profile over time, the benefit being that the site will tailor its content to her interests. She decides to take up the offer, she sees an IN button, which she clicks. Her identity agent informs her that geeknews.com is requesting some data, an Identifier. She selects an existing identifier that represents a subset of her identity, which is used for a subset of the sites she has a relationship with. She provides consent and the data is sent to the site. 5.7. B7 Beth wants to have multiple identifiers, for different aspects of herself, her personas. She wants to have a 'home' persona for identity data that she releases to her personal sites, such as geeknews.com. She wants to have a separate 'work' persona for identity data that she releases to work-related sites, such as helpdesk.com. She wants some of her identity data to be the same for her different personas, and other data to be different. 5.8. B8 [Assumptions: Beth has visited geeknews and geekdate before and has informed her identity agent that she consents to a relationship with them.] Beth starts her day with a strong coffee and a perusal of geeknews.com. She starts her computer and authenticates herself to the operating system. By that authentication mechanism she has also authenticated herself to her identity agent, as her vendor of that system has hooked it into the operating system's authentication system. She browses to geeknews.com and clicks the IN button and is directly shown the content, no further clicks. She then browses to geekdate.com, she clicks the IN button and is directly presented with her profile no further clicks. 5.9. B9 Beth's identity agent prompts her to provide a 'spoken name'. Using the multimedia capabilities of her computer she records her spoken name; an mp3 of her saying 'Beth'. She later browses to voicebox.com, which runs a voicemail service, she opts to create an account and the site requests some properties, amongst which is a Merrells Expires November 6, 2006 [Page 9] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 request for her spoken name. She provides consent and the data is sent to the site. 5.10. B10 Beth purchases a book from an online store, as she's checking out the store makes her an offer: 10% off for completion of a demographic survey. She's tempted, but how many data fields are there? One hundred! Too many to be worth the effort. But it happens to be commonly requested data, which she has already entered during previous exchanges with other sites. So, she completes the remaining fields, saving them to her identity agent for future reuse. She provides consent and the data is sent to the site. 5.11. B11 Beth has invested significant effort in building up a persona and reputation around a specific identifier, her 'home' identifier. But, she has become dissatisfied with her identity agent and so decides to switch vendors. She establishes a new agent and migrates her identity data from the old one to the new one. She then delegates authority for her identifier to her new identity agent for authentication and provision of identity data. 5.12. B12 Whilst in town Beth stops off at an Internet Cafe to check her email. She goes to her webmail account, which requires that she identity herself. Her Identity Agent prompts her for consent and provides her identifier so that she can gain access to her email. 5.13. B13 Beth visits a website to purchase some books. The site requests some identity information, her shipping address. Her Identity Agent warns her that satisfying the request would contravene her established privacy policy. The website wishes to pass her address to affiliated companies so that they may send her valuable promotional offers, but Beth has a privacy policy that not allow unsolicited mail to be sent to her shipping address. 5.14. B14 Beth moves house, so she changes the home address information stored by her Identity Agent. Her Identity Agent offers to notify all relying parties to whom she has previously provided her home address. Merrells Expires November 6, 2006 [Page 10] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 5.15. B15 Beth leaves work and goes to the bus stop. Whilst waiting for the next bus home she uses her smart phone to browse geeknews.com. Her Identity Agent provides her with the same ease of browsing that she experiences on her work and home computers. 5.16. B16 Beth is ending her day at work. She leaves work and waits for the next bus home. Her friend calls and invites her to the movies. She uses her phone to browse to the movies.com to find out what's playing. The site requests her current location, which she consents to release via her Identity Agent. 5.17. B17 Beth signs up with a financial services site, BigPicture.com, which provides an aggregate view of her finances. To provide its service BigPicture.com requires access to her existing bank accounts. Beth wishes to securely provide agency rights to BigPicture.com, so she acquires the appropriate access tokens from her existing bank account providers and stores them with her Identity Agent. She then presents the access tokens to BigPicture.com so that it can access her account data. 5.18. B18 Beth goes to an auction side, ibay.com. Her Identity Agent shows a signed graphic of ibay.com for releasing data. Beth knows that she's dealing with ibay.com, and not an impostor. 5.19. B19 Adam decides to create a profile at geekdate.com. geekdate.com requests an Identifier. He instructs his identity agent to create an identifier specific to his relationship with geekdate.com. 5.20. B20 Adam heavily frequents two gambling sites, goldenslots.com and luckydice.com. He uses the same identifier across both sites as he wants them to know he is the same person. 5.21. B21 Beth has many computing devices in her life, running different operating systems and different application software. She makes her Merrells Expires November 6, 2006 [Page 11] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 own choices about her own computing environment, but she has little choice when the software is bundled by the device manufacturer or at work where she is subject to her employer's policies. A consequence is that she has multiple Identity Agents, which she uses for managing different personas. Merrells Expires November 6, 2006 [Page 12] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 6. Claims Use Cases These use cases motivate the need for third-party attribute assertions, commonly known as claims. 6.1. C1 Beth is a frequent traveler on Galactic Air, whose site offers a claim of membership for use at affiliate sites. She acquires a membership claim, which her Identity Agent stores for her. 6.2. C2 Beth visits a Galactic Air affiliate site that provides discounted travel insurance for frequent travelers. She presents her Galactic Air membership claim from her Identity Agent and receives a discount. 6.3. C3 Beth visits a rental cars site. She opts out of the offered drivers insurance as she is covered by her travel insurance. To complete the booking the site requests a claim that she has valid insurance. Her identity agent is unable to satisfy the request so provides a list of suggested sources. Beth picks her insurance provider and her identity agent acquires the required claim and with her consent presents it to the rental car site. 6.4. C4 A couple of months later Beth books another trip. The travel site requests her claim of Galactic Air membership. Her identity agent finds that the claim has expired, so refreshes it by requesting an updated claim from galacticair.com. 6.5. C5 Beth visits her online bank, which requires the use of a strong authentication mechanism. She authenticates to her Identity Agent using a two-factor device indicated by the bank to be an acceptable mechanism. 6.6. C6 Adam uses a service to acquire a verified email claim. With it he can prove that he owns his email address, Adam@example.com, without having to go through a verification process. Merrells Expires November 6, 2006 [Page 13] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 6.7. C7 Beth gives her friend, Adam@example.com, access to her photos. Adam receives an email from Beth inviting him to view her photos. He goes to the site, which requests a verified email claim. He presents his claim and gains access to the photos Beth has published for him. 6.8. C8 Adam visits a site that requires that he prove he is over 21. He provides the site with a claim that he is over 21, issues by the government of his country of residence, gov.ca. The claim contains no other information about Adam and the site is unable to use the claim to discover more information about Adam. 6.9. C9 Adam returns to the same site. He must again prove that he is over 21. He provides a claim, but the site cannot tell that it is Adam that has returned again to the site. 6.10. C10 Beth provides a claim from galacticair.com to many different websites. She wants all of the sites to know that she is the same person providing the claim, so she can receive a free flight at the end of the year. 6.11. C11 Beth's employer has partnered with a local university to provide it's staff with access to online courses. She signs up for some modules at the university admissions website acquiring an enrollment claim. She then browses to the computer science school website to sign up for an advanced programming course. The site requests claims that she is an employee, that she has previously completed some basic introductory modules, and that she has been enrolled. 6.12. C12 Beth is shopping online for a new laptop computer. She visits an online site that caters to recently graduated professionals. She selects a machine and investigates the lease options available. To work out the monthly payment the site requests some claims: A claim that she's an alumni of a university, so that the site can include an appropriately branded tote bag. A claim that she's a member of Galactic Air, so that she can be credited with airmiles for her purchase. And, a claim from a credit scoring agency that she has a Merrells Expires November 6, 2006 [Page 14] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 'good' credit rating. 6.13. C13 Beth is at home checking her work email, she has an email from a colleague assigning a customer support issue to her. The company help desk system is provided by helpdesk.com, an on-demand application provider. She clicks through a link in the email to the page that describes the issue. Helpdesk.com requests a claim that Beth is an employee of 'Nano Software Inc', which she provides from her Identity Agent, and she gains access to the page. 6.14. C14 Beth is shopping online at a site for a college text book. The site offers a discount to students, so requests an appropriate claim. With Beth's consent her Identity Agent acquires an enrollment claim from her university. The university issues the claim, but signs it as a parent authority, which represents all universities in the region. The Identity Agent, with Beth's consent, presents the claim to the site, which can now verify that Beth is a student, but can not determine which university she is a student of. Merrells Expires November 6, 2006 [Page 15] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 7. Non Browser Based Use Cases These use cases motivate alternative protocol bindings for a DIX protocol. 7.1. NB1 - REST Beth wants to use QOPO.com for printing her pictures that are stored in flackr. She visits QOPO.com and her identity agent is instructed to acquire a token from flackr. Her Identity Agent retrieves the token from flackr and presents it to QOPO.com. QOPO.com passes the token over the REST based web service that flackr provides to retrieve her photos for printing. 7.2. NB2 Beth is a big fan of Rocky Gervas and listens to his podcast fanatically. The Rocky Gervas show recently started charging a small fee for the podcast. Her media player polls the podcast periodically. When polled the site requests a claim from Beth's Identity Agent asserting that Beth has paid for the podcast. Beth's Identity Agent retrieves the claim presents it to the site and the latest episode of The Rocky Gervas show is downloaded. 7.3. NB3 - WebDAV At work Beth uses her website editing software (a WebDAV client) to publish some company confidential content to their extranet. Beth is collaborating with Charles at another company, who requires access to the content. Beth configures the extranet to allow Charles access. Charles uses his website editing software (also a WebDAV client) to fetch the content. The extranet site requests identity information, which his client presents from his Identity agent, and he is able to edit the content. 7.4. NB4 - AtomPub Beth uses a blogging client (AtomPub) to both post content to her blog and to add comments on other people's blog postings. Her client uses her identity agent to associate identifying information (her blog url and favicon) with her comments. 7.5. NB5 - XCAP and SIMPLE Beth uses her instant messaging client (a SIMPLE client) to communicate with her friends. She uses her client to update her profile information (via XCAP), adding a new friend. Her client didn't need to authenticate to her XCAP server, as she had already Merrells Expires November 6, 2006 [Page 16] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 authenticated herself to her identity agent. 7.6. NB6 - CalDAV Beth needs to arrange a conference call with Charles. She uses her calendaring software (a CalDAV client) to publish her free-busy time to Charles. Charles uses his calendaring software (also a CalDAV client) to fetch Beth's free-busy time. Beth's calendar publisher requests some identity information of Charle's client. It's provided from his identity agent and he is able to book a time for the call. 7.7. NB7 - IMAP/POP3 and CalDAV At work Beth uses both calendaring (CalDAV) and email (IMAP,POP3,SMTP) clients to manage her time and messages. Her identity agent authenticates her as owning the identifier that both clients use to identify her. In this way she need only authenticate once to her identity agent instead of twice, once to each client. 7.8. NB8 - RSS, Web, and CalDAV Beth works in a distributed workgroup collaborating with colleagues, individual contractors, and employees of partner companies. The calendaring information she has access to is available via CalDAV, RSS, and HTTP/HTML. Each of her software clients uses her identity agent to ensure she need only authenticate once, instead of once per client. Merrells Expires November 6, 2006 [Page 17] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 8. Acknowledgements The editor acknowledges the use case contributions made by Dick Hardt, Robert Yates, Lisa Dusseault and Laurie Rae. Merrells Expires November 6, 2006 [Page 18] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 9. Security Considerations None. 10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [dmd1] Merrells, J., "draft-merrells-dix-01.txt", March 2006. [identitygang] The Identity Gang, "http://identitygang.org/Lexicon", March 2006. Merrells Expires November 6, 2006 [Page 19] =0C Internet-Draft Digital Identity Exchange - Use Cases May 2006 Author's Address John Merrells Sxip Identity 798 Beatty Street Vancouver, BC V6B 2M1 Canada Email: merrells@sxip.com URI: http://sxip.com/ Merrells Expires November 6, 2006 [Page 20] =0C Internet-Draft Digital Identity Exchange - Use Cases May 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. Merrells Expires November 6, 2006 [Page 21] =0C --Apple-Mail-3-1064228535 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-3-1064228535-- From dix-bounces@ietf.org Wed May 17 20:38:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWWu-0005xn-7L; Wed, 17 May 2006 20:38:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWWs-0005xi-OX for dix@ietf.org; Wed, 17 May 2006 20:38:14 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWWr-0005hx-EV for dix@ietf.org; Wed, 17 May 2006 20:38:14 -0400 Received: from [192.168.1.125] (adsl-69-106-229-235.dsl.pltn13.pacbell.net [69.106.229.235]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k4I0c3D6016814 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 May 2006 17:38:04 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <2C35F67D-832E-48C4-81C0-6B8F54F340B2@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Wed, 17 May 2006 17:38:00 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dix] digital signatures for images 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'm sure there's an RFC on signing an image... but i can't find it. Google is failing me... or probably my ability to some up with variations on 'digitally signed image rfc damnit'. Someone on this list knows where it is... and probably wrote it. URL please :) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 11:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCnq-0005sZ-Mw; Mon, 22 May 2006 11:58:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCnp-0005sU-8P for dix@ietf.org; Mon, 22 May 2006 11:58:41 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCnk-0007ZS-IK for dix@ietf.org; Mon, 22 May 2006 11:58:41 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1D2741E8C1C; Mon, 22 May 2006 08:58:23 -0700 (PDT) To: Sam Hartman References: From: Eric Rescorla Date: Mon, 22 May 2006 08:58:23 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 22 May 2006 10:28:08 -0400") Message-ID: <868xou831c.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: 3a4bc66230659131057bb68ed51598f8 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 1. This is not principally a protocol problem but rather a UI problem. The protocol problems are generally well understood. If the UI problems are solved, nearly any protocol will work. In particular, there have been a number of published designs [1] [2] that have mostly adequate (though not perfect) protocols, though without complete solutions to the UI problem. Indeed, a slightly different design for Digest (in which the absolute URI was hashed) combined with a secure UI would pretty much defeat current phishing attacks. 2. It's really important to distinguish between different levels of attack. Conventional phishing attacks rely on generating a reference which appears to be valid but actually points at the attacker's site. (This is why SSL/TLS doesn't help much). But this is different from attacks in which the attacker actually intercepts the user's communication. In these settings, some sort of cryptographic protection for the channel (a la HTTPS) or the messages (a la S-HTTP) must be provided. On a similar note, in current phishing attacks the attacker attempts to directly extract the user's password. If C-R mechanisms are used, a dictionary attack is natural. I assume that's why you wave in the direction of ZKPPs in S 4.3. However, it's worth asking whether we would be satisified with a system that was only partly strengthened against dictionary attacks (see [2] again). 3. The term "password equivalent" is a bit confusing. See draft-iab-auth-mech for some discussion of strong versus weak password equivalent. 4. I agree that server authentication is a good, but I'm not totally sold that it's a necessity. It's principally important when you're changing credentials, but even then with a properly designed scheme where the server has a weakly password equivalent credential, the exposure is fairly limited. A standard practice is to hash the hostname into the password hash stored on the server. 5. You write: 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 is not strictly true. A ZKPP removes the risk of offline dictionary attack, but not online attack. These attacks do still get mounted [3] 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 and being extra careful to make sure the right server is used when establishing a password can minimize this risk. It's not clear to me that this helps, unless you're assuming a ZKPP. If the attacker can capture a hashed password or C-R handshake (which a phisher can generally force in non-ZKPP cases) then they can mount an offline dictionary attack anyway. Consider a typical design where the user has a master password P and then generates per-site passwords as H(Site-Name || P). In the C-R handshake, the user provides: H(challenge || H(Site-Name || P). Dictionary attacking this isn't significantly harder than dictionary attacking H(Site-Name || P). 6. You write: In situations where there is an identity provider that is separate from the website as a relying party, additional requirements are needed. The identity provider MUST verify that the website is a valid relying party for this identity. 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. The relying party MUST prove its identity is the one expected by the identity provider. I agree that this is is a likely business goal for identity providers, but it's not required for protection against phishing. Really, there are two interests here: 1. To prove to the user (the guy with the browser) that he is doing business with an "authorized" provider. 2. To allow the identity provider to extract rents from the relying parties. Neither strictly requires the relying party authenticating to the identity provider during the transaction. The first can obviously done by issueing the relying party a long-term credential. The second can be done by encrypting the credential under the relying party's key. You don't necessarily need the identity provider to receive a proof that the relying party was able to decrypt it. -Ekr [1] Blake Ross, Collin Jackson, Nicholas Miyake, Dan Boneh and John C. Mitchell Stronger Password Authentication Using Browser Extensions. Proceedings of the 14th Usenix Security Symposium, 2005. [2] Halderman, J. A., Waters, B., and Felten, E. W. 2005. A convenient method for securely managing passwords. In Proceedings of the 14th international Conference on World Wide Web (Chiba, Japan, May 10 - 14, 2005). WWW '05. ACM Press, New York, NY, 471-479. DOI= http://doi.acm.org/10.1145/1060745.1060815 [3] http://www.whitedust.net/article/27/Recent%20SSH%20Brute-Force%20Attacks/ _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 12:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD3k-0004tV-64; Mon, 22 May 2006 12:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD3i-0004tQ-Vd for dix@ietf.org; Mon, 22 May 2006 12:15:06 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD3e-00089A-DK for dix@ietf.org; Mon, 22 May 2006 12:15:06 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4MGExif019381 for ; Mon, 22 May 2006 09:14:59 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4MGExFO008546 for ; Mon, 22 May 2006 10:14:59 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4MGEwSH017703; Mon, 22 May 2006 11:14:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4MGEv6n017702; Mon, 22 May 2006 11:14:57 -0500 (CDT) Date: Mon, 22 May 2006 11:14:57 -0500 From: Nicolas Williams To: EKR , Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements Message-ID: <20060522161457.GK16695@binky.Central.Sun.COM> References: <868xou831c.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868xou831c.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf-http-auth@lists.osafoundation.org, Sam Hartman 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 Mon, May 22, 2006 at 08:58:23AM -0700, Eric Rescorla wrote: > 1. This is not principally a protocol problem but rather a UI problem. I've not read Sam's I-D yet, but he did present to me last week, so perhaps I can comment. This is not just a UI problem, and there are several problems. Sam seems to assume that enrolment is not the problem he should be solving, but that it is already solved (even if it isn't). Given this assumption then the principal problem is about tying the UI and the protocols. And I couldn't agree more. Now, that pesky enrolment problem... Except it's not quite so pesky; it requires that the user not get confused (conned) once [per-site?], at enrolment. Beyond that, users don't want to have to enroll every time, at least not with passwords. But now I must go read Sam's I-D. > The protocol problems are generally well understood. If the UI > problems are solved, nearly any protocol will work. In particular, > there have been a number of published designs [1] [2] that have mostly > adequate (though not perfect) protocols, though without complete > solutions to the UI problem. Indeed, a slightly different design > for Digest (in which the absolute URI was hashed) combined with > a secure UI would pretty much defeat current phishing attacks. So, the protocols and the [secure] UI have to be "combined" -- can you expand on this? How is this not what Sam proposes? Or are you two in violent agreement? :) Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 12:18:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD76-0005X2-Ii; Mon, 22 May 2006 12:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD75-0005U8-EO for dix@ietf.org; Mon, 22 May 2006 12:18:35 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD73-0008Ec-P9 for dix@ietf.org; Mon, 22 May 2006 12:18:35 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k4MGIWaN013312 for ; Mon, 22 May 2006 09:18:32 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4MGIWOm010734 for ; Mon, 22 May 2006 10:18:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4MGIWdb017714; Mon, 22 May 2006 11:18:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4MGIVw2017713; Mon, 22 May 2006 11:18:31 -0500 (CDT) Date: Mon, 22 May 2006 11:18:31 -0500 From: Nicolas Williams To: Robert Sayre Message-ID: <20060522161831.GL16695@binky.Central.Sun.COM> References: <868xou831c.fsf@raman.networkresonance.com> <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre wrote: > On 5/22/06, Eric Rescorla wrote: > >1. This is not principally a protocol problem but rather a UI problem. > > The protocol problems are generally well understood. If the UI > > problems are solved, nearly any protocol will work. In particular, > > there have been a number of published designs [1] [2] that have mostly > > adequate (though not perfect) protocols, though without complete > > solutions to the UI problem. > > One aspect of Sam's document that concerned me was the section on > possible UI solutions. The requirements around spoofing seem directly > opposed to the branding and usage patterns that web authors require. > HTTP authentication currently presents a modal dialog with no design > control, and this is a significant reason most sites opt for form > controls. Sam wants to put control over the UI in the web site's authors' hands. But he wants this UI tied intimately to a new browser function that is tied intimately to authentication protocols. > Roy has previously mentioned that 401 Unauthorized responses should be > displayed to the user. This would allow a site to embed a new type of > form control for authentication purposes... but as I mentioned above, > this intermingling could increase the risk of spoofing. As Sam says: the browser must change. There are problems we cannot solve using nothing more than HTML, HTTP/HTTPS and existing browser functionality. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 12:24:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDCq-0000QI-Ij; Mon, 22 May 2006 12:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDCp-0000Oj-JQ for dix@ietf.org; Mon, 22 May 2006 12:24:31 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDCo-0008Rf-9W for dix@ietf.org; Mon, 22 May 2006 12:24:31 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D97041E8C1C; Mon, 22 May 2006 09:24:29 -0700 (PDT) To: Nicolas Williams Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> From: Eric Rescorla Date: Mon, 22 May 2006 09:24:29 -0700 In-Reply-To: <20060522161457.GK16695@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 22 May 2006 11:14:57 -0500") Message-ID: <86wtce6n9e.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 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Sam Hartman 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 Nicolas Williams writes: > On Mon, May 22, 2006 at 08:58:23AM -0700, Eric Rescorla wrote: >> 1. This is not principally a protocol problem but rather a UI problem. > > I've not read Sam's I-D yet, but he did present to me last week, so > perhaps I can comment. > > This is not just a UI problem, and there are several problems. I agree that there are several problems, but only some subset of those problems are the "phishing" problem. >> The protocol problems are generally well understood. If the UI >> problems are solved, nearly any protocol will work. In particular, >> there have been a number of published designs [1] [2] that have mostly >> adequate (though not perfect) protocols, though without complete >> solutions to the UI problem. Indeed, a slightly different design >> for Digest (in which the absolute URI was hashed) combined with >> a secure UI would pretty much defeat current phishing attacks. > > So, the protocols and the [secure] UI have to be "combined" -- can you > expand on this? This is all pretty much laid out in the PwdHash and Felten papers. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 13:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDxd-0008TF-JQ; Mon, 22 May 2006 13:12:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDxc-0008TA-ET for dix@ietf.org; Mon, 22 May 2006 13:12:52 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDxb-00020q-2D for dix@ietf.org; Mon, 22 May 2006 13:12:52 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id AEB921E8C4C; Mon, 22 May 2006 10:12:49 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 22 May 2006 10:12:49 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 22 May 2006 13:10:56 -0400") Message-ID: <86r72m6l0u.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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Nicolas Williams 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: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> This is all pretty much laid out in the PwdHash and Felten > Eric> papers. > > Sure. My goal here is to describe a series of reasonably obvious > requirements so that we can evaluate solutions because we'e seen some > solutions like the ones you cite that meet a large number of these > conditions and we've seen other solutions that do not. This was in response to Nico asking: "So, the protocols and the [secure] UI have to be "combined" -- can you expand on this? " > I find specific requirements useful in such situations. Right. I indicated in my message, I'm not sure this draft dissects the reqts correctly. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 13:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiE5k-0002Fq-FK; Mon, 22 May 2006 13:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiE5i-0002FM-Pl for dix@ietf.org; Mon, 22 May 2006 13:21:14 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiE5f-0002Fn-8L for dix@ietf.org; Mon, 22 May 2006 13:21:14 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4MHLArM012796 for ; Mon, 22 May 2006 10:21:10 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4MHKJR1020283 for ; Mon, 22 May 2006 11:20:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4MHL95I018099; Mon, 22 May 2006 12:21:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4MHL9Pn018098; Mon, 22 May 2006 12:21:09 -0500 (CDT) Date: Mon, 22 May 2006 12:21:09 -0500 From: Nicolas Williams To: Eric Rescorla Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements Message-ID: <20060522172109.GR16695@binky.Central.Sun.COM> References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86r72m6l0u.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Sam Hartman 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 Mon, May 22, 2006 at 10:12:49AM -0700, Eric Rescorla wrote: > Sam Hartman writes: > > >>>>>> "Eric" == Eric Rescorla writes: > > > > Eric> This is all pretty much laid out in the PwdHash and Felten > > Eric> papers. > > > > Sure. My goal here is to describe a series of reasonably obvious > > requirements so that we can evaluate solutions because we'e seen some > > solutions like the ones you cite that meet a large number of these > > conditions and we've seen other solutions that do not. > > This was in response to Nico asking: > > "So, the protocols and the [secure] UI have to be "combined" -- can you > expand on this? " I asked two other questions in the same paragraph. All three were aimed at rooting out whether you happen to be in broad agreement with Sam's position. This particular question was aimed at understanding in what respects your view differs from Sam's. Pointing me at these papers doesn't answer my question :) But I'll score you two as being in broad agreement anyways (if nothing else it's a safe bet). Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 13:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEA5-0005Cl-70; Mon, 22 May 2006 13:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEA4-0005Cg-5f for dix@ietf.org; Mon, 22 May 2006 13:25:44 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEA2-0002Mi-Ss for dix@ietf.org; Mon, 22 May 2006 13:25:44 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7D7791E8C1C; Mon, 22 May 2006 10:25:42 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 22 May 2006 10:25:42 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 22 May 2006 13:22:37 -0400") Message-ID: <86bqtq6kfd.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: 79899194edc4f33a41f49410777972f8 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: >>>>>> "Eric" == Eric Rescorla writes: > Eric> Right. I indicated in my message, I'm not sure this draft > Eric> dissects the reqts correctly. > > Understood. However all your criticisms to date have been rather > minor. Hmm... I didn't mean to give that impression. I certainly don't think the "it's all about UI" point is minor. In any case, I'll try to write up a more substantial review when I have some more time, probably in the next week or so. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjP-0002pI-Sf; Mon, 22 May 2006 14:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBOK-0005Av-3W for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBOJ-00034H-44 for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C58AE000E; Mon, 22 May 2006 10:28:08 -0400 (EDT) To: ietf-http-auth@lists.osafoundation.org, dix@ietf.org From: Sam Hartman Date: Mon, 22 May 2006 10:28:08 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d9377227c64d8007f9382a92e11ad5d X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Subject: [dix] New draft on anti-phishing requirements 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 --=-=-= Hi folks. One thing that concerns me thinking about authentication and identity on the web is how to make sure that we don't make phishing worse and in fact to make sure that we significantly improve it. I've written a draft on requirements for web authentication solutions to minimize phishing risk. That draft has been submitted but is not yet in the ID repository so I'm attaching a copy. I believe that DIX, my proposal or anything else in this space needs to meet these requirements or requirements that are very similar. Some of these requirements apply to the protocol used between an identity provider and a subject to authenticate to the identity provider. Other requirements apply to protocols used to carry authentication or identity information between identity providers and relying parties. Some requirements apply to both. The line is a bit blurry in some solutions. Comments are welcome. --=-=-= Content-Disposition: attachment; filename=draft-hartman-webauth-phishing-00.txt Content-Description: Requirements for web authentication solutions to minimize phishing risk Network Working Group S. Hartman Internet-Draft MIT Expires: November 21, 2006 May 20, 2006 Requirements for Web Authentication Resistant to Phishing draft-hartman-webauth-phishing-00.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 November 21, 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 November 21, 2006 [Page 1] Internet-Draft Web Phishing Requirements May 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 Authenticating the Server . . . . . . . . . . . . . . . . 9 4.5 Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Hartman Expires November 21, 2006 [Page 2] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 3] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 4] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 5] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 6] Internet-Draft Web Phishing Requirements May 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. 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 November 21, 2006 [Page 7] Internet-Draft Web Phishing Requirements May 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. 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. 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 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. Hartman Expires November 21, 2006 [Page 8] Internet-Draft Web Phishing Requirements May 2006 In addition to making sure that passwords are only given to trusted components, trusted UI will play another important role in the overall solution to phishing. Once the user is authenticated to the website then the website can use trusted UI based on a secret shared between the user and website to convince the user that they have authenticated to the correct site. This use of trusted UI dependes critically on the requirements of Section 4.4 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 trusted UI is displayed after authentication then phishers could not obtain the trusted UI. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials. 4.3 No Password Equivelents A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a password equivalent. A password equivalent is anything that would allow a phisher to authenticate to a third party as the user. 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. 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 Authenticating the Server The Google paper [ANTIPHISHING] describes a requirement for mutual authentication. A common phishing practice is to accept a user name and password as part of an attempt to make the phishing site Hartman Expires November 21, 2006 [Page 9] Internet-Draft Web Phishing Requirements May 2006 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. Then the attacker can either ignore the authentication or attempt to tunnel the authentication exchange back to the real site. If successful such tunneling could allow the attacker to access the real site as the user. 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. 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. In situations where there is an identity provider that is separate from the website as a relying party, additional requirements are needed. The identity provider MUST verify that the website is a valid relying party for this identity. 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. The relying party MUST prove its identity is the one expected by the identity provider. This set of requirements is incompatible with a model where the identity of the relying party is hidden from the identity provider. Sites that need this level of privacy may wish to provide their own identities or to provide aggregation points that can separate the identity provider from the site. The aggregation point needs to know the relying party, but the identity provider only needs to know the Hartman Expires November 21, 2006 [Page 10] Internet-Draft Web Phishing Requirements May 2006 aggregation point. To prevent attacks where the authentication is tunneled, the protocol between the web browser and website MUST 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 4.5 Protecting Enrollment One area of particular vulnerability to phishing is enrollment. 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 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 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 November 21, 2006 [Page 11] Internet-Draft Web Phishing Requirements May 2006 5. 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 November 21, 2006 [Page 12] Internet-Draft Web Phishing Requirements May 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. 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 and being extra careful to make sure the right server is used when establishing a password can minimize this risk. Hartman Expires November 21, 2006 [Page 13] Internet-Draft Web Phishing Requirements May 2006 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.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. Author's Address Sam Hartman Massachusetts Institute of Technology Email: hartmans-ietf@mit.edu Hartman Expires November 21, 2006 [Page 14] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 15] --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002pN-0o; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD3V-0004qo-L6 for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD3U-00088t-Eg for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: by py-out-1112.google.com with SMTP id f28so1510001pyf for ; Mon, 22 May 2006 09:14:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e0O0/3Ep7xnHsKlQ8l6feioj6ef3T5MPMwA/v5iO1DavRNECUBCN6C9ScEsszB29Sz62q1kjMRtBjKEnlfxzKGST9X4nQMQMf2ZpmBCGYb+zEWYNb2WlRreiBRQXmnZW936mekzheOXzGrin7HoGu8IChkIf/CijbV20CedsPLA= Received: by 10.35.112.3 with SMTP id p3mr3365104pym; Mon, 22 May 2006 09:14:52 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Mon, 22 May 2006 09:14:51 -0700 (PDT) Message-ID: <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> Date: Mon, 22 May 2006 12:14:51 -0400 From: "Robert Sayre" To: EKR In-Reply-To: <868xou831c.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xou831c.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 5/22/06, Eric Rescorla wrote: > 1. This is not principally a protocol problem but rather a UI problem. > The protocol problems are generally well understood. If the UI > problems are solved, nearly any protocol will work. In particular, > there have been a number of published designs [1] [2] that have mostly > adequate (though not perfect) protocols, though without complete > solutions to the UI problem. One aspect of Sam's document that concerned me was the section on possible UI solutions. The requirements around spoofing seem directly opposed to the branding and usage patterns that web authors require. HTTP authentication currently presents a modal dialog with no design control, and this is a significant reason most sites opt for form controls. Roy has previously mentioned that 401 Unauthorized responses should be displayed to the user. This would allow a site to embed a new type of form control for authentication purposes... but as I mentioned above, this intermingling could increase the risk of spoofing. --=20 Robert Sayre _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002qk-QY; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEaZ-0007jK-Vu for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEaY-00040b-QI for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5EAA3E000E; Mon, 22 May 2006 13:53:00 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> <86bqtq6kfd.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:53:00 -0400 In-Reply-To: <86bqtq6kfd.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 10:25:42 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 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: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla writes: Eric> Right. I indicated in my message, I'm not sure this draft Eric> dissects the reqts correctly. >> Understood. However all your criticisms to date have been >> rather minor. Eric> Hmm... I didn't mean to give that impression. I certainly Eric> don't think the "it's all about UI" point is minor. I am not sure whether it is minor. I think we are in broad agreement that the interesting work in this space must involve the UI and is not principally a protocol problem. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002q1-9n; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDvs-0008Dm-P6 for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDvr-0001wI-JH for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15D33E000E; Mon, 22 May 2006 13:10:56 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:10:56 -0400 In-Reply-To: <86wtce6n9e.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 09:24:29 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Nicolas Williams 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: Eric> This is all pretty much laid out in the PwdHash and Felten Eric> papers. Sure. My goal here is to describe a series of reasonably obvious requirements so that we can evaluate solutions because we'e seen some solutions like the ones you cite that meet a large number of these conditions and we've seen other solutions that do not. I find specific requirements useful in such situations. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjP-0002pI-Sf; Mon, 22 May 2006 14:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBOK-0005Av-3W for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBOJ-00034H-44 for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C58AE000E; Mon, 22 May 2006 10:28:08 -0400 (EDT) To: ietf-http-auth@lists.osafoundation.org, dix@ietf.org From: Sam Hartman Date: Mon, 22 May 2006 10:28:08 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d9377227c64d8007f9382a92e11ad5d X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Subject: [dix] New draft on anti-phishing requirements 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 --=-=-= Hi folks. One thing that concerns me thinking about authentication and identity on the web is how to make sure that we don't make phishing worse and in fact to make sure that we significantly improve it. I've written a draft on requirements for web authentication solutions to minimize phishing risk. That draft has been submitted but is not yet in the ID repository so I'm attaching a copy. I believe that DIX, my proposal or anything else in this space needs to meet these requirements or requirements that are very similar. Some of these requirements apply to the protocol used between an identity provider and a subject to authenticate to the identity provider. Other requirements apply to protocols used to carry authentication or identity information between identity providers and relying parties. Some requirements apply to both. The line is a bit blurry in some solutions. Comments are welcome. --=-=-= Content-Disposition: attachment; filename=draft-hartman-webauth-phishing-00.txt Content-Description: Requirements for web authentication solutions to minimize phishing risk Network Working Group S. Hartman Internet-Draft MIT Expires: November 21, 2006 May 20, 2006 Requirements for Web Authentication Resistant to Phishing draft-hartman-webauth-phishing-00.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 November 21, 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 November 21, 2006 [Page 1] Internet-Draft Web Phishing Requirements May 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 Authenticating the Server . . . . . . . . . . . . . . . . 9 4.5 Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Hartman Expires November 21, 2006 [Page 2] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 3] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 4] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 5] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 6] Internet-Draft Web Phishing Requirements May 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. 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 November 21, 2006 [Page 7] Internet-Draft Web Phishing Requirements May 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. 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. 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 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. Hartman Expires November 21, 2006 [Page 8] Internet-Draft Web Phishing Requirements May 2006 In addition to making sure that passwords are only given to trusted components, trusted UI will play another important role in the overall solution to phishing. Once the user is authenticated to the website then the website can use trusted UI based on a secret shared between the user and website to convince the user that they have authenticated to the correct site. This use of trusted UI dependes critically on the requirements of Section 4.4 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 trusted UI is displayed after authentication then phishers could not obtain the trusted UI. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials. 4.3 No Password Equivelents A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a password equivalent. A password equivalent is anything that would allow a phisher to authenticate to a third party as the user. 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. 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 Authenticating the Server The Google paper [ANTIPHISHING] describes a requirement for mutual authentication. A common phishing practice is to accept a user name and password as part of an attempt to make the phishing site Hartman Expires November 21, 2006 [Page 9] Internet-Draft Web Phishing Requirements May 2006 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. Then the attacker can either ignore the authentication or attempt to tunnel the authentication exchange back to the real site. If successful such tunneling could allow the attacker to access the real site as the user. 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. 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. In situations where there is an identity provider that is separate from the website as a relying party, additional requirements are needed. The identity provider MUST verify that the website is a valid relying party for this identity. 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. The relying party MUST prove its identity is the one expected by the identity provider. This set of requirements is incompatible with a model where the identity of the relying party is hidden from the identity provider. Sites that need this level of privacy may wish to provide their own identities or to provide aggregation points that can separate the identity provider from the site. The aggregation point needs to know the relying party, but the identity provider only needs to know the Hartman Expires November 21, 2006 [Page 10] Internet-Draft Web Phishing Requirements May 2006 aggregation point. To prevent attacks where the authentication is tunneled, the protocol between the web browser and website MUST 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 4.5 Protecting Enrollment One area of particular vulnerability to phishing is enrollment. 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 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 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 November 21, 2006 [Page 11] Internet-Draft Web Phishing Requirements May 2006 5. 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 November 21, 2006 [Page 12] Internet-Draft Web Phishing Requirements May 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. 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 and being extra careful to make sure the right server is used when establishing a password can minimize this risk. Hartman Expires November 21, 2006 [Page 13] Internet-Draft Web Phishing Requirements May 2006 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.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. Author's Address Sam Hartman Massachusetts Institute of Technology Email: hartmans-ietf@mit.edu Hartman Expires November 21, 2006 [Page 14] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 15] --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002pN-0o; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD3V-0004qo-L6 for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD3U-00088t-Eg for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: by py-out-1112.google.com with SMTP id f28so1510001pyf for ; Mon, 22 May 2006 09:14:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e0O0/3Ep7xnHsKlQ8l6feioj6ef3T5MPMwA/v5iO1DavRNECUBCN6C9ScEsszB29Sz62q1kjMRtBjKEnlfxzKGST9X4nQMQMf2ZpmBCGYb+zEWYNb2WlRreiBRQXmnZW936mekzheOXzGrin7HoGu8IChkIf/CijbV20CedsPLA= Received: by 10.35.112.3 with SMTP id p3mr3365104pym; Mon, 22 May 2006 09:14:52 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Mon, 22 May 2006 09:14:51 -0700 (PDT) Message-ID: <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> Date: Mon, 22 May 2006 12:14:51 -0400 From: "Robert Sayre" To: EKR In-Reply-To: <868xou831c.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xou831c.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 5/22/06, Eric Rescorla wrote: > 1. This is not principally a protocol problem but rather a UI problem. > The protocol problems are generally well understood. If the UI > problems are solved, nearly any protocol will work. In particular, > there have been a number of published designs [1] [2] that have mostly > adequate (though not perfect) protocols, though without complete > solutions to the UI problem. One aspect of Sam's document that concerned me was the section on possible UI solutions. The requirements around spoofing seem directly opposed to the branding and usage patterns that web authors require. HTTP authentication currently presents a modal dialog with no design control, and this is a significant reason most sites opt for form controls. Roy has previously mentioned that 401 Unauthorized responses should be displayed to the user. This would allow a site to embed a new type of form control for authentication purposes... but as I mentioned above, this intermingling could increase the risk of spoofing. --=20 Robert Sayre _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002qk-QY; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEaZ-0007jK-Vu for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEaY-00040b-QI for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5EAA3E000E; Mon, 22 May 2006 13:53:00 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> <86bqtq6kfd.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:53:00 -0400 In-Reply-To: <86bqtq6kfd.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 10:25:42 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 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: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla writes: Eric> Right. I indicated in my message, I'm not sure this draft Eric> dissects the reqts correctly. >> Understood. However all your criticisms to date have been >> rather minor. Eric> Hmm... I didn't mean to give that impression. I certainly Eric> don't think the "it's all about UI" point is minor. I am not sure whether it is minor. I think we are in broad agreement that the interesting work in this space must involve the UI and is not principally a protocol problem. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002q1-9n; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDvs-0008Dm-P6 for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDvr-0001wI-JH for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15D33E000E; Mon, 22 May 2006 13:10:56 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:10:56 -0400 In-Reply-To: <86wtce6n9e.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 09:24:29 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Nicolas Williams 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: Eric> This is all pretty much laid out in the PwdHash and Felten Eric> papers. Sure. My goal here is to describe a series of reasonably obvious requirements so that we can evaluate solutions because we'e seen some solutions like the ones you cite that meet a large number of these conditions and we've seen other solutions that do not. I find specific requirements useful in such situations. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjP-0002pI-Sf; Mon, 22 May 2006 14:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBOK-0005Av-3W for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBOJ-00034H-44 for dix@ietf.org; Mon, 22 May 2006 10:28:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C58AE000E; Mon, 22 May 2006 10:28:08 -0400 (EDT) To: ietf-http-auth@lists.osafoundation.org, dix@ietf.org From: Sam Hartman Date: Mon, 22 May 2006 10:28:08 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d9377227c64d8007f9382a92e11ad5d X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Subject: [dix] New draft on anti-phishing requirements 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 --=-=-= Hi folks. One thing that concerns me thinking about authentication and identity on the web is how to make sure that we don't make phishing worse and in fact to make sure that we significantly improve it. I've written a draft on requirements for web authentication solutions to minimize phishing risk. That draft has been submitted but is not yet in the ID repository so I'm attaching a copy. I believe that DIX, my proposal or anything else in this space needs to meet these requirements or requirements that are very similar. Some of these requirements apply to the protocol used between an identity provider and a subject to authenticate to the identity provider. Other requirements apply to protocols used to carry authentication or identity information between identity providers and relying parties. Some requirements apply to both. The line is a bit blurry in some solutions. Comments are welcome. --=-=-= Content-Disposition: attachment; filename=draft-hartman-webauth-phishing-00.txt Content-Description: Requirements for web authentication solutions to minimize phishing risk Network Working Group S. Hartman Internet-Draft MIT Expires: November 21, 2006 May 20, 2006 Requirements for Web Authentication Resistant to Phishing draft-hartman-webauth-phishing-00.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 November 21, 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 November 21, 2006 [Page 1] Internet-Draft Web Phishing Requirements May 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 Authenticating the Server . . . . . . . . . . . . . . . . 9 4.5 Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Normative References . . . . . . . . . . . . . . . . . . . 14 6.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Hartman Expires November 21, 2006 [Page 2] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 3] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 4] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 5] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 6] Internet-Draft Web Phishing Requirements May 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. 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 November 21, 2006 [Page 7] Internet-Draft Web Phishing Requirements May 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. 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. 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 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. Hartman Expires November 21, 2006 [Page 8] Internet-Draft Web Phishing Requirements May 2006 In addition to making sure that passwords are only given to trusted components, trusted UI will play another important role in the overall solution to phishing. Once the user is authenticated to the website then the website can use trusted UI based on a secret shared between the user and website to convince the user that they have authenticated to the correct site. This use of trusted UI dependes critically on the requirements of Section 4.4 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 trusted UI is displayed after authentication then phishers could not obtain the trusted UI. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials. 4.3 No Password Equivelents A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a password equivalent. A password equivalent is anything that would allow a phisher to authenticate to a third party as the user. 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. 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 Authenticating the Server The Google paper [ANTIPHISHING] describes a requirement for mutual authentication. A common phishing practice is to accept a user name and password as part of an attempt to make the phishing site Hartman Expires November 21, 2006 [Page 9] Internet-Draft Web Phishing Requirements May 2006 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. Then the attacker can either ignore the authentication or attempt to tunnel the authentication exchange back to the real site. If successful such tunneling could allow the attacker to access the real site as the user. 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. 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. In situations where there is an identity provider that is separate from the website as a relying party, additional requirements are needed. The identity provider MUST verify that the website is a valid relying party for this identity. 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. The relying party MUST prove its identity is the one expected by the identity provider. This set of requirements is incompatible with a model where the identity of the relying party is hidden from the identity provider. Sites that need this level of privacy may wish to provide their own identities or to provide aggregation points that can separate the identity provider from the site. The aggregation point needs to know the relying party, but the identity provider only needs to know the Hartman Expires November 21, 2006 [Page 10] Internet-Draft Web Phishing Requirements May 2006 aggregation point. To prevent attacks where the authentication is tunneled, the protocol between the web browser and website MUST 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 4.5 Protecting Enrollment One area of particular vulnerability to phishing is enrollment. 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 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 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 November 21, 2006 [Page 11] Internet-Draft Web Phishing Requirements May 2006 5. 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 November 21, 2006 [Page 12] Internet-Draft Web Phishing Requirements May 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. 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 and being extra careful to make sure the right server is used when establishing a password can minimize this risk. Hartman Expires November 21, 2006 [Page 13] Internet-Draft Web Phishing Requirements May 2006 6. References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.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. Author's Address Sam Hartman Massachusetts Institute of Technology Email: hartmans-ietf@mit.edu Hartman Expires November 21, 2006 [Page 14] Internet-Draft Web Phishing Requirements May 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 November 21, 2006 [Page 15] --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002pN-0o; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiD3V-0004qo-L6 for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiD3U-00088t-Eg for dix@ietf.org; Mon, 22 May 2006 12:14:53 -0400 Received: by py-out-1112.google.com with SMTP id f28so1510001pyf for ; Mon, 22 May 2006 09:14:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e0O0/3Ep7xnHsKlQ8l6feioj6ef3T5MPMwA/v5iO1DavRNECUBCN6C9ScEsszB29Sz62q1kjMRtBjKEnlfxzKGST9X4nQMQMf2ZpmBCGYb+zEWYNb2WlRreiBRQXmnZW936mekzheOXzGrin7HoGu8IChkIf/CijbV20CedsPLA= Received: by 10.35.112.3 with SMTP id p3mr3365104pym; Mon, 22 May 2006 09:14:52 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Mon, 22 May 2006 09:14:51 -0700 (PDT) Message-ID: <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> Date: Mon, 22 May 2006 12:14:51 -0400 From: "Robert Sayre" To: EKR In-Reply-To: <868xou831c.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xou831c.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 5/22/06, Eric Rescorla wrote: > 1. This is not principally a protocol problem but rather a UI problem. > The protocol problems are generally well understood. If the UI > problems are solved, nearly any protocol will work. In particular, > there have been a number of published designs [1] [2] that have mostly > adequate (though not perfect) protocols, though without complete > solutions to the UI problem. One aspect of Sam's document that concerned me was the section on possible UI solutions. The requirements around spoofing seem directly opposed to the branding and usage patterns that web authors require. HTTP authentication currently presents a modal dialog with no design control, and this is a significant reason most sites opt for form controls. Roy has previously mentioned that 401 Unauthorized responses should be displayed to the user. This would allow a site to embed a new type of form control for authentication purposes... but as I mentioned above, this intermingling could increase the risk of spoofing. --=20 Robert Sayre _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002qk-QY; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEaZ-0007jK-Vu for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEaY-00040b-QI for dix@ietf.org; Mon, 22 May 2006 13:53:07 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5EAA3E000E; Mon, 22 May 2006 13:53:00 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> <86bqtq6kfd.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:53:00 -0400 In-Reply-To: <86bqtq6kfd.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 10:25:42 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 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: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla writes: Eric> Right. I indicated in my message, I'm not sure this draft Eric> dissects the reqts correctly. >> Understood. However all your criticisms to date have been >> rather minor. Eric> Hmm... I didn't mean to give that impression. I certainly Eric> don't think the "it's all about UI" point is minor. I am not sure whether it is minor. I think we are in broad agreement that the interesting work in this space must involve the UI and is not principally a protocol problem. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002q1-9n; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDvs-0008Dm-P6 for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDvr-0001wI-JH for dix@ietf.org; Mon, 22 May 2006 13:11:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15D33E000E; Mon, 22 May 2006 13:10:56 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:10:56 -0400 In-Reply-To: <86wtce6n9e.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 09:24:29 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org, Nicolas Williams 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: Eric> This is all pretty much laid out in the PwdHash and Felten Eric> papers. Sure. My goal here is to describe a series of reasonably obvious requirements so that we can evaluate solutions because we'e seen some solutions like the ones you cite that meet a large number of these conditions and we've seen other solutions that do not. I find specific requirements useful in such situations. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002qV-Ki; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiE7A-0003UX-Nv for dix@ietf.org; Mon, 22 May 2006 13:22:44 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiE79-0002Hh-IO for dix@ietf.org; Mon, 22 May 2006 13:22:44 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2A34DE000E; Mon, 22 May 2006 13:22:37 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 13:22:37 -0400 In-Reply-To: <86r72m6l0u.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 10:12:49 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 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: Eric> Right. I indicated in my message, I'm not sure this draft Eric> dissects the reqts correctly. Understood. However all your criticisms to date have been rather minor. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002pm-51; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiDiq-0003C1-Fv for dix@ietf.org; Mon, 22 May 2006 12:57:36 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiDiq-0001Ou-4R for dix@ietf.org; Mon, 22 May 2006 12:57:36 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5C56CE000E; Mon, 22 May 2006 12:57:28 -0400 (EDT) To: EKR References: <868xou831c.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 12:57:28 -0400 In-Reply-To: <868xou831c.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 08:58:23 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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: Eric> 1. This is not principally a protocol problem but rather a Eric> UI problem. The protocol problems are generally well Eric> understood. If the UI problems are solved, nearly any Eric> protocol will work. In particular, there have been a number Eric> of published designs [1] [2] that have mostly adequate Eric> (though not perfect) protocols, though without complete I agree with you that this is not principally a protocol problem. I'm not sure I agree that this is principally a UI problem; I think it is principally an architecture problem where you need the UI and protocol to cooperate. I also believe that as you point out, the protocol problems are mostly solved. I do think there is still work to do on getting a protocol that is easy to deploy and that for example deals with enrollment, etc. Eric> 2. It's really important to distinguish between different Eric> levels of attack. Conventional phishing attacks rely on Eric> generating a reference which appears to be valid but Eric> actually points at the attacker's site. (This is why SSL/TLS Eric> doesn't help much). Eric> But this is different from attacks in which the attacker Eric> actually intercepts the user's communication. In these Eric> settings, some sort of cryptographic protection for the Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be Eric> provided. Are there specific places in my document where you believe the distinction is critical? Eric> On a similar note, in current phishing attacks the Eric> attacker attempts to directly extract the user's Eric> password. If C-R mechanisms are used, a dictionary attack is Eric> natural. I assume that's why you wave in the direction of Eric> ZKPPs in S 4.3. However, it's worth asking whether we would Eric> be satisified with a system that was only partly Eric> strengthened against dictionary attacks (see [2] again). Yes, probably. I think we'd be satisfied with many things better than what we have:-) I think we'd like to get a ZKPP, but I think we have no reason to assume the IPR situation will be any better with this effort. Eric> 3. The term "password equivalent" is a bit confusing. See Eric> draft-iab-auth-mech for some discussion of strong versus Eric> weak password equivalent. Your IAB draft seems to be focusing on what is stored rather than on what is transported in the protocol. I don't have a problem if a server stores a weak password equivelant, but I do have a problem if the server stores or even receives a strong password equivelant. Eric> 4. I agree that server authentication is a good, but I'm not Eric> totally sold that it's a necessity. I will work on selling you or revising my position. Eric> 5. You write: Eric> The risk of dictionary attack is always a significant Eric> concern for password systems. Users can (but typically do Eric> not) minimize this risk by choosing long, hard to guess Eric> phrases for passwords. The risk can be removed once a Eric> password is already established by using a zero-knowledge Eric> password protocol. Eric> This is not strictly true. A ZKPP removes the risk of Eric> offline dictionary attack, but not online attack. These Eric> attacks do still get mounted [3] Yes, and I even know that:-) Thanks for pointing out that I was being sloppy. Will fix. Eric> However the risk of dictionary attack is always present Eric> when setting up a new password or changing a password. Eric> Minimizing the number of services that use the same password Eric> and being extra careful to make sure the right server is Eric> used when establishing a password can minimize this risk. Eric> It's not clear to me that this helps, unless you're assuming Eric> a ZKPP. If the attacker can capture a Eric> hashed password or Eric> C-R handshake (which a phisher can generally force in Eric> non-ZKPP cases) then they can mount an offline dictionary Eric> attack anyway. Consider a typical design where the user has Eric> a master password P and then generates per-site passwords as Eric> H(Site-Name || P). In the C-R handshake, the user provides: Eric> H(challenge || H(Site-Name || P). Eric> Dictionary attacking this isn't significantly harder than Eric> dictionary attacking H(Site-Name || P). I'm not sure what you meant by this above. If you mean using different passwords, I meant using different master passwords. I believe that actually does help. But I was assuming a ZKPP in that paragraph, and I believ in the ZKPP case, contacting the right server does help. I will update the text. Eric> 6. You write: Eric> In situations where there is an identity provider that is Eric> separate from the website as a relying party, additional Eric> requirements are needed. The identity provider MUST verify Eric> that the website is a valid relying party for this identity. Eric> Some identity providers will allow anyone to accept their Eric> identity. However particularly for financial institutions Eric> and large service providers it will be common that only Eric> authorized business partners will be able to accept the Eric> identity. The confirmation that the the relying party is Eric> such a business partner will often be a significant part of Eric> the value provided by the identity provider, so it is Eric> important that the protocol enable this. The relying party Eric> MUST prove its identity is the one expected by the identity Eric> provider. Eric> I agree that this is is a likely business goal for identity Eric> providers, but it's not required for protection against Eric> phishing. Really, there are two interests here: Eric> 1. To prove to the user (the guy with the browser) that he Eric> is doing business with an "authorized" provider. 2. To Eric> allow the identity provider to extract rents from the Eric> relying parties. Eric> Neither strictly requires the relying party authenticating Eric> to the identity provider during the transaction. The first Eric> can obviously done by issueing the relying party a long-term Eric> credential. The second can be done by encrypting the Eric> credential under the relying party's key. You don't Eric> necessarily need the identity provider to receive a proof Eric> that the relying party was able to decrypt it. I don't believe that my requirements would require that the relying party talk to the identity provider. I believe that assuming a reasonable set of trust anchors, having the web browser ask the identity provider if the dnsname is allowed to accept the identity. That provides a protocol hook allowing the identity provider to meet the requirement that it MUST confirm the relying party is a valid relying party for the identity. If the relying party later proves that it has a trusted certificate for this identity it meets the second requirement. Can you suggest clarifications to the text? Eric> -Ekr P.S. Thanks for the references. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEjQ-0002qG-Ff; Mon, 22 May 2006 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiE0V-0000uS-9x for dix@ietf.org; Mon, 22 May 2006 13:15:51 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiE0U-00025c-2X for dix@ietf.org; Mon, 22 May 2006 13:15:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6DD10E000E; Mon, 22 May 2006 13:15:43 -0400 (EDT) To: Nicolas Williams References: <868xou831c.fsf@raman.networkresonance.com> <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> <20060522161831.GL16695@binky.Central.Sun.COM> From: Sam Hartman Date: Mon, 22 May 2006 13:15:43 -0400 In-Reply-To: <20060522161831.GL16695@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 22 May 2006 11:18:31 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Mon, 22 May 2006 14:02:14 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Robert Sayre Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, May 22, 2006 at 12:14:51PM -0400, Robert Sayre Nicolas> wrote: >> On 5/22/06, Eric Rescorla wrote: >> >1. This is not principally a protocol problem but rather a UI >> problem. > The protocol problems are generally well >> understood. If the UI > problems are solved, nearly any >> protocol will work. In particular, > there have been a number >> of published designs [1] [2] that have mostly > adequate >> (though not perfect) protocols, though without complete > >> solutions to the UI problem. >> >> One aspect of Sam's document that concerned me was the section >> on possible UI solutions. The requirements around spoofing seem >> directly opposed to the branding and usage patterns that web >> authors require. HTTP authentication currently presents a >> modal dialog with no design control, and this is a significant >> reason most sites opt for form controls. Nicolas> Sam wants to put control over the UI in the web site's Nicolas> authors' hands. Nicolas> But he wants this UI tied intimately to a new browser Nicolas> function that is tied intimately to authentication Nicolas> protocols. >> Roy has previously mentio Exactly. I don't think we want today's http authentication dialogues. Really. the secure UI could be as simple as any of the following: * You choose what icon is used for bullets in a secure password form control when you create your account on a computer. The standard bullet is used if it is a normal HTML control; the one you selected is used if it is a control that will make the password available only to the trusted authentication part of the browser. * You have a keystroke and mouse action that will hide non-trusted components of the UI. I'm not a UI designer. I don't know how to come up with a UI that maximizes the probability that the user will actually notice when they are typing a password into the wrong place. I'm just trying to demonstrate that we need not have something as clunky as current http authentication dialogues. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:13:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEuJ-0007ak-CY; Mon, 22 May 2006 14:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiEuH-0007Z1-Vn for dix@ietf.org; Mon, 22 May 2006 14:13:29 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiEuF-00054d-8Z for dix@ietf.org; Mon, 22 May 2006 14:13:29 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 835E41E8C1C; Mon, 22 May 2006 11:13:26 -0700 (PDT) To: Sam Hartman References: <868xou831c.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 22 May 2006 11:13:26 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 22 May 2006 12:57:28 -0400") Message-ID: <86wtce53nd.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: 944ecb6e61f753561f559a497458fb4f Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> 1. This is not principally a protocol problem but rather a > Eric> UI problem. The protocol problems are generally well > Eric> understood. If the UI problems are solved, nearly any > Eric> protocol will work. In particular, there have been a number > Eric> of published designs [1] [2] that have mostly adequate > Eric> (though not perfect) protocols, though without complete > > I agree with you that this is not principally a protocol problem. I'm > not sure I agree that this is principally a UI problem; I think it is > principally an architecture problem where you need the UI and protocol > to cooperate. I don't think I agree. Both of the papers I cited above provide basically acceptable phishing defenses without changing the wire protocol (they do change the password on the server, of course). So, you could certainly do better with a protocol, but I think we have existence proofs that one isn't needed. > Eric> 2. It's really important to distinguish between different > Eric> levels of attack. Conventional phishing attacks rely on > Eric> generating a reference which appears to be valid but > Eric> actually points at the attacker's site. (This is why SSL/TLS > Eric> doesn't help much). > > Eric> But this is different from attacks in which the attacker > Eric> actually intercepts the user's communication. In these > Eric> settings, some sort of cryptographic protection for the > Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be > Eric> provided. > > Are there specific places in my document where you believe the distinction is critical? Well, whenever you're talking about capturing credentials versus capturing the session. Since non-reusable credentials protect against credential capture but not against hijacking. > Eric> 3. The term "password equivalent" is a bit confusing. See > Eric> draft-iab-auth-mech for some discussion of strong versus > Eric> weak password equivalent. > > Your IAB draft seems to be focusing on what is stored rather than on > what is transported in the protocol. I don't have a problem if a > server stores a weak password equivelant, but I do have a problem if > the server stores or even receives a strong password equivelant. Sure. > > Eric> 6. You write: > > Eric> In situations where there is an identity provider that is > Eric> separate from the website as a relying party, additional > Eric> requirements are needed. The identity provider MUST verify > Eric> that the website is a valid relying party for this identity. > Eric> Some identity providers will allow anyone to accept their > Eric> identity. However particularly for financial institutions > Eric> and large service providers it will be common that only > Eric> authorized business partners will be able to accept the > Eric> identity. The confirmation that the the relying party is > Eric> such a business partner will often be a significant part of > Eric> the value provided by the identity provider, so it is > Eric> important that the protocol enable this. The relying party > Eric> MUST prove its identity is the one expected by the identity > Eric> provider. > > Eric> I agree that this is is a likely business goal for identity > Eric> providers, but it's not required for protection against > Eric> phishing. Really, there are two interests here: > > Eric> 1. To prove to the user (the guy with the browser) that he > Eric> is doing business with an "authorized" provider. 2. To > Eric> allow the identity provider to extract rents from the > Eric> relying parties. > > Eric> Neither strictly requires the relying party authenticating > Eric> to the identity provider during the transaction. The first > Eric> can obviously done by issueing the relying party a long-term > Eric> credential. The second can be done by encrypting the > Eric> credential under the relying party's key. You don't > Eric> necessarily need the identity provider to receive a proof > Eric> that the relying party was able to decrypt it. > > I don't believe that my requirements would require that the relying > party talk to the identity provider. I believe that assuming a > reasonable set of trust anchors, having the web browser ask the > identity provider if the dnsname is allowed to accept the identity. > That provides a protocol hook allowing the identity provider to meet > the requirement that it MUST confirm the relying party is a valid > relying party for the identity. If the relying party later proves > that it has a trusted certificate for this identity it meets the > second requirement. > > Can you suggest clarifications to the text? I don't think so because we don't agree on the requirements. My point is that the relying party does not need to prove its authorization to the identity provider in any way in order to solve the phishing problem. It may be required if the identity provider wants to charge relying parties, but even then it can be done without "confirming" as I indicated above. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFUq-0002za-IA; Mon, 22 May 2006 14:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFUp-0002zV-JP for dix@ietf.org; Mon, 22 May 2006 14:51:15 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFUo-0006hX-8h for dix@ietf.org; Mon, 22 May 2006 14:51:15 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id B2BCD1E8C1C; Mon, 22 May 2006 11:51:13 -0700 (PDT) To: Sam Hartman References: <868xou831c.fsf@raman.networkresonance.com> <86wtce53nd.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 22 May 2006 11:51:13 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 22 May 2006 14:40:36 -0400") Message-ID: <86mzd96ggu.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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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: >>>>>> "Eric" == Eric Rescorla writes: > > >> I don't believe that my requirements would require that the > >> relying party talk to the identity provider. I believe that > >> assuming a reasonable set of trust anchors, having the web > >> browser ask the identity provider if the dnsname is allowed to > >> accept the identity. That provides a protocol hook allowing > >> the identity provider to meet the requirement that it MUST > >> confirm the relying party is a valid relying party for the > >> identity. If the relying party later proves that it has a > >> trusted certificate for this identity it meets the second > >> requirement. > >> > >> Can you suggest clarifications to the text? > > Eric> I don't think so because we don't agree on the > Eric> requirements. My point is that the relying party does not > Eric> need to prove its authorization to the identity provider in > Eric> any way in order to solve the phishing problem. > > OK, we disagree on the requirements. I believe that allowing the > identity provider to validate the identity actually provides > significant defenses against phishing. > > > Assume that examplebank.com is a financial institution that acts as an > identity provider for themselves and for business partners. If they > are given the ability to confirm that the website I'm going to is > allowed to accept their identity, then they can give me an error if I > attempt to use their identity with some random phishing site I got a > link to in email. > > You may disagree that this defense is important. However it is a > defense. And I never said otherwise, but just being a defense does not make it a requirement. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 14:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFX4-0003HW-Ic; Mon, 22 May 2006 14:53:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFX3-0003HR-3b for dix@ietf.org; Mon, 22 May 2006 14:53:33 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFX1-0006tJ-Ms for dix@ietf.org; Mon, 22 May 2006 14:53:33 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4MIrVxW014885 for ; Mon, 22 May 2006 12:53:31 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4MIqeUe008848 for ; Mon, 22 May 2006 12:52:40 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4MIrUYq018161; Mon, 22 May 2006 13:53:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4MIrU8l018160; Mon, 22 May 2006 13:53:30 -0500 (CDT) Date: Mon, 22 May 2006 13:53:30 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060522185330.GA18146@binky.Central.Sun.COM> References: <868xou831c.fsf@raman.networkresonance.com> <86wtce53nd.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 Mon, May 22, 2006 at 02:40:36PM -0400, Sam Hartman wrote: > Assume that examplebank.com is a financial institution that acts as an > identity provider for themselves and for business partners. If they > are given the ability to confirm that the website I'm going to is > allowed to accept their identity, then they can give me an error if I > attempt to use their identity with some random phishing site I got a > link to in email. > > You may disagree that this defense is important. However it is a > defense. It amounts to a hook for white/black-listing. It can only really work well as a whitelist, and only if the list is kept very small. ISPs acting as IdPs may not want to be in the blacklisting business, and whitelisting won't be an option. So I see this as an optional feature, not a requirement. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 17:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiI8j-0002Zj-4L; Mon, 22 May 2006 17:40:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFPX-0002RO-7Y for dix@ietf.org; Mon, 22 May 2006 14:45:47 -0400 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFPW-0006RP-1T for dix@ietf.org; Mon, 22 May 2006 14:45:47 -0400 Received: by py-out-1112.google.com with SMTP id f28so1545415pyf for ; Mon, 22 May 2006 11:45:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nfHusgvJhFRcKFy2/1QKiUXitsVOVVbC84mV0mAEXehOP0e1j/eNtLix3AuOarKJsBOrZWlRxUDRis1bwBRPUIs6u93qTxqajg0elpgoBMjgOan7n3V0iQH6GklEENVnX8BzNM1Kv1vAkkWGU3bD7cPs6qh55D/Xv4QZ8vDPbQ0= Received: by 10.35.99.14 with SMTP id b14mr2939694pym; Mon, 22 May 2006 11:45:45 -0700 (PDT) Received: by 10.35.121.2 with HTTP; Mon, 22 May 2006 11:45:45 -0700 (PDT) Message-ID: <68fba5c50605221145r15a9d398t5130beef831a41a9@mail.gmail.com> Date: Mon, 22 May 2006 14:45:45 -0400 From: "Robert Sayre" To: "Nicolas Williams" In-Reply-To: <20060522161831.GL16695@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <868xou831c.fsf@raman.networkresonance.com> <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> <20060522161831.GL16695@binky.Central.Sun.COM> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 22 May 2006 17:40:36 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 5/22/06, Nicolas Williams wrote: > > As Sam says: the browser must change. Sure, and I suspect almost all browser vendors are willing to do that, but I think better security is an insufficient motivator for web authors. The requirement for mutual authentication was interesting to me. Groups extending Web formats and APIs[1] often encounter situations where a slightly elevated trust level for certain scripts would be useful. Offering a carrot in the form of an extended JavaScript API for authenticated scripts would probably accelerate deployment of these new efforts. [1] http://www.w3.org/2006/webapi/ --=20 Robert Sayre _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 17:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiI8i-0002Ze-W4; Mon, 22 May 2006 17:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiFKe-0000pP-NF for dix@ietf.org; Mon, 22 May 2006 14:40:44 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiFKd-0006EM-Gw for dix@ietf.org; Mon, 22 May 2006 14:40:44 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1C9A3E000E; Mon, 22 May 2006 14:40:36 -0400 (EDT) To: EKR References: <868xou831c.fsf@raman.networkresonance.com> <86wtce53nd.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 22 May 2006 14:40:36 -0400 In-Reply-To: <86wtce53nd.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 22 May 2006 11:13:26 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Mon, 22 May 2006 17:40:36 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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: >> I don't believe that my requirements would require that the >> relying party talk to the identity provider. I believe that >> assuming a reasonable set of trust anchors, having the web >> browser ask the identity provider if the dnsname is allowed to >> accept the identity. That provides a protocol hook allowing >> the identity provider to meet the requirement that it MUST >> confirm the relying party is a valid relying party for the >> identity. If the relying party later proves that it has a >> trusted certificate for this identity it meets the second >> requirement. >> >> Can you suggest clarifications to the text? Eric> I don't think so because we don't agree on the Eric> requirements. My point is that the relying party does not Eric> need to prove its authorization to the identity provider in Eric> any way in order to solve the phishing problem. OK, we disagree on the requirements. I believe that allowing the identity provider to validate the identity actually provides significant defenses against phishing. Assume that examplebank.com is a financial institution that acts as an identity provider for themselves and for business partners. If they are given the ability to confirm that the website I'm going to is allowed to accept their identity, then they can give me an error if I attempt to use their identity with some random phishing site I got a link to in email. You may disagree that this defense is important. However it is a defense. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 22 18:10:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIbD-0001rH-AI; Mon, 22 May 2006 18:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiIbC-0001rC-Bx for dix@ietf.org; Mon, 22 May 2006 18:10:02 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiIb8-0000nT-FV for dix@ietf.org; Mon, 22 May 2006 18:10:02 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4MM9vUm015622 for ; Mon, 22 May 2006 15:09:57 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4MM95UE014395 for ; Mon, 22 May 2006 16:09:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4MM9umc020023; Mon, 22 May 2006 17:09:56 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4MM9tD3020022; Mon, 22 May 2006 17:09:55 -0500 (CDT) Date: Mon, 22 May 2006 17:09:55 -0500 From: Nicolas Williams To: Robert Sayre Message-ID: <20060522220955.GE18176@binky.Central.Sun.COM> References: <868xou831c.fsf@raman.networkresonance.com> <68fba5c50605220914p4311cd58wd256d7332dcc59e0@mail.gmail.com> <20060522161831.GL16695@binky.Central.Sun.COM> <68fba5c50605221145r15a9d398t5130beef831a41a9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68fba5c50605221145r15a9d398t5130beef831a41a9@mail.gmail.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org, Sam Hartman Subject: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements 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 Mon, May 22, 2006 at 02:45:45PM -0400, Robert Sayre wrote: > On 5/22/06, Nicolas Williams wrote: > > > >As Sam says: the browser must change. > > Sure, and I suspect almost all browser vendors are willing to do that, > but I think better security is an insufficient motivator for web > authors. The requirement for mutual authentication was interesting to > me. Groups extending Web formats and APIs[1] often encounter > situations where a slightly elevated trust level for certain scripts > would be useful. > > Offering a carrot in the form of an extended JavaScript API for > authenticated scripts would probably accelerate deployment of these > new efforts. Call it an "extended JavaScript API" or something else, it doesn't matter what it is called, as long as it is: a) a browser function b) that can be invoked from an HTML UI element c) and which ties into the actual protocol and authentication mechanism(s) used on the wire Again, you can call the HTML UI element a form, or something else. It is a carrot. Those who don't want to use it won't have to. But why not use it if it's available? That this all has to live in the browser should be no obstacle. That web site authors have to detect its presence in their client browsers and choose to use it should be no obstacle either. Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed May 24 05:47:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fipxr-0003Od-LJ; Wed, 24 May 2006 05:47:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fipxq-0003Jl-52 for dix@ietf.org; Wed, 24 May 2006 05:47:38 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fipxn-0005Fg-Tm for dix@ietf.org; Wed, 24 May 2006 05:47:38 -0400 Received: from lavazza.does-not-exist.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 2DB5F4EFCE; Wed, 24 May 2006 05:47:35 -0400 (EDT) Received: from roessler by lavazza.does-not-exist.org with local (Exim 4.62) (envelope-from ) id 1Fipxm-0006AO-NU; Wed, 24 May 2006 10:47:34 +0100 Date: Wed, 24 May 2006 10:47:34 +0100 From: Thomas Roessler To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements Message-ID: <20060524094734.GF20146@lavazza.does-not-exist.org> Mail-Followup-To: Sam Hartman , EKR , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org References: <868xou831c.fsf@raman.networkresonance.com> <20060522161457.GK16695@binky.Central.Sun.COM> <86wtce6n9e.fsf@raman.networkresonance.com> <86r72m6l0u.fsf@raman.networkresonance.com> <86bqtq6kfd.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 2006-05-22 13:53:00 -0400, Sam Hartman wrote: > I think we are in broad agreement that the interesting work > in this space must involve the UI and is not principally a > protocol problem. I very much agree. Incidentally, you may want have a look at the report from the March W3C workshop: http://www.w3.org/2005/Security/usability-ws/report We (W3C) are currently thinking about how to best charter work that would specify some browser user interface components that would have to be outside the control of web sites, and could be used to make sure that users know (as opposed to look at on their screens) where they are going to send their confidential information. Another element that we took as important from the workshop in NYC is to enable user agents to reliably recognize HTML forms that are used for authentication. This ability would enable user agents to manage credentials on behalf of the user. It would also enable user agents to *not* submit credentials using HTTP POST (even when entered through HTML forms), but instead grab them and use them for whatever HTTP-level authentication mechanism is used. User agents could also do intelligent things in the UI to make sure that users understand what they are doing here. PS: I'm currently at WWW 2006 in Edinburgh. If any of you guys want to chat more about this, please feel free to drop me a line, so we can meet up somewhere. Regards, -- Thomas Roessler, W3C _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed May 24 12:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiw5B-0001Ca-W8; Wed, 24 May 2006 12:19:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiw5A-0001CS-Pp; Wed, 24 May 2006 12:19:36 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiw59-0007ZP-C2; Wed, 24 May 2006 12:19:36 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ECC68E0074; Wed, 24 May 2006 12:19:27 -0400 (EDT) To: saag@mit.edu, ietf@ietf.org, dix@ietf.org From: Sam Hartman mail-copies-to: ietf-http-auth@lists.osafoundation.org mail-followups-to: ietf-http-auth@lists.osafoundation.org Date: Wed, 24 May 2006 12:19:27 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Subject: [dix] [Sam Hartman] [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing 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 --=-=-= Hello. I'd like to draw your attention te the following BOF proposal. Please discuss on ietf-http-auth@ietf.org. I'd appreciate comments and indications of interest. I'd also like to draw your attention to two resources besides the BOF proposal: http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-May/000241.html contains a better describption of what I think the BOF presentations should cover. http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt contains my comments on anti-phishing requiremnts and I hope will be a starting point for what it means for web authentication to be resistant to phishing. I believe that similar requirements should apply to other proposals including things in the DIX space. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue, 23 May 2006 17:34:25 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by suchdamage.org (Postfix) with ESMTP id 9A2F0138B7 for ; Tue, 23 May 2006 17:34:24 -0400 (EDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 61B1B7F851; Tue, 23 May 2006 14:34:21 -0700 (PDT) X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0134C7F829 for ; Tue, 23 May 2006 14:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E72FC142291 for ; Tue, 23 May 2006 14:34:19 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06285-02 for ; Tue, 23 May 2006 14:34:18 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F387614228B for ; Tue, 23 May 2006 14:34:17 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F2B6AE000E; Tue, 23 May 2006 17:34:09 -0400 (EDT) To: ietf-http-auth@lists.osafoundation.org From: Sam Hartman Date: Tue, 23 May 2006 17:34:09 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Subject: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-http-auth-bounces@osafoundation.org Errors-To: ietf-http-auth-bounces@osafoundation.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 [Sent to the ADs; comments very much appreciated.] BOF Description: At IETF 65, the DIX BOF demonstrated a consensus to work on a solution to the problem that there are two many passwords for the web. This BOF proposes to develop a authentication architecture for the web and other HTTP-based applications using existing technology with at most small changes necessary to improve deployability that addresses this problem. One of the critical challenges facing the web today is the problem of phishing, where users are directed to fraudulent websites that request confidential information. Any solution to the phishing problem will require UI changes in web browsers. However the HTTP authentication architecture needs to work with these UI changes and provide clear technical requirements for the security features required from the UI. Proposed Charter: Web Authentication Resistant to Phishing (WARP) Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-http-auth@lists.osafoundation.org To Subscribe: ietf-http-auth-requst@lists.osafoundation.org In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: WARP is chartered to develop a method for using existing authentication technology to address two critical problems with authentication for the web and other HTTP-using applications. The first problem is that users must remember and maintain passwords for each HTTP service they use. The second problem is that of phishing. While browser UIs must change in order to combat the problem of phishing, WARP must work with these UI changes and must provide clear technical requirements for the security features needed from authentication UI. WARP will attack the problem of multiple passwords in two ways. First, it will be safe from a security standpoint to use the same password with multiple HTTP services. Second, WARP will support the concept of an identity provider, which is a service that clients can authenticate to and that can make assertions about their identity to third parties. Employers authenticating their employees to business partners, distributed communities that share a concept of identity and services like Microsoft's Passport service demonstrate the wide variety of identity providers. There will never be a single identity that a user can use on the web: many users would not choose to use the same identity in a work context that they use personally; similarly business relationships and policies will dictate what identities services can accept. However WARP will support the concept of identity providers so that when policies permit, users can minimize the number of identities they use. WARP must support identity providers associated with servers and should support identity providers that have relationships with users. WARP needs to support mobile users, including users that use HTTP services from computers they have never used before. WARP must not require per-service or per-identity-provider configuration. While WARP is focused on passwords as that is expected to be the primary means of authentication, WARP needs to support other credentials including smart cards, one-time passwords and zero-knowledge password protocols. It is desirable that WARP be able to carry assertions about identity such as Security Assertion Markup Language assertions. The WARP working group will first write a problem statement and a requirements draft describing what it means to produce an authentication solution that is resistant to phishing. Then WARP will choose a mandatory-to-implement authentication technology and protocol for the interaction between the identity provider and website. WARP will coordinate with W3C in working on the UI implications of phishing. WARP will not propose specific UI nor specific extensions to HTML, although WARP may recommend requirements for both as these requirements directly impact the security or deployability of WARP. Deliverables: * Problem statement for WARP * Requirements for authentication resistant to phishing * WARP protocol document describing how an existing authentication system is used to meet the requirements of WARP. This document may specify mandatory to implement modes in addition to those specified in the underlying system. * A proposed standard describing how an identity is registered with an identity provider or website. * A proposed standard describing how an identity associated with a user is linked to an HTTP service's concept of an account. BOF Agenda (2.5 hour slot requested): * Presentation on the multiple passwords problem (10 minutes) * Presentation on phishing (30 minutes) * Presentation arguing that existing technology is available (30 minutes) * Description of Charter (10 minutes) * Discussion _______________________________________________ Ietf-http-auth mailing list Ietf-http-auth@osafoundation.org http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- From dix-bounces@ietf.org Thu May 25 06:31:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjD7l-0006Zw-Om; Thu, 25 May 2006 06:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjD7l-0006Zr-4D for dix@ietf.org; Thu, 25 May 2006 06:31:25 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjD7j-0002zp-FQ for dix@ietf.org; Thu, 25 May 2006 06:31:25 -0400 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k4PAV1Bs022930 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 25 May 2006 10:31:11 GMT Date: Thu, 25 May 2006 20:31:17 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <564522964.20060525203117@pobox.com> To: dix@ietf.org Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: >> I don't believe that my requirements would require that the >> relying party talk to the identity provider. How do you propose to protect my privacy in this scenario? I do not want the same credentials of mine revealed when I log in to "shame-your-boss.com" as when I log in to my sourceforge account, but I would like to avoid having to remember multitudes of different usernames and passwords for every web site I visit, as well as enjoy phishing defences... Kind Regards, Chris Drake. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 25 11:20:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHdx-0006p5-7R; Thu, 25 May 2006 11:20:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHdv-0006p0-Es for dix@ietf.org; Thu, 25 May 2006 11:20:55 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHdt-00024p-5N for dix@ietf.org; Thu, 25 May 2006 11:20:55 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6461E1E8C4C; Thu, 25 May 2006 08:20:46 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <564522964.20060525203117@pobox.com> From: Eric Rescorla Date: Thu, 25 May 2006 08:20:46 -0700 In-Reply-To: <564522964.20060525203117@pobox.com> (Chris Drake's message of "Thu, 25 May 2006 20:31:17 +1000") Message-ID: <86mzd62ks1.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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Chris Drake writes: >>>>>> "Eric" == Eric Rescorla writes: > > >> I don't believe that my requirements would require that the > >> relying party talk to the identity provider. > > How do you propose to protect my privacy in this scenario? I do not > want the same credentials of mine revealed when I log in to > "shame-your-boss.com" as when I log in to my sourceforge account, but > I would like to avoid having to remember multitudes of different > usernames and passwords for every web site I visit, as well as enjoy > phishing defences... And you'd prefer to have your identity provider have a record of every site you've visited? -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 25 11:42:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHym-000314-0f; Thu, 25 May 2006 11:42:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjHyk-00030z-FS for dix@ietf.org; Thu, 25 May 2006 11:42:26 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjHyg-0004HC-1p for dix@ietf.org; Thu, 25 May 2006 11:42:26 -0400 Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k4PFgLQU023890 for ; Thu, 25 May 2006 08:42:21 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k4PFfOiH006565 for ; Thu, 25 May 2006 09:41:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k4PFgKfv019488; Thu, 25 May 2006 10:42:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k4PFgKYJ019487; Thu, 25 May 2006 10:42:20 -0500 (CDT) Date: Thu, 25 May 2006 10:42:20 -0500 From: Nicolas Williams To: EKR , Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements Message-ID: <20060525154219.GV11607@binky.Central.Sun.COM> References: <564522964.20060525203117@pobox.com> <86mzd62ks1.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mzd62ks1.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 On Thu, May 25, 2006 at 08:20:46AM -0700, Eric Rescorla wrote: > Chris Drake writes: > > How do you propose to protect my privacy in this scenario? I do not > > want the same credentials of mine revealed when I log in to > > "shame-your-boss.com" as when I log in to my sourceforge account, but > > I would like to avoid having to remember multitudes of different > > usernames and passwords for every web site I visit, as well as enjoy > > phishing defences... > > And you'd prefer to have your identity provider have a record > of every site you've visited? If you're your own IdP... Or if your ISP is your IdP... (your ISP already knows what sites you visit) _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 25 11:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjI7z-0006wg-I2; Thu, 25 May 2006 11:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjI7x-0006wb-Jg for dix@ietf.org; Thu, 25 May 2006 11:51:57 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjI7w-0004uK-9a for dix@ietf.org; Thu, 25 May 2006 11:51:57 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id CAB241E8C1C; Thu, 25 May 2006 08:51:55 -0700 (PDT) To: Nicolas Williams Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <564522964.20060525203117@pobox.com> <86mzd62ks1.fsf@raman.networkresonance.com> <20060525154219.GV11607@binky.Central.Sun.COM> From: Eric Rescorla Date: Thu, 25 May 2006 08:51:55 -0700 In-Reply-To: <20060525154219.GV11607@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 25 May 2006 10:42:20 -0500") Message-ID: <86ejyi2jc4.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: bb8f917bb6b8da28fc948aeffb74aa17 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 Nicolas Williams writes: > On Thu, May 25, 2006 at 08:20:46AM -0700, Eric Rescorla wrote: >> Chris Drake writes: >> > How do you propose to protect my privacy in this scenario? I do not >> > want the same credentials of mine revealed when I log in to >> > "shame-your-boss.com" as when I log in to my sourceforge account, but >> > I would like to avoid having to remember multitudes of different >> > usernames and passwords for every web site I visit, as well as enjoy >> > phishing defences... >> >> And you'd prefer to have your identity provider have a record >> of every site you've visited? > > If you're your own IdP... Or if your ISP is your IdP... (your ISP > already knows what sites you visit) But neither of these cases is universal--and of course you can hide your actions from your IdP using a number of techniques (Tor, for instance). My point is merely that there are also privacy implications to having your IdP involved in every transaction. Moreover, it's not a necessary condition for providing minimal information to the relying party. You could, for instance, have the IdP issue separate credentials for a bunch of attributes (all ties to the same underlying authentication credential) and have the user control which ones are provided to the relying party. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 25 12:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIRq-0001eI-HH; Thu, 25 May 2006 12:12:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIRp-0001eD-UG for dix@ietf.org; Thu, 25 May 2006 12:12:29 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIRo-0006T9-6v for dix@ietf.org; Thu, 25 May 2006 12:12:29 -0400 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k4PGC6C1023462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 25 May 2006 16:12:15 GMT Date: Fri, 26 May 2006 02:12:13 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <1314254837.20060526021213@pobox.com> To: EKR , Digital Identity Exchange Subject: Re[2]: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements In-Reply-To: <86mzd62ks1.fsf@raman.networkresonance.com> References: <564522964.20060525203117@pobox.com> <86mzd62ks1.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 ER> Chris Drake writes: >>>>>>> "Eric" == Eric Rescorla writes: >> >> >> I don't believe that my requirements would require that the >> >> relying party talk to the identity provider. >> >> How do you propose to protect my privacy in this scenario? I do not >> want the same credentials of mine revealed when I log in to >> "shame-your-boss.com" as when I log in to my sourceforge account, but >> I would like to avoid having to remember multitudes of different >> usernames and passwords for every web site I visit, as well as enjoy >> phishing defences... ER> And you'd prefer to have your identity provider have a record ER> of every site you've visited? Which would you prefer? Neither is ideal - the best solution would in fact *be* neither, but if I'm *forced* to let either the site who I chose to trust with my identity and privacy know where I go, or, let everywhere I go know who I am - I'll reluctantly choose the former. If my ID provider publishes a privacy policy telling me that they don't keep records of these things - then I might even be happy with my decision. No amount of relying party privacy policies will make me happy though - it's difficult to trust one site with my identity, impossible to trust them all. I forget offhand how double-blind emailling and mixmaster stuff works, but I think the concept of enabling dix and at the same time preventing either the relying party or the IdP form knowing too much is just a cryptographic solution? (except for the problem of HTTP REFERRER it's just simple asymmetric-key-protected transaction.) Additionally - I can't, off the top of my head, think how to get my long-term credential into the relying party's web site without using HTTP redirects (introducing the referrer problem), extra installed software components (which corporate/internet-cafe users won't have permission to install), or users copy/pasting things into input boxes (tricky, unsafe, no phishing protection) > Nicolas Williams Wrote: >If you're your own IdP... Or if your ISP is your IdP... (your ISP >already knows what sites you visit) I don't think Joe User's going to be able to be their own IdP or use their ISP for it - too many of them surf both from home and work, and if they can't get their email when they're on holidays, dix has failed. Kind Regards, Chris Drake _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu May 25 12:18:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIXY-0006Rb-T6; Thu, 25 May 2006 12:18:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIXY-0006RV-5t for dix@ietf.org; Thu, 25 May 2006 12:18:24 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIXW-0006c4-RY for dix@ietf.org; Thu, 25 May 2006 12:18:24 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 78D191E8C1C; Thu, 25 May 2006 09:18:22 -0700 (PDT) To: Chris Drake Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <564522964.20060525203117@pobox.com> <86mzd62ks1.fsf@raman.networkresonance.com> <1314254837.20060526021213@pobox.com> From: Eric Rescorla Date: Thu, 25 May 2006 09:18:22 -0700 In-Reply-To: <1314254837.20060526021213@pobox.com> (Chris Drake's message of "Fri, 26 May 2006 02:12:13 +1000") Message-ID: <86ac962i41.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 Chris Drake writes: > ER> Chris Drake writes: > >>>>>>>> "Eric" == Eric Rescorla writes: >>> >>> >> I don't believe that my requirements would require that the >>> >> relying party talk to the identity provider. >>> >>> How do you propose to protect my privacy in this scenario? I do not >>> want the same credentials of mine revealed when I log in to >>> "shame-your-boss.com" as when I log in to my sourceforge account, but >>> I would like to avoid having to remember multitudes of different >>> usernames and passwords for every web site I visit, as well as enjoy >>> phishing defences... > > ER> And you'd prefer to have your identity provider have a record > ER> of every site you've visited? > > Which would you prefer? > > Neither is ideal - the best solution would in fact *be* neither, but > if I'm *forced* to let either the site who I chose to trust with my > identity and privacy know where I go, or, let everywhere I go know who > I am - I'll reluctantly choose the former. Right, but you're not forced to. This sort of problem is fairly well covered in the cryptographic literature. > Additionally - I can't, off the top of my head, think how to get my > long-term credential into the relying party's web site without using > HTTP redirects (introducing the referrer problem), extra installed > software components (which corporate/internet-cafe users won't have > permission to install), or users copy/pasting things into input boxes > (tricky, unsafe, no phishing protection) Basically any solution which is going to be phishing safe is likely to involve modifyign the browser somehow. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon May 29 09:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhWc-0006Xg-Pt; Mon, 29 May 2006 09:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhWZ-0006Wz-Bo for dix@ietf.org; Mon, 29 May 2006 09:11:11 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkhWY-0004J8-3k for dix@ietf.org; Mon, 29 May 2006 09:11:11 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 29 May 2006 06:11:09 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="1814705084:sNHT30343346" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k4TDB9xA004165; Mon, 29 May 2006 06:11:09 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k4TDB9Is027625; Mon, 29 May 2006 06:11:09 -0700 (PDT) Received: from [192.168.1.103] (che-vpn-cluster-2-184.cisco.com [10.86.242.184]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k4TD7txH014122; Mon, 29 May 2006 06:07:55 -0700 Message-ID: <447AF2F4.8030302@cisco.com> Date: Mon, 29 May 2006 15:11:16 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: EKR , Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements References: <564522964.20060525203117@pobox.com> <86mzd62ks1.fsf@raman.networkresonance.com> In-Reply-To: <86mzd62ks1.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-8.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=358; t=1148908269; x=1149772269; c=relaxed/simple; s=sjdkim8001; 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]=20Re=3A=20[Ietf-http-auth]=20New=20draft=20on=20anti-phish ing=20requirements; X=v=3Dcisco.com=3B=20h=3DjhQDcTD+XgEaQcIJE/1ENIAkbx4=3D; b=WsHITKWbsmS1WeVlgEQafUEdIMZ3RDpzIy2TaqppblnRtAkj3vLlWr5rL4dHlilg3MdLmrMa FsZ8Xkb0XKqZLtdVhXuwkhqwz6ONR6an7y03rO0lVpRKCBHtgkEMyZYq; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Eric Rescorla wrote: > And you'd prefer to have your identity provider have a record > of every site you've visited? > What if the identity provider is an identity subsystem either on your own computer or in some adjunct such as a smart card? Then this problem does not come up. See December 2004 USENIX Login: Security Special issue. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed May 31 23:49:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FleBf-00052k-Ah; Wed, 31 May 2006 23:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FleBe-00052U-FL for dix@ietf.org; Wed, 31 May 2006 23:49:30 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FleBb-0002hc-4G for dix@ietf.org; Wed, 31 May 2006 23:49:30 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k513nPYt075262 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 May 2006 20:49:25 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <8F34AB22-FBA7-4FCC-986E-C7881CECCE60@sxip.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Wed, 31 May 2006 20:49:21 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [dix] draft-merrells-use-cases-04.txt 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 Incorporated comments provided by Jeffrey Altman, Cat Okita, and Jim Sermershiem. http://dixs.org/index.php/Draft-merrells-use-cases-04.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed May 31 23:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FleD7-0005hQ-K6; Wed, 31 May 2006 23:51:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FleD6-0005hL-MJ for dix@ietf.org; Wed, 31 May 2006 23:51:00 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FleD5-0002kX-Ap for dix@ietf.org; Wed, 31 May 2006 23:51:00 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k513owQU075358 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 May 2006 20:50:58 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Digital Identity Exchange From: John Merrells Date: Wed, 31 May 2006 20:50:54 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [dix] draft-merrells-dix-assertion-00.txt 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 This draft describes a format for an attribute value assertion attested by a third party. In other words a DIX Property encoded as a SAML Assertion. http://dixs.org/index.php/Draft-merrells-dix-assertion-00.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix