Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 822577F74D for ; Thu, 29 Jun 2006 06:54:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 738BC1422DC for ; Thu, 29 Jun 2006 06:54:25 -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 04740-01 for ; Thu, 29 Jun 2006 06:54:24 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 016941422C8 for ; Thu, 29 Jun 2006 06:54:23 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k5TDsHKF002242; Thu, 29 Jun 2006 06:54:17 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 06:54:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-http-auth] Re: [dix] BOF plans Date: Thu, 29 Jun 2006 06:54:08 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B56506@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-http-auth] Re: [dix] BOF plans Thread-Index: AcabeyI2QKSc5tdgTfC69+Lve2JNVgAB2w1w From: "Hallam-Baker, Phillip" To: "Sam Hartman" , "Digital Identity Exchange" X-OriginalArrivalTime: 29 Jun 2006 13:54:07.0402 (UTC) FILETIME=[7D6E00A0:01C69B83] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 13:54:25 -0000 > [mailto:ietf-http-auth-bounces@osafoundation.org] On Behalf=20 > I agree that it is important and achievable to share=20 > authentication against all of these protocols. >=20 > My proposal definitely works that wy. There are things you=20 > need to do in the binding to http--and one of those is state=20 > management. However it is quite clear that anything that=20 > will work with http negotiate authentication also works with=20 > xmpp, smtp, ldap, imap, and friends. >=20 > In the specific case of Kerberos, we have a lot of running code. Cookies should have been Kerberos tokens from the start.=20 Whatever scheme we come up with is going to have two distinct phases. 1) In the authentication phase the user will on success receive some = form of ticket. 2) In the ticket phase the ticket will be presented for multiple = transactions until it expires. We have to have a balance here between simplicity and generality. We do = need to support multiple application protocols. We do not need to = support multiple authentication protocols for the same authentication = mechanism. We must not redo ISAKMP. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 67FA37F71C for ; Thu, 29 Jun 2006 05:54:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5965C1422E0 for ; Thu, 29 Jun 2006 05:54:24 -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 30190-08 for ; Thu, 29 Jun 2006 05:54:22 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 95C651422CD for ; Thu, 29 Jun 2006 05:54:22 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AEEB3E0079; Thu, 29 Jun 2006 08:54:21 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> <44A228D1.7050609@cisco.com> Date: Thu, 29 Jun 2006 08:54:21 -0400 In-Reply-To: <44A228D1.7050609@cisco.com> (Eliot Lear's message of "Wed, 28 Jun 2006 08:59:29 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 12:54:24 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Hi, >> I doubt it will be possible to use exactly the same methods for HTTP, >> XMPP, SMTP and IMAP. The latter three (XMPP, SMTP and IMAP) are >> session based, and might require authentication/authorization only >> once during a session. HTTP is stateless (at least in general), so >> some thought needs to be given to extending the auth across multiple >> requests. Eliot> While I agree there may be some differences between application Eliot> protocols, it is the primary authentication method that must be shared. Eliot> Consider the case where some sort of authentication subsystem sits Eliot> outside each application. So long as the API for that can be shared, Eliot> we're probably good. If HTTP requires a method to retain state across Eliot> connections that is HTTP's business. I would not link the two together. I agree that it is important and achievable to share authentication against all of these protocols. My proposal definitely works that wy. There are things you need to do in the binding to http--and one of those is state management. However it is quite clear that anything that will work with http negotiate authentication also works with xmpp, smtp, ldap, imap, and friends. In the specific case of Kerberos, we have a lot of running code. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 608627F75C for ; Wed, 28 Jun 2006 23:00:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 51A951422C2 for ; Wed, 28 Jun 2006 23:00:39 -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 13962-08 for ; Wed, 28 Jun 2006 23:00:37 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id D58201422C0 for ; Wed, 28 Jun 2006 23:00:37 -0700 (PDT) Received: from [192.168.1.105] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5T60W8V008442 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 28 Jun 2006 23:00:32 -0700 (PDT) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <20060619220742.40B85222427@laser.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Date: Wed, 28 Jun 2006 23:00:30 -0700 To: IETF HTTP Auth , Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Subject: [Ietf-http-auth] Google Account Authorization - slightly off topic X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 06:00:39 -0000 Google rolled out some some APIs[1] to make it easier for rich clients [2] and websites[3] to act on behalf of a Google user. Of course this deepens the identity silo that is building at Google. [3] looks like some concepts that ekr has been talking about. Ben: hate to put you on the spot, but is Google looking to participate in WAE? [1] http://code.google.com/apis/accounts/Authentication.html [2] http://code.google.com/apis/accounts/AuthForInstalledApps.html [3] http://code.google.com/apis/accounts/AuthForWebApps.html Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 22B987F762 for ; Wed, 28 Jun 2006 20:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 145471422AB for ; Wed, 28 Jun 2006 20:48:55 -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 08063-04 for ; Wed, 28 Jun 2006 20:48:54 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 567C31422A1 for ; Wed, 28 Jun 2006 20:48:54 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B1AE9E0079; Wed, 28 Jun 2006 23:48:56 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange References: <20060619220742.40B85222427@laser.networkresonance.com> Date: Wed, 28 Jun 2006 23:48:56 -0400 In-Reply-To: (Pete Resnick's message of "Mon, 26 Jun 2006 22:42:11 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] Re: [dix] BOF plans X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 03:48:55 -0000 >>>>> "Pete" == Pete Resnick writes: Pete> EKR's note seems to have sparked discussions in the right Pete> - What problem does this address that isn't addressed by a local Pete> "keychain" or information database on the client? (For example, Pete> possible answers include: "The problem of not having to change the Pete> local user agent" and "The problem of portability".) What's the Pete> downside if we don't solve those problems? First, I think there is IETF work to do even if all we are doing is working with W3c to recommend best client practices. However I think that providing portable identities that meet ekr's COC critera and that do not increase risk of phishing requires IETF work. I believe that the same mechanisms that give us COC can give us CRC and HRA. Pete> - Does the mechanism use or extend currently deployed web Pete> authentication mechanisms (client side and server side)? If not, why Pete> not? My proposal at least does. Pete> - Is the client able to decide which identifying information goes to Pete> the server? In my proposal, yes in a limited form. This can be expanded over time. I wanted to bite off a small chunk to start from. While this is supported, I hope future work increases the granularity of client control. Pete> - Does the mechanism involve 3rd parties for authentication or Pete> identifying info? Does the 3rd party need to be trusted by the relying Pete> party? My mechanism does. The third party is delegated a portion of a namespace. The third party can produce credentials for any identifier in that namespace. The third party needs to be trusted as much as the most trusted identity that the RP currently accepts in its namespace. Pete> - Does the mechanism use a format for the information that has widely Pete> available implementations? Yes. Pete> - Are you using a mechanism to authenticate the information that has Pete> widely available implementations? I do not understand this question. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7E4EA7F762 for ; Wed, 28 Jun 2006 20:39:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6F6721422C0 for ; Wed, 28 Jun 2006 20:39:58 -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 17201-04 for ; Wed, 28 Jun 2006 20:39:57 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3AF701422A1 for ; Wed, 28 Jun 2006 20:39:57 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5A572E0079; Wed, 28 Jun 2006 23:39:55 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange References: <20060619220742.40B85222427@laser.networkresonance.com> Date: Wed, 28 Jun 2006 23:39:55 -0400 In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> (Eric Rescorla's message of "Mon, 19 Jun 2006 14:59:29 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] Re: [dix] Notes on Web authentication enhancements X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2006 03:39:58 -0000 Hi. First, I'd like to thank you for this excellent starting point for the discussion. I do have a few comments, but this is a great taxonomy. Requirements 2. Hijack-Resistant Authentication (HRA) An authentication system in which credentials which are bound to protocol messages in such a way that attacker who observes the credentials can't use them to authenticate messages of their choice. The rationale for this feature is to make cut-and-paste attacks difficult. I think this description and the subsequent discussion in transporting/binding credentials has some concepts I'd like to distinguish muddled together. Some schemes will provide integrity: a man in the middle can observe the conversation but cannot modify the content of the request or response. Some schemes will provide confidentiality even given the practical difficulties with server certificate validation. I argue in section 4.5 and 5 of version 01 of my phishing requirements draft that providing confidentiality of the resulting page is important even given these practical server certificate issues. So, I'd like to ask you to add that as a potential requirement I might want so I can ask for it. Also, let's be careful to distinguish this from HRA. You don't seem to have a requirement that corresponds to section 4.6 of 01 of my phishing requirements draft. This was one of the issues muddled into the confusing mutual authentication section in 00 of my draft. I contend that if there are a small number of RPs that by policy should be allowed to accept a given identity,there is a security benefit in restricting the identity to only those RPs. In particular, if a user successfully authenticates the user knows that because their identity was successfully accepted, they have authenticated to one of the valid RPs. I'd be happy to discuss specific customer deployments where this will be useful with you off-list. I understand based on your review of my 00 draft that you don't like this requirement. I still think it reasonable to discuss. TLS Client AUthentication Your taxonomy assumes that TLS is a valid approach to client authentication. As I understand HTTP, that is only true assuming there are no proxies between the user and the RP. We could extend HTTP to allow a proxy to assert authentication information it received via TLS to the next hop. It might be possible but would be more challenging to extend HTTP so that a client could give a proxy credentials to use for TLS client authentication outbound from that proxy. I think these issues are important to consider when comparing how credentials and authentication are transported. (Personally, I wish we could just ignore the whole issue of proxies. I don't think that will be acceptable to the market though.) Transporting and Binding Credentials An additional issue is hijacking: without cryptographic binding, an attacker who observes a request can make future requests in the name of the user via a cut-and-paste attack (remember, the token is bearer). If you take the threat of this type of attack seriously, you need to run the traffic over SSL/TLS. [1] [1] Note that if you're worried about this class of attack, you need *every* PDU to be cryptographically bound to the credential with all designs. If, for instance, you use cert-based auth but then transition to cookies over HTTP for state management, there's a cut-and-paste attack there. I think the primary paragraph is misleading. We've started from an assumption that there are practical problems that prevent server certificates from being validated. Given this assumption I don't understand how TLS actually gives us protection against the hijacking. I also think the footnote ignores an important deployment model. I may be concerned about whether I have reached the right RP while not concerned about network level hijacking. So I'm not at all convinced that you always need to protect every exchange if you are concerned about hijacking in some situations. Thanks again for your excellent work and for your consideration of my comments. --Sam Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 42E917F779 for ; Wed, 28 Jun 2006 15:59:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33FF71422C0 for ; Wed, 28 Jun 2006 15:59:46 -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 01513-06 for ; Wed, 28 Jun 2006 15:59:43 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1043C14228F for ; Wed, 28 Jun 2006 15:59:43 -0700 (PDT) Received: from [192.168.1.137] (adsl-75-20-217-131.dsl.pltn13.sbcglobal.net [75.20.217.131]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5SMxdHk097679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 28 Jun 2006 15:59:40 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: References: <20060619220742.40B85222427@laser.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Date: Wed, 28 Jun 2006 15:59:38 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.752.2) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 22:59:46 -0000 On 26-Jun-06, at 10:42 PM, Pete Resnick wrote: > I expect anyone who wants to propose a problem and/or solution to > be able to say how their proposal answers these questions: I'm willing to answer these questions from the DIX perspective... for both the problem as documented in draft-merrells-use-cases-xx and the proposed solution in the protocol and assertion drafts. I'd hope that others attending the BOF with a view to presenting their ideas would surface them on this (these) lists, answer these questions, and enter into any resulting conversations. > - What problem does this address that isn't addressed by a local > "keychain" or information database on the client? (For example, > possible answers include: "The problem of not having to change the > local user agent" and "The problem of portability".) What's the > downside if we don't solve those problems? From the DIX use-cases: We have as a goal 'ease of adoption'... from this flows a solution architecture that mandates no changes to the User Agent, and minimal changes to both the Relying Party and to the User's behaviour. All complexity is pushed back to onto the Identity Agent, which could be an IdP. The downside we believe is lower rates of adoption at a slower pace. Portability is covered by use-cases B12 and B15. Portability is important to a large class of users as they have multiple devices for accessing internet services. The downside of not addressing portability is that it's a barrier to adoption... if a solution has only one thing a potential user doesn't like they won't use it. Joel Spolsky makes the point aptly in his book 'Joel on Software' where he writes that the killer feature in Excel 4 that tipped the market in the favour was the the ability to _write_ lotus 123 files. The last objection to adoption has been removed. DIX use-cases A1 through A14 document scenarios for the acquisition and presentation of third-party attested assertions. From this flows requirements upon the solution for a protocol between the Identity Issuer (the authoritative source) and the Identity Agent. Maybe this goes beyond the scope of your question... but it's our opinion that that this is a problem and a solution would provide benefits to internet users. The downside... a missed opportunity to enable many useful services on the internet that exist in the real world today. But, this could be layered on top of an existing architecture at a later data. This was the approach we took when I published draft- merrells-dix-00, but without 'claims' the solution proposal appears to not offer enough value to some. By explicitly documenting the claims use-cases we aimed to sketch out a roadmap of functionality that could be built upon this digital-identity-exchange architecture. > - Does the mechanism use or extend currently deployed web > authentication mechanisms (client side and server side)? If not, > why not? For User Authentication the DIX drafts explicitly state that it as out of scope. It's not a problem that appears in the DIX use-cases. The DIX use-cases motivate requirements for moving around the result of an authentication event, rather than performing the authentication process itself. However, I'm glad that others are willing to document and address that issue though. For Server Authentication the DIX use-cases don't call that out as an issue, but draft-merrells-dix-xx drafts do include some functionality for providing the user with some assurance that they are dealing with whom they think they are. We allow the request and response messages to include references to signed logos. > - Is the client able to decide which identifying information goes > to the server? By 'client' I take it to mean 'user'. This is a fundamental requirement, as document in Kim's laws of identity. It's part of the problem and every solution to be adoptable must meet this requirement. DIX does. > - Does the mechanism involve 3rd parties for authentication or > identifying info? Does the 3rd party need to be trusted by the > relying party? For authentication - No not really, as the user is self asserting that they own an identifier and there's a verification mechanism to check that they do. The identifier, a URL, may be hosted, but I don't count that as a third party. The user's identity agent may be a website, or an enhanced browser, but I don't count that as a third party either. For 'identifying info', which I think means third-party attested attribute value assertions, then yes there is a third-party that is the authoritative source of that attribute and yes the relying-party has to trust that third-party to accept the assertion to be valid. > - Does the mechanism use a format for the information that has > widely available implementations? 'the information' is a bit ambiguous there, as in the question above it's 'identifying information', which to me means an 'identifier'. In DIX (dmd2) we state the identifier as being a URI and define a PersonaURL property that describes how to use a URL as an identifier. But I think you mean authentication and attribute assertions. Authentication Assertions in DIX are response messages containing an identifier property where the whole message has been signed using a 'lightweight' signing mechanism (HMAC). In dmd1 the message format was name-value pairs, in dmd2 it is a SAML message. The SAML message however mostly reuses the syntax of SAML and not much of the semantics... work would have to be done there to make the SAML message both look and behave as a SAML message in existing SAML profiles. Jeff/Scott have kicked out a draft that takes an existing SAML profile and extra-profiles it to use a 'lightweight' signing mechanism. (I haven't read it - but i think that's the gist of it). Attribute Assertions in DIX may be self-asserted or third-party- asserted. Self-asserted are name-value pairs... where the value is a UTF-8 string... to highly portable and you can impose any information model you want on that, so long as you can serialize it into a string. Third-party assertions are documented in draft-merrells- assertion-xx and is a profile of a SAML assertion. Lots of code out there to deal with those. But, there are many forms of claim that could be used. The problem is moving them about, not creating or consuming them.. > - Are you using a mechanism to authenticate the information that > has widely available implementations? See last para... basically SAML assertions for attributes. > I'll probably have more questions, but these are along these lines > of the ones you should be thinking about. Answers to these here on > the list will help me formulate agenda items. I'd encourage you, and everyone, to ask more general questions of the problem and solution proposers so that we can all learn as much about each other's positions before we meet up in Montreal next month. I hope that the BOF will be productive and that we'll leave there having identified the problem(s) and with a plan for how we tackle them. John Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 582F57F838 for ; Wed, 28 Jun 2006 08:30:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 48E251422DF for ; Wed, 28 Jun 2006 08:30:25 -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 17381-03 for ; Wed, 28 Jun 2006 08:30:22 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by laweleka.osafoundation.org (Postfix) with ESMTP id 768BD1422C2 for ; Wed, 28 Jun 2006 08:30:22 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id n15so1092698nfc for ; Wed, 28 Jun 2006 08:30:21 -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=URUMKz/VaKXDVS8Ub7eiMaw09lln5ickOsSAHajQXCCrAzFGBKckyi/T6WvV/m5yBR1gYFqC0GLNaaUcm/uGSktqiLcGNUgiQcVVWoNvh90nuusi44H5UEQ7V35iv1e2cNF+Ug1a+pSCcg0qY8XgiLi22+4SbxoN7MDMGVv9oGk= Received: by 10.48.161.1 with SMTP id j1mr603067nfe; Wed, 28 Jun 2006 08:30:21 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Wed, 28 Jun 2006 08:30:20 -0700 (PDT) Message-ID: <68fba5c50606280830p6bc3771u210731885ca4fb94@mail.gmail.com> Date: Wed, 28 Jun 2006 11:30:20 -0400 From: "Robert Sayre" To: "Eliot Lear" Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) In-Reply-To: <44A228D1.7050609@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> <44A228D1.7050609@cisco.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 15:30:25 -0000 On 6/28/06, Eliot Lear wrote: > > While I agree there may be some differences between application > protocols, it is the primary authentication method that must be shared. > Consider the case where some sort of authentication subsystem sits > outside each application. Sam Hartman asked that HMAC Digest[1] define a SASL mechanism for this reason. I assume the same reasoning applies here [2,3]. Alexey and I need to rev the draft to account for feedback from Yngve Pettersen, Joe Orton, and others. 1.) 2.) 3.) -- Robert Sayre Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 941ED7F88B for ; Tue, 27 Jun 2006 23:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 858F11422C5 for ; Tue, 27 Jun 2006 23:59:35 -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 11329-09 for ; Tue, 27 Jun 2006 23:59:34 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by laweleka.osafoundation.org (Postfix) with ESMTP id 18DF2142295 for ; Tue, 27 Jun 2006 23:59:34 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jun 2006 23:59:33 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5S6xXxH000805; Tue, 27 Jun 2006 23:59:33 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5S6xXke016852; Tue, 27 Jun 2006 23:59:33 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp79.cisco.com [10.61.64.79]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5S6sR3S031244; Tue, 27 Jun 2006 23:54:28 -0700 Message-ID: <44A228D1.7050609@cisco.com> Date: Wed, 28 Jun 2006 08:59:29 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: thayes0993@aol.com Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> In-Reply-To: <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=808; t=1151477973; x=1152341973; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Ietf-http-auth]=20Re=3A=20[dix]=20BOF=20plans=20(Was=3A=20Notes =20on=20Web=20authentication=0A=20enhancements); X=v=3Dcisco.com=3B=20h=3DDPTbt0l2spWdpQGnR8bjZ5e5oG0=3D; b=v2dtMM3QqUrWrDTUH1tlHc0vHztTRvZjTdwny2FTd8ACC/I4GFiPvaZYNvk3I/q+VDaVKs4M qUDKyHnOl07Wj5fD3RR1I/8VRkg8lx79ik0S5TE7O2famgGmC6nBdx0g; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 06:59:35 -0000 Hi, > I doubt it will be possible to use exactly the same methods for HTTP, > XMPP, SMTP and IMAP. The latter three (XMPP, SMTP and IMAP) are > session based, and might require authentication/authorization only > once during a session. HTTP is stateless (at least in general), so > some thought needs to be given to extending the auth across multiple > requests. While I agree there may be some differences between application protocols, it is the primary authentication method that must be shared. Consider the case where some sort of authentication subsystem sits outside each application. So long as the API for that can be shared, we're probably good. If HTTP requires a method to retain state across connections that is HTTP's business. I would not link the two together. Eliot Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 315417F801 for ; Tue, 27 Jun 2006 12:15:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D0E761422F0 for ; Tue, 27 Jun 2006 12:15:04 -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 01674-10 for ; Tue, 27 Jun 2006 12:14:59 -0700 (PDT) Received: from imo-m22.mail.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0AAB11422EA for ; Tue, 27 Jun 2006 12:14:58 -0700 (PDT) Received: from THayes0993@aol.com by imo-m22.mx.aol.com (mail_out_v38_r7.5.) id c.534.184b222 (60479); Tue, 27 Jun 2006 15:14:51 -0400 (EDT) Received: from FWM-R33 (fwm-r33.webmail.aol.com [152.163.181.137]) by ciaaol-m04.mx.aol.com (v109.13) with ESMTP id MAILCIAAOLM044-ec3f44a183aa36c; Tue, 27 Jun 2006 15:14:51 -0400 Date: Tue, 27 Jun 2006 15:14:51 -0400 Message-Id: <8C868351930B201-1384-5@FWM-R33.sysops.aol.com> From: thayes0993@aol.com References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> <44A16387.5040602@cisco.com> Received: from 10.169.155.114 by FWM-R33.sysops.aol.com (152.163.181.137) with HTTP (WebMailUI); Tue, 27 Jun 2006 15:14:50 -0400 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <44A16387.5040602@cisco.com> X-Mailer: AOL WebMail 18663 Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) Content-Type: multipart/alternative; boundary="--------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com" MIME-Version: 1.0 To: lear@cisco.com, dix@ietf.org X-AOL-IP: 152.163.181.137 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.3 tagged_above=-50.0 required=4.0 tests=AWL, HTML_20_30, HTML_MESSAGE, MSGID_FROM_MTA_HEADER, NO_REAL_NAME, URI_REDIRECTOR X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 19:15:05 -0000 ----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I doubt it will be possible to use exactly the same methods for HTTP, XMPP, SMTP and IMAP. The latter three (XMPP, SMTP and IMAP) are session based, and might require authentication/authorization only once during a session. HTTP is stateless (at least in general), so some thought needs to be given to extending the auth across multiple requests. A method for HTTP will need to consider potential performance issues, replay protection, and possible tie-in with other available session state (such as a TLS channel), among other things. The others can generally get away with a on-time verification step per session. It may be possible to share portions of the mechanism. In fact, TLS/SSL with client authentication supports all 4 protocols. However it seems to be rejected because of other issues: PKI lifecycles, physical portability of the key, trust management, etc. Terry Hayes AOL LLC -----Original Message----- From: lear@cisco.com To: dix@ietf.org Cc: ietf-http-auth@lists.osafoundation.org Sent: Tue, 27 Jun 2006 9:57 AM Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) Ben Laurie wrote: >> >> - Does the mechanism use or extend currently deployed web >> authentication mechanisms (client side and server side)? If not, why >> not? > > No - because if you use web authentication, then it will not work for > protocols that are not HTTP based - XMPP and IMAP are obvious examples > that spring to mind. I'm not sure I'd go so far as No, but the mechanism or an analog must be easily ported to other application protocols such as XMPP, SMTP, or IMAP. I would think an existence proof of 2 (one being HTTP; the other being IMAP) would be a very useful thing for any WG. Eliot _______________________________________________ Ietf-http-auth mailing list Ietf-http-auth@osafoundation.org http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth ________________________________________________________________________ Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on demand. Always Free. ----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
I doubt it will be possible to use exactly the same methods for HTTP, XMPP, SMTP and IMAP.  The latter three (XMPP, SMTP and IMAP) are session based, and might require authentication/authorization only once during a session.   HTTP is stateless (at least in general), so some thought needs to be given to extending the auth across multiple requests.

A method for HTTP will need to consider potential performance issues, replay protection, and possible tie-in with other available session state (such as a TLS channel), among other things.  The others can generally get away with a on-time verification step per session.

It may be possible to share portions of the mechanism.  In fact, TLS/SSL with client authentication supports all 4 protocols.  However it seems to be rejected because of other issues: PKI lifecycles, physical portability of the key, trust management, etc.

Terry Hayes
AOL LLC
 
-----Original Message-----
From: lear@cisco.com
To: dix@ietf.org
Cc: ietf-http-auth@lists.osafoundation.org
Sent: Tue, 27 Jun 2006 9:57 AM
Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements)

Ben Laurie wrote:
>>
>> - Does the mechanism use or extend currently deployed web
>> authentication mechanisms (client side and server side)? If not, why
>> not?
>
> No - because if you use web authentication, then it will not work for
> protocols that are not HTTP based - XMPP and IMAP are obvious examples
> that spring to mind.

I'm not sure I'd go so far as No, but the mechanism or an analog must be
easily ported to other application protocols such as XMPP, SMTP, or
IMAP.  I would think an existence proof of 2 (one being HTTP; the other
being IMAP)  would be a very useful thing for any WG.

Eliot
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-auth@osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on demand. Always Free.
----------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com-- Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1E5857F7E7 for ; Tue, 27 Jun 2006 09:59:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 101ED1422DF for ; Tue, 27 Jun 2006 09:59:58 -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 25154-01 for ; Tue, 27 Jun 2006 09:59:56 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9AF4A1422DB for ; Tue, 27 Jun 2006 09:59:56 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 549801E8C1F; Tue, 27 Jun 2006 09:59:56 -0700 (PDT) To: Eliot Lear Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> <86d5cvafly.fsf@raman.networkresonance.com> <44A162F5.3000705@cisco.com> From: Eric Rescorla Date: Tue, 27 Jun 2006 09:59:56 -0700 In-Reply-To: <44A162F5.3000705@cisco.com> (Eliot Lear's message of "Tue, 27 Jun 2006 18:55:17 +0200") Message-ID: <86bqse5yb7.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:59:58 -0000 Eliot Lear writes: > In order for this replay to be effective the attacker would have had to > compromised the privacy of the exchange or one end of the > communication. Yeah, like if it weren't done over TLS. > A cookie approach is reasonable where this risk is > reasonable, and can be further mitigated through brief durations or one > time use depending on need. Do we need more? Well, I think the question is whether such settings are the only ones we're interested in. -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0917B7F7E4 for ; Tue, 27 Jun 2006 09:57:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EE0D81422DF for ; Tue, 27 Jun 2006 09:57:44 -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 24258-05 for ; Tue, 27 Jun 2006 09:57:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8E2CB1422DB for ; Tue, 27 Jun 2006 09:57:44 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 27 Jun 2006 09:57:44 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="1833447151:sNHT186412068" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5RGvhv5025062; Tue, 27 Jun 2006 09:57:43 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RGvhke021919; Tue, 27 Jun 2006 09:57:43 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp206.cisco.com [10.61.64.206]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5RGqfZP012965; Tue, 27 Jun 2006 09:52:42 -0700 Message-ID: <44A16387.5040602@cisco.com> Date: Tue, 27 Jun 2006 18:57:43 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange References: <20060619220742.40B85222427@laser.networkresonance.com> <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> In-Reply-To: <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=623; t=1151427464; x=1152291464; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20BOF=20plans=20(Was=3A=20Notes=20on=20Web=20authenticatio n=20enhancements); X=v=3Dcisco.com=3B=20h=3Dujkd5C8n9KP6zdKgdyWezb2l88Y=3D; b=klTHAyGsUOu7AiVZtX6Uc37vP4E3U1xJJVNOOcuNyjJEOSHcKmzYU7GjyX+lKnSP8nJlv7wH wJHWYfe8DbSyGlQxR42pAbhLssZ1iKqGmau0VoTPCvfqKnYbnXLqbRMK; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org Subject: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:57:45 -0000 Ben Laurie wrote: >> >> - Does the mechanism use or extend currently deployed web >> authentication mechanisms (client side and server side)? If not, why >> not? > > No - because if you use web authentication, then it will not work for > protocols that are not HTTP based - XMPP and IMAP are obvious examples > that spring to mind. I'm not sure I'd go so far as No, but the mechanism or an analog must be easily ported to other application protocols such as XMPP, SMTP, or IMAP. I would think an existence proof of 2 (one being HTTP; the other being IMAP) would be a very useful thing for any WG. Eliot Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 766147F5F0 for ; Tue, 27 Jun 2006 09:55:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 67BFF1422DF for ; Tue, 27 Jun 2006 09:55:22 -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 24258-02 for ; Tue, 27 Jun 2006 09:55:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by laweleka.osafoundation.org (Postfix) with ESMTP id CF14C1422DB for ; Tue, 27 Jun 2006 09:55:19 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Jun 2006 09:55:19 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="301738446:sNHT32358620" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5RGtJnX021893; Tue, 27 Jun 2006 09:55:19 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k5RGtJke019586; Tue, 27 Jun 2006 09:55:19 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp206.cisco.com [10.61.64.206]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5RGoF9Q012919; Tue, 27 Jun 2006 09:50:16 -0700 Message-ID: <44A162F5.3000705@cisco.com> Date: Tue, 27 Jun 2006 18:55:17 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: EKR , Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> <86d5cvafly.fsf@raman.networkresonance.com> In-Reply-To: <86d5cvafly.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1525; t=1151427319; x=1152291319; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Re=3A=20[Ietf-http-auth]=20Notes=20on=20Web=20authentica tion=20enhancements; X=v=3Dcisco.com=3B=20h=3D6fF7tacvwU7fjFDfz9mfyRkqrlE=3D; b=kBaiBwNxi9AUPIWxkweNVxk9fcdCC23dB+T/9ss3CM+Su0yEOjudNcee1+L08ZqYvXntnHey qu8QbGwto/e5mutg/oJgVcKJEasjz2H4+FlfeHlf3iJFTToIUMAQRlJi; X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:55:22 -0000 Eric, > So, let's take the diagram from my recent mail message: > > > User RP IdP > ---- -- --- > Sell me beer -> > <- Prove you're 21 > > IdP, help me! -> > <---------- Auth exchange -------------> > <- Credential > > Credential -> > <- OK > > > The IdP gives the User some credential that he gives the > RP. That's fine for the first request, but what happens when > the user wants to make a second request? You clearly don't > want to go back to the IdP every time. The classic solution > is for the server to give you some cookie: those cookies > can obviously be cut-and-pasted from one message to another. > Even if you make them single-time (evolve them every time) > there's a window between the cookie delivery (in the HTTP > response) and the next HTTP request. > > Another option is to bypass the cookie thing and just make > the Credential reusable, but this has the same problem... > > In order for this replay to be effective the attacker would have had to compromised the privacy of the exchange or one end of the communication. A cookie approach is reasonable where this risk is reasonable, and can be further mitigated through brief durations or one time use depending on need. Do we need more? Eliot Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7F2B47F7C4 for ; Tue, 27 Jun 2006 09:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 707011422DF for ; Tue, 27 Jun 2006 09:23:47 -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 20482-06 for ; Tue, 27 Jun 2006 09:23:45 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.205]) by laweleka.osafoundation.org (Postfix) with ESMTP id CE3F91422C2 for ; Tue, 27 Jun 2006 09:23:45 -0700 (PDT) Received: by nz-out-0102.google.com with SMTP id l8so847719nzf for ; Tue, 27 Jun 2006 09:23:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VB/FL0vw1CyhRvbJPdmiHcs0Br7tkxdAi4bLJfgBLNiji5l39yegy3UbWZbmMbNBQKg7wPBd+kYSgqi3we9OAxophsXQBybaABaQzLxyacRQAYokLwa6WiU+AQYPuhqG3OzBlbeuFP5psuot1sMAL1SCnDNsQoY083d8iJ/VYNY= Received: by 10.65.215.8 with SMTP id s8mr4922445qbq; Tue, 27 Jun 2006 09:23:40 -0700 (PDT) Received: by 10.65.222.8 with HTTP; Tue, 27 Jun 2006 09:23:40 -0700 (PDT) Message-ID: Date: Tue, 27 Jun 2006 17:23:40 +0100 From: "Stephan Fowler" Sender: stephanfowler@gmail.com To: "Robert Sayre" Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements In-Reply-To: <68fba5c50606270804j1f327371kba8499f61f0e5e8c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> <68fba5c50606270804j1f327371kba8499f61f0e5e8c@mail.gmail.com> X-Google-Sender-Auth: 777f9183d2d47a2b X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 16:23:47 -0000 On 6/27/06, Robert Sayre wrote: > On 6/26/06, Stephan Fowler wrote: > > > > Notwithstanding Phil's point about protocol issues being out of scope, > > which is likely correct, I'll nevertheless mention a recent > > authentication protocol called HTTPsec: > > http://httpsec.org/protocol/1.0/ > > Interesting. But, I have a question. How does the client know to send > the Authorization: initialization header in the first request? Consider: (1) Reactive authentication: the server responds to a unauthenticated request with a "WWW-Authenticate: httpsec/1.0 challenge" header (kinda =E0 la Digest auth), invoking the client to retry with an initialization header. (2) Active authentication of server: Client sends the initialization because it has the policy of doing so for specific sites, and has prior notions of the public-keys that those sites must authenticate against. Imagine bookmarks that associate URLs with server public keys. On selection of such a bookmark, client would send an initialization bearing a "responder-auth" directive. (3) Active client authentication: Suppose bookmarks associate URLs with a *client* private key. On selection of such a bookmark, the client would sends an initialization bearing a "requester" directive containing a reference to its public key. Note that 1 is normative, whereas 2 and 3 are use-cases applicable when "client" means a browser (I say that because we initially developed this for server-to-server interactions, e.g. ReST, web services etc, which represent another set of use-cases). The bookmark thing is something we are experimenting with at the moment. Stephan Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 723307F766 for ; Tue, 27 Jun 2006 08:04:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 63CD11422A2 for ; Tue, 27 Jun 2006 08:04:32 -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 11051-01 for ; Tue, 27 Jun 2006 08:04:31 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9D6F014229D for ; Tue, 27 Jun 2006 08:04:30 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id n15so967747nfc for ; Tue, 27 Jun 2006 08:04:29 -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=Zr9/b3yVWF5dJv2luozoNZ1pR9qTNBTaYFoPid2td/VoLf8e82433WahnmzeNagYE8tllFAsAXOO1MwnnaSUmvw7vSZxJhBXaVejwM4bz/NhAGmb2CgVFyDAdebDciQkfr5HYspsF/G/YD+H3Lum9HEKA8c2PrGsnw6417Eo65s= Received: by 10.49.92.10 with SMTP id u10mr5693965nfl; Tue, 27 Jun 2006 08:04:29 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Tue, 27 Jun 2006 08:04:29 -0700 (PDT) Message-ID: <68fba5c50606270804j1f327371kba8499f61f0e5e8c@mail.gmail.com> Date: Tue, 27 Jun 2006 11:04:29 -0400 From: "Robert Sayre" To: "Stephan Fowler" Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 15:04:32 -0000 On 6/26/06, Stephan Fowler wrote: > > Notwithstanding Phil's point about protocol issues being out of scope, > which is likely correct, I'll nevertheless mention a recent > authentication protocol called HTTPsec: > http://httpsec.org/protocol/1.0/ Interesting. But, I have a question. How does the client know to send the Authorization: initialization header in the first request? http://httpsec.org/protocol/1.0/#Examples -- Robert Sayre Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E95587F78E for ; Tue, 27 Jun 2006 01:01:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id DB2021422E2 for ; Tue, 27 Jun 2006 01:01:48 -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 00595-09 for ; Tue, 27 Jun 2006 01:01:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4E4101422DF for ; Tue, 27 Jun 2006 01:01:47 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5R81jec030362; Tue, 27 Jun 2006 04:01:45 -0400 Received: from turnip.cambridge.redhat.com (turnip.cambridge.redhat.com [172.16.18.137]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k5R81iDx031831; Tue, 27 Jun 2006 04:01:44 -0400 Received: from turnip.cambridge.redhat.com (localhost.localdomain [127.0.0.1]) by turnip.cambridge.redhat.com (8.13.6/8.13.5) with ESMTP id k5R81hcE021615; Tue, 27 Jun 2006 09:01:43 +0100 Received: (from jorton@localhost) by turnip.cambridge.redhat.com (8.13.6/8.13.6/Submit) id k5R81gox021613; Tue, 27 Jun 2006 09:01:42 +0100 X-Authentication-Warning: turnip.cambridge.redhat.com: jorton set sender to jorton@redhat.com using -f Date: Tue, 27 Jun 2006 09:01:42 +0100 From: Joe Orton To: Eric Rescorla Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Message-ID: <20060627080142.GA21461@redhat.com> Mail-Followup-To: Eric Rescorla , Mark Nottingham , dix@ietf.org, ietf-http-auth@lists.osafoundation.org References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> <7AAA4939-903E-4A48-BDB3-A06CC476F299@yahoo-inc.com> <86u067agij.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <86u067agij.fsf@raman.networkresonance.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2006 08:01:49 -0000 On Mon, Jun 26, 2006 at 12:00:52PM -0700, Eric Rescorla wrote: > Mark Nottingham writes: > > > On 2006/06/23, at 3:29 PM, Eric Rescorla wrote: > >> Part of the problem is that the user and the software have > >> a different view of the RP's identity. The software knows that > >> C1tibank and Citibank are different, but the user does not. > > > > Fair enough. > > > > Would it be correct to say that HTTP Digest Auth has this property > > alreadly (because A2 includes the digest-uri-value)? There are other > > attacks that can be made against Digest, of course (e.g., dictionary > > against weak passwords), but it's interesting to think of it as > > having anti-phishing properties. > > I'm not 100% sure. IIRC, the digest-uri-value is only the > path portion, i.e., > > /example/example.html digest-uri-value just matches the Request-URI, so it depends on whether the client is using a proxy or not - HTTP/1.1 clients will typically use an absoluteURI in the Request-URI iff configured to use a proxy (and not tunnelling using CONNECT); otherwise they use the abs_path. joe Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 76FE27F85B for ; Mon, 26 Jun 2006 15:00:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 680C31422D0 for ; Mon, 26 Jun 2006 15:00: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 32142-01 for ; Mon, 26 Jun 2006 15:00:18 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C55621422C5 for ; Mon, 26 Jun 2006 15:00:18 -0700 (PDT) Received: from [192.168.6.116] (rover.sxip.com [192.168.6.116]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5QM0906014844 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 26 Jun 2006 15:00:09 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <86d5cvafly.fsf@raman.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> <86d5cvafly.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14371FAB-7358-4209-84DD-7F19EF91A4CF@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Mon, 26 Jun 2006 15:00:08 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 22:00:19 -0000 On 26-Jun-06, at 12:20 PM, Eric Rescorla wrote: > Dick Hardt writes: > >> On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote: >>>> >>>> In DIX, the RP includes a nonce in the request, which must then >>>> also >>>> be in the nonce which would prevent replay attacks assuming the >>>> RP is >>>> managing nonce state would it not? >>> >>> Only if each authentication token is only single-use. Otherwise, >>> an attacker can replay it during the validity period. Even then, >>> cut-and-paste attacks are still possible if you block the >>> initial request. >> >> My understanding of the definition of a nonce is that it is single- >> use. >> Would you humour me with an explanation of a cut-and-paste attack per >> above? > > So, let's take the diagram from my recent mail message: > > > User RP IdP > ---- -- --- > Sell me beer -> > <- Prove you're 21 > > IdP, help me! -> > <---------- Auth exchange -------------> > <- Credential > > Credential -> > <- OK > > > The IdP gives the User some credential that he gives the > RP. That's fine for the first request, but what happens when > the user wants to make a second request? You clearly don't > want to go back to the IdP every time. The classic solution > is for the server to give you some cookie: those cookies > can obviously be cut-and-pasted from one message to another. > Even if you make them single-time (evolve them every time) > there's a window between the cookie delivery (in the HTTP > response) and the next HTTP request. > > Another option is to bypass the cookie thing and just make > the Credential reusable, but this has the same problem... Thanks Eric. Very useful to understand. This seems to be a more general issue of securely managing state over HTTP would it not? -- Dick Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2C7007F8DF for ; Mon, 26 Jun 2006 14:03:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1E1AD1422C5 for ; Mon, 26 Jun 2006 14:03:04 -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 17242-08 for ; Mon, 26 Jun 2006 14:03:02 -0700 (PDT) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 841351422A8 for ; Mon, 26 Jun 2006 14:03:02 -0700 (PDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k5QL2xdQ007080; Mon, 26 Jun 2006 14:02:59 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 14:02:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-http-auth] Notes on Web authentication enhancements Date: Mon, 26 Jun 2006 14:02:58 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B56201@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-http-auth] Notes on Web authentication enhancements Thread-Index: AcaZWwOV5V8/rK+MSfuCriDTigl2/AACJWRg From: "Hallam-Baker, Phillip" To: "Mark Nottingham" , "EKR" X-OriginalArrivalTime: 26 Jun 2006 21:02:49.0467 (UTC) FILETIME=[E1BC64B0:01C69963] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 21:03:04 -0000 I have not read any of the patents on this for reasons that will be = familiar. If I was going to revisit Digest I would at the very least include an = ephemeral D-H key into the mix so that the digest value was at a minimum = secure against a brute force attack by a man in the middle. Has every avenue to that end been encumbered? > -----Original Message----- > From: ietf-http-auth-bounces@osafoundation.org=20 > [mailto:ietf-http-auth-bounces@osafoundation.org] On Behalf=20 > Of Mark Nottingham > Sent: Monday, June 26, 2006 3:58 PM > To: EKR > Cc: dix@ietf.org; ietf-http-auth@lists.osafoundation.org > Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements >=20 > You're right (unless I missed something else); >=20 > [2617] > > digest-uri =3D "uri" "=3D" digest-uri-value > > digest-uri-value =3D request-uri ; As specified by HTTP/1.1 >=20 > [2616] > > Request-URI =3D "*" | absoluteURI | abs_path | authority > ^^^^^^^^ A pity. > =09 >=20 > On 2006/06/26, at 12:00 PM, Eric Rescorla wrote: >=20 > > Mark Nottingham writes: > > > >> On 2006/06/23, at 3:29 PM, Eric Rescorla wrote: > >>> Part of the problem is that the user and the software have a=20 > >>> different view of the RP's identity. The software knows that=20 > >>> C1tibank and Citibank are different, but the user does not. > >> > >> Fair enough. > >> > >> Would it be correct to say that HTTP Digest Auth has this property=20 > >> alreadly (because A2 includes the digest-uri-value)? There=20 > are other=20 > >> attacks that can be made against Digest, of course (e.g.,=20 > dictionary=20 > >> against weak passwords), but it's interesting to think of it as=20 > >> having anti-phishing properties. > > > > I'm not 100% sure. IIRC, the digest-uri-value is only the path=20 > > portion, i.e., > > > > /example/example.html > > > > rather than > > > > http://www.example.com/example/example.html > > > > But I could totally be wrong on this. > > > > > > -Ekr > > > > >=20 > -- > Mark Nottingham > mnot@yahoo-inc.com >=20 >=20 >=20 > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth >=20 >=20 Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C54DC7F7B0 for ; Mon, 26 Jun 2006 12:59:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B59F11422C0 for ; Mon, 26 Jun 2006 12:59:25 -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 10169-08 for ; Mon, 26 Jun 2006 12:59:24 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6128D1422AE for ; Mon, 26 Jun 2006 12:59:24 -0700 (PDT) Received: from [172.21.37.137] (chancetrain-lm.corp.yahoo.com [172.21.37.137]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5QJvn3I030394; Mon, 26 Jun 2006 12:57:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=ifz4cWbIQsHZpuIevO+GqoP3ecLY53v3vjZHlpP5rVaHylxVumhJKIws/SLFwNVh In-Reply-To: <86u067agij.fsf@raman.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> <7AAA4939-903E-4A48-BDB3-A06CC476F299@yahoo-inc.com> <86u067agij.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Mon, 26 Jun 2006 12:57:49 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-15.5 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_WHOIS, USER_IN_DEF_WHITELIST X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:59:25 -0000 You're right (unless I missed something else); [2617] > digest-uri = "uri" "=" digest-uri-value > digest-uri-value = request-uri ; As specified by HTTP/1.1 [2616] > Request-URI = "*" | absoluteURI | abs_path | authority ^^^^^^^^ A pity. On 2006/06/26, at 12:00 PM, Eric Rescorla wrote: > Mark Nottingham writes: > >> On 2006/06/23, at 3:29 PM, Eric Rescorla wrote: >>> Part of the problem is that the user and the software have >>> a different view of the RP's identity. The software knows that >>> C1tibank and Citibank are different, but the user does not. >> >> Fair enough. >> >> Would it be correct to say that HTTP Digest Auth has this property >> alreadly (because A2 includes the digest-uri-value)? There are other >> attacks that can be made against Digest, of course (e.g., dictionary >> against weak passwords), but it's interesting to think of it as >> having anti-phishing properties. > > I'm not 100% sure. IIRC, the digest-uri-value is only the > path portion, i.e., > > /example/example.html > > rather than > > http://www.example.com/example/example.html > > But I could totally be wrong on this. > > > -Ekr > > -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4CBCD7F8BB for ; Mon, 26 Jun 2006 12:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3D3BC1422C2 for ; Mon, 26 Jun 2006 12:20:26 -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 03146-07 for ; Mon, 26 Jun 2006 12:20:25 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id B11101422AF for ; Mon, 26 Jun 2006 12:20:25 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7C86D1E8C1F; Mon, 26 Jun 2006 12:20:25 -0700 (PDT) To: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> From: Eric Rescorla Date: Mon, 26 Jun 2006 12:20:25 -0700 In-Reply-To: <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> (Dick Hardt's message of "Sat, 24 Jun 2006 07:57:14 -0700") Message-ID: <86d5cvafly.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:20:26 -0000 Dick Hardt writes: > On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote: >>> >>> In DIX, the RP includes a nonce in the request, which must then also >>> be in the nonce which would prevent replay attacks assuming the RP is >>> managing nonce state would it not? >> >> Only if each authentication token is only single-use. Otherwise, >> an attacker can replay it during the validity period. Even then, >> cut-and-paste attacks are still possible if you block the >> initial request. > > My understanding of the definition of a nonce is that it is single-use. > Would you humour me with an explanation of a cut-and-paste attack per > above? So, let's take the diagram from my recent mail message: User RP IdP ---- -- --- Sell me beer -> <- Prove you're 21 IdP, help me! -> <---------- Auth exchange -------------> <- Credential Credential -> <- OK The IdP gives the User some credential that he gives the RP. That's fine for the first request, but what happens when the user wants to make a second request? You clearly don't want to go back to the IdP every time. The classic solution is for the server to give you some cookie: those cookies can obviously be cut-and-pasted from one message to another. Even if you make them single-time (evolve them every time) there's a window between the cookie delivery (in the HTTP response) and the next HTTP request. Another option is to bypass the cookie thing and just make the Credential reusable, but this has the same problem... -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8C8C37F907 for ; Mon, 26 Jun 2006 12:00:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7EEB61422AF for ; Mon, 26 Jun 2006 12:00:54 -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 08019-03 for ; Mon, 26 Jun 2006 12:00:53 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0E6F61422AA for ; Mon, 26 Jun 2006 12:00:53 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 995601E8C1F; Mon, 26 Jun 2006 12:00:52 -0700 (PDT) To: Mark Nottingham Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> <7AAA4939-903E-4A48-BDB3-A06CC476F299@yahoo-inc.com> From: Eric Rescorla Date: Mon, 26 Jun 2006 12:00:52 -0700 In-Reply-To: <7AAA4939-903E-4A48-BDB3-A06CC476F299@yahoo-inc.com> (Mark Nottingham's message of "Mon, 26 Jun 2006 11:54:43 -0700") Message-ID: <86u067agij.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 19:00:54 -0000 Mark Nottingham writes: > On 2006/06/23, at 3:29 PM, Eric Rescorla wrote: >> Part of the problem is that the user and the software have >> a different view of the RP's identity. The software knows that >> C1tibank and Citibank are different, but the user does not. > > Fair enough. > > Would it be correct to say that HTTP Digest Auth has this property > alreadly (because A2 includes the digest-uri-value)? There are other > attacks that can be made against Digest, of course (e.g., dictionary > against weak passwords), but it's interesting to think of it as > having anti-phishing properties. I'm not 100% sure. IIRC, the digest-uri-value is only the path portion, i.e., /example/example.html rather than http://www.example.com/example/example.html But I could totally be wrong on this. -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2208E7F8FD for ; Mon, 26 Jun 2006 11:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 127B51422BC for ; Mon, 26 Jun 2006 11:55:06 -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 03012-07 for ; Mon, 26 Jun 2006 11:55:05 -0700 (PDT) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by laweleka.osafoundation.org (Postfix) with ESMTP id 58F9D1422A1 for ; Mon, 26 Jun 2006 11:55:05 -0700 (PDT) Received: from [172.21.37.137] (chancetrain-lm.corp.yahoo.com [172.21.37.137]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5QIsi5q091132; Mon, 26 Jun 2006 11:54:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=viWiZAhSweGYNaAbcEr2Q8e1ZaRANkOzSGip5N5g35/WqNd06qk2tvAgCk9Aoqq9 In-Reply-To: <86lkrnfqv3.fsf@raman.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7AAA4939-903E-4A48-BDB3-A06CC476F299@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Mon, 26 Jun 2006 11:54:43 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-15.6 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_WHOIS, USER_IN_DEF_WHITELIST X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 18:55:06 -0000 On 2006/06/23, at 3:29 PM, Eric Rescorla wrote: >>> 1. Capture-Resistant Credentials (CRC) >>> Credentials which are designed so that if you authenticate >>> to relying party (RP) X, X cannot use them to impersonate you to >>> RP Y >>> (even if your intention was to go to Y). Phishing is based >>> on the fact that passwords do not have this property. >>> The rationale for this feature is to make phishing-type >>> attacks difficult. >> >> This is a bit confusing; to me (disclaimer -- I'm just a layman, not >> a security expert), phishing is based on confusing the user about the >> RP's identity, not reusing credentials from RP X with RP Y. Of >> course, if you enable Common User Credentials, phishing will be >> possible in this manner. > > I see what you mean here, but let me try to explain what I'm > talking about and see if you still disagree with my taxonomy. > In a classic phishing attack, the attacker convinces you > to authenticate to them under the impression (in between > your ears) that you're authenticating to someone else. For > concreteness, say that the Phishing site is spoofing Citibank > and the Phishing site has domain name C1tibank. > > The reason this works is that the authentication token that > your software sends to C1tibank (your password) is the same > as the token it sends to Citibank. In systems where these > are separated (e.g., Boneh's PwdHash) then phishing attacks > don't work. You can capture an authentication token but > you can't re-use it to impersonate the user to the real RP. > > Part of the problem is that the user and the software have > a different view of the RP's identity. The software knows that > C1tibank and Citibank are different, but the user does not. Fair enough. Would it be correct to say that HTTP Digest Auth has this property alreadly (because A2 includes the digest-uri-value)? There are other attacks that can be made against Digest, of course (e.g., dictionary against weak passwords), but it's interesting to think of it as having anti-phishing properties. >> With that in mind, I wonder if this is much different from... >> >>> 2. Hijack-Resistant Authentication (HRA) >>> An authentication system in which credentials which are bound to >>> protocol messages in such a way that attacker who observes the >>> credentials can't use them to authenticate messages of their >>> choice. The rationale for this feature is to make cut-and-paste >>> attacks difficult. > > To take a concrete example here, PwdHash is susceptible to > hijacking attacks (do ordinary connection hijacking) if SSL/TLS > is not used but is not susceptible to straight phishing attacks. > So, I don't think these are different. Did you mean you *do*? >>> 11. Private Authentication (PA) >>> Some third-party authentication systems require an interaction >>> with the 3rd party for each authentication. In some such systems, >>> the 3rd party knows the relying party for each authentication >>> and the claims which were asserted. PA means that the 3rd party >>> does not get that information. The rationale for this feature >>> is to protect the user's privacy from the 3rd party. >> >> I *think* this is saying that there's a requirement to separate the >> identity from authentication, so that a 3rd party site doesn't learn >> any details about the user at all (e.g., userid, password, name, e- >> mail, etc.), but only is given the ability to act on their behalf in >> certain cases. >> >> Do I have that right, or is this something else? > > That's not what I had in mind, though it's another interesting > property. See also: http://www.w3.org/2005/Security/usability-ws/papers/32-dean- auth-for-web-services/ > What I meant was that the 3rd party doesn't find out > what sites you're visiting and what credentials you proved > to them; that way if Yahoo is my identity provider they > don't find out what kind of porn sites I visit. Ah, so it goes both ways... Thanks, -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 4DA3A7F88E for ; Mon, 26 Jun 2006 08:59:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3E9721422C5 for ; Mon, 26 Jun 2006 08:59:15 -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 07254-10 for ; Mon, 26 Jun 2006 08:59:13 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by laweleka.osafoundation.org (Postfix) with ESMTP id 770661422C2 for ; Mon, 26 Jun 2006 08:59:13 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id n15so837443nfc for ; Mon, 26 Jun 2006 08:59:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=T7ISKbigHAUMPi65DdZMzYtTCt0R7VdOQADk6BvuJGvmXEYp0jiKGc6qTNttI+bwmX9tBzdHygIVXbWQaRzHGkqiX8NRhKTTpI9IiQgk6/d5PbR4ia+gT67Li3R0ULSJWx4p/PAzXXNTrxpPFEhgBthBeroOHSfJHz7OZm/dJ0I= Received: by 10.49.58.3 with SMTP id l3mr4856791nfk; Mon, 26 Jun 2006 08:59:11 -0700 (PDT) Received: by 10.65.222.8 with HTTP; Mon, 26 Jun 2006 08:59:11 -0700 (PDT) Message-ID: Date: Mon, 26 Jun 2006 16:59:11 +0100 From: "Stephan Fowler" Sender: stephanfowler@gmail.com To: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> X-Google-Sender-Auth: 19c56708dfcf28f5 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=RCVD_BY_IP X-Spam-Level: X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 15:59:15 -0000 > BARE CRYPTOGRAPHIC IDENTIFIER > After username/password, probably the most familiar sort of > remote identifier is a bare public key. The way this is > used is familiar from SSH: the user generates a public key > and provides the key (or fingerprint) to the relying party > (or parties). He can then sign with the private key to > prove possession. > ... > > CRYPTOGRAPHIC BINDING INSIDE HTTP > If you're using public key for authentication, the natural approach is > to simply have the credentials bound directly to the HTTP PDUs they > vouch for. So, the PDU would contain a signature line that covered the > request itself. This is what, for example, S-HTTP does. Notwithstanding Phil's point about protocol issues being out of scope, which is likely correct, I'll nevertheless mention a recent authentication protocol called HTTPsec: http://httpsec.org/protocol/1.0/ This provides unilateral or mutual authentication using RSA public keys, or symmetric keys if pre-shared, applicable to arbitrary messages. It's somewhat "lighter" than S-HTTP; the latter encapsulates the entire message, whereas HTTPsec adds a single header containing a MAC, amongst other directives. Obviously, it requires extra code at client- and server-side. Stephan Fowler Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C11737F9D2 for ; Sat, 24 Jun 2006 09:28:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B296514230C for ; Sat, 24 Jun 2006 09:28:02 -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 11316-08 for ; Sat, 24 Jun 2006 09:28:00 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 429161422D8 for ; Sat, 24 Jun 2006 09:28:00 -0700 (PDT) Received: from [192.168.1.105] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5OGRtPh045014 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 24 Jun 2006 09:27:55 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <1b587cab0606240923sd7f435ds7fbf1aeecf2b304f@mail.google.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> <1b587cab0606240923sd7f435ds7fbf1aeecf2b304f@mail.google.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Sat, 24 Jun 2006 09:27:52 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 16:28:02 -0000 On 24-Jun-06, at 9:23 AM, Ben Laurie wrote: >> On a related note, the primary security threat I saw with DIX was how >> the user knows they are at their IdP. DIX considers that out of band >> as there does not need to be a standard way of doing it for DIX, each >> IdP could do it a different way, and given this is a place the user >> is visiting often whose purpose is to make sure the user knows they >> are at the IdP and the IdP to have certainty it is the user, the >> investment in stronger authN for both the user and the site is >> worthwhile. > > Isn't this essentially the primary security threat behind all > phishing? Agreed. My point is that it is much easier to solve it in one place then on all sites. The IdP can become a combination of client side and server side code to deal much more effectively with the phishing issue. It is unreasonable for every site to do that. -- Dick Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3C0C07F959 for ; Sat, 24 Jun 2006 09:23:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D4FA1422D8 for ; Sat, 24 Jun 2006 09:23:10 -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 19696-10 for ; Sat, 24 Jun 2006 09:23:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8C5541422CE for ; Sat, 24 Jun 2006 09:23:09 -0700 (PDT) Received: from chris.corp.google.com (chris.corp.google.com [172.24.0.146]) by smtp-out.google.com with ESMTP id k5OGN61f013870 for ; Sat, 24 Jun 2006 09:23:06 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=fOO3xDoxmX5wCRArE3Em/K+X3QD23Jnkr0LlpjL6VpKJwNC9d4x+2R/I8WhZplTrp 5oOCCox41cLBg9/vyGvzA== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by chris.corp.google.com with ESMTP id k5OGMbJ6031177 for ; Sat, 24 Jun 2006 09:23:02 -0700 Received: by smtp-out2.google.com with SMTP id 7so37292fpr for ; Sat, 24 Jun 2006 09:23:02 -0700 (PDT) Received: by 10.253.29.14 with SMTP id c14mr112390fpc; Sat, 24 Jun 2006 09:23:02 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Sat, 24 Jun 2006 09:23:02 -0700 (PDT) Message-ID: <1b587cab0606240923sd7f435ds7fbf1aeecf2b304f@mail.google.com> Date: Sat, 24 Jun 2006 17:23:02 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements In-Reply-To: <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.3 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Mailman-Approved-At: Mon, 26 Jun 2006 12:36:18 -0700 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 16:23:10 -0000 [re-adding missing lists] On 6/24/06, Dick Hardt wrote: > > On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote: > >> > >> In DIX, the RP includes a nonce in the request, which must then also > >> be in the nonce which would prevent replay attacks assuming the RP is > >> managing nonce state would it not? > > > > Only if each authentication token is only single-use. Otherwise, > > an attacker can replay it during the validity period. Even then, > > cut-and-paste attacks are still possible if you block the > > initial request. > > My understanding of the definition of a nonce is that it is single-use. > Would you humour me with an explanation of a cut-and-paste attack per > above? Ideally a nonce is single-use, but often people want to avoid keeping state on the server(s), so instead the nonce expires after a (short) time. For example, the nonce is a random number+a timestamp signed by the server. When it comes back, the server checks the signature and the timestamp. > >> I saw the security risk here being the reliance on DNS for identity > >> of the IdP in the verification step. > > > > Hmm.... I think this depends on the design. If you're using > > SSL/TLS, you should be able to block most attacks of this > > class, provided you have a CRA authentication method... > > Agreed. > > On a related note, the primary security threat I saw with DIX was how > the user knows they are at their IdP. DIX considers that out of band > as there does not need to be a standard way of doing it for DIX, each > IdP could do it a different way, and given this is a place the user > is visiting often whose purpose is to make sure the user knows they > are at the IdP and the IdP to have certainty it is the user, the > investment in stronger authN for both the user and the site is > worthwhile. Isn't this essentially the primary security threat behind all phishing? Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 01AF47F9CF for ; Sat, 24 Jun 2006 07:57:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E74E3142310 for ; Sat, 24 Jun 2006 07:57:25 -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 04663-07 for ; Sat, 24 Jun 2006 07:57:23 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 702111422D8 for ; Sat, 24 Jun 2006 07:57:23 -0700 (PDT) Received: from [192.168.1.102] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5OEvHfc043196 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 24 Jun 2006 07:57:17 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <868xnnfarh.fsf@raman.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> <868xnnfarh.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <528CC6D5-3549-438F-88AE-61D610B9D92F@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Sat, 24 Jun 2006 07:57:14 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 14:57:26 -0000 On 23-Jun-06, at 9:17 PM, Eric Rescorla wrote: >> >> In DIX, the RP includes a nonce in the request, which must then also >> be in the nonce which would prevent replay attacks assuming the RP is >> managing nonce state would it not? > > Only if each authentication token is only single-use. Otherwise, > an attacker can replay it during the validity period. Even then, > cut-and-paste attacks are still possible if you block the > initial request. My understanding of the definition of a nonce is that it is single-use. Would you humour me with an explanation of a cut-and-paste attack per above? >> I saw the security risk here being the reliance on DNS for identity >> of the IdP in the verification step. > > Hmm.... I think this depends on the design. If you're using > SSL/TLS, you should be able to block most attacks of this > class, provided you have a CRA authentication method... Agreed. On a related note, the primary security threat I saw with DIX was how the user knows they are at their IdP. DIX considers that out of band as there does not need to be a standard way of doing it for DIX, each IdP could do it a different way, and given this is a place the user is visiting often whose purpose is to make sure the user knows they are at the IdP and the IdP to have certainty it is the user, the investment in stronger authN for both the user and the site is worthwhile. -- Dick Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 667807F99A for ; Fri, 23 Jun 2006 21:17:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56AB91422D7 for ; Fri, 23 Jun 2006 21:17:07 -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 13089-08 for ; Fri, 23 Jun 2006 21:17:06 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id C25661422D2 for ; Fri, 23 Jun 2006 21:17:06 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7E2D71E8C1F; Fri, 23 Jun 2006 21:17:06 -0700 (PDT) To: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> From: Eric Rescorla Date: Fri, 23 Jun 2006 21:17:06 -0700 In-Reply-To: <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> (Dick Hardt's message of "Fri, 23 Jun 2006 19:14:58 -0700") Message-ID: <868xnnfarh.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 04:17:07 -0000 Dick Hardt writes: > On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote: > >> CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP >> One approach that comes up quite a bit is to just embed >> authentication tokens (typically generated by an IdP) in >> the HTTP messages that go from the user to the RP (DIX is >> an example of such a scheme). In this system, the tokens >> themselves are "bearer"--they enable any holder to impersonate >> the user. In order to protect against token capture, the tokens >> are generally made specific to the RP, so that one RP can't >> use them to impersonate the user to another. >> >> An additional issue is hijacking: without cryptographic >> binding, an attacker who observes a request can make future >> requests in the name of the user via a cut-and-paste attack >> (remember, the token is bearer). If you take the threat of >> this type of attack seriously, you need to run the traffic >> over SSL/TLS. [1] >> >> The primary attraction of this kind of design is that it >> may be implementable without changing the client software >> at all (again, see DIX). Many people see that as important >> for deployment. > > In DIX, the RP includes a nonce in the request, which must then also > be in the nonce which would prevent replay attacks assuming the RP is > managing nonce state would it not? Only if each authentication token is only single-use. Otherwise, an attacker can replay it during the validity period. Even then, cut-and-paste attacks are still possible if you block the initial request. > I saw the security risk here being the reliance on DNS for identity > of the IdP in the verification step. Hmm.... I think this depends on the design. If you're using SSL/TLS, you should be able to block most attacks of this class, provided you have a CRA authentication method... -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 2E6B97F988 for ; Fri, 23 Jun 2006 21:11:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F7D01422D7 for ; Fri, 23 Jun 2006 21:11:24 -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 08183-03 for ; Fri, 23 Jun 2006 21:11:21 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id B40DD1422D2 for ; Fri, 23 Jun 2006 21:11:21 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4D1B21E8C1F; Fri, 23 Jun 2006 21:11:21 -0700 (PDT) To: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Fri, 23 Jun 2006 21:11:21 -0700 In-Reply-To: (Dick Hardt's message of "Fri, 23 Jun 2006 18:51:26 -0700") Message-ID: <86fyhvfb12.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 04:11:24 -0000 Dick Hardt writes: >> Part of the problem is that the user and the software have >> a different view of the RP's identity. The software knows that >> C1tibank and Citibank are different, but the user does not. > > Minor clarification: I was at the recent Anti Phishing Working Group > meeting and many phishing attacks are gathering personal data in > addition to or instead of the user's password. Fair enough.... -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3E6217F99F for ; Fri, 23 Jun 2006 20:59:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2F71C1422D7 for ; Fri, 23 Jun 2006 20:59:56 -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 13089-04 for ; Fri, 23 Jun 2006 20:59:55 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A3CB314230B for ; Fri, 23 Jun 2006 20:59:55 -0700 (PDT) Received: from [192.168.1.102] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5O3xdDq027161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 23 Jun 2006 20:59:52 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EFA8C54-9BF9-41CA-ABD0-D6286601A5B1@sxip.com> Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Fri, 23 Jun 2006 19:14:58 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 03:59:56 -0000 On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote: > CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP > One approach that comes up quite a bit is to just embed > authentication tokens (typically generated by an IdP) in > the HTTP messages that go from the user to the RP (DIX is > an example of such a scheme). In this system, the tokens > themselves are "bearer"--they enable any holder to impersonate > the user. In order to protect against token capture, the tokens > are generally made specific to the RP, so that one RP can't > use them to impersonate the user to another. > > An additional issue is hijacking: without cryptographic > binding, an attacker who observes a request can make future > requests in the name of the user via a cut-and-paste attack > (remember, the token is bearer). If you take the threat of > this type of attack seriously, you need to run the traffic > over SSL/TLS. [1] > > The primary attraction of this kind of design is that it > may be implementable without changing the client software > at all (again, see DIX). Many people see that as important > for deployment. In DIX, the RP includes a nonce in the request, which must then also be in the nonce which would prevent replay attacks assuming the RP is managing nonce state would it not? I saw the security risk here being the reliance on DNS for identity of the IdP in the verification step. -- Dick Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A88947F99F for ; Fri, 23 Jun 2006 20:59:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 905DC142306 for ; Fri, 23 Jun 2006 20:59:55 -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 18891-01 for ; Fri, 23 Jun 2006 20:59:53 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B22431422FE for ; Fri, 23 Jun 2006 20:59:53 -0700 (PDT) Received: from [192.168.1.102] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5O3xdDp027161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 23 Jun 2006 20:59:51 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Fri, 23 Jun 2006 19:12:16 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 03:59:55 -0000 On 19-Jun-06, at 2:59 PM, Eric Rescorla wrote: > > 4. Fill-in of Personal Information (FPI) > One of the common complaints about Web form registration systems > is the need to repeatedly type in your user information. Think of this > as automatic form fill-in on steroids. The rationale for this > feature is to avoid repeated typing of this kind of information. Once there is a programatic method of moving the identity data, it could be much richer then what people would type into a form. Eg. my list of favorite books, movies. This week I met someone that wanted to move virtual model data so that the user could tell a clothing store their dimensions etc. This also leads into moving the identity data from a site that might generate to storage for later use. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 182D17F998 for ; Fri, 23 Jun 2006 20:59:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 08F801422FE for ; Fri, 23 Jun 2006 20:59:50 -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 17649-06 for ; Fri, 23 Jun 2006 20:59:49 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6C8B71422D7 for ; Fri, 23 Jun 2006 20:59:49 -0700 (PDT) Received: from [192.168.1.102] (d154-5-111-179.bchsia.telus.net [154.5.111.179]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5O3xdDl027161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 23 Jun 2006 20:59:45 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <86lkrnfqv3.fsf@raman.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> <86lkrnfqv3.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dick Hardt Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Fri, 23 Jun 2006 18:51:26 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2006 03:59:50 -0000 On 23-Jun-06, at 3:29 PM, Eric Rescorla wrote: >>> >>> 1. Capture-Resistant Credentials (CRC) >>> Credentials which are designed so that if you authenticate >>> to relying party (RP) X, X cannot use them to impersonate you to >>> RP Y >>> (even if your intention was to go to Y). Phishing is based >>> on the fact that passwords do not have this property. >>> The rationale for this feature is to make phishing-type >>> attacks difficult. >> >> This is a bit confusing; to me (disclaimer -- I'm just a layman, not >> a security expert), phishing is based on confusing the user about the >> RP's identity, not reusing credentials from RP X with RP Y. Of >> course, if you enable Common User Credentials, phishing will be >> possible in this manner. > > I see what you mean here, but let me try to explain what I'm > talking about and see if you still disagree with my taxonomy. > In a classic phishing attack, the attacker convinces you > to authenticate to them under the impression (in between > your ears) that you're authenticating to someone else. For > concreteness, say that the Phishing site is spoofing Citibank > and the Phishing site has domain name C1tibank. > > The reason this works is that the authentication token that > your software sends to C1tibank (your password) is the same > as the token it sends to Citibank. In systems where these > are separated (e.g., Boneh's PwdHash) then phishing attacks > don't work. You can capture an authentication token but > you can't re-use it to impersonate the user to the real RP. > > Part of the problem is that the user and the software have > a different view of the RP's identity. The software knows that > C1tibank and Citibank are different, but the user does not. Minor clarification: I was at the recent Anti Phishing Working Group meeting and many phishing attacks are gathering personal data in addition to or instead of the user's password. -- Dick Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D19BB7F979 for ; Fri, 23 Jun 2006 15:30:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id C2AF5142306 for ; Fri, 23 Jun 2006 15:30:07 -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 07831-05 for ; Fri, 23 Jun 2006 15:30:06 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1583B14230B for ; Fri, 23 Jun 2006 15:30:05 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id n15so569537nfc for ; Fri, 23 Jun 2006 15:30:04 -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=Fh2SxnRl6+QMFPNSha2X/ayUavTt6BKKCbTZOLVnaR30GQOcQH2hiBECqZzsY2NLWuSvwiISiw6RJr4pOquV3FWWG3hCRrHfJQph44h2lBJ+hGrhxrnPfckcNxgxtLp3e/Tg9aQAGWQ3jvweMz+n4ydal3xbUE+M59mcDnTY8NU= Received: by 10.49.34.19 with SMTP id m19mr2887987nfj; Fri, 23 Jun 2006 15:30:04 -0700 (PDT) Received: by 10.49.40.10 with HTTP; Fri, 23 Jun 2006 15:30:04 -0700 (PDT) Message-ID: <68fba5c50606231530l3a6b879didb0d421bcfb5bf3e@mail.gmail.com> Date: Fri, 23 Jun 2006 18:30:04 -0400 From: "Robert Sayre" To: "Mark Nottingham" Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements In-Reply-To: <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, RCVD_BY_IP X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:30:08 -0000 On 6/23/06, Mark Nottingham wrote: > > On 2006/06/19, at 2:59 PM, Eric Rescorla wrote: > >> 1. Capture-Resistant Credentials (CRC) > > This is a bit confusing; to me (disclaimer -- I'm just a layman, not a > security expert), phishing is based on confusing the user about the RP's > identity, not reusing credentials from RP X with RP Y. Of course, if you > enable Common User Credentials, phishing will be possible in this manner. > FWIW, I took this mean that the attacker is able to reuse your credentials on the site being impersonated. For example, Basic+TLS requests give up your plain text password to chase.com if you are tricked into sending them to evil-chase.com. -- Robert Sayre Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 752337F979 for ; Fri, 23 Jun 2006 15:29:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 65AF514230B for ; Fri, 23 Jun 2006 15:29:21 -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 27135-10 for ; Fri, 23 Jun 2006 15:29:20 -0700 (PDT) Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laweleka.osafoundation.org (Postfix) with ESMTP id 61DED142306 for ; Fri, 23 Jun 2006 15:29:20 -0700 (PDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0BE561E8C1F; Fri, 23 Jun 2006 15:29:20 -0700 (PDT) To: Mark Nottingham Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements References: <20060619220742.40B85222427@laser.networkresonance.com> <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> From: Eric Rescorla Date: Fri, 23 Jun 2006 15:29:20 -0700 In-Reply-To: <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> (Mark Nottingham's message of "Fri, 23 Jun 2006 15:12:48 -0700") Message-ID: <86lkrnfqv3.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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:29:21 -0000 Mark Nottingham writes: > Eric, > > This is excellent -- very helpful. I agree WRT the lack of a common > view of requirements. > > A few comments / questions below. > > On 2006/06/19, at 2:59 PM, Eric Rescorla wrote: >> >> 1. Capture-Resistant Credentials (CRC) >> Credentials which are designed so that if you authenticate >> to relying party (RP) X, X cannot use them to impersonate you to RP Y >> (even if your intention was to go to Y). Phishing is based >> on the fact that passwords do not have this property. >> The rationale for this feature is to make phishing-type >> attacks difficult. > > This is a bit confusing; to me (disclaimer -- I'm just a layman, not > a security expert), phishing is based on confusing the user about the > RP's identity, not reusing credentials from RP X with RP Y. Of > course, if you enable Common User Credentials, phishing will be > possible in this manner. I see what you mean here, but let me try to explain what I'm talking about and see if you still disagree with my taxonomy. In a classic phishing attack, the attacker convinces you to authenticate to them under the impression (in between your ears) that you're authenticating to someone else. For concreteness, say that the Phishing site is spoofing Citibank and the Phishing site has domain name C1tibank. The reason this works is that the authentication token that your software sends to C1tibank (your password) is the same as the token it sends to Citibank. In systems where these are separated (e.g., Boneh's PwdHash) then phishing attacks don't work. You can capture an authentication token but you can't re-use it to impersonate the user to the real RP. Part of the problem is that the user and the software have a different view of the RP's identity. The software knows that C1tibank and Citibank are different, but the user does not. > With that in mind, I wonder if this is much different from... > >> 2. Hijack-Resistant Authentication (HRA) >> An authentication system in which credentials which are bound to >> protocol messages in such a way that attacker who observes the >> credentials can't use them to authenticate messages of their >> choice. The rationale for this feature is to make cut-and-paste >> attacks difficult. To take a concrete example here, PwdHash is susceptible to hijacking attacks (do ordinary connection hijacking) if SSL/TLS is not used but is not susceptible to straight phishing attacks. So, I don't think these are different. > FWIW, I'd leave out most of the first sentence here; protocol binding > is more implementation detail than requirement. Fair enough, but I think it needs to be inverted to make the requirement clear. >> 7. User-Friendly Names (UFN) >> The ability to prove possession of some non-random-appearing >> name. The reason to separate this out is that one natural >> way to provide CI is simply to generate some random asymmetric >> key pair and use that (or its digest) as your identity. This >> name is not user friendly. Note that this is the first requirement >> in this list that appears to require a third party (to assign >> the names). The rationale for this feature is that random names >> are hard to remember. > > Well, it requires a third party if you're trying to co-ordinate names > across multiple domains (again, there's an i-built assumption that > there will be CUC). I think mostly true, though even in single-site systems, it's annoying to have to force unique names. >> 8. Assertion of External Claims (AEC) >> The ability to demonstrate some real-world fact about the user >> (e.g., I am a certain age, this is my address, etc.) to the >> RP. The rationale for this feature is that there are contexts >> in which the relying party needs to be able to establish this >> sort of information. >> >> 10. Independent Assertion of Claims (IAC) >> The ability to assert claims independently so that the user >> could (for instance) demonstrate their age to the RP without >> without revealing their address. The rationale for this >> feature is to protect the user's privacy. > > #10 is a sub-case of #8, no? Yes. >> 11. Private Authentication (PA) >> Some third-party authentication systems require an interaction >> with the 3rd party for each authentication. In some such systems, >> the 3rd party knows the relying party for each authentication >> and the claims which were asserted. PA means that the 3rd party >> does not get that information. The rationale for this feature >> is to protect the user's privacy from the 3rd party. > > I *think* this is saying that there's a requirement to separate the > identity from authentication, so that a 3rd party site doesn't learn > any details about the user at all (e.g., userid, password, name, e- > mail, etc.), but only is given the ability to act on their behalf in > certain cases. > > Do I have that right, or is this something else? That's not what I had in mind, though it's another interesting property. What I meant was that the 3rd party doesn't find out what sites you're visiting and what credentials you proved to them; that way if Yahoo is my identity provider they don't find out what kind of porn sites I visit. -Ekr Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id C22A57F932 for ; Fri, 23 Jun 2006 15:16:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id B235E14230B for ; Fri, 23 Jun 2006 15:16:17 -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 03573-05 for ; Fri, 23 Jun 2006 15:16:16 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by laweleka.osafoundation.org (Postfix) with ESMTP id DB9B0142306 for ; Fri, 23 Jun 2006 15:16:16 -0700 (PDT) Received: from [192.168.1.5] (snvvpn1-10-72-72-c183.corp.yahoo.com [10.72.72.183]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k5NMCnqu080727; Fri, 23 Jun 2006 15:12:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: from:subject:date:to:x-mailer; b=2yPKPlBIbekfF5ilel4yajBtk5TSe4I6Yme2zCBw+Y1uIfdk3pvhgHu97Ij9Uvvk In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/alternative; boundary=Apple-Mail-1-994876998 Message-Id: <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> From: Mark Nottingham Subject: Re: [Ietf-http-auth] Notes on Web authentication enhancements Date: Fri, 23 Jun 2006 15:12:48 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-15.6 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_WHOIS, HTML_30_40, HTML_MESSAGE, USER_IN_DEF_WHITELIST X-Spam-Level: Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 22:16:17 -0000 --Apple-Mail-1-994876998 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Eric, This is excellent -- very helpful. I agree WRT the lack of a common view of requirements. A few comments / questions below. On 2006/06/19, at 2:59 PM, Eric Rescorla wrote: > > 1. Capture-Resistant Credentials (CRC) > Credentials which are designed so that if you authenticate > to relying party (RP) X, X cannot use them to impersonate you to RP Y > (even if your intention was to go to Y). Phishing is based > on the fact that passwords do not have this property. > The rationale for this feature is to make phishing-type > attacks difficult. This is a bit confusing; to me (disclaimer -- I'm just a layman, not a security expert), phishing is based on confusing the user about the RP's identity, not reusing credentials from RP X with RP Y. Of course, if you enable Common User Credentials, phishing will be possible in this manner. With that in mind, I wonder if this is much different from... > 2. Hijack-Resistant Authentication (HRA) > An authentication system in which credentials which are bound to > protocol messages in such a way that attacker who observes the > credentials can't use them to authenticate messages of their > choice. The rationale for this feature is to make cut-and-paste > attacks difficult. FWIW, I'd leave out most of the first sentence here; protocol binding is more implementation detail than requirement. > 7. User-Friendly Names (UFN) > The ability to prove possession of some non-random-appearing > name. The reason to separate this out is that one natural > way to provide CI is simply to generate some random asymmetric > key pair and use that (or its digest) as your identity. This > name is not user friendly. Note that this is the first requirement > in this list that appears to require a third party (to assign > the names). The rationale for this feature is that random names > are hard to remember. Well, it requires a third party if you're trying to co-ordinate names across multiple domains (again, there's an i-built assumption that there will be CUC). > 8. Assertion of External Claims (AEC) > The ability to demonstrate some real-world fact about the user > (e.g., I am a certain age, this is my address, etc.) to the > RP. The rationale for this feature is that there are contexts > in which the relying party needs to be able to establish this > sort of information. > > 10. Independent Assertion of Claims (IAC) > The ability to assert claims independently so that the user > could (for instance) demonstrate their age to the RP without > without revealing their address. The rationale for this > feature is to protect the user's privacy. #10 is a sub-case of #8, no? > 11. Private Authentication (PA) > Some third-party authentication systems require an interaction > with the 3rd party for each authentication. In some such systems, > the 3rd party knows the relying party for each authentication > and the claims which were asserted. PA means that the 3rd party > does not get that information. The rationale for this feature > is to protect the user's privacy from the 3rd party. I *think* this is saying that there's a requirement to separate the identity from authentication, so that a 3rd party site doesn't learn any details about the user at all (e.g., userid, password, name, e- mail, etc.), but only is given the ability to act on their behalf in certain cases. Do I have that right, or is this something else? Overall, that's quite an ambitious list, and I'm very curious to see how much any effort will attempt to bite off. One other thing; > CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP > One approach that comes up quite a bit is to just embed > authentication tokens (typically generated by an IdP) in > the HTTP messages that go from the user to the RP (DIX is > an example of such a scheme). In this system, the tokens > themselves are "bearer"--they enable any holder to impersonate > the user. In order to protect against token capture, the tokens > are generally made specific to the RP, so that one RP can't > use them to impersonate the user to another. > > An additional issue is hijacking: without cryptographic > binding, an attacker who observes a request can make future > requests in the name of the user via a cut-and-paste attack > (remember, the token is bearer). If you take the threat of > this type of attack seriously, you need to run the traffic > over SSL/TLS. [1] > > The primary attraction of this kind of design is that it > may be implementable without changing the client software > at all (again, see DIX). Many people see that as important > for deployment. It sounds like one interesting discussion would surround what people's tolerance for these attacks is, and ways to mitigate them. Cheers, -- Mark Nottingham mnot@yahoo-inc.com --Apple-Mail-1-994876998 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Eric,

This is excellent -- very = helpful. I agree WRT the lack of a common view of = requirements.

A= few comments / questions below.

On 2006/06/19, at = 2:59 PM, Eric Rescorla wrote:

1. Capture-Resistant = Credentials (CRC)
Credentials which are designed so that if = you authenticate
to relying party (RP) X, X cannot use them to = impersonate you to RP Y
(even if your intention was to go to = Y). Phishing is based
on the fact that passwords do not have = this property.
The rationale for this feature is to make = phishing-type
attacks difficult.

This is a bit confusing; to = me (disclaimer -- I'm just a layman, not a security expert), phishing is = based on confusing the user about the RP's identity, not reusing = credentials from RP X with RP Y. Of course, if you enable Common User = Credentials, phishing will be possible in this manner.

With that in mind, I wonder = if this is much different from...

2. Hijack-Resistant Authentication (HRA)
An = authentication system in which credentials which are bound = to
protocol messages in such a way that attacker who observes = the
credentials can't use them to authenticate messages of = their
choice. The rationale for this feature is to make = cut-and-paste
attacks difficult.

FWIW, I'd leave out most of = the first sentence here; protocol binding is more implementation detail = than requirement.

7. = User-Friendly Names (UFN)
The ability to prove possession of = some non-random-appearing
name. The reason to separate this = out is that one natural
way to provide CI is simply to = generate some random asymmetric
key pair and use that (or its = digest) as your identity. This
name is not user friendly. Note = that this is the first requirement
in this list that appears = to require a third party (to assign
the names). The rationale = for this feature is that random names
are hard to = remember.

Well, it requires a third = party if you're trying to co-ordinate names across multiple domains = (again, there's an i-built assumption that there will be = CUC).=A0

8. Assertion of = External Claims (AEC)
The ability to demonstrate some = real-world fact about the user
(e.g., I am a certain age, this = is my address, etc.) to the
RP. The rationale for this feature = is that there are contexts
in which the relying party needs to = be able to establish this
sort of = information.

10. Independent Assertion of = Claims (IAC)
The ability to assert claims independently so = that the user
could (for instance) demonstrate their age to = the RP without
without revealing their address. The rationale = for this
feature is to protect the user's = privacy.

#10 is a sub-case of #8, = no?

11. Private Authentication = (PA)
Some third-party authentication systems require an = interaction
with the 3rd party for each authentication. In = some such systems,
the 3rd party knows the relying party for = each authentication
and the claims which were asserted. PA = means that the 3rd party
does not get that information. The = rationale for this feature
is to protect the user's privacy = from the 3rd party.

I *think* this is saying = that there's a requirement to separate the identity from authentication, = so that a 3rd party site doesn't learn any details about the user at all = (e.g., userid, password, name, e-mail, etc.), but only is given the = ability to act on their behalf in certain cases.=A0

Do I have that right, or is = this something else?


Overall, that's quite an = ambitious list, and I'm very curious to see how much any effort will = attempt to bite off.

One other = thing;

CARRIED = NONCRYPTOGRAPHICALLY INSIDE HTTP
One approach that comes up = quite a bit is to just embed=A0
authentication tokens = (typically generated by an IdP) in
the HTTP messages that go = from the user to the RP (DIX is
an example of such a scheme). = In this system, the tokens
themselves are "bearer"--they = enable any holder to impersonate
the user. In order to protect = against token capture, the tokens
are generally made specific = to the RP, so that one RP can't
use them to impersonate the = user to another.=A0

An additional issue is = hijacking: without cryptographic=A0
binding, an attacker who = observes a request can make future
requests in the name of the = user via a cut-and-paste attack
(remember, the token is = bearer). If you take the threat of
this type of attack = seriously, you need to run the traffic
over SSL/TLS. = [1]=A0

The primary attraction of this kind of = design is that it
may be implementable without changing the = client software
at all (again, see DIX). Many people see that = as important
for deployment.=A0
It sounds like one interesting = discussion would surround what people's tolerance for these attacks is, = and ways to mitigate them.

Cheers,

=
--
Mark Nottingham=A0



= --Apple-Mail-1-994876998-- Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 8B94B7F795 for ; Wed, 21 Jun 2006 07:16:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6517B142295 for ; Wed, 21 Jun 2006 07:16:52 -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 22277-04 for ; Wed, 21 Jun 2006 07:16:50 -0700 (PDT) Received: from carter-zimmerman.mit.edu (STRATTON-THREE-SEVENTY-EIGHT.MIT.EDU [18.187.6.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F054A142285 for ; Wed, 21 Jun 2006 07:16:49 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E8CBCE0079; Wed, 21 Jun 2006 10:16:46 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [dix] RE: [Ietf-http-auth] Notes on Web authentication enhancements References: <198A730C2044DE4A96749D13E167AD37B55F08@MOU1WNEXMB04.vcorp.ad.vrsn.com> Date: Wed, 21 Jun 2006 10:16:46 -0400 In-Reply-To: <198A730C2044DE4A96749D13E167AD37B55F08@MOU1WNEXMB04.vcorp.ad.vrsn.com> (Phillip Hallam-Baker's message of "Tue, 20 Jun 2006 14:34:00 -0700") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests= X-Spam-Level: Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2006 14:16:52 -0000 Phil, I think I agree with the importance of having definitions. I find it amusing that I cannot understand what you mean by user interaction attacks and chrome attacks; I cannot tell what you would consider within those definitions and what you would consider outside those definitions. I also don't know where you consider the boundary for network layer issues; I may or may not agree with you that should be out of scope. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7969B7F8B8 for ; Tue, 20 Jun 2006 14:34:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54F79142298 for ; Tue, 20 Jun 2006 14:34:07 -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 30868-03 for ; Tue, 20 Jun 2006 14:34:06 -0700 (PDT) Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A6322142297 for ; Tue, 20 Jun 2006 14:34:06 -0700 (PDT) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k5KLY4pi010603; Tue, 20 Jun 2006 14:34:04 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jun 2006 14:33:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ietf-http-auth] Notes on Web authentication enhancements Date: Tue, 20 Jun 2006 14:34:00 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B55F08@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ietf-http-auth] Notes on Web authentication enhancements Thread-Index: AcaT66fVABlUV4dsQJeDVOPUcA/m0gAxLmzA From: "Hallam-Baker, Phillip" To: , X-OriginalArrivalTime: 20 Jun 2006 21:33:55.0052 (UTC) FILETIME=[3B3B92C0:01C694B1] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.4 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 21:34:07 -0000 I just sent this message to the W3C pre-WG mailing list. I think the = message is equally applicable here only any new group/groups should = either identify a different part of the problem to address or they = should coordinate with the W3C group so that the groups avoid going off = to hunt the same bear. When that happens the most likely outcome is the = groups end up shooting each other instead of the bear. I was at the TIPPI workshop yesterday which showed a similar tendency to = become defocused as people became confused about the question of what = problem was being addressed in a presentation. =20 Presenter shows plugin designed to explore the user interface issues: =20 "What about key loggers", "what about a man in the middle = attack", "no the real problem is the authentication credentials", "the = phishing criminals will just go into selling plots of land in the = Florida", and so on. =20 There are many problems here, when we are talking about digest = algorithms we have an established vocabulary of terms, SHA-1 is not = broken, it is subject to a compression collision attack but is still = secure against the second pre-image attack. So when we are talking about = S/MIME we say, no the SHA-1attacks do not compromise the use in that = protocol but they are a sign we should start the transition process.=20 =20 What we need is a simple taxonomy of four or five terms (5 =3D 7-2) that = we can use to refer to the various attacks. We choose to address one or = at most two of those terms in this group. Everything else is out of = scope. =20 Examples: =20 Platform Layer Attacks: OUT OF SCOPE =20 Keyboard loggers, mouse click and screen capture trojans are all = serious security issues.=20 =20 Building platforms resistant to those attacks are the sole = responsibility of Brian, Butler, Linus and Steve (surnames redacted for = their own protection). It makes no sense for a standards working group = to attempt to solve those problems. Preventing the circulation of = malware is going to be the responsibility of the ISPs hosting the bots.=20 =20 Network Layer Attacks: OUT OF SCOPE =20 We have several people in the group who are cryptographers = and/or network security protocol designers. There is a place to discuss = that work, this is not it. There is no shortage of forums that are = developing authentication &ct. protocols.=20 =20 Trust Infrastructure Attacks: OUT OF SCOPE =20 If we are going to stop phishing we are going to need a means of = making sure that the site representing itself as Contoso bank on the net = reall is the same corporation as the place where you opened the account = abd handed over the check. This infrastructure is necessary, complex and = I am currently sitting in the CA-Browser forum where we are discussing = that exact problem. =20 User Interaction Attacks: IN SCOPE =20 How does the browser communicate the security context to the = user? =20 Chrome Attacks: IN SCOPE =20 How does the browser ensure that the trusted path used to = communicate the security context is trustworthy? =20 The title of this group is not 'the lone group that is going to stop the = problem of phishing all by itself'.=20 We have retrod the well trodden paths plenty of times. We have to assume = that the groups that are dedicated to addressing those problems are = going to deliver controls that are effective at an acceptable level. =20 At the moment the groups working on those problems are all saying 'we = can stop the keylogger problem but what is the point if the social = engineering attack is still open'. =20 Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 251757F5C3 for ; Mon, 19 Jun 2006 14:59:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 017C81422AE for ; Mon, 19 Jun 2006 14:59:32 -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 27498-07 for ; Mon, 19 Jun 2006 14:59:30 -0700 (PDT) Received: from laser.networkresonance.com (laser.networkresonance.com [198.144.196.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id BCD9D1422AA for ; Mon, 19 Jun 2006 14:59:29 -0700 (PDT) Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 40B85222427; Mon, 19 Jun 2006 15:07:42 -0700 (PDT) To: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 19 Jun 2006 14:59:29 -0700 From: Eric Rescorla Message-Id: <20060619220742.40B85222427@laser.networkresonance.com> X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Subject: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 21:59:32 -0000 There's obviously a lot of interest in working on various enhancements to Web and Web Services applications. Unfortunately, after reading the various drafts and mailing list postings produced by the proponents of various technologies, I don't come away with the sense that people have a common view of what is needed. This message is a first cut at a taxonomy of requirements/features and technical options. BACKGROUND: THE CURRENT STATE OF HTTP AUTHENTICATION ---------------------------------------------------- HTTP has two native authentication mechanisms, Basic Authentication (passwords in the clear in an HTTP header) and Digest Authentication (a challenge-response handshake also in the HTTP header). Both mechanisms depend on the client proving the possession of a shared secret string (a password in all real cases) to the server. The server is unauthenticated. For a variety of reasons, including bad UI on the clients, nearly all real-world Web applications use neither mechanism but rather use an HTML form to prompt the user for his password. This password is then sent in the clear over the HTTP connection. The standard security advice for how to secure this data is to use HTTPS (HTTP over SSL/TLS) to encrypt the entire channel and use the server's certificate to authenticate the server. Practical difficulties with checking the certificate have led to phishing attacks, in which the attacker gathers the user's password and can then impersonate the user. An additional problem is that it's hard for Web Services apps (e.g., DAV) to use this kind of mechanism because HTML may not be involved and so if it works at all you end up resorting to screen-scraping. In principle, if you run HTTPS, you can leverage HTTPS's client authentication mechanisms (client certificates and "pre-shared keys") to authenticate the client, but in practice this is not done, probably due to UI reasons and lack of familiarity with the TLS mechanisms (this applies in particular to PSK). DESIRABLE FUNCTIONALITY ----------------------- As I mentioned above, a lot of different types of functionality have been discussed. In this section, I try to break these down into a set of somewhat independent functions, with the intention that we can end up saying that we want a system that provides function X and not Y. These all have sort of lame names that I thought of on the spot. 1. Capture-Resistant Credentials (CRC) Credentials which are designed so that if you authenticate to relying party (RP) X, X cannot use them to impersonate you to RP Y (even if your intention was to go to Y). Phishing is based on the fact that passwords do not have this property. The rationale for this feature is to make phishing-type attacks difficult. 2. Hijack-Resistant Authentication (HRA) An authentication system in which credentials which are bound to protocol messages in such a way that attacker who observes the credentials can't use them to authenticate messages of their choice. The rationale for this feature is to make cut-and-paste attacks difficult. 3. Portable Credentials (PC) The nice thing about passwords is that you can memorize your password and then use it anywhere. The rationale for this is to make it easy for people to use credentials on multiple computers. 4. Fill-in of Personal Information (FPI) One of the common complaints about Web form registration systems is the need to repeatedly type in your user information. Think of this as automatic form fill-in on steroids. The rationale for this feature is to avoid repeated typing of this kind of information. 5. Common User Credentials (CUC) One way to limit the damage from credential compromise is to have each RP use a separate credential and force the user to make them independent (e.g., a separate password for each RP.) This is inconvenient, of course. CUC means that at the number of separate credentials that the user handles is small (if not 1). The rationale for this feature is to minimize user attention and storage overhead. 6. Continuity of Identity (CI) The ability to prove to some RP that you are the same user as was involved in some other transaction. The rationale for this feature is to have a cheap form of personal "account" for systems like blog comments, message boards, etc. 7. User-Friendly Names (UFN) The ability to prove possession of some non-random-appearing name. The reason to separate this out is that one natural way to provide CI is simply to generate some random asymmetric key pair and use that (or its digest) as your identity. This name is not user friendly. Note that this is the first requirement in this list that appears to require a third party (to assign the names). The rationale for this feature is that random names are hard to remember. 8. Assertion of External Claims (AEC) The ability to demonstrate some real-world fact about the user (e.g., I am a certain age, this is my address, etc.) to the RP. The rationale for this feature is that there are contexts in which the relying party needs to be able to establish this sort of information. 10. Independent Assertion of Claims (IAC) The ability to assert claims independently so that the user could (for instance) demonstrate their age to the RP without without revealing their address. The rationale for this feature is to protect the user's privacy. 11. Private Authentication (PA) Some third-party authentication systems require an interaction with the 3rd party for each authentication. In some such systems, the 3rd party knows the relying party for each authentication and the claims which were asserted. PA means that the 3rd party does not get that information. The rationale for this feature is to protect the user's privacy from the 3rd party. ARCHITECTURAL CHOICES --------------------- In this section, we survey a number of potential architectural options. This list isn't exhaustive, but is just intended to give a flavor of the major available choices beyond the simple two-party username-password schemes we have now. Note that I use a lot of PKIX-type terminology below, but the concepts are generic and can be extended to something more SAML-oid or something-else-oid. BARE CRYPTOGRAPHIC IDENTIFIER After username/password, probably the most familiar sort of remote identifier is a bare public key. The way this is used is familiar from SSH: the user generates a public key and provides the key (or fingerprint) to the relying party (or parties). He can then sign with the private key to prove possession. User RP ---- -- [Personal Info], K_pub -> \ Registration <- OK / Phase Sign(K_priv, Something) -> \ Use <- Service / Phase In the Registration phase, the user provides his registration info to the relying party (site) along with the public key. The RP stores the data somewhere. In the Use phase the user signs something with his key to prove his identity. Properties: If properly embedded in a protocol (it's easy to get this wrong), this scheme can provide: CRC -- the RP only has K_pub HRA -- you can cryptographically bind the requests to the key CUC -- you can use the same K_pub, K_priv pair over and over CI -- you use the same identity every time even if nobody knows who you are. PA -- there's no third-party to know anything about the exchange With an automated form fillin scheme like that specified in DIX, you could also provide FPI. IDENTITY CERTIFICATES One of the major inconveniences in dealing with bare cryptographic identifiers is that that names look basically random: they're just public keys or hashes of public keys. This is a particular problem if two RPs want to communicate about a user through some human-based protocol, i.e., "Don't trust bob@example.com" The natural way to deal with this problem is to have certificate authorities which are responsible for sections of the namespace and can issue certificates with user-friendly names. These certificates can come in two flavors: 1. Real-world identity certificates. 2. Unique-identity certificates Real-world identity certificates are familiar from the HTTPS world: an SSL certificate from VeriSign is an assertion that the certificate holder is the actual owner/operator of a given domain. A unique-identity certificate is just a promise from a CA not to issue any other certificates with the same username. Either form of identity certificate allows you to have nice userfriendly names (or at least more userfriendly than random numbers). The protocol looks something like this: User CA ---- -- [Personal Info], K_pub -> \ Certificate <- OK / Issuance The user gets a certificate (possibly covering some personal info) from the CA. They can then use this certificate much in the same way they used a bare key, by registering with the RP and then getting service. User RP ---- -- [Personal Info], Cert -> \ Registration <- OK / Phase Sign(K_priv, Something) -> \ Use <- Service / Phase Note that some people also think of the mere possession of a credential, even if it has no underlying AEC semantics as worth something. I.e., this person registered *somewhere* and I know that about them. This makes sense in contexts like blog comment authentication where you are just trying to erect a minimal registration barrier. Properties: This scheme has most of the same properties as the bare cryptographic identifiers, but also has at minimum User Friendly Naming (UFN). In addition, if the certificates are real-world identity certificates, it provides a very limited form of AEC, namely "this person has the right to this e-mail address, domain name, etc." SIGNATURE + KEY SERVER Both bare cryptographic identifiers and identity certificates suffer from portability problems. The part of your identifier that you need available to you at authentication time is a fairly long random number that most people won't be willing to memorize. [0] The natural approach is to carry the data around on a token (USB key, PCMCIA card, etc.) but this seems unattractive to many. Another option is to use a SACRED-type server to store the key and then let the user fetch it at whatever computer they are at. SIP is also considering a similar technique for moving keys between handsets (see (draft-ietf-sip-certs) Properties: Same as underlying authentication scheme + Portable Credentials. ATTRIBUTE CERTIFICATES The clear problem with all the schemes mentioned so far is that they only provide very limited AEC, which a lot of people clearly want. The standard solution for combining AEC with public-key-based authentication systems is to use attribute certificates: certificates that assert a certain fact about the holder of key K, such as: "The person who holds key K is an American citizen." In PKIX these are often (always?) tied to some actual 3rd-party certificate but from an architectural perspective, they could be tied to a bare key. Attribute certificates can also be used to provide IAC: you have a bundle of attribute certs with one for each claim you wish to assert and you simply provide the relevant certs to the RP. The basic protocol looks like this: User CA ---- -- [Personal Info], K_pub -> \ Certificate <- AC1 (Over 21) > Issuance <- AC2 (US Citizen) / In the Certificate Issuance phase, the user proves to the CA the claims that he wants the CA to vouch for and the CA gives him ACs for those claims. User RP ---- -- Sell me beer -> \ <- Prove you're 21 \ Use Sign(K_priv, Something), AC -> / Phase <- Service / In the use phase, the RP indicates which claims he wants the user to demonstrate and the user provides the appropriate ACs and demonstrates that he has the corresponding key. Of course, for any attributes for which you have ACs, you also get some FPI for free as part of the authentication. Properties: CRC, HRA, FPI (Some), PC (if used with key server), CUC, CI, UFN, AEC, IAC, PA IDENTITY PROVIDERS A lot of the designs that people seem interested in involve Identity Providers (IdP). An IdP is a server that offers interactive identity claims. (One way to think of this is as a real-time CA). There are a bunch of different topologies, but the basic idea is as below: User IdP ---- --- [Personal Info], Auth Info -> \ Registration <- OK / Phase The user registers with the IdP and (optionally) proves the claims that he wishes the IdP to assert later. The user needs to establish some sort of authentication credential with the IdP so that he can authenticate later. This can be a password or a public key pair (as above). Later, when he wants to actually use his identity, we get an exchange like this: User RP IdP ---- -- --- Sell me beer -> <- Prove you're 21 IdP, help me! -> <---------- Auth exchange -------------> <- Credential Credential -> <- OK When the user requests service, the RP prompts them for their identity (or in the case above, to prove some claims). The User then contacts the IdP and proves their identity (authenticates as the person who previously registered) and gets a credential. He Then provides the credential to the RP, who provides the service. There are a lot of ways to implement this general architecture and they all have different properties. Properties: At minimum, IdP based schemes provide: PC -- you can contact the IdP from anywhere CUC -- you only need to authenticate to the IdP and then can leverage that to authenticate everywhere CI -- you use the same IdP acct over and over UFN -- the IdP can issue you some easy name If the IdP makes claims about you, then you can also have FPI, AEC and IAC. In general, because the IdP knows which claims you're asserting for a given RP, you do not get PA. There are, however, ways to provide this feature, but often the contrary is part of the design of the system. A lot of the variation in IdP schemes is the implementation of the authentication, both from the user to the IdP and from the IdP (and user) to the RP. There's too much variation to discuss here, but I'll cover a few high points. Authentication to the IdP: Part of the point of an IdP scheme is that you authenticate to the IdP in order to get your credentials. Obviously, this authentication can be done in a lot of ways. Some of them allow phishing, credential capture, etc. It's clearly desirable to couple an IdP scheme with some sort of auth scheme that provides CRC and probably HRA. Binding of credentials to requests: In an IdP scheme, the IdP provides some token to the user that is then provided to the RP. This token may or may not be cryptographically bound to the messages that the user is sending to the RP. If this is not done, then the user<->RP protocol is potentially susceptible to hijacking. Note that it's well understood how to design both of these protocols securely. However, it involves more changes to the current implementations of Web and WS protocols. TRANSPORTING/BINDING CREDENTIALS -------------------------------- The discussion above has focused primarily on dataflow, but from the perspective of implementation/deployment, how you transport and bind the credentials to the PDUs they're authenticating matters. Note that to some extent this is orthogonal to the type of authentication architecture you're using. You can, for instance, use public key signatures with multiple binding/transport mechanisms. There are three commonly proposed transport/binding methods: CRYPTOGRAPHIC BINDING INSIDE HTTP If you're using public key for authentication, the natural approach is to simply have the credentials bound directly to the HTTP PDUs they vouch for. So, the PDU would contain a signature line that covered the request itself. This is what, for example, S-HTTP does. In systems like this, additional credentials (ACs, SAML assertions, etc.) are just carried in the message and the whole thing is bound together with the signature. Something like this: POST / HTTP/1.0 X-Attribute-Cert: X-Signature: XXX Post arguments The signature is computed over the entire message and headers (except for the signature itself, of course), or part of it (hopefully enough to block cut-and-paste attacks). This kind of technique, if performed correctly, provides both CRC and HRA for the messages between the user and the RP. Similar techniques can be use with symmetric keys and MACs over the PDUs. In such schemes, if you're using an IdP, then you'll probably also have to carry around a ticket that gives the RP the symmetric key needed to verify the message. Implementing this kind of scheme would generally require a fair amount of modification to the browser and server at least to protect the messages. SSL/TLS CLIENT AUTHENTICATION Another approach is to do things at a layer below HTTP, typically using SSL/TLS client authentication. Currently, SSL/TLS supports client authentication using pre-shared keys and certificates (you can use self-signed certs as bare keys). draft-housley-tls-authz-extns defines how to carry X.509 ACs and SAML assertions inside of TLS, so these could be used as well. This technique automatically provides CRC and HRA. In principle, TLS clients and servers already support at least cert-based client auth. In practice, the UI on the client is so bad that you would almost certainly need to clean it up quite a bit in order to make this kind of system usable. CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP One approach that comes up quite a bit is to just embed authentication tokens (typically generated by an IdP) in the HTTP messages that go from the user to the RP (DIX is an example of such a scheme). In this system, the tokens themselves are "bearer"--they enable any holder to impersonate the user. In order to protect against token capture, the tokens are generally made specific to the RP, so that one RP can't use them to impersonate the user to another. An additional issue is hijacking: without cryptographic binding, an attacker who observes a request can make future requests in the name of the user via a cut-and-paste attack (remember, the token is bearer). If you take the threat of this type of attack seriously, you need to run the traffic over SSL/TLS. [1] The primary attraction of this kind of design is that it may be implementable without changing the client software at all (again, see DIX). Many people see that as important for deployment. -Ekr [0] You can use asymmetric key pairs generated from passwords, but even with the application of key stretching techniques, this makes a lot of people uncomfortable. [1] Note that if you're worried about this class of attack, you need *every* PDU to be cryptographically bound to the credential with all designs. If, for instance, you use cert-based auth but then transition to cookies over HTTP for state management, there's a cut-and-paste attack there. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B02BF7F734 for ; Mon, 19 Jun 2006 10:59:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BF9E1422B4 for ; Mon, 19 Jun 2006 10:59:31 -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 16635-07 for ; Mon, 19 Jun 2006 10:59:31 -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 D6C061422B3 for ; Mon, 19 Jun 2006 10:59:30 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BE7D8E0079; Mon, 19 Jun 2006 13:59:25 -0400 (EDT) From: Sam Hartman To: ietf-http-auth@lists.osafoundation.org Date: Mon, 19 Jun 2006 13:59:25 -0400 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.1 tagged_above=-50.0 required=4.0 tests=SARE_TOWRITE X-Spam-Level: Subject: [Ietf-http-auth] [Sam Hartman] [dix] An HTTP-based solution for digital identity X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2006 17:59:31 -0000 --=-=-= I think we're using the dix list to discuss stuff for the IETF 66 BOF at this point. --=-=-= 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; Mon, 19 Jun 2006 13:31:33 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from megatron.ietf.org (www1.ietf.org [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by suchdamage.org (Postfix) with ESMTP id 535551324F for ; Mon, 19 Jun 2006 13:31:33 -0400 (EDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNb1-0001zk-UA; Mon, 19 Jun 2006 13:31:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsNb1-0001yc-3v for dix@ietf.org; Mon, 19 Jun 2006 13:31:31 -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 1FsNaz-0008FU-Ri for dix@ietf.org; Mon, 19 Jun 2006 13:31:31 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E8F8BE0079; Mon, 19 Jun 2006 13:31:21 -0400 (EDT) From: Sam Hartman To: dix@ietf.org Date: Mon, 19 Jun 2006 13:31:21 -0400 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [dix] An HTTP-based solution for digital identity 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 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 Hi, folks. I said I was working on a draft describing use cases and a specific technical proposal. I have that draft done and it compliments my phishing requirements draft. I expect to update the phishing requirements draft based on several reviews I've received and based on what confuses people about it when I have explained it to them in person. I was intrigued by Phil Hallam-Baker's idea to separate HTTP authentication into two parts : one between a user and some authentication/identity service and one between the authentication service and the relying party. It is important to standardize the second protocol; while standard methods of authentication to a identity service would be desirable extensions offered by specific identity providers may be useful and can be supported. Phil suggested starting with something like http-digest. I started doing that mentally during the last IETF meeting. I found that I was reinventing a lot of the Kerberos ap-req exchange--the exchange used to authenticate to the server. I started thinking about reuse of deployed code and realized that it would probably be desirable to use existing code rather than inventing some new protocol. New protocols are often more complicated than they at first seem they need to be and I definitely think this would be on exception. So, I decided to put together a sketch of how you could just use Kerberos to meet these needs. I was shocked at how much of the infrastructure necessary to do this is already available in current web browsers. So, I decided to write up a proposal on how to realize some of the goals in this space using Kerberos and other related technologies. I also described the use cases I'm attempting to solve. My use cases are less ambitious than the DIX use cases; personally I think that is a good thing. I do believe that my proposal can be expanded to meet all the use cases that impinge on protocol interactions. My belief is that this should be done gradually. I'm sure someone out there is going to claim that Kerberos is a horrible fit for this and that it is too complicated. I encourage you to specify an alternative in at least as much detail as I have done so we can compare the complexity, functionality, reuse of technology and ease of deployment of proposals. While any comments are welcome, alternative proposals or explanations of how I got use cases wrong may make constructive discussion easier than comments of the form "this sucks." At some level, the DIX proposal is an alternative. However as I think more about this problem space, I'm coming to the conclusion that a redirect based approach is not really in conflict with a longer-term in-band approach. My approach will work better for webdav, caldav and other non-HTML-based approaches. I think my approach may provide a better user experience even for web pages once it is available. However the DIX proposal can be deployed with much less effort. If both proposals end up using SAML to express information about identity, they could be complimentary. I do have some serious questions about whether a redirect-based approach should be standardized. I'll ask those questions in another message. I'm also talking to people interested in deploying redirect-based approaches along with those who have done so, trying to get a more informed opinion. Any way, I'd like to draw your attention to draft-hartman-webauth-00.txt. Let the flames begin. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 187737F8B9 for ; Wed, 7 Jun 2006 14:34:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 098C314233B for ; Wed, 7 Jun 2006 14:34:02 -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 17872-07 for ; Wed, 7 Jun 2006 14:34:00 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 741EF142335 for ; Wed, 7 Jun 2006 14:34:00 -0700 (PDT) Received: from [192.168.6.116] (rover.sxip.com [192.168.6.116]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k57LXwdB030932 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Jun 2006 14:33:59 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <44874588.9040105@neustar.biz> References: <44874588.9040105@neustar.biz> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <8C8809DC-3A47-4941-9A89-7C343A193567@sxip.com> Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [Ietf-http-auth] TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal Information Date: Wed, 7 Jun 2006 14:33:57 -0700 To: Jeff Hodges X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.0 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: IETF HTTP Auth X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:34:02 -0000 Sounds interesting, unfortunate that it overlaps with the Berkman=20=20 conference in Harvard http://idmashup.com/wiki/Main_Page On 7-Jun-06, at 2:30 PM, Jeff Hodges wrote: > TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and=20=20 > Personal Information > June 7th, 2006 by JeffH > http://identitymeme.org/archives/2006/06/07/tippi-workshop-=20 > trustworthy-user-interfaces-for-passwords-and-personal-information/ > > Dan Boneh yesterday announced the open registration (free, as in=20=20 > beer) for the 2nd Annual TIPPI Workshop TIPPI/> at Stanford University. Looks like there is an interesting=20=20 > batch of papers to be presented, which have relevance to recent=20=20 > discussions on the IETF-HTTP-Auth@ mailing list (especially threads=20=20 > during May-2006, e.g. =93New draft on anti-phishing requirements=94,=20= =20 > =93BOF proposal=94, =93BOF Request: WARP - Web Authentication Resistant= =20=20 > to Phishing=94). > Technorati Tags: Security, UI, usability, user interface > > Posted in Identity, Security, User Interface, Events, Workshops > > > > _______________________________________________ > Ietf-http-auth mailing list > Ietf-http-auth@osafoundation.org > http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth > > Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 911527F8B2 for ; Wed, 7 Jun 2006 14:31:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 80EFB14233B for ; Wed, 7 Jun 2006 14:31:08 -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 17010-03 for ; Wed, 7 Jun 2006 14:31:05 -0700 (PDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 08542142335 for ; Wed, 7 Jun 2006 14:31:04 -0700 (PDT) Received: from [127.0.0.1] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k57LUxWS014181 for ; Wed, 7 Jun 2006 21:31:03 GMT Message-ID: <44874588.9040105@neustar.biz> Date: Wed, 07 Jun 2006 14:30:48 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: IETF HTTP Auth Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=1.1 tagged_above=-50.0 required=4.0 tests=AWL, DNS_FROM_RFC_POST X-Spam-Level: * Subject: [Ietf-http-auth] TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal Information X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2006 21:31:08 -0000 TIPPI Workshop: Trustworthy [User] Interfaces for Passwords and Personal = Information June 7th, 2006 by JeffH http://identitymeme.org/archives/2006/06/07/tippi-workshop-trustworthy-us= er-interfaces-for-passwords-and-personal-information/ Dan Boneh yesterday announced the open registration (free, as in beer) fo= r the=20 2nd Annual TIPPI Workshop at Stanford= =20 University. Looks like there is an interesting batch of papers to be pres= ented,=20 which have relevance to recent discussions on the IETF-HTTP-Auth@ mailing= list=20 (especially threads during May-2006, e.g. =93New draft on anti-phishing=20 requirements=94, =93BOF proposal=94, =93BOF Request: WARP - Web Authentic= ation=20 Resistant to Phishing=94). Technorati Tags: Security, UI, usability, user interface Posted in Identity, Security, User Interface, Events, Workshops Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D3BC7F903 for ; Fri, 2 Jun 2006 13:52:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2D7EF14229E for ; Fri, 2 Jun 2006 13:52:04 -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 21295-04 for ; Fri, 2 Jun 2006 13:52:01 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 6997A14229B for ; Fri, 2 Jun 2006 13:52:01 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52D1EE000C; Fri, 2 Jun 2006 16:51:51 -0400 (EDT) To: John Merrells Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> From: Sam Hartman Date: Fri, 02 Jun 2006 16:51:51 -0400 In-Reply-To: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> (John Merrells's message of "Fri, 2 Jun 2006 13:19:01 -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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 20:52:04 -0000 >>>>> "John" == John Merrells writes: John> I'm not sure if you're saying this but... DIX does not John> impose any specific number of identifiers on a user. They John> can have as many as they choose to have, from 0 to infinity. No, but dix does support transporting more than one claim and does support claims that are not identifiers. I don't view doing so as a requirement. >> but that can transition to more complex forms of identity >> claims in the future. You seem to want sets of identity claims >> today. John> I find the 'claim' term to be a bit ambiguous, so try to John> avoid it. I'm not sure how claims relate to identifiers in John> your comment above. I use the terms claim, identity, subject and relying party as they are used in the Laws of Identity paper. An identifier is a claim that is alegidly unique; email addresses are viewed by some as identifiers. Email addresses *are* the identifier within the namespace of amazon.com identifiers as an example. --Sam Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1F89C7F83D for ; Fri, 2 Jun 2006 13:19:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 11C6B14228F for ; Fri, 2 Jun 2006 13:19:12 -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 18329-04 for ; Fri, 2 Jun 2006 13:19:11 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5546914228D for ; Fri, 2 Jun 2006 13:19:11 -0700 (PDT) Received: from [192.168.1.101] (adsl-71-138-128-188.dsl.pltn13.pacbell.net [71.138.128.188]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k52KJ64Y045818 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 2 Jun 2006 13:19:07 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Fri, 2 Jun 2006 13:19:01 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 20:19:12 -0000 On 2-Jun-06, at 8:01 AM, Sam Hartman wrote: > I think we view the requirements somewhat differently or at least view > what requirements need to be solved when somewhat differently. Yes, that may well be the case. We're coming at this from a different angle than you. > I'm OK with a solution that supports situations where I have a single > alegidly unique identifier today I'm not sure if you're saying this but... DIX does not impose any specific number of identifiers on a user. They can have as many as they choose to have, from 0 to infinity. > but that can transition to more > complex forms of identity claims in the future. You seem to want sets > of identity claims today. I find the 'claim' term to be a bit ambiguous, so try to avoid it. I'm not sure how claims relate to identifiers in your comment above. The DIX protocol draft specifies how the an attribute value assertion can be moved between parties... and the assertion draft shows how those attribute value assertions could actually be third party attested attribute value assertions. The benefits are that websites that use common property names will get more data of better quality and users won't have to deal with tedious user registration forms.... And... if we can move around third party assertions (Beth>21) then we have a safer more productive internet. > I'm much more interested in reusing existing security technology and > am not interested in working on entirely new protocols. Well, we are too. Hence the reuse of SAML/HTML/HTTP/HMAC, etc. We're just bringing the bits together in such a way that the barrier to adoption (the really big problem) can be as low as possible. > (And I do see > this as a security problem which may also be a difference in how we > come at this.) Yes, we're coming at this from a slightly different angle... not that security isn't important, but we feel that we can provide real value with just enough security... and show a roadmap of how people can move up to more security when they need it. > I consider requirements related to binding things together at multiple > levels (4.4 in my draft) really critical to forward progress on > phishing. A lot of people disagree with me. One on one I have been > able to convince people that I'm right, but the text in the current > section 4.4 clearly does not stand on its own and needs significant > revision. I agree with you. > Finally, I think it critical that whatever solution we have here needs > to work both with non-web HTTP applications (atompub, caldav, webdav, > deltav) and with non-HTTP applications. I'd hate to see people pushed > towards HTTP as a substrate to get better identity management. I agree too. I think the DIX messages could be mapped onto other protocols, or pushed down into the stack. Our approach though has been to try to avoid changing any code and any user behaviour. Not easy. > Needless to say my vision of the solution space is different because I > view these requirements differently. Yes. > I am working on a specific solution proposal to demonstrate that what > I want to do can be accomplished with incremental changes to existing > technology. I'm looking forward to reading that. I hope you get buy in for solving the secure user authentication problem. John Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 90D7B7F999 for ; Fri, 2 Jun 2006 08:01:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B554142298 for ; Fri, 2 Jun 2006 08:01:43 -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 01981-06 for ; Fri, 2 Jun 2006 08:01:43 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id C3652142297 for ; Fri, 2 Jun 2006 08:01:42 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BA4C4E000C; Fri, 2 Jun 2006 11:01:33 -0400 (EDT) To: John Merrells Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: From: Sam Hartman Date: Fri, 02 Jun 2006 11:01:33 -0400 In-Reply-To: (John Merrells's message of "Thu, 1 Jun 2006 18:58:36 -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-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 15:01:43 -0000 Hi, John. Thanks for the new drafts. I especially look forward to the new use cases draft and will sit down to read that after finishing this reply. I do agree there is significant overlap; my interest in this area was more or less directly motivated by the DIX bof and evaluating SXIP, Infocard and other solutions for a talk I gave at a conference. I think we view the requirements somewhat differently or at least view what requirements need to be solved when somewhat differently. I'm OK with a solution that supports situations where I have a single alegidly unique identifier today but that can transition to more complex forms of identity claims in the future. You seem to want sets of identity claims today. I'm much more interested in reusing existing security technology and am not interested in working on entirely new protocols. (And I do see this as a security problem which may also be a difference in how we come at this.) I consider requirements related to binding things together at multiple levels (4.4 in my draft) really critical to forward progress on phishing. A lot of people disagree with me. One on one I have been able to convince people that I'm right, but the text in the current section 4.4 clearly does not stand on its own and needs significant revision. Finally, I think it critical that whatever solution we have here needs to work both with non-web HTTP applications (atompub, caldav, webdav, deltav) and with non-HTTP applications. I'd hate to see people pushed towards HTTP as a substrate to get better identity management. Needless to say my vision of the solution space is different because I view these requirements differently. I am working on a specific solution proposal to demonstrate that what I want to do can be accomplished with incremental changes to existing technology. --Sam Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D88557F99B for ; Thu, 1 Jun 2006 18:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CAE9D142260 for ; Thu, 1 Jun 2006 18:59:10 -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 22567-09 for ; Thu, 1 Jun 2006 18:59:06 -0700 (PDT) Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B80F614225C for ; Thu, 1 Jun 2006 18:59:06 -0700 (PDT) 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 k521x1LX019045 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 1 Jun 2006 18:59:01 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Thu, 1 Jun 2006 18:58:36 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.750) X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL X-Spam-Level: Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2006 01:59:11 -0000 Hello Sam, I read your webauth-phishing draft. I thought it explored the phishing problem space really well. Your BOF request below seems to go further in scope though and overlaps with what the DIX group have been working on. I'm going to work through your text calling out the bits where the scope of DIX and WARP appear to overlap. [A quick aside. I just published some updated DIX drafts today... Use Cases, Protocol, and Assertion. They're all available here: http://dixs.org/index.php/DIX_Protocol_Internet_Drafts] On 23-May-06, at 2:34 PM, Sam Hartman wrote: > 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. This is a good thing. With DIX we chose for the actual authentication of the user to be out of scope. We just focused on how the resultant authentication assertion would be moved from the Identity Provider to the Relying Party. (To use SAML terminology.) > The > first problem is that users must remember and maintain passwords > for each HTTP service they use. The way I'm reading this I think this goes beyond the scope of authenticating the user... perhaps towards identifying the user. In DIX we enable third-party authentication and identify the user with an identifier (a URI... typically a URL). > 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. Is this in the scope of the IETF though... to provide UI requirements... to be met by the W3C? > 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. In DIX we term this the Identity Agent, which can be a Website or an Application. What kinds of 'assertions about identity' do you mean? I'd assumed your identity provider would only be generating authentication assertions. In DIX we support both self asserted and third-party attribute value assertions. Note that that's not just from the Identity Provider, but from other Service Providers authoritative for some attribute of the user. And to what kinds of third parties? Thus far I'd assumed that the only parties involved were the User Agent and the Identity Provider. I think these are the 'HTTP services' above. Which in DIX is a Service Provider that consumes the attributes and assertions from the Identity Agent. Is this what you mean? This bit clearly overlaps with DIX. > 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. This sounds very much like DIX, and Identity 2.0 in general... but doesn't cover all of Kim's Laws of Identity. You could just reference that, but I'm concerned you're trying to take on the whole thing, rather than just tackling a more secure way of authenticating the user. > WARP needs to support mobile users, 'Mobile' equals 'cell phone' to me... a european thing perhaps. Maybe there's a better word, but I can't think of one. > including users that use > HTTP services from computers they have never used before. WARP > must not require per-service or per-identity-provider > configuration. I don't understand that statement. WARP can be deployed without changing any service or IdP code/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. That's all good. > It is > desirable that WARP be able to carry assertions about identity such > as Security Assertion Markup Language assertions. But, is this DIX again. What are the assertions about and where are the coming from and going to. I'm suspecting they're any assertion and they're coming from the IdP to the SP. DIX covers that with more flexibility... in that roles of the IdP are separated out. > 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 That's good. > and > protocol for the interaction between the identity provider and > website. I think this is DIX... > 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. I'm not sure how this will work in practice. I'd image the W3C would want to define their own UI/HTML requirements... but I'm sure they'd welcome input if the group generates some requirements as a side-effect of the work. > 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. I read this as WARP does 'authentication resistant to phishing', and I don't think that covers a protocol from the identity provider to the website. > * A proposed standard describing how an identity is registered with > an identity provider or website. What does that mean? Maybe I just need more detail. But why an 'or' in 'identity provider or website'... In DIX a User Identifier is either assigned by the Identity Agent, or the user delegates authentication of an existing URL to an Identity Agent. And a Service Provider has a range of options over whether the User needs to identify themselves or not. There are privacy benefits to the SP being able to offer a service without actually having to create an 'account'. > * A proposed standard describing how an identity associated with a > user is linked to an HTTP service's concept of an account. Sounds much like the 'or website' bit above. But again... DIX does this... and is set up so that you don't need to. In summary: I think there's lots of value in WARP for dealing with authentication of the user to the identity provider... but if you go beyond that from the identity provider to the website then you're coving the scope of DIX... which in-my-not-so-humble-opinion has thought through and dealt with all these issues already and more besides. I think that if the scope of the work can be tightened up and there are people interested in working on this that it'll be a great complement to the DIX work. John