From dix-bounces@ietf.org Thu Jun 01 15:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsXa-0007oR-Rl; Thu, 01 Jun 2006 15:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlsXZ-0007oH-QA for dix@ietf.org; Thu, 01 Jun 2006 15:09:05 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlsXX-0006Z5-FT for dix@ietf.org; Thu, 01 Jun 2006 15:09:05 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k51J912r009234 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 1 Jun 2006 12:09:01 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Thu, 1 Jun 2006 12:08:56 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [dix] draft-merrells-dix-02.txt X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hello, We've been busy working away in the background reworking the protocol draft. As a result of the feedback at the IETF 65 DIX BOF we have recast much of the DIX protocol as SAML messages, assertions, and profiles. As ever we'd welcome your feedback on this draft. John Changelog Highlights Request and Response messages now encoded as SAML messages. Replaced DIX URIs with URNs. Renamed Membersite as Service Provider. Renamed Homesite as Identity Agent. Renamed Capability to Service. ID http://dixs.org/index.php/Draft-merrells-dix-02.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 01 16:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fltg1-0005Wl-2I; Thu, 01 Jun 2006 16:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fltfz-0005Jz-QU for dix@ietf.org; Thu, 01 Jun 2006 16:21:51 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fltfx-0005FZ-Cg for dix@ietf.org; Thu, 01 Jun 2006 16:21:51 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k51KLlwt010811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 1 Jun 2006 13:21:47 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <8F34AB22-FBA7-4FCC-986E-C7881CECCE60@sxip.com> References: <8F34AB22-FBA7-4FCC-986E-C7881CECCE60@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-use-cases-04.txt Date: Thu, 1 Jun 2006 13:21:42 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 31-May-06, at 8:49 PM, John Merrells wrote: > http://dixs.org/index.php/Draft-merrells-use-cases-04.txt That was a wiki html page. This is the ID as a .txt file. http://dixs.org/documents/draft-merrells-use-cases-04.txt This is the ID as a .html file. http://dixs.org/documents/draft-merrells-use-cases-04.html John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 01 16:22:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltgZ-0001FH-IG; Thu, 01 Jun 2006 16:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FltgX-00015y-HW for dix@ietf.org; Thu, 01 Jun 2006 16:22:25 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltgW-0005Hl-6i for dix@ietf.org; Thu, 01 Jun 2006 16:22:25 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k51KLlwu010811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 1 Jun 2006 13:22:21 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F464063-125D-4741-87BC-6A8B1BB483E4@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-assertion-00.txt Date: Thu, 1 Jun 2006 13:22:16 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 31-May-06, at 8:50 PM, John Merrells wrote: > http://dixs.org/index.php/Draft-merrells-dix-assertion-00.txt That was a wiki html page. This is the ID as a .txt file. http://dixs.org/documents/draft-merrells-dix-assertion-00.txt This is the ID as a .html file. http://dixs.org/documents/draft-merrells-dix-assertion-00.html John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 01 16:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flth3-000310-RS; Thu, 01 Jun 2006 16:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flth3-0002yP-2a for dix@ietf.org; Thu, 01 Jun 2006 16:22:57 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flth1-0005Id-NJ for dix@ietf.org; Thu, 01 Jun 2006 16:22:57 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k51KLlwv010811 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 1 Jun 2006 13:22:54 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Thu, 1 Jun 2006 13:22:49 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 1-Jun-06, at 12:08 PM, John Merrells wrote: > http://dixs.org/index.php/Draft-merrells-dix-02.txt That was a wiki html page. This is the ID as a .txt file. http://dixs.org/documents/draft-merrells-dix-02.txt This is the ID as a .html file. http://dixs.org/documents/draft-merrells-dix-02.html John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 01 21:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlywO-0006nq-FV; Thu, 01 Jun 2006 21:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlywM-0006nl-5r for dix@ietf.org; Thu, 01 Jun 2006 21:59:06 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlywK-0001n1-JG for dix@ietf.org; Thu, 01 Jun 2006 21:59:06 -0400 Received: from [192.168.1.101] (adsl-75-17-62-198.dsl.pltn13.sbcglobal.net [75.17.62.198]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id 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 Date: Thu, 1 Jun 2006 18:58:36 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hello 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 11:01:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmB9j-0001Ne-7w; Fri, 02 Jun 2006 11:01:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmB9h-0001NU-RR for dix@ietf.org; Fri, 02 Jun 2006 11:01:41 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmB9g-0006OQ-Ip for dix@ietf.org; Fri, 02 Jun 2006 11:01:41 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BA4C4E000C; Fri, 2 Jun 2006 11:01:33 -0400 (EDT) To: John Merrells 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-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 12:37:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCe4-0003kS-2q; Fri, 02 Jun 2006 12:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmCe2-0003j8-Bh for dix@ietf.org; Fri, 02 Jun 2006 12:37:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmCJD-0006jd-TK for dix@ietf.org; Fri, 02 Jun 2006 12:15:35 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmC4M-0006kw-0O for dix@ietf.org; Fri, 02 Jun 2006 12:00:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 6A419E000C; Fri, 2 Jun 2006 12:00:06 -0400 (EDT) To: dix@ietf.org From: Sam Hartman Date: Fri, 02 Jun 2006 12:00:06 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [dix] Comments on use cases draft X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi. As far as I can tell, the use cases draft does an excellent job of describing all the possible things that could work in this space. I think it is important to do a much better job of describing which use cases you actually see as important in the first version. I think that many of the use cases that involve communications between the identity agent and parties who identity claims have been given to in the past should be ruled out of scope a they hugely complicate the solution. I also think that it is unlikely that Beth will have a single identity agent. For example if Beth works for the NSA, I doubt they will let her use the same identity agent for her work persona as for her home persona. I think the implications of this for use cases need to be explored. I really like the draft though as it allows me to concretely understand what we're talking about here. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 15:41:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFWn-0004Aq-OV; Fri, 02 Jun 2006 15:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFWn-00047z-2M for dix@ietf.org; Fri, 02 Jun 2006 15:41:49 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFWk-0003Ee-Np for dix@ietf.org; Fri, 02 Jun 2006 15:41:49 -0400 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 k52JfiOq044769 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Jun 2006 12:41:45 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <6841E172-FD14-427D-ADC5-9646DC0DF9C2@sxip.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Digital Identity Exchange From: John Merrells Date: Fri, 2 Jun 2006 12:41:39 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [dix] draft-merrells-use-cases-02.txt X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I made a mistake with the draft numbering for the use cases. I forgot to publish -02 and -03 to the RFC editor... so I have had to rename the -04 draft as -02. Same content, different number and URLs. Sorry about that :( John wiki http://dixs.org/index.php/Draft-merrells-use-cases-02.txt .html http://dixs.org/documents/draft-merrells-use-cases-02.html .txt http://dixs.org/documents/draft-merrells-use-cases-02.txt _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 16:37:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGOG-0006GG-Bl; Fri, 02 Jun 2006 16:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGOF-0006Fp-QI for dix@ietf.org; Fri, 02 Jun 2006 16:37:03 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGOE-0002VZ-FM for dix@ietf.org; Fri, 02 Jun 2006 16:37:03 -0400 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 k52Kb0QE046294 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 2 Jun 2006 13:37:00 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Comments on use cases draft Date: Fri, 2 Jun 2006 13:36:54 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 2-Jun-06, at 9:00 AM, Sam Hartman wrote: > Hi. As far as I can tell, the use cases draft does an excellent job > of describing all the possible things that could work in this space. Thanks. > I think it is important to do a much better job of describing which > use cases you actually see as important in the first version. OK. I agree that's not clear. Perhaps the DIX protocol draft should reference which use cases it's trying to cover? > I think that many of the use cases that involve communications between > the identity agent and parties who identity claims have been given to > in the past should be ruled out of scope a they hugely complicate the > solution. Which use cases are those? There's only B14 I think? And, that's not about claims. > I also think that it is unlikely that Beth will have a single identity > agent. Doesn't B22 address this? The user should be able to have as many Identity Agents as they want... 0 to infinity.... If this is unclear then I need to fix this. > For example if Beth works for the NSA, I doubt they will let > her use the same identity agent for her work persona as for her home > persona. I think the implications of this for use cases need to be > explored. Or is this a case I've missed? > I really like the draft though as it allows me to concretely > understand what we're talking about here. Thank you! Your feedback is most welcome. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 16:52:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGcl-0006zS-28; Fri, 02 Jun 2006 16:52:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmGcj-0006wR-N0 for dix@ietf.org; Fri, 02 Jun 2006 16:52:01 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGci-00053v-EZ for dix@ietf.org; Fri, 02 Jun 2006 16:52:01 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 52D1EE000C; Fri, 2 Jun 2006 16:51:51 -0400 (EDT) To: John Merrells 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-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 02 18:06:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHn0-0000wY-Co; Fri, 02 Jun 2006 18:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmHmz-0000uu-01 for dix@ietf.org; Fri, 02 Jun 2006 18:06:41 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmHmx-0002VB-Pi for dix@ietf.org; Fri, 02 Jun 2006 18:06:40 -0400 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 k52M6d6v011879 for ; Fri, 2 Jun 2006 18:06:39 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k52M6c6d001799 for ; Fri, 2 Jun 2006 18:06:39 -0400 Received: from [172.16.25.166] (dhcp-172-16-25-166.sfbay.redhat.com [172.16.25.166]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k52M6b8w003353 for ; Fri, 2 Jun 2006 18:06:38 -0400 Message-ID: <4480B66D.8040109@redhat.com> Date: Fri, 02 Jun 2006 15:06:37 -0700 From: Pete Rowley User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0964861483==" Errors-To: dix-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0964861483== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030605020502090606080400" This is a cryptographically signed message in MIME format. --------------ms030605020502090606080400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sam Hartman wrote: >>>>>> "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. > It is a requirement if you require to support more than authN. Access to a site might require an "I am over 21" token, authZ without direct authN - DIX supports that, and I believe it is important to do so. -- Pete --------------ms030605020502090606080400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oX DTA2MTIxODAxMzE1M1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYScHJvd2xleUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAz5qzj9DVTZ6HS76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FW pszLXfKUgYnLBqgXXaSN7+Ve1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1 gLOjF6Yze9cHpio66W9orNdf1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55 j+Oj9+xGHeHK4lI96ljkWhTdgVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwup adY+BFiwBJRVMUTHlgSC99RJBgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQAB oy8wLTAdBgNVHREEFjAUgRJwcm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQQFAAOBgQCcnTFjF+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkz D3HLJYXu/9H1ltmXtDJMtOw/U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvks HDyJmWz1CvXmKzVHXnSaeK21vR/TKV3Z2Zu/7bXQGtRMmzCCAt4wggJHoAMCAQICEA20YTBn SYVXR4HA/CqysV4wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxODAxMzE1M1oXDTA2MTIxODAxMzE1M1owRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScHJvd2xl eUByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz5qzj9DVTZ6H S76A4N+wJR5kydgI+g5Z6CbdYyyeURgVLOxE2xUqtBusY9FWpszLXfKUgYnLBqgXXaSN7+Ve 1MAJUpKqnyb0YdDooAEb75UecqAvtWf5zaD9BnSM+1ju1lA1gLOjF6Yze9cHpio66W9orNdf 1ggO/cWejhpO++Vsx3mLETR6OdOUu3n9bo1XKaVnBvinPA55j+Oj9+xGHeHK4lI96ljkWhTd gVDXV85EkvuDQJWbGKn++uoZQXzKGiTwBiJADOL5drjPjwupadY+BFiwBJRVMUTHlgSC99RJ BgLuiaumrTW4EF83ABYAGkGpaXVK8RsC13OtL/WjIQIDAQABoy8wLTAdBgNVHREEFjAUgRJw cm93bGV5QHJlZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQCcnTFj F+go0tfTvhi8PpxmT72+9Dp0QKfGGzeiI0udie/WuatwXRkzD3HLJYXu/9H1ltmXtDJMtOw/ U5Roj1wGquA9EmCi+ZF3Z75kkFG6k5Yf2tBEQ3MVM38KYvksHDyJmWz1CvXmKzVHXnSaeK21 vR/TKV3Z2Zu/7bXQGtRMmzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQDbRhMGdJ hVdHgcD8KrKxXjAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wNjA2MDIyMjA2MzdaMCMGCSqGSIb3DQEJBDEWBBQLrdZyA3Kwvjzf qU8h5aGHlYiA6zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20 YTBnSYVXR4HA/CqysV4wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEA20YTBnSYVXR4HA/CqysV4wDQYJKoZIhvcN AQEBBQAEggEAFH23JToSQc4VX3uKLZYf/wPyU/T6xK8uVr/erWOUQ8T9ttUMpJxvC2Xt+3D7 pwC1KTbPrAr345B0ZBkiyexdsKInKhFY6g4kZYTUEIrt8TQeZ6J1IfkaSPkX1yQsXenN9nWx q8f1xJRNKKFjUcWWyuPuHFbv2StrOhSfPig/+uRRed4rRkvfJIMTxyWfagC6S7ZX1xmGKVIR EEeqGvbsx8X9mgqohfxWICtAmHhg4xmoai/cBnXbIS3Sc1cdqt8DWVZFWQ+fHVUz57lOCOBU oTrcvTaVj5gziNYVJ4PeHu6SrIj2hTORhUIJXTP0mgSEeFNpAcyRouXH+f7ViAHYywAAAAAA AA== --------------ms030605020502090606080400-- --===============0964861483== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0964861483==-- From dix-bounces@ietf.org Fri Jun 02 18:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI1Z-0005Ay-Bw; Fri, 02 Jun 2006 18:21:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmI1Y-00053h-8j for dix@ietf.org; Fri, 02 Jun 2006 18:21:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmGQi-0002dn-J1 for dix@ietf.org; Fri, 02 Jun 2006 16:39:36 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FmG6v-0002pE-Ov for dix@ietf.org; Fri, 02 Jun 2006 16:19:10 -0400 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 Date: Fri, 2 Jun 2006 13:19:01 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Ted Hardie , Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 18:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn0sD-0002Hm-KQ; Sun, 04 Jun 2006 18:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn0sC-0002Hh-NU for dix@ietf.org; Sun, 04 Jun 2006 18:15:04 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn0sB-00086K-F7 for dix@ietf.org; Sun, 04 Jun 2006 18:15:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 985C6E000C; Sun, 4 Jun 2006 18:14:55 -0400 (EDT) To: Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> From: Sam Hartman Date: Sun, 04 Jun 2006 18:14:55 -0400 In-Reply-To: <4480B66D.8040109@redhat.com> (Pete Rowley's message of "Fri, 02 Jun 2006 15:06:37 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Pete" == Pete Rowley writes: Pete> It is a requirement if you require to support more than Pete> authN. Access to a site might require an "I am over 21" Pete> token, authZ without direct authN - DIX supports that, and I Pete> believe it is important to do so. I think the over-21 example is particularly bad because I cannot imagine a site (at least in the US) not taking responsibility for that check themselves based on demographic data they request. It seems like way too much of a risk to outsource this to an identity provider especially if you allow identities from a number of different identity providers. However I do agree that non-identifier claims are something we want to support in the fullness of time. I just think that we can learn a lot by getting something that supports a single identifier claim in the first version. I don't even mind if we standardize more than that, I just question whether it needs to be mandatory to implement. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 18:35:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1CM-0001mY-6Q; Sun, 04 Jun 2006 18:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1CK-0001mS-O4 for dix@ietf.org; Sun, 04 Jun 2006 18:35:52 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn1CI-0001Kv-DK for dix@ietf.org; Sun, 04 Jun 2006 18:35:52 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 617C51E8C1C; Sun, 4 Jun 2006 15:35:49 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> From: Eric Rescorla Date: Sun, 04 Jun 2006 15:35:49 -0700 In-Reply-To: (Sam Hartman's message of "Sun, 04 Jun 2006 18:14:55 -0400") Message-ID: <86psho5z22.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: >>>>>> "Pete" == Pete Rowley writes: > > Pete> It is a requirement if you require to support more than > Pete> authN. Access to a site might require an "I am over 21" > Pete> token, authZ without direct authN - DIX supports that, and I > Pete> believe it is important to do so. > > I think the over-21 example is particularly bad because I cannot > imagine a site (at least in the US) not taking responsibility for that > check themselves based on demographic data they request. It seems > like way too much of a risk to outsource this to an identity provider > especially if you allow identities from a number of different identity > providers. I'm surprised to see you make this claim, since outsourced adult verification services for porn sites are extremely common. http://en.wikipedia.org/wiki/Adult_Verification_System -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 19:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1q5-0007Zg-MG; Sun, 04 Jun 2006 19:16:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1q4-0007Xv-J7 for dix@ietf.org; Sun, 04 Jun 2006 19:16:56 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn1q1-0004TH-7z for dix@ietf.org; Sun, 04 Jun 2006 19:16:56 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k54NGpv7003014 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 16:16:51 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Sun, 4 Jun 2006 16:16:43 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 3:14 PM, Sam Hartman wrote: > However I do agree that non-identifier claims are something we want to > support in the fullness of time. I just think that we can learn a lot > by getting something that supports a single identifier claim in the > first version. Not thinking through all the issues leads to solutions that can't be built upon. Note that OpenID can move an 'identifier claim'... but can't move other claims... because it wasn't part of the design requirements. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 20:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn2Vo-0006IJ-57; Sun, 04 Jun 2006 20:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn2Vl-0006I1-Il for dix@ietf.org; Sun, 04 Jun 2006 20:00:01 -0400 Received: from rwcrmhc11.comcast.net ([204.127.192.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn2Vj-00035A-9g for dix@ietf.org; Sun, 04 Jun 2006 20:00:01 -0400 Received: from [192.168.101.14] (c-67-188-95-205.hsd1.ca.comcast.net[67.188.95.205]) by comcast.net (rwcrmhc11) with SMTP id <20060604235958m1100kvc3oe>; Sun, 4 Jun 2006 23:59:58 +0000 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> Content-Type: multipart/mixed; boundary=Apple-Mail-22--640294140 Message-Id: <3FA3D665-6E1E-4E02-AC30-4BDCA9C6DD8B@netmesh.us> From: Johannes Ernst Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Sun, 4 Jun 2006 16:59:57 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org --Apple-Mail-22--640294140 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 4, 2006, at 16:16, John Merrells wrote: > Not thinking through all the issues leads to solutions that can't be > built upon. Note that OpenID can move an 'identifier claim'... but > can't move other claims... because it wasn't part of the design > requirements. Sure you don't mean to imply that nobody can build on OpenID? Today, there are working and deployed OpenID-enabled identity providers that do - VCard data exchange - social network data exchange - registration data exchange - authenticated messaging and there a number in the labs that add a fairly impressive set of other capabilities ranging from location-based services to social media and e-commerce enablement. (And that's just the ones I know about.) On top of OpenID, no problem whatsoever. You are entirely right that OpenID's initial requirements were only about proving that a browser session was owned by somebody who had control over a certain URL. However, in conjunction with the Yadis discovery and composition framework, it has become a very "composable" piece of technology since last fall; for example, at NetMesh we are running all LID services on top of OpenID authentication just as well as on top of LID's original GPG-based authentication. A number of other companies have built on top as well with new services that meet their customer's needs. Let's not mistake orthogonality for limitation when looking at designs. I don't want to take this thread off subject from "WARP - Web Authentication Resistant to Phishing" -- I just thought I need to put the record straight here. Johannes Ernst NetMesh Inc. --Apple-Mail-22--640294140 Content-Transfer-Encoding: base64 Content-Type: image/gif; x-unix-mode=0666; name="lid.gif" Content-Disposition: inline; filename=lid.gif R0lGODlhJAAOAPcXMf////////////////////////////////////////////////////////// ///////////////////////////////exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/exv/e xv/exv/exv/exv/exv/exv/exv/exv/exv/exv/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/O pf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf/Opf+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1 hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+1hP+MQv+MQv+MQv+MQv+MQv+M Qv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv+MQv9jAP9jAP9j AP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAP9jAPfv 5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv5/fv 5/fv5/ethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPethPet hPethPethPethOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOdaAOda AOdaAOdaAOdaAOdaAOdaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZaANZa ANZaANZaANZaANZaANZaANZaANZaAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZS AMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAMZSAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsx AHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAHsxAAAAACwAAAAAJAAOAAAIsgABCBy4 oqDBgwgTGhzIkOGKNRAjSpxIMaKqhg4ratwI8SLGhxGrALAwUSTJNSIHnoz4qyHIkCOpSTQp02Ql ICMpEqRo8tfMkT5FrggKoMrEli9/rpAJcynKmBBzHlVVsedPC0QtMJUqMR2AqlBhan06VqTRrgN9 /gQEpK1RmmR/mZzolaFaiCkHAiFbk+FKiHUbHqVGmDDEX9TUIi6MFqPAuxwjB3b8NZ3ly5gza7aM MSAAOw== --Apple-Mail-22--640294140 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed http://netmesh.info/jernst --Apple-Mail-22--640294140 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --Apple-Mail-22--640294140-- From dix-bounces@ietf.org Sun Jun 04 23:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5y6-0005v7-NB; Sun, 04 Jun 2006 23:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5y5-0005v2-PC for dix@ietf.org; Sun, 04 Jun 2006 23:41:29 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn5y4-0000cM-Ed for dix@ietf.org; Sun, 04 Jun 2006 23:41:29 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k553fMeX007003 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 20:41:23 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <3FA3D665-6E1E-4E02-AC30-4BDCA9C6DD8B@netmesh.us> References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <3FA3D665-6E1E-4E02-AC30-4BDCA9C6DD8B@netmesh.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Sun, 4 Jun 2006 20:41:15 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 4:59 PM, Johannes Ernst wrote: > Let's not mistake orthogonality for limitation when looking at > designs. Yes, and let's not confuse flaws with features. If OpenID could move attribute value assertions we'd all be better off. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 23:43:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5zw-0006tl-Gl; Sun, 04 Jun 2006 23:43:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn5zv-0006td-Dm for dix@ietf.org; Sun, 04 Jun 2006 23:43:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn5zv-00017D-6C for dix@ietf.org; Sun, 04 Jun 2006 23:43:23 -0400 Received: from [127.0.0.1] (stdhcp-101.va.neustar.com [10.31.13.101]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k553hIHq007994 for ; Mon, 5 Jun 2006 03:43:22 GMT Message-ID: <4483A84C.6030100@neustar.biz> Date: Sun, 04 Jun 2006 20:43:08 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: dix@ietf.org Subject: Re: [dix] draft-merrells-dix-02.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I have some comments on draft-merrells-dix-02. I'll touch on only the first-order ones in this message -- there are various detail-level issues I've noticed, but I'd rather discuss the former first. Although it is good (for various reasons) that this spec has been recast nominally in the form of a "SAML profile", I don't feel it is, as presently written, actually one. Rather, the spec is written more in terms of attempting to wedge a slight veneer of SAML into the SXIP framework. For example, retaining the "DIX protocol" terminology, as is done in section 3, and in the entitling of section 4.3 as "Employing SAML in DIX", is symptomatic. Specifically, rather than appropriately reusing the SAML Authentication Request Protocol and the SAML Assertion Query and Request Protocol, draft-merrells-dix-02 invents its own Fetch protocols and messages (which are analogous to the former SAML abstract protocols), only cursorily basing them upon the SAML RequestAbstractType. These protocols do not reuse the notion of, and elements for, "Subject"s -- rather, inventing their own top-level elements for naming of entities (eg "SPName"). Since SAML presently doesn't have a notion of a "store" protocol, it is reasonable to invent such, though I believe one could design it such that it intersects more fully with SAML approaches. Furthermore, the notion of SAML assertions as a means of concisely conveying Subject information is not directly employed. SAML assertions are nominally profiled in draft-merrells-dix-assertion-00, but, for example, are not actually employed in draft-merrells-dix-02. The reasons these points matter are at least.. * established SAML semantics largely aren't employed - thus all the added-value security knowledge-base that they represent is not leveraged * crafting implementations facilitating convenient re-configuration to "turn security on" isn't facilitated (i.e. security mechs other than those sxip-derived ones that are in the spec) * ditto for facilitating "turning on identity federation" This is a serious "lose", in my view. As such, although they are a "SAML profile" in some small, nominal fashion, these specs are _not_ in my view crafted in the terms of the present family of SAML profiles, and thus will tend to foster divergence rather than convergence. I suspect it is possible to craft a lightweight SAML web SSO profile that can support the sxip features (eg the signing approach) desired by some, and also support other, more conventional signing approaches (but not use xmldsig) -- both of which can be optional so it can be deployed in ultimate lightweight fashion if desired. This profile, designed with established SAML semantics and approaches, will then facilitate deployments' migration (perhaps even by reconfiguration) to more robust security and identity federation if desired. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 23:51:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn67Y-0004uo-4W; Sun, 04 Jun 2006 23:51:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn67X-0004ug-11 for dix@ietf.org; Sun, 04 Jun 2006 23:51:15 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn67V-0001WH-ND for dix@ietf.org; Sun, 04 Jun 2006 23:51:15 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k553pBZ1007584 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 20:51:12 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Sun, 4 Jun 2006 20:51:03 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > Rather, the spec is written more in terms of attempting to wedge a > slight > veneer of SAML into the SXIP framework. For example, retaining the > "DIX protocol" terminology, as is done in section 3, and in the > entitling of section 4.3 as "Employing SAML in DIX", is symptomatic. Which terms do you mean? I actually switched from Homesite/Membersite to Identity Agent/Service Provider as they seemed more inline with SAML. Actually the 4.3 title is a holdover from the text I stole from your SAML over SIP draft :) What do you think it should be called? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 23:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6DH-0001cM-6G; Sun, 04 Jun 2006 23:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6DF-0001cH-Us for dix@ietf.org; Sun, 04 Jun 2006 23:57:09 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn6DE-0001yI-KH for dix@ietf.org; Sun, 04 Jun 2006 23:57:09 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k553v6ix007682 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 20:57:06 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Sun, 4 Jun 2006 20:56:59 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > Furthermore, the notion of SAML assertions as a means of concisely > conveying > Subject information is not directly employed. I'm currently looking into how we can reuse Subject and Subject Confirmation to carry our Persona URL and to signal that it should be verified using the lighter weight signing mechanism. > SAML assertions are nominally > profiled in draft-merrells-dix-assertion-00, but, for example, 'nominally'? Meaning not enough? > are not actually employed in draft-merrells-dix-02. Intentionally, the assertions are an example of a claim format that could be used for moving around third party attested attribute value assertions. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sun Jun 04 23:58:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6EM-0002q6-NS; Sun, 04 Jun 2006 23:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6EL-0002pg-Bt for dix@ietf.org; Sun, 04 Jun 2006 23:58:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn6EL-00023O-AY for dix@ietf.org; Sun, 04 Jun 2006 23:58:17 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fn6AG-00007x-G3 for dix@ietf.org; Sun, 04 Jun 2006 23:54:05 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k553s2LX007641 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 20:54:02 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Sun, 4 Jun 2006 20:53:54 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: -1.3 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > Specifically, rather than appropriately reusing the SAML > Authentication Request Protocol and the SAML Assertion Query and > Request Protocol, draft-merrells-dix-02 invents its own Fetch > protocols and messages (which are analogous to the former SAML > abstract protocols), only cursorily basing them upon the SAML > RequestAbstractType. > > Since SAML presently doesn't have a notion of a "store" protocol, > it is reasonable to invent such, though I believe one could design > it such that it intersects more fully with SAML approaches. Our first crack at the fetch request message was exactly as you suggest, but then we realized that the Store request would have to be different... so we ended up switching the fetch to the same scheme to make them more orthogonal. > These protocols do not reuse the notion of, and elements for, > "Subject"s -- rather, inventing their own top-level elements for > naming of entities (eg "SPName"). Where would you expect 'SPName' to appear? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 00:00:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6GS-0004NU-Bw; Mon, 05 Jun 2006 00:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6GQ-0004NO-9u for dix@ietf.org; Mon, 05 Jun 2006 00:00:26 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn6GO-00029I-WC for dix@ietf.org; Mon, 05 Jun 2006 00:00:26 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5540NY2007914 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 21:00:24 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <484655A6-9902-4D83-859B-935BE9330AD1@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Sun, 4 Jun 2006 21:00:16 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > The reasons these points matter are at least.. > > * established SAML semantics largely aren't employed - thus all the > added-value security knowledge-base that they represent is not > leveraged For example? > * crafting implementations facilitating convenient re-configuration to > "turn security on" isn't facilitated (i.e. security mechs other > than those sxip-derived ones that are in the spec) I think that it is, just isn't documented. If it were documented better you'd be happy? > * ditto for facilitating "turning on identity federation" I'm not sure what that means. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 00:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6Ih-00064f-G7; Mon, 05 Jun 2006 00:02:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn6Ig-00062g-Hh for dix@ietf.org; Mon, 05 Jun 2006 00:02:46 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn6If-0002Py-7B for dix@ietf.org; Mon, 05 Jun 2006 00:02:46 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5542hEL007992 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 4 Jun 2006 21:02:43 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Sun, 4 Jun 2006 21:02:35 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > I suspect it is possible to craft a lightweight SAML web SSO > profile that can support the sxip features (eg the signing > approach) desired by some, and also support other, more > conventional signing approaches (but not use xmldsig) -- both of > which can be optional so it can be deployed in ultimate lightweight > fashion if desired. This profile, designed with established SAML > semantics and approaches, will then facilitate deployments' > migration (perhaps even by reconfiguration) to more robust security > and identity federation if desired. I think that DIX is moving to becoming that. I've reused (based your advise, and Scott's and Bob's) as much SAML as I could whilst still maintaining the goals we've established for this work. If there's more SAML we can reuse than I'd greatly appreciate your expertise, guidance and support in making that a reality. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 05:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBrY-0001TC-4c; Mon, 05 Jun 2006 05:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnBrW-0001T2-Tt for dix@ietf.org; Mon, 05 Jun 2006 05:59:06 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnBrV-0000eU-FA for dix@ietf.org; Mon, 05 Jun 2006 05:59:06 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k559x4rs002879 for ; Mon, 5 Jun 2006 02:59:04 -0700 Received: from MOU1WNEXMB11.vcorp.ad.vrsn.com ([10.25.13.219]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 02:58:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web AuthenticationResistant to Phishing Date: Mon, 5 Jun 2006 02:58:55 -0700 Message-ID: <8A1A6155AA70064EBE4DC370E709147B913B4A@MOU1WNEXMB11.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web AuthenticationResistant to Phishing Thread-Index: AcaIUfRAOuGnLrV8R32tZmn/bJjpvgAM46Tg From: "Recordon, David" To: "Digital Identity Exchange" X-OriginalArrivalTime: 05 Jun 2006 09:58:57.0035 (UTC) FILETIME=[A914DDB0:01C68886] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 When Brad designed OpenID last year, his goal was only to "move an 'identifier claim'". I certainly wouldn't say that this is a flaw within his design, rather a conscious decision to keep the protocol simple and implementable. With the framework Yadis and OpenID provides, it is possible to build other services on top, including profile exchange. OpenID Simple Registration (http://www.openidenabled.com/openid/simple-registration-extension/) is already an example of how nine pieces of profile data can be requested by a relying party and provided with the identity assertion from the IdP. In any case, you'll be able to move rich attribute value assertions on top of OpenID within the next month, with the end goal being a framework flexible enough to pass around XML-vCards, Sxip 2.0 key/value pairs, the Dix SAML profile, other opaque messages, and whatever else becomes popular in the future. --David -----Original Message----- From: John Merrells [mailto:merrells@sxip.com]=20 Sent: Sunday, June 04, 2006 8:41 PM To: Digital Identity Exchange Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web AuthenticationResistant to Phishing On 4-Jun-06, at 4:59 PM, Johannes Ernst wrote: > Let's not mistake orthogonality for limitation when looking at=20 > designs. Yes, and let's not confuse flaws with features. If OpenID could move attribute value assertions we'd all be better off. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 12:48:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIFX-0001nI-FD; Mon, 05 Jun 2006 12:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnIFW-0001nD-65 for dix@ietf.org; Mon, 05 Jun 2006 12:48:18 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnIFU-0002Iz-SJ for dix@ietf.org; Mon, 05 Jun 2006 12:48:18 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55GmEmO026984 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 09:48:15 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <8A1A6155AA70064EBE4DC370E709147B913B4A@MOU1WNEXMB11.vcorp.ad.vrsn.com> References: <8A1A6155AA70064EBE4DC370E709147B913B4A@MOU1WNEXMB11.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E23895B-06E6-47FB-9DFB-7E8DD2E2FB13@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web AuthenticationResistant to Phishing Date: Mon, 5 Jun 2006 09:48:07 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 2:58 AM, Recordon, David wrote: > Sxip 2.0 key/value pairs, the > Dix SAML profile Note that the core of SXIP 2.0 is the DIX protocol. DIX moves properties around, which are key/value pairs... so you can move any identity information you want. DIX doesn't define any property keys, and suggests one encoding for a third party attribute value assertions (a SAML assertion). John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 13:49:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJCu-0003aL-Q7; Mon, 05 Jun 2006 13:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnJCu-0003aG-6J for dix@ietf.org; Mon, 05 Jun 2006 13:49:40 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnJCs-0004Lj-Sf for dix@ietf.org; Mon, 05 Jun 2006 13:49:40 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55HnaV3029270 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 10:49:37 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4483A84C.6030100@neustar.biz> References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43AF2F18-1980-4DCE-8EBF-E6E2A4A09EFA@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Mon, 5 Jun 2006 10:49:28 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > These protocols do not reuse the notion of, and elements for, > "Subject"s -- rather, inventing their own top-level elements for > naming of entities (eg "SPName"). I don't see how these are related. SPName is in the request and is the identifier of the service provider, whereas Subject would be the identifier of the user, their Persona URL. Yes? I can't find an equivalent for SPName in SAML... the closest thing would be AssertionConsumerServiceURL, but I'm putting that into Issuer. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:00:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMBW-0005ok-7E; Mon, 05 Jun 2006 17:00:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMBU-0005oT-Hx for dix@ietf.org; Mon, 05 Jun 2006 17:00:24 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMBT-000204-7q for dix@ietf.org; Mon, 05 Jun 2006 17:00:24 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55L0LOg037205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 14:00:21 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <4483A84C.6030100@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Mon, 5 Jun 2006 14:00:13 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 4-Jun-06, at 8:51 PM, John Merrells wrote: > > On 4-Jun-06, at 8:43 PM, Jeff Hodges wrote: > >> and in the entitling of section 4.3 as "Employing SAML in DIX", is >> symptomatic. > > Actually the 4.3 title is a holdover from the text I stole from > your SAML > over SIP draft :) What do you think it should be called? I've renamed it 'Profiling SAML for DIX'. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:00:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMBx-0006Ca-HH; Mon, 05 Jun 2006 17:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMBw-0006CQ-4s for dix@ietf.org; Mon, 05 Jun 2006 17:00:52 -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 1FnMBu-00023v-V1 for dix@ietf.org; Mon, 05 Jun 2006 17:00:52 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 57A9BE000C; Mon, 5 Jun 2006 17:00:41 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 05 Jun 2006 17:00:41 -0400 In-Reply-To: <86psho5z22.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Sun, 04 Jun 2006 15:35:49 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >>>>>>> "Pete" == Pete Rowley writes: >> Pete> It is a requirement if you require to support more than Pete> authN. Access to a site might require an "I am over 21" Pete> token, authZ without direct authN - DIX supports that, and I Pete> believe it is important to do so. >> I think the over-21 example is particularly bad because I >> cannot imagine a site (at least in the US) not taking >> responsibility for that check themselves based on demographic >> data they request. It seems like way too much of a risk to >> outsource this to an identity provider especially if you allow >> identities from a number of different identity providers. Eric> I'm surprised to see you make this claim, since outsourced Eric> adult verification services for porn sites are extremely Eric> common. My point is that I expect the porn site to have a contract with some verification service they trust and not to want to handle that data transport through the identity exchange. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:07:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMID-0003ox-Ol; Mon, 05 Jun 2006 17:07:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMIC-0003os-Tv for dix@ietf.org; Mon, 05 Jun 2006 17:07:20 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMIB-0002SE-IY for dix@ietf.org; Mon, 05 Jun 2006 17:07:20 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55L7H1s037446 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 14:07:17 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.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: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Mon, 5 Jun 2006 14:07:07 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 2:00 PM, Sam Hartman wrote: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> Sam Hartman writes: >>>>>>>> "Pete" == Pete Rowley writes: >>> > Pete> It is a requirement if you require to support more than > Pete> authN. Access to a site might require an "I am over 21" > Pete> token, authZ without direct authN - DIX supports that, and I > Pete> believe it is important to do so. >>> I think the over-21 example is particularly bad because I >>> cannot imagine a site (at least in the US) not taking >>> responsibility for that check themselves based on demographic >>> data they request. It seems like way too much of a risk to >>> outsource this to an identity provider especially if you allow >>> identities from a number of different identity providers. > > Eric> I'm surprised to see you make this claim, since outsourced > Eric> adult verification services for porn sites are extremely > Eric> common. > > My point is that I expect the porn site to have a contract with some > verification service they trust They would in both cases. They 'trust' the authority, and they need a mechanism to verify the claim. > and not to want to handle that data > transport through the identity exchange. Why not? It costs less to implement. The Service Provider just has to state up front what it's policy is wrt to the set of claims it requires to permit access to the requested content. The claims are some kind of signed blob (eg SAML assertion)... why would they care if it came in with the user's 'login' to the site? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:19:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMUH-0008G2-Pw; Mon, 05 Jun 2006 17:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMUG-0008Fo-VO for dix@ietf.org; Mon, 05 Jun 2006 17:19:48 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMUE-0002oj-I6 for dix@ietf.org; Mon, 05 Jun 2006 17:19:48 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 877641E8C1C; Mon, 5 Jun 2006 14:19:45 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 05 Jun 2006 14:19:45 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 05 Jun 2006 17:00:41 -0400") Message-ID: <86fyij47wu.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> Sam Hartman writes: > >>>>>>> "Pete" == Pete Rowley writes: > >> > Pete> It is a requirement if you require to support more than > Pete> authN. Access to a site might require an "I am over 21" > Pete> token, authZ without direct authN - DIX supports that, and I > Pete> believe it is important to do so. > >> I think the over-21 example is particularly bad because I > >> cannot imagine a site (at least in the US) not taking > >> responsibility for that check themselves based on demographic > >> data they request. It seems like way too much of a risk to > >> outsource this to an identity provider especially if you allow > >> identities from a number of different identity providers. > > Eric> I'm surprised to see you make this claim, since outsourced > Eric> adult verification services for porn sites are extremely > Eric> common. > > My point is that I expect the porn site to have a contract with some > verification service they trust and not to want to handle that data > transport through the identity exchange. I'm not sure I see the distinction here. As I mentioned at the DIX BOF in Dallas, there are two kinds of claim that one could imagine an identity provider making: 1. Claims for which they are authoritative (like when rtfm.com's name server asserts that www.rtfm.com has a certain IP address) 2. Claims for which it's not authoritative but which have some independent truth value (e.g., this person is over 21, has the following SSN, etc.) Any system which allows for the second kind of claim must by necessity involve the relying party having some trust in the provider making the assertion (as opposed to the first in which you simply need to verify who they are). No? In what way couldn't that apply to an "identity exchange"? I'm also not sure that I understand your point about a "contract". After all, we routinely trust physical (drivers licenses) and electronic (SSL certs) credentials from organizations with which we have no prior relationship. The reason for there to be a contract betwen the porn site and the AVS isn't really so that the porn site can trust the AVS but rather so that money can flow. [1] In the absence of that money flow (or the presence of a direct money flow like in the case where you show ID to buy alcohol) then it's not clear to me that the relying party needs a contract with the AVS. -Ekr [1] Incidentally, the way the money flows here is generally from the AVS to the porn site. Effectively, the AVS is charging you for accessing the site. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:23:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMXx-0003zI-07; Mon, 05 Jun 2006 17:23:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMXv-0003yt-56 for dix@ietf.org; Mon, 05 Jun 2006 17:23:35 -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 1FnMXt-0002xD-UP for dix@ietf.org; Mon, 05 Jun 2006 17:23:35 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B3562E000C; Mon, 5 Jun 2006 17:23:26 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 05 Jun 2006 17:23:26 -0400 In-Reply-To: <86fyij47wu.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 05 Jun 2006 14:19:45 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla writes: >> Eric> Sam Hartman writes: >> >>>>>>> "Pete" == Pete Rowley writes: >> >> Pete> It is a requirement if you require to support more than Pete> authN. Access to a site might require an "I am over 21" Pete> token, authZ without direct authN - DIX supports that, and I Pete> believe it is important to do so. >> >> I think the over-21 example is particularly bad because I >> >> cannot imagine a site (at least in the US) not taking >> >> responsibility for that check themselves based on demographic >> >> data they request. It seems like way too much of a risk to >> >> outsource this to an identity provider especially if you >> allow >> identities from a number of different identity >> providers. >> Eric> I'm surprised to see you make this claim, since outsourced Eric> adult verification services for porn sites are extremely Eric> common. >> My point is that I expect the porn site to have a contract >> with some verification service they trust and not to want to >> handle that data transport through the identity exchange. Eric> I'm not sure I see the distinction here. The distinction is layer 9; I don't think there is a technical distincition. It is my impression mostly from financial sector businesses that you are going to see people verifying this information themselves (through a separate exchange with a business partner) rather than trusting the same assertion signed as part of the identity exchange. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:37:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMlN-0003EL-MH; Mon, 05 Jun 2006 17:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMlM-0003EG-Ow for dix@ietf.org; Mon, 05 Jun 2006 17:37:28 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMlL-0004Rr-EO for dix@ietf.org; Mon, 05 Jun 2006 17:37:28 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55LbPNf038557 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 14:37:25 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.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: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Mon, 5 Jun 2006 14:37:17 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 2:23 PM, Sam Hartman wrote: > It is my impression mostly from financial sector businesses that you > are going to see people verifying this information themselves (through > a separate exchange with a business partner) rather than trusting the > same assertion signed as part of the identity exchange. It doesn't have to be the same assertion. There can be multiple assertions each signed by different authorities. The IdP may have authority for identifying and authenticating the person... but the other assertions that come in the exchange could be issued by other authorities. This is why in DIX we have the separation between the acquisition of an assertion and the presentation of an assertion. And why the Fetch message allows for the combination of a request for an authentication assertion with the request for attribute assertions... all with different signers. The user can then collect claims from whatever authorities they chose, before an exchange, or upon demand. The Relying Party then only needs to trust the Authority of the claim rather than where the claim is coming from. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMqI-0004AU-5O; Mon, 05 Jun 2006 17:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMqH-00049q-GP for dix@ietf.org; Mon, 05 Jun 2006 17:42:33 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMqG-0005Il-45 for dix@ietf.org; Mon, 05 Jun 2006 17:42:33 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 955AF1E8C1C; Mon, 5 Jun 2006 14:42:31 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 05 Jun 2006 14:42:31 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 05 Jun 2006 17:23:26 -0400") Message-ID: <86d5dn2sag.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> Sam Hartman writes: > >>>>>>> "Eric" == Eric Rescorla writes: > >> > Eric> Sam Hartman writes: > >> >>>>>>> "Pete" == Pete Rowley writes: > >> >> > Pete> It is a requirement if you require to support more than > Pete> authN. Access to a site might require an "I am over 21" > Pete> token, authZ without direct authN - DIX supports that, and I > Pete> believe it is important to do so. > >> >> I think the over-21 example is particularly bad because I >> > >> cannot imagine a site (at least in the US) not taking >> > >> responsibility for that check themselves based on demographic > >> >> data they request. It seems like way too much of a risk to > >> >> outsource this to an identity provider especially if you > >> allow >> identities from a number of different identity > >> providers. > >> > Eric> I'm surprised to see you make this claim, since outsourced > Eric> adult verification services for porn sites are extremely > Eric> common. > >> My point is that I expect the porn site to have a contract > >> with some verification service they trust and not to want to > >> handle that data transport through the identity exchange. > > Eric> I'm not sure I see the distinction here. > > The distinction is layer 9; I don't think there is a technical distincition. > > It is my impression mostly from financial sector businesses that you > are going to see people verifying this information themselves (through > a separate exchange with a business partner) rather than trusting the > same assertion signed as part of the identity exchange. I'm still not sure I get what you're saying. Let me see if I can try again looking at the flows of data. OPTION 1: What I take DIX to be doing Client IdP Relying Party ------------------------- Service Please ------------> <------------------------- Prove you're over 21-------- <-------Auth exchange ------> <------- Over 21 credential-- <----------------- Auth exchange plus over 21 cred ----> OPTION 2: What I think you're describing Client IdP Relying Party Business partner ---------- Service Please ------------> <--------- Prove your identity -------- <-- Auth exch -- <---Id cred ---- <------ Auth exchange plus Id cred ----> --- User's ID --> <-- Over 21 ----- Do I have this correct? -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 17:57:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN4W-00079s-IB; Mon, 05 Jun 2006 17:57:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnN4V-00079n-9W for dix@ietf.org; Mon, 05 Jun 2006 17:57:15 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnN4T-0006f9-V0 for dix@ietf.org; Mon, 05 Jun 2006 17:57:15 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55Lv9l0039514 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 14:57:09 -0700 (PDT) (envelope-from merrells@sxip.com) In-Reply-To: <86d5dn2sag.fsf@raman.networkresonance.com> References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.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: John Merrells Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing Date: Mon, 5 Jun 2006 14:57:01 -0700 To: EKR , Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Sam Hartman X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 2:42 PM, Eric Rescorla wrote: > > I'm still not sure I get what you're saying. Let me see if I can > try again looking at the flows of data. > > > OPTION 1: What I take DIX to be doing Yes, this interaction diagram is correct. > Client IdP Relying Party > > ------------------------- Service Please ------------> > <------------------------- Prove you're over 21-------- > > <-------Auth exchange ------> > <------- Over 21 credential-- > > <----------------- Auth exchange plus over 21 cred ----> Assuming that at some point earlier the user acquired an over 21 assertion from an appropriate authority. Client Identity Agent Authority ------------------------- Service Please ------------> <--- Auth/Verify exchange, maybe even out of band ----> <------- Over 21 credential---------------------------- <--------- Over 21 cred ----> John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 18:10:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNGt-0005bp-BN; Mon, 05 Jun 2006 18:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNGs-0005bk-A1 for dix@ietf.org; Mon, 05 Jun 2006 18:10:02 -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 1FnNGr-0008My-4k for dix@ietf.org; Mon, 05 Jun 2006 18:10:02 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DCE64E000C; Mon, 5 Jun 2006 18:09:56 -0400 (EDT) To: dix@ietf.org From: Sam Hartman Message-Id: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> Date: Mon, 5 Jun 2006 18:09:56 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [dix] IETF requirement for automated key management X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi. I want to draw your attention to RFC 4107. This rfc specifies a mandatory requirement for new work in the IETF that except in a small number of cases that there needs to be automated key management. For example if you have a protocol like DIX where there are MACs of messages, you need a key management solution to set up and maintain these keys. --Sam _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 18:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNPJ-0002fR-6h; Mon, 05 Jun 2006 18:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnNPH-0002fJ-NO for dix@ietf.org; Mon, 05 Jun 2006 18:18:43 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnNPE-0000ry-CY for dix@ietf.org; Mon, 05 Jun 2006 18:18:43 -0400 Received: from [192.168.1.101] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55MIcfd040154 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 15:18:38 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> References: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] IETF requirement for automated key management Date: Mon, 5 Jun 2006 15:18:16 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 3:09 PM, Sam Hartman wrote: > I want to draw your attention to RFC 4107. Thanks. I'll read that and see if and how it applies to DIX. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:04:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnO7w-0000Vu-0L; Mon, 05 Jun 2006 19:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnO7v-0000Vf-2G for dix@ietf.org; Mon, 05 Jun 2006 19:04:51 -0400 Received: from stratton-three-o-one.mit.edu ([18.187.6.46] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnO7t-0006So-TM for dix@ietf.org; Mon, 05 Jun 2006 19:04:51 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 71118E000C; Mon, 5 Jun 2006 19:04:47 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 05 Jun 2006 19:04:47 -0400 In-Reply-To: <86d5dn2sag.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 05 Jun 2006 14:42:31 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Yes, your understanding is correct. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOPC-0001DQ-Gc; Mon, 05 Jun 2006 19:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOPB-0001DK-Pm for dix@ietf.org; Mon, 05 Jun 2006 19:22:41 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOPA-0008CK-JD for dix@ietf.org; Mon, 05 Jun 2006 19:22:41 -0400 Received: from [10.31.13.229] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k55NMdWQ029166 for ; Mon, 5 Jun 2006 23:22:40 GMT Message-ID: <4484BCB7.5010505@neustar.biz> Date: Mon, 05 Jun 2006 16:22:31 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft-merrells-dix-02.txt References: <4483A84C.6030100@neustar.biz> <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> In-Reply-To: <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sorry am at a conference for a few days, plus little league playoff games, so responses will have higher than my already high latency. John Merrells wrote: > > I've renamed it 'Profiling SAML for DIX'. As of yet, nobody's attempted to concoct catchy names for SAML profiles. If you're set on doing so, eg using "DIX", I'd do it like so.. "DIX: A Web Browser SSO SAML Profile" JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:28:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOVG-0003cA-PP; Mon, 05 Jun 2006 19:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOVF-0003c4-HM for dix@ietf.org; Mon, 05 Jun 2006 19:28:57 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOVE-0008Mr-2d for dix@ietf.org; Mon, 05 Jun 2006 19:28:57 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E9A651E8C1C; Mon, 5 Jun 2006 16:28:52 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 05 Jun 2006 16:28:52 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 05 Jun 2006 19:04:47 -0400") Message-ID: <86lksbyyff.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: > Yes, your understanding is correct. Good. Then we have a basis to talk about them. So, for reference here's my summary of the schemes in text form: The way that DIX works is that you authenticate to the IDP which hands you some credential which attests to some set of assertions about you. In this case, said credential would contain the claim that you were over 21. You'd then provide the credential to the relying party. In the scheme Sam is describing you would authenticate to the relying party, possible using something like DIX, but with some scheme that gave the relying party your actual identity (true name, SSN, drivers' license #, whatever). The relying party would then independently contact some authority it trusted to find out what it wanted to know (e.g., if you're over 21). With respect to your original argument that relying parties will want to have contractual arrangements with the third party authorities they're getting information from, I certainly agree that that's true in many cases, such as background checks, taxes, etc., where the databases are all keyed by some sort of individual identifier (name, phone number, driver's license number, SSN/TIN, etc.). However,there are also many cases where it's untrue, with the most obvious being the use of state-issued photographic ID for various kinds of identification and age verification purposes. When a bar checks my ID before serving, they're not relying on any contract between them and the state of California.[0] So, I don't think it's really accurate to say that asserting claims along the identify exchange path isn't something that people are going to want to do in general. Moreover, true-name based systems like the one you describe have quite poor privacy properties: (1) it means handing out your true name all over the place. (2) you have very little control or even visibility into what the third party gives to the relying party. (3) the third party tends to collect a lot of information about your activities as a matter of course. So, a system in which you could individually assert individual claims without exposing a bunch of irrelevant but sensitive information would have some advantages from a privacy perspective. I absolutely agree with you that there are settings in which relying parties will want to get your identity and then use that for their own research obviously if one designs a system without independently assertable claims of this kind, then that will be the only thing they can do, which seems like a bug. -Ekr [0] Yes, I realize that some states do license bars, but consider the case of out-of-state or Federal ID if you want to be picky. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOZH-000402-US; Mon, 05 Jun 2006 19:33:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOZG-0003zw-Pa for dix@ietf.org; Mon, 05 Jun 2006 19:33:06 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOZF-0000kB-Iz for dix@ietf.org; Mon, 05 Jun 2006 19:33:06 -0400 Received: from [10.31.13.229] (stsc1260-corp-dns.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k55NX4WQ029543 for ; Mon, 5 Jun 2006 23:33:05 GMT Message-ID: <4484BF28.2050101@neustar.biz> Date: Mon, 05 Jun 2006 16:32:56 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft-merrells-dix-02.txt References: <4483A84C.6030100@neustar.biz> <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> <4484BCB7.5010505@neustar.biz> In-Reply-To: <4484BCB7.5010505@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Jeff Hodges wrote: > > As of yet, nobody's attempted to concoct catchy names for SAML profiles. > If you're set on doing so, eg using "DIX", I'd do it like so.. > > "DIX: A Web Browser SSO SAML Profile" that's not to say, tho, that I think the spec as presently constituted is a SAML profile in the spirit of other present SAML profiles, as I noted in my prior msg. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:43:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOj8-000497-73; Mon, 05 Jun 2006 19:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOj7-000492-2I for dix@ietf.org; Mon, 05 Jun 2006 19:43:17 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOj5-0001Qu-NL for dix@ietf.org; Mon, 05 Jun 2006 19:43:17 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0F2371E8C1C; Mon, 5 Jun 2006 16:43:15 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] IETF requirement for automated key management References: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> From: Eric Rescorla Date: Mon, 05 Jun 2006 16:43:14 -0700 In-Reply-To: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> (Sam Hartman's message of "Mon, 5 Jun 2006 18:09:56 -0400 (EDT)") Message-ID: <86fyijyxrh.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: > Hi. I want to draw your attention to RFC 4107. > > This rfc specifies a mandatory requirement for new work in the IETF > that except in a small number of cases that there needs to be > automated key management. For example if you have a protocol like DIX > where there are MACs of messages, you need a key management solution > to set up and maintain these keys. As I understand DIX 16.2, the only way in which the MAC is used is for the Identity Agent to be able to determine that messages it has generated are valid. The MAC isn't verified by anyone else and a MAC is just a suggested implementation anyway. I'm not sure how automated key management would fit in here. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 19:55:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOuq-0001lg-O2; Mon, 05 Jun 2006 19:55:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnOuq-0001lb-7n for dix@ietf.org; Mon, 05 Jun 2006 19:55:24 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnOuo-0003eL-PU for dix@ietf.org; Mon, 05 Jun 2006 19:55:24 -0400 Received: from [192.168.1.137] (adsl-69-226-212-154.dsl.pltn13.pacbell.net [69.226.212.154]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k55NtJcL043517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 16:55:20 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <86fyijyxrh.fsf@raman.networkresonance.com> References: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> <86fyijyxrh.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B5E8E42-7494-4C02-A35F-97D400264ED3@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] IETF requirement for automated key management Date: Mon, 5 Jun 2006 16:55:07 -0700 To: EKR , Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 4:43 PM, Eric Rescorla wrote: > Sam Hartman writes: > >> Hi. I want to draw your attention to RFC 4107. >> >> This rfc specifies a mandatory requirement for new work in the IETF >> that except in a small number of cases that there needs to be >> automated key management. For example if you have a protocol like >> DIX >> where there are MACs of messages, you need a key management solution >> to set up and maintain these keys. > > As I understand DIX 16.2, the only way in which the MAC is used is for > the Identity Agent to be able to determine that messages it has > generated are valid. The MAC isn't verified by anyone else and > a MAC is just a suggested implementation anyway. I'm not sure > how automated key management would fit in here. Correct, and I don't think it does either. I'm working on a draft of how an Identity Agent Application (as opposed to an Identity Agent Website) would work. When using the DIX message signing and signature verification method this necessitates a collaborative website to receive and process the verify request messages. The 'key' then needs to be shared between the website and the application. RFC 4107 may play a part in that exchange. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 20:03:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP38-00069o-Dt; Mon, 05 Jun 2006 20:03:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnP37-00069j-Ao for dix@ietf.org; Mon, 05 Jun 2006 20:03:57 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnP35-0004u0-T1 for dix@ietf.org; Mon, 05 Jun 2006 20:03:57 -0400 Received: from [192.168.1.137] (adsl-69-226-212-154.dsl.pltn13.pacbell.net [69.226.212.154]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5603q4m043836 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 17:03:53 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4484BCB7.5010505@neustar.biz> References: <4483A84C.6030100@neustar.biz> <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> <4484BCB7.5010505@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5751E3DA-FFAF-4469-B089-004CC1A53543@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Mon, 5 Jun 2006 17:03:22 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 4:22 PM, Jeff Hodges wrote: > As of yet, nobody's attempted to concoct catchy names for SAML > profiles. If you're set on doing so, eg using "DIX", I'd do it like > so.. > > "DIX: A Web Browser SSO SAML Profile" It's not just for SSO though, as the fetch is designed for moving both authentication and/or attribute assertions, either self asserted, or third-party asserted. And although the binding in the dmd draft is based on HTTP/HTML the messages could be mapped onto alternative transports. So I'm not sure what to call it... 'DIX SAML Profile'. What is the collective term for a set of SAML profiles, and bindings, etc... is that itself a Profile? John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 20:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPAZ-0001lD-E5; Mon, 05 Jun 2006 20:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPAY-0001l8-T3 for dix@ietf.org; Mon, 05 Jun 2006 20:11:38 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPAX-0006Ah-Gn for dix@ietf.org; Mon, 05 Jun 2006 20:11:38 -0400 Received: from [192.168.1.137] (adsl-69-226-212-154.dsl.pltn13.pacbell.net [69.226.212.154]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k560BWok044071 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 5 Jun 2006 17:11:34 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <4484BF28.2050101@neustar.biz> References: <4483A84C.6030100@neustar.biz> <75BB69C0-F4FD-478F-BF41-10241B53FB61@sxip.com> <4484BCB7.5010505@neustar.biz> <4484BF28.2050101@neustar.biz> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt Date: Mon, 5 Jun 2006 17:11:20 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 5-Jun-06, at 4:32 PM, Jeff Hodges wrote: > that's not to say, tho, that I think the spec as presently > constituted is a SAML profile in the spirit of other present SAML > profiles, as I noted in my prior msg. That's due to incompetence rather than any malaise on my part. I'm trying to reuse as much of SAML as I can whilst still satisfying all the DIX goals and use cases. The next revision of the draft (dmd3) now includes Subject in the Fetch Response Message and registers a Subject Confirmation Method for Persona Delegation Verification. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 20:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPKz-0007Tv-3j; Mon, 05 Jun 2006 20:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPKx-0007T8-TX for dix@ietf.org; Mon, 05 Jun 2006 20:22:23 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPKw-0006Qe-L3 for dix@ietf.org; Mon, 05 Jun 2006 20:22:23 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7E679E000C; Mon, 5 Jun 2006 20:22:16 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> <86lksbyyff.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 05 Jun 2006 20:22:16 -0400 In-Reply-To: <86lksbyyff.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 05 Jun 2006 16:28:52 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >> Yes, your understanding is correct. Eric> Good. Then we have a basis to talk about them. I basically agree with the general statements you have made. I believe that the specific example of age verification on the web will tend not to fall into the case where people use independently asserted idenity claims especially in the medium future. I don't have high confidence in that belief though and I don't think it matters much whether I'm right or not. We both agree that there will be third party claims. As I've said before I think that whatever we design needs to eventually support claims and third party claims. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 20:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPQH-0008Bj-HL; Mon, 05 Jun 2006 20:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPQG-0008Be-KZ for dix@ietf.org; Mon, 05 Jun 2006 20:27:52 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPQF-0006Y5-9p for dix@ietf.org; Mon, 05 Jun 2006 20:27:52 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 33FE31E8C1C; Mon, 5 Jun 2006 17:27:50 -0700 (PDT) To: Sam Hartman Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> <86lksbyyff.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Mon, 05 Jun 2006 17:27:50 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 05 Jun 2006 20:22:16 -0400") Message-ID: <86bqt7yvp5.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> Sam Hartman writes: > >> Yes, your understanding is correct. > > Eric> Good. Then we have a basis to talk about them. > > I basically agree with the general statements you have made. I > believe that the specific example of age verification on the web will > tend not to fall into the case where people use independently asserted > idenity claims especially in the medium future. I don't have high > confidence in that belief though and I don't think it matters much > whether I'm right or not. We both agree that there will be third > party claims. > > As I've said before I think that whatever we design needs to > eventually support claims and third party claims. I think there's a missing part to this statement: if you plan to support third party claims, I think there's a pretty strong argument that such claims need to be independently assertable. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 20:29:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPRi-0000ZX-DH; Mon, 05 Jun 2006 20:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPRh-0000ZS-M4 for dix@ietf.org; Mon, 05 Jun 2006 20:29:21 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPRg-0006th-FW for dix@ietf.org; Mon, 05 Jun 2006 20:29:21 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 921A1E000C; Mon, 5 Jun 2006 20:29:13 -0400 (EDT) To: EKR Subject: Re: [dix] IETF requirement for automated key management References: <20060605220956.DCE64E000C@carter-zimmerman.mit.edu> <86fyijyxrh.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 05 Jun 2006 20:29:13 -0400 In-Reply-To: <86fyijyxrh.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 05 Jun 2006 16:43:14 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> As I understand DIX 16.2, the only way in which the MAC is Eric> used is for the Identity Agent to be able to determine that Eric> messages it has generated are valid. The MAC isn't verified Eric> by anyone else and a MAC is just a suggested implementation Eric> anyway. I'm not sure how automated key management would fit Eric> in here. OK, if so then I am confused. I thought I saw an instance where the homesite and the visited site needed to share a MAC key in a previous version. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 05 22:10:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnR1l-0002Bf-SU; Mon, 05 Jun 2006 22:10:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnR1l-0002BX-16 for dix@ietf.org; Mon, 05 Jun 2006 22:10:41 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnR1i-00028j-JO for dix@ietf.org; Mon, 05 Jun 2006 22:10:40 -0400 Received: from evilmonkey.corp.google.com (evilmonkey.corp.google.com [172.24.0.124]) by smtp-out.google.com with ESMTP id k562AX5b022169 for ; Mon, 5 Jun 2006 19:10:33 -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=iyh8KjrPWsI4osym+9LB+B7yp8nupYgqxdnmAXtpxlldf7qg35ytRNE6GGqaM0+XY xKT86PB7bpOG95siG/cCA== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by evilmonkey.corp.google.com with ESMTP id k560r2Xw012014 for ; Mon, 5 Jun 2006 19:10:28 -0700 Received: by smtp-out2.google.com with SMTP id 7so126945fpr for ; Mon, 05 Jun 2006 19:10:28 -0700 (PDT) Received: by 10.253.1.7 with SMTP id 7mr438068fpa; Mon, 05 Jun 2006 19:10:28 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Mon, 5 Jun 2006 19:10:28 -0700 (PDT) Message-ID: <1b587cab0606051910n1cb6c189mdebe222ba44c15b8@mail.google.com> Date: Tue, 6 Jun 2006 03:10:28 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/5/06, Sam Hartman wrote: > >>>>> "Eric" =3D=3D Eric Rescorla writes: > > Eric> Sam Hartman writes: > >>>>>>> "Eric" =3D=3D Eric Rescorla writes= : > >> > Eric> Sam Hartman writes: > >> >>>>>>> "Pete" =3D=3D Pete Rowley writes: > >> >> > Pete> It is a requirement if you require to support more than > Pete> authN. Access to a site might require an "I am over 21" > Pete> token, authZ without direct authN - DIX supports that, and I > Pete> believe it is important to do so. > >> >> I think the over-21 example is particularly bad because I >> > >> cannot imagine a site (at least in the US) not taking >> > >> responsibility for that check themselves based on demographic > >> >> data they request. It seems like way too much of a risk to > >> >> outsource this to an identity provider especially if you > >> allow >> identities from a number of different identity > >> providers. > >> > Eric> I'm surprised to see you make this claim, since outsourced > Eric> adult verification services for porn sites are extremely > Eric> common. > >> My point is that I expect the porn site to have a contract > >> with some verification service they trust and not to want to > >> handle that data transport through the identity exchange. > > Eric> I'm not sure I see the distinction here. > > The distinction is layer 9; I don't think there is a technical distinciti= on. > > It is my impression mostly from financial sector businesses that you > are going to see people verifying this information themselves (through > a separate exchange with a business partner) rather than trusting the > same assertion signed as part of the identity exchange. Hmmm. I see people trusting client certs (in the financial sector, as it happens), so I can't say I agree that this is by any means universal. > > > --Sam > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 09:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnbBX-00013L-9C; Tue, 06 Jun 2006 09:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnbBW-00013F-43 for dix@ietf.org; Tue, 06 Jun 2006 09:01:26 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fna4q-0006Yv-LI for dix@ietf.org; Tue, 06 Jun 2006 07:50:28 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FnZfs-0001H4-Q2 for dix@ietf.org; Tue, 06 Jun 2006 07:24:42 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A11BEE000C; Tue, 6 Jun 2006 07:24:28 -0400 (EDT) To: EKR Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> <86lksbyyff.fsf@raman.networkresonance.com> <86bqt7yvp5.fsf@raman.networkresonance.com> From: Sam Hartman Date: Tue, 06 Jun 2006 07:24:28 -0400 In-Reply-To: <86bqt7yvp5.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Mon, 05 Jun 2006 17:27:50 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla writes: >> Eric> Sam Hartman writes: >> >> Yes, your understanding is correct. >> Eric> Good. Then we have a basis to talk about them. >> I basically agree with the general statements you have made. >> I believe that the specific example of age verification on the >> web will tend not to fall into the case where people use >> independently asserted idenity claims especially in the medium >> future. I don't have high confidence in that belief though and >> I don't think it matters much whether I'm right or not. We >> both agree that there will be third party claims. >> >> As I've said before I think that whatever we design needs to >> eventually support claims and third party claims. Eric> I think there's a missing part to this statement: if you Eric> plan to support third party claims, I think there's a pretty Eric> strong argument that such claims need to be independently Eric> assertable. Agreed. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 10:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FncVH-0002q3-Cs; Tue, 06 Jun 2006 10:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FncVG-0002ja-C9 for dix@ietf.org; Tue, 06 Jun 2006 10:25:54 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FncVE-0004HH-JO for dix@ietf.org; Tue, 06 Jun 2006 10:25:53 -0400 Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k56EPqJw021257; Tue, 6 Jun 2006 07:25:52 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Jun 2006 07:25:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dix] Re: [Ietf-http-auth] BOF Request: WARP - WebAuthentication Resistant to Phishing Date: Tue, 6 Jun 2006 07:25:48 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B5573C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Re: [Ietf-http-auth] BOF Request: WARP - WebAuthentication Resistant to Phishing Thread-Index: AcaJaWhnoAIKJejOTkqCSLMaEwyQmQACxVVA From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , "EKR" X-OriginalArrivalTime: 06 Jun 2006 14:25:44.0097 (UTC) FILETIME=[18727110:01C68975] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I think that as far as the infrastructure is concerned anyone should be = able to assert any claim they choose at any time. Whether that claim is or should be accepted by the relying party is an = entirely different matter. Statements like 'fred@example.com is a notorious spammer' or = 'fred@example.com is a highly reputable poster' are going to be = essential in any scheme to moderate blog spam and vandalism. It is also = essential that they come from trustworthy third parties if the bad guys = are going to be shut out. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 14:42:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngVz-0007sG-9p; Tue, 06 Jun 2006 14:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FngVy-0007sB-6f for dix@ietf.org; Tue, 06 Jun 2006 14:42:54 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FngVx-0005yx-0U for dix@ietf.org; Tue, 06 Jun 2006 14:42:54 -0400 Received: from [172.21.37.137] (chancetrain-lm.corp.yahoo.com [172.21.37.137]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k56IgLlB021091 for ; Tue, 6 Jun 2006 11:42:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=mime-version:content-transfer-encoding:message-id: content-type:to:from:subject:date:x-mailer; b=E3jCOVGqb1zLSHOptzyaIqLtGmDLk2g81FL/JR6CJNEl+nj+t0LqNSMch1Mtfm70 Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: dix@ietf.org From: Mark Nottingham Date: Tue, 6 Jun 2006 11:42:27 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [dix] Requirements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I'm new to what people are trying to do here, so please forgive my ignorance. After reading the use cases document and the protocol document, I'm scratching my head as to where they meet. It would be helpful if the requirements derived from the use cases were explicitly documented, so that the proposed solution could be evaluated against the requirements; otherwise, any number of approaches would work. Most of the Browser-Based use cases, for example, could be met by modern browsers that keep identifying information on behalf of users, possibly along with P3P and APPEL (to manage the users' preferences about releasing it). The only requirements there that aren't met having to do with portability of identity across devices, but that could be met by a persistence format. I suspect that there are a few unwritten requirements implied here, including; * That an "identity agent" be a separate network entity, potentially under the control of a separate party, which has its own identity. * That currently deployed user agents be able to use them without modification. Is this the case, and are there more? Knowing these kinds of assumptions and requirements would be helpful in evaluating this proposal. Also, some discussion of what motivated the choice of SAML (which even its strongest proponents wouldn't call "simple") would be helpful. Cheers, -- Mark Nottingham mnot@yahoo-inc.com _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 18:32:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnk65-0006EN-7M; Tue, 06 Jun 2006 18:32:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnk61-00068b-FL for dix@ietf.org; Tue, 06 Jun 2006 18:32:21 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnk60-0003iX-3z for dix@ietf.org; Tue, 06 Jun 2006 18:32:21 -0400 Received: by wr-out-0506.google.com with SMTP id 50so46679wri for ; Tue, 06 Jun 2006 15:32:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=iYrzKlD+B/wnFR8C+uTyVp92f0tYQaZpSe8JFC1lJEJAY2OwNSjDSQH6JoZsQFkpu8YmVSZ55sxfxztW9MNRaS2FmioViyNxuhDTT3HcyLlvKw5nkTQDkbFIVZSE2b1prl7XLER01OMciFbTcbz073ZZRjWaQ/nsc9N1itqVbcc= Received: by 10.54.120.7 with SMTP id s7mr85960wrc; Tue, 06 Jun 2006 15:31:21 -0700 (PDT) Received: from ?9.33.34.88? ( [129.33.1.37]) by mx.gmail.com with ESMTP id g2sm1009110wra.2006.06.06.15.32.17; Tue, 06 Jun 2006 15:32:17 -0700 (PDT) Message-ID: <44860270.9000703@gmail.com> Date: Tue, 06 Jun 2006 18:32:16 -0400 From: Robert Yates User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] draft-merrells-dix-02.txt - yadis? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 John Merrells wrote: > > Hello, > > We've been busy working away in the background reworking the protocol > draft. As a result of the feedback at the IETF 65 DIX BOF we have recast > much of the DIX protocol as SAML messages, assertions, and profiles. > > As ever we'd welcome your feedback on this draft. > > John The new draft with the SAML mapping seems to me to be harder to follow than the last, but having said that you seem to have done a great job of keeping the SAML complexity to a minimum. I was a little disappointed to see it explicit that non browser clients are not being considered, feedreaders and blog clients seem extremely important to me and I worry about leaving them out. It will be interesting to see if they are accomodated in WARP and whether Sam is going to propose some sort of federated digest authentication scheme, potentially similar to the one proposed by Philip http://www1.ietf.org/mail-archive/web/dix/current/msg00368.html. A scheme such as this would benefit from sharing a common definition of persona-url and persona-document with DIX. Has there been any discussion on moving the persona-url and persona-document definitions out of the DIX protocol specification and into its own specification. They seem more broadly useful and the corresponding specification can build on the Yadis work. Are any of the Yadis folks thinking of submitting a draft to the IETF? Rob _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 18:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkL8-0007aY-Uo; Tue, 06 Jun 2006 18:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkL7-0007aT-BQ for dix@ietf.org; Tue, 06 Jun 2006 18:47:57 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkL6-0005sX-0g for dix@ietf.org; Tue, 06 Jun 2006 18:47:57 -0400 Received: from [192.168.1.137] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k56MlnQ0084693 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 6 Jun 2006 15:47:50 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44860270.9000703@gmail.com> References: <44860270.9000703@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52A443A2-3942-4A1A-A62B-E8B1CD2A964F@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] draft-merrells-dix-02.txt - yadis? Date: Tue, 6 Jun 2006 15:47:38 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6-Jun-06, at 3:32 PM, Robert Yates wrote: > The new draft with the SAML mapping seems to me to be harder to > follow than the last, but having said that you seem to have done a > great job of keeping the SAML complexity to a minimum. Thanks. It's not that easy. This draft is +20 pages longer, and there's still more detail to drill into. :-( > I was a little disappointed to see it explicit that non browser > clients are not being considered, feedreaders and blog clients seem > extremely important to me and I worry about leaving them out. Just a lack of bandwidth. The scope of the group should be no wider than there are authoring teams to write documents and code. It'd be great if you want to put together a team to address the use cases you care most about. I have a draft of how an Identity Agent Application would work, which would provide some insight there perhaps. I hope to get that out in the next couple of weeks. > Has there been any discussion on moving the persona-url and persona- > document definitions out of the DIX protocol specification and into > its own specification. No, but that occurred to me, which is why I've structured the document so that the Persona URL is entirely in it's own section. (Microformat...?) John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 06 19:01:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkYL-0005Za-R6; Tue, 06 Jun 2006 19:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnkYK-0005ZS-Jy for dix@ietf.org; Tue, 06 Jun 2006 19:01:36 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnkYJ-0007gO-8V for dix@ietf.org; Tue, 06 Jun 2006 19:01:36 -0400 Received: from [192.168.1.137] (adsl-75-17-60-17.dsl.pltn13.sbcglobal.net [75.17.60.17]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k56N1WMI085375 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 6 Jun 2006 16:01:33 -0700 (PDT) (envelope-from merrells@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <182E0831-0F02-408C-8BA7-58F7590D53F3@sxip.com> Content-Transfer-Encoding: 7bit From: John Merrells Subject: Re: [dix] Requirements Date: Tue, 6 Jun 2006 16:01:23 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6-Jun-06, at 11:42 AM, Mark Nottingham wrote: > After reading the use cases document and the protocol document, I'm > scratching my head as to where they meet. It would be helpful if > the requirements derived from the use cases were explicitly > documented, I think that would be a good thing to do. We started there, but people wanted use cases first, so the documentation of the requirements got left behind. Volunteers welcome. > so that the proposed solution could be evaluated against the > requirements; otherwise, any number of approaches would work. Yes, it'd be good to map the solution documents back onto the requirements. > Most of the Browser-Based use cases, for example, could be met by > modern browsers that keep identifying information on behalf of > users, possibly along with P3P and APPEL (to manage the users' > preferences about releasing it). The only requirements there that > aren't met having to do with portability of identity across > devices, but that could be met by a persistence format. Well, some cases, but not all, eg: B3 - third party authentication B6 - reuse of an identifier across multiple sites And once you get into moving third party assertions around there's no browser that can help you there. > I suspect that there are a few unwritten requirements implied here, > including; Well, none of the requirements are actually written down. There's just the goals and the use-cases.. > * That an "identity agent" be a separate network entity, > potentially under the control of a separate party, which has its > own identity. The IA can be implemented in multiple ways. As a website, or as an application. That requirement probably doesn't hold. > * That currently deployed user agents be able to use them without > modification. Yes, that requirement would satisfy the goal of 'ease-of-adoption'. > Also, some discussion of what motivated the choice of SAML (which > even its strongest proponents wouldn't call "simple") would be > helpful. We had a simpler solution, see draft-merrells-dix-01. The audience of the DIX BOF felt that existing technology (ie. SAML) should be reused as much as possible. So, I'm trying to recast DIX as SAML where they overlap, and keep just the distinctive DIX pieces that meet the use- cases that the existing SAML profiles do not satisfy. John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 07 08:10:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwrZ-000809-LF; Wed, 07 Jun 2006 08:10:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwrY-0007uZ-IH for dix@ietf.org; Wed, 07 Jun 2006 08:10:16 -0400 Received: from lucius.provo.novell.com ([137.65.81.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwrX-0001Fa-8G for dix@ietf.org; Wed, 07 Jun 2006 08:10:16 -0400 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Wed, 07 Jun 2006 06:10:07 -0600 Message-Id: <4485D27F.A648.00B6.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Wed, 07 Jun 2006 06:11:43 -0600 From: "Haripriya S" To: "Digital Identity Exchange" Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing References: <114A4275-DD35-48B3-85D3-B7B305E2967B@sxip.com> <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 John, Looking at the last diagram, and the discussion on keeping the acquisition of assertions separate from presenting those, I have this basic question (could also be due to my lack of knowledge of SAML assertions :-)): When a user needs to present the identity assertion, and the "over 21 assertion" from the ID agent, what prevents a man-in-the-middle from mixing and matching assertions? Example: What if I have browser code to take my ID assertion from the ID agent, and someone else's "Over 21" assertion (which I probably captured by posing as a replying party), and passed it on to the replying party. Is this scenario possible? Is there a restriction on who can present an assertion in the assertion itself? Thanks and Regards, Haripriya S. >>> John Merrells 06/06/06 3:27 am >>> On 5- Jun- 06, at 2:42 PM, Eric Rescorla wrote: > > I'm still not sure I get what you're saying. Let me see if I can > try again looking at the flows of data. > > > OPTION 1: What I take DIX to be doing Yes, this interaction diagram is correct. > Client IdP Relying Party > > ------------------------- Service Please ------------ > > <------------------------- Prove you're over 21-------- > > <------- Auth exchange ------ > > <------- Over 21 credential-- > > <----------------- Auth exchange plus over 21 cred ---- > Assuming that at some point earlier the user acquired an over 21 assertion from an appropriate authority. Client Identity Agent Authority ------------------------- Service Please ------------ > <--- Auth/Verify exchange, maybe even out of band ---- > <------- Over 21 credential---------------------------- <--------- Over 21 cred ---- > John _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 07 08:16:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwxG-0003ZT-0y; Wed, 07 Jun 2006 08:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnwxF-0003ZN-Jn for dix@ietf.org; Wed, 07 Jun 2006 08:16:09 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnwxD-0001Nd-6K for dix@ietf.org; Wed, 07 Jun 2006 08:16:09 -0400 Received: from lois.corp.google.com (lois.corp.google.com [172.24.0.50]) by smtp-out.google.com with ESMTP id k57CG18N018701 for ; Wed, 7 Jun 2006 05:16:01 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=l7StillGUx8fVusgyeCOjVT9eQUmsm2MaGREePFKDCxR7Q/sB0tQI9YO/CkWkKCen b/1EofZSdhd09wbQaAWBQ== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by lois.corp.google.com with ESMTP id k57CCn9q004971 for ; Wed, 7 Jun 2006 05:15:57 -0700 Received: by smtp-out2.google.com with SMTP id 7so234589fpr for ; Wed, 07 Jun 2006 05:15:57 -0700 (PDT) Received: by 10.253.29.11 with SMTP id c11mr726241fpc; Wed, 07 Jun 2006 05:15:57 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Wed, 7 Jun 2006 05:15:57 -0700 (PDT) Message-ID: <1b587cab0606070515u41db71bcw7f997ca02be40e58@mail.google.com> Date: Wed, 7 Jun 2006 13:15:57 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] Re: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing In-Reply-To: <4485D27F.A648.00B6.0@novell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4480B66D.8040109@redhat.com> <86psho5z22.fsf@raman.networkresonance.com> <86fyij47wu.fsf@raman.networkresonance.com> <86d5dn2sag.fsf@raman.networkresonance.com> <4485D27F.A648.00B6.0@novell.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/7/06, Haripriya S wrote: > John, > > Looking at the last diagram, and the discussion on keeping the > acquisition of assertions separate from presenting those, I have this > basic question (could also be due to my lack of knowledge of SAML > assertions :-)): > > When a user needs to present the identity assertion, and the "over 21 > assertion" from the ID agent, what prevents a man-in-the-middle from > mixing and matching assertions? Example: What if I have browser code to > take my ID assertion from the ID agent, and someone else's "Over 21" > assertion (which I probably captured by posing as a replying party), and > passed it on to the replying party. Is this scenario possible? Is there > a restriction on who can present an assertion in the assertion itself? I think you mean "relying" rather than "replying". And certainly it can be arranged that a man in the middle cannot present it - for example, you could have the owner sign the assertion (and have that signature signed by the issuer of the assertion) and then require them to prove ownership of the signing key when presenting the assertion. > > Thanks and Regards, > Haripriya S. > > > >>> John Merrells 06/06/06 3:27 am >>> > > On 5- Jun- 06, at 2:42 PM, Eric Rescorla wrote: > > > > > I'm still not sure I get what you're saying. Let me see if I can > > try again looking at the flows of data. > > > > > > OPTION 1: What I take DIX to be doing > > Yes, this interaction diagram is correct. > > > Client IdP Relying Party > > > > ------------------------- Service Please ------------ > > > <------------------------- Prove you're over 21-------- > > > > <------- Auth exchange ------ > > > <------- Over 21 credential-- > > > > <----------------- Auth exchange plus over 21 cred ---- > > > Assuming that at some point earlier the user acquired an over 21 > assertion > from an appropriate authority. > > Client Identity Agent Authority > > ------------------------- Service Please ------------ > > <--- Auth/Verify exchange, maybe even out of band ---- > > <------- Over 21 credential---------------------------- > <--------- Over 21 cred ---- > > > John > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 08 00:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoC93-0004C3-9M; Thu, 08 Jun 2006 00:29:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoC92-0004Bv-3q for dix@ietf.org; Thu, 08 Jun 2006 00:29:20 -0400 Received: from download.sappenin.net ([216.154.215.212] helo=sappenin.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoC90-0004Wv-UQ for dix@ietf.org; Thu, 08 Jun 2006 00:29:20 -0400 Received: from Genesis (adsl-69-209-158-147.dsl.sfldmi.ameritech.net [69.209.158.147]) by sappenin.net (8.12.11.20060308/8.12.10) with ESMTP id k584SLTA003176; Thu, 8 Jun 2006 00:28:22 -0400 From: "Sappenin Technologies LLC" To: Date: Thu, 8 Jun 2006 00:29:12 -0400 Organization: Sappenin Technologies LLC Message-ID: <001f01c68ab4$18145590$f864a8c0@Genesis> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKtBeOpMnjjmMMSEmESA2MMASNTA== X-Spam-Flag: NO X-Scanned-By: milter-spamc/0.25.321 ( [0.0.0.0]); Thu, 08 Jun 2006 00:28:25 -0400 X-Spam-Status: NO, hits=0.10 required=4.00 X-Spam-Level: X-Spam-Score: 0.1 (/) X-Scan-Signature: 28aa4dc616a7f0ac0889ef522e9e39ef Subject: [dix] Email Verification with Dix - a Possible Method? X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@sappenin.com, Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966078257==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0966078257== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C68A92.9102B590" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C68A92.9102B590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This post offers a discussion about incorporating some sort of email verification into the DIX protocol, either in the main DIX spec itself, or along-side DIX in a sub or related spec. In particular, I propose an email verification solution that allows domain owners to assert ownership over an email address, and link that ownership to a DIX persona-url. To be clear, I view the method proposed in this post as one method (of many possibilities) that DIX ServiceProviders _could_ use to high effectiveness. I'm not sure to what degree "email verification in DIX" has been discussed on this list, but I'd like to offer a few arguments in favor of my proposed scheme (or something like it), as well as a sample flow of how such a scheme might work in the context of DIX. Any feedback and/or comments are welcome. david info@sappenin.com -- First, the primary reason that DIX should have the capability to validate email addresses in particular (and not necessarily other "verifiable" pieces of information) is that most websites today use an email-address as a unique identifier (think username). When these sites transition to DIX, they (the sites) will rely on a persona-url being associated with, and possibly the actual owner of, a given email address. This is a lot of verification work to be done. Further, while the transition to DIX will move people to a persona-url-based identifier, and away from an email-based identifier, verified email addresses will still be required by each Service Provider that relies on the validity of an email address belonging to a given persona. It has been offered that external solutions already exist to solve the problem of email address verification, and as such, the challenge of such verification should _not_ be included in the DIX spec. Two common approaches that I have seen (that already exist outside of DIX) are as follows: Approach 1.) Use a 3rd party signed claim about the email address, where the service provider trusts the third party making the assertion. This is probably the most secure solution, since this would use some form of cryptographic signatures to assert validity. However, IMHO _many_ people are not going to go through the hassle of getting a "verified" email address. It will probably cost money (I'm thinking of Verisign), and the average person won't really understand the benefit of getting "verified", at least initially. Plus, it's one extra hassle for a person who already "owns" their email address. Approach 2.) The ServiceProvider does some sort of email verification once it receives the email address for the first time. e.g. - SP sends an email to saying "you signed up for geeknews.com, please click this link to complete your signup". This is not a terrible solution (many companies employ this today for email verification), although I have heard arguments against using such mechanisms. In the end, however, this solution requires end-user work at potentially every new Service Provider, which is annoying to the user, and may hinder anti-phishing initiatives (by continuing to confuse end-users trying to decipher legitimate from forged emails). It would be better if the end-user only needed to establish email ownership once (with their IdP), in a way that all ServiceProviders could then trust and verify (and that didn't necessarily involve a certificate-based 3rd party signed assertions that may or may not cost money/be difficult to use). Thus, I propose a third approach that allows domain owners to assert ownership over email addresses, and then link that ownership to a DIX persona-url via the DIX protocol (or DIX-like mechanisms). Approach 3.) Automatic Email Verification by a Service Provider We know that a given email is always owned by the domain that the email sits in. For example, microsoft.com is the authoritative domain for the email address . Likewise, sxip.com is authoritative for sxip.com email addresses, and so on. Therefore, the domain owner is the best entity to verify an email address! In lieu of a signed 3rd party assertion, or an email with a "verify-me" link, domain owners can facilitate email verification in the following way: 3.1) Service Provider receives a Fetch-Response with an email address that the SP wishes to verify. Assume the following: a1) The proposal introduces a new service called the "email_verification_service" that receives requests to validate a given email address. This service can run on any machine in any domain (more on this in later sections). a2) The DIX IdP's "Fetch-Response" contains a field called "email_verifier_hash" that is an SHA hash of 1.) Beth's persona's email address, and 2.) A secret number (preferably long) that only the email_verification_service knows. For example: SHA1(email_address + email_verification_secret_id) ==> SHA1("beth@example.com" + "A939....3939") ==> [email_verifier_hash]. To clarify, only the email_authentication_service knows what the email_verification_secret_id is. Conversely, the "email_verifier_hash" is given to the IdP upon account creation (once), and freely passed around between IdP, SP, and email_verifier_service. 3.2a) To verify the email address , the ServiceProvider navigates to http://example.com (the domain specified in Beth's email address), and follows the DIX discovery protocol to find a DIX.html file or the root document. *** This is despite the fact that Beth specified a different IdP during her regular DIX auth session.*** 3.2b) If http://example.com has no DIX capability, then fallback to email verification approaches 1 or 2 above, or possibly deny the login, or take some other measure. 3.3a) If http://example.com has DIX capability, then the root document (or DIX.html) might contain regular DIX Links, but will also contain a new link that indicates an endpoint URL that has email authority for the specified example.com domain. For example, the Link could be something like: . Alternatively, Beth's domain (example.com) might delegate this authority to an endpoint in a different domain using something like . Whatever the case, the example.com domain owner asserts this link since the domain owner should have control of the DIX.html or root html document in its domain. 3.3b) The designated 'email-endpoint' HREF is used as a service endpoint URL to determine if a given email address/persona-url combo is valid. This email_verification query would look something like this: ServiceProvider sends email-verification-endpoint (which is, e.g., http://www.verifier.com/smtp/endpoint) the following: a.) SHA1(email_address + email_verification_id), which is equivalent to the email_verifier_hash provided in the fetch response from the IdP. b.) persona-url=http://homesite.org/493838 ==> Also provided in the fetch response from the IdP. The email_verification_endpoint will perform a lookup based on the supplied information (email_verifier_hash and persona-url), and respond with something like "DIX:true" if the persona url actually "owns" the indicated email address. Otherwise, the response should be something like "DIX:false", or perhaps "DIX:unknown" if the verification_server is not sure(?). ** Notice that an eavesdropper will not know which email is being verified ** *** By proving (via domain ownership) that a given persona-url is linked to a given email address, the email_verification_service can vouch that a given persona-url controls or doesn't control a given email address.*** Potential Problems (and resolutions) -------- P1.) What if the secret email_verification_id is guessed or compromised? [Answer] First, the secret verification id is never passed out to remote sites, and should be different for each email address. If an attacker somehow figured out the secret email_verification_id, the attacker would still need to know the associated persona-url that matched the specified email address. In the worst case, if an attacker knew all 3 pieces of info (email address, persona-url, and secret key), he would only be able to figure out if a single email is valid for a given persona-url. It wouldn't tell the attacker anything more about the email address in question, nor about the persona's other personal info, nor about any other email addresses that may or may not exist. The secret key is really used to mask the email address so that a casual eavesdropper will not know which email is being verified, and to prevent spam trolling on the email_verification_service. P2.) Couldn't someone else's email_verification_service vouch for my email address without my permission? [Answer] No. The email_verification_protocol specifies that a Service Provider perform a DIX discovery at the root domain of the specified email address. So, example.com is the first place to go in order to verify any "example.com" email address. Only the specified domain of an email address can delegate to a different domain for email_verification (via DIX discovery). P3.) What if I don't control my domain's root page (i.e., a yahoo.com email address)? [Answer] Worst case, you would need to fallback on solution 1 or 2 above, or urge the entity that does control your domain to embrace DIX. P4.) How does the email_verification_service assert control over a given email address in the first place? [Answer] Basically, a user who actually controls an email address needs to login to the email_verification_service to get the process started. The mechanism employed for login is email_verification_service implementation-defined. The email_verification_service could have some non-DIX method of allowing a given user to login with their email address (perhaps using the same login/password that the email account uses, since the domain owner already knows this anyway). In any event, after somehow logging in, the user tells the email_verification_service what persona-url is linked to their specific email address(es), and the email_verification_service does the rest through the protocol. P5.) If the IdP and the email_verification service aren't the same thing (i.e., separate domains or servers), how do the IdP and the Email_Verification_Service share the secret email_verification_id for comparison purposes? [Answer] They don't. The IdP is given an SHA Hash of the "email address" + the secret email_verification_id. This hash value can then be sent out to various Service Providers, since this hash value is just another DIX parameter that gets filled in when a user creates a new IdP account. It is feasible that an email_verification_service could somehow use a DIX store method to propagate this information, but this requires further thought. SUMMARY ------- The main purpose of the email_verification_service is that a domain owner should be the one to vouch for who controls an email address. In addition, DIX ServiceProviders that use the proposed email_verification_service can automatically determine if a given persona-url is linked to a given email, and can trust that determination because it is made by the owners of the domain that controls the email address. In the final analysis, no continuing end-user interaction is required for each ServiceProvider that wishes to validate an email address. Plus, email_verification as laid out in this post is not a requirement. SP's could use alternative methods to verify an email if, for instance, a given email domain doesn't support the email verification service, or the SP determines that a stronger method of email verification should be used. ------=_NextPart_000_0020_01C68A92.9102B590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This post offers a discussion about incorporating = some sort of email verification into the DIX protocol, either in the main DIX spec itself, or along-side DIX in a sub or related spec.  In particular, = I propose an email verification solution that allows domain owners to = assert ownership over an email address, and link that ownership to a DIX persona-url.  To be clear, I view the method proposed in this post = as one method (of many possibilities) that DIX ServiceProviders _could_ use to = high effectiveness.

 

I'm not sure to what degree "email verification = in DIX" has been discussed on this list, but I'd like to offer a few arguments in favor of my proposed scheme (or something like it), as well = as a sample flow of how such a scheme might work in the context of DIX.  = Any feedback and/or comments are welcome.

 

david

info@sappenin.com

 

--

 

First, the primary reason that DIX should have the capability to validate email addresses in particular (and not = necessarily other “verifiable” pieces of information) is that most websites = today use an email-address as a unique identifier (think username).  When = these sites transition to DIX, they (the sites) will rely on a persona-url = being associated with, and possibly the actual owner of, a given email = address.  This is a lot of verification work to be done.  Further, while the transition to DIX will move people to a persona-url-based identifier, = and away from an email-based identifier, verified email addresses will still be = required by each Service Provider that relies on the validity of an email address belonging to a given persona.

 

It has been offered that external solutions already = exist to solve the problem of email address verification, and as such, the = challenge of such verification should _not_ be included in the DIX spec.  Two = common approaches that I have seen (that already exist outside of DIX) are as = follows:

 

Approach 1.) Use a 3rd party signed claim = about the email address, where the service provider trusts the third party = making the assertion.

This is probably the most secure solution, since this = would use some form of cryptographic signatures to assert validity.  = However, IMHO _many_ people are not going to go through the hassle of getting a "verified" email address.  It will probably cost money = (I'm thinking of Verisign), and the average person won't really understand = the benefit of getting "verified", at least initially.  Plus, it’s one extra hassle for a person who already “owns” = their email address.

 

Approach 2.) The ServiceProvider does some sort of = email verification once it receives the email address for the first = time.  e.g. - SP sends an email to <bill.gates@microsoft.com> saying "you = signed up for geeknews.com, please click this link to complete your = signup".  This is not a terrible solution (many companies employ this today for = email verification), although I have heard arguments against using such mechanisms.  In the end, however, this solution requires end-user = work at potentially every new Service Provider, which is annoying to the user, = and may hinder anti-phishing initiatives (by continuing to confuse end-users = trying to decipher legitimate from forged emails).

 

It would be better if the end-user only needed to = establish email ownership once (with their IdP), in a way that all = ServiceProviders could then trust and verify (and that didn't necessarily involve a = certificate-based 3rd party signed assertions that may or may not cost money/be difficult = to use).

 

Thus, I propose a third approach that allows domain = owners to assert ownership over email addresses, and then link that ownership = to a DIX persona-url via the DIX protocol (or DIX-like = mechanisms).

 

Approach 3.) Automatic Email Verification by a = Service Provider

 

We know that a given email is always owned by the = domain that the email sits in.  For example, microsoft.com is the = authoritative domain for the email address <bill.gates@microsoft.com>.  = Likewise, sxip.com is authoritative for sxip.com email addresses, and so on.  Therefore, the domain owner is the best entity to verify an email address!  In lieu of a signed 3rd party assertion, or an email with = a "verify-me" link, domain owners can facilitate email = verification in the following way:

 

3.1) Service Provider receives a Fetch-Response with = an email address <beth@example.com> that the SP wishes to = verify.  Assume the following:

 

         =    a1) The proposal introduces a new service called the "email_verification_service" that receives requests to = validate a given email address.  This service can run on any machine in any = domain (more on this in later sections).

 

a2) The DIX IdP's "Fetch-Response" contains a field called "email_verifier_hash" that is an SHA hash of 1.) Beth's = persona's email address, and 2.) A secret number (preferably long) that only the = email_verification_service knows.  For example: SHA1(email_address + = email_verification_secret_id) =3D=3D> SHA1("beth@example.com" + "A939....3939") = =3D=3D> [email_verifier_hash].  To clarify, only the = email_authentication_service knows what the email_verification_secret_id is.  Conversely, the "email_verifier_hash" is given to the IdP upon account = creation (once), and freely passed around between IdP, SP, and = email_verifier_service.

 

3.2a) To verify the email address = <beth@example.com>, the ServiceProvider navigates to http://example.com (the domain = specified in Beth’s email address), and follows the DIX discovery protocol to = find a DIX.html file or the root document. *** This is despite the fact that = Beth specified a different IdP during her regular DIX auth = session.***

3.2b) If http://example.com has no DIX capability, = then fallback to email verification approaches 1 or 2 above, or possibly deny = the login, or take some other measure.

 

3.3a) If http://example.com has DIX capability, then = the root document (or DIX.html) might contain regular DIX Links, but will = also contain a new link that indicates an endpoint URL that has email = authority for the specified example.com domain.  For example, the Link could be something like:  <LINK = REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"= HREF=3D"http://www.example.com/smtp/endpoint">.  = Alternatively, Beth's domain (example.com) might delegate this authority to an endpoint = in a different domain using something like <LINK = REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"= HREF=3D"http://www.verifier.com/smtp/endpoint">.  = Whatever the case, the example.com domain owner asserts this link since the domain = owner should have control of the DIX.html or root html document in its = domain.

 

3.3b) The designated 'email-endpoint' HREF is used as = a service endpoint URL to determine if a given email address/persona-url = combo is valid.  This email_verification query would look something like = this:

 

ServiceProvider sends email-verification-endpoint = (which is, e.g., http://www.verifier.com/smtp/endpoint) the = following:

a.) SHA1(email_address + email_verification_id), = which is equivalent to the email_verifier_hash provided in the fetch response = from the IdP.

b.) persona-url=3Dhttp://homesite.org/493838 = =3D=3D> Also provided in the fetch response from the = IdP.

 

The email_verification_endpoint will perform a lookup = based on the supplied information (email_verifier_hash and persona-url), and = respond with something like "DIX:true" if the persona url actually "owns" the indicated email address.  Otherwise, the = response should be something like "DIX:false", or perhaps "DIX:unknown" if the verification_server is not = sure(?).

 

** Notice that an eavesdropper will not know which = email is being verified **

*** By proving (via domain ownership) that a given persona-url is linked to a given email address, the = email_verification_service can vouch that a given persona-url controls or doesn't control a given = email address.***

 

 

Potential Problems (and = resolutions)

--------

P1.) What if the secret email_verification_id is = guessed or compromised?

[Answer] First, the secret verification id is never = passed out to remote sites, and should be different for each email = address.  If an attacker somehow figured out the secret email_verification_id, the = attacker would still need to know the associated persona-url that matched the = specified email address. 

 

In the worst case, if an attacker knew all 3 pieces = of info (email address, persona-url, and secret key), he would only be able to = figure out if a single email is valid for a given persona-url.  It = wouldn't tell the attacker anything more about the email address in question, nor = about the persona's other personal info, nor about any other email addresses that = may or may not exist.  The secret key is really used to mask the email = address so that a casual eavesdropper will not know which email is being verified, = and to prevent spam trolling on the = email_verification_service.

 

P2.) Couldn't someone else's = email_verification_service vouch for my email address without my = permission?

[Answer] No.  The email_verification_protocol = specifies that a Service Provider perform a DIX discovery at the root domain of = the specified email address.  So, example.com is the first place to go = in order to verify any "example.com" email address.  Only = the specified domain of an email address can delegate to a different domain = for email_verification (via DIX discovery).

 

P3.) What if I don't control my domain's root page = (i.e., a yahoo.com email address)?

[Answer] Worst case, you would need to fallback on = solution 1 or 2 above, or urge the entity that does control your domain to = embrace DIX.

 

P4.) How does the email_verification_service assert = control over a given email address in the first = place?

[Answer] Basically, a user who actually controls an = email address needs to login to the email_verification_service to get the = process started.  The mechanism employed for login is = email_verification_service implementation-defined.  The email_verification_service could have = some non-DIX method of allowing a given user to login with their email = address (perhaps using the same login/password that the email account uses, = since the domain owner already knows this anyway).  In any event, after = somehow logging in, the user tells the email_verification_service what = persona-url is linked to their specific email address(es), and the = email_verification_service does the rest through the protocol.

 

P5.) If the IdP and the email_verification service = aren't the same thing (i.e., separate domains or servers), how do the IdP and = the Email_Verification_Service share the secret email_verification_id for comparison purposes?

[Answer]  They don't.  The IdP is given an = SHA Hash of the "email address" + the secret = email_verification_id.  This hash value can then be sent out to various Service Providers, since = this hash value is just another DIX parameter that gets filled in when a user creates a new IdP account.  It is feasible that an email_verification_service could somehow use a DIX store method to = propagate this information, but this requires further = thought.

 

SUMMARY

-------

The main purpose of the email_verification_service is = that a domain owner should be the one to vouch for who controls an email address.   In addition, DIX ServiceProviders that use the = proposed email_verification_service can automatically determine if a given = persona-url is linked to a given email, and can trust that determination because it = is made by the owners of the domain that controls the email address.  In = the final analysis, no continuing end-user interaction is required for each ServiceProvider that wishes to validate an email address.  Plus, email_verification as laid out in this post is not a requirement.  SP’s could use alternative methods to verify an email if, for = instance, a given email domain doesn’t support the email verification service, = or the SP determines that a stronger method of email verification should be = used.

 

------=_NextPart_000_0020_01C68A92.9102B590-- --===============0966078257== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0966078257==-- From dix-bounces@ietf.org Thu Jun 08 02:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDsT-0002T2-HV; Thu, 08 Jun 2006 02:20:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoDsR-0002Sx-Qq for dix@ietf.org; Thu, 08 Jun 2006 02:20:19 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDsP-0003QO-U2 for dix@ietf.org; Thu, 08 Jun 2006 02:20:19 -0400 Received: from [192.168.1.100] (d154-5-108-31.bchsia.telus.net [154.5.108.31]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k586K88g044619 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 7 Jun 2006 23:20:12 -0700 (PDT) (envelope-from dick@sxip.com) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <001f01c68ab4$18145590$f864a8c0@Genesis> References: <001f01c68ab4$18145590$f864a8c0@Genesis> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Dick Hardt Subject: Re: [dix] Email Verification with Dix - a Possible Method? Date: Wed, 7 Jun 2006 23:18:38 -0700 To: info@sappenin.com, Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi David Interesting concept to distribute email verification. A modification=20=20 on it would be *if* we get secure DNS, that the domain would be able=20=20 to have a public key available and it could digitally sign the email=20=20 to the persona URL. This lets the world not have to *trust* a=20=20 centralized email verification service. Having said that, I think there is a good likelyhood that trusted=20=20 email verification services will be offered for free, which means=20=20 that A1 may become widely adopted if it is as simple as todays email=20=20 process, but that the user only has to do it once. Since only one (or=20=20 maybe a few) sites do the verification, each domain does not need to=20=20 do any config and the user can have any email address. To pick up on the value of verified email, there is another use of an=20=20 verified email address (or for the privacy conscience, a verified=20=20 hash of an email address). ACLs. It is a total pain to give certain=20=20 people access to a resource. Many of the private space wikis use=20=20 email invites. Taking that a step further, you enter in the email=20=20 addresses of who you would like to have access (email is an easy ID=20=20 for people), and your invitees prove they own that email address --=20=20 essentially it is the attribute that grants them access. -- Dick On 7-Jun-06, at 9:29 PM, Sappenin Technologies LLC wrote: > This post offers a discussion about incorporating some sort of=20=20 > email verification into the DIX protocol, either in the main DIX=20=20 > spec itself, or along-side DIX in a sub or related spec. In=20=20 > particular, I propose an email verification solution that allows=20=20 > domain owners to assert ownership over an email address, and link=20=20 > that ownership to a DIX persona-url. To be clear, I view the=20=20 > method proposed in this post as one method (of many possibilities)=20=20 > that DIX ServiceProviders _could_ use to high effectiveness. > > > > I'm not sure to what degree "email verification in DIX" has been=20=20 > discussed on this list, but I'd like to offer a few arguments in=20=20 > favor of my proposed scheme (or something like it), as well as a=20=20 > sample flow of how such a scheme might work in the context of DIX.=20=20= =20 > Any feedback and/or comments are welcome. > > > > david > > info@sappenin.com > > > > -- > > > > First, the primary reason that DIX should have the capability to=20=20 > validate email addresses in particular (and not necessarily other=20=20 > =93verifiable=94 pieces of information) is that most websites today use= =20=20 > an email-address as a unique identifier (think username). When=20=20 > these sites transition to DIX, they (the sites) will rely on a=20=20 > persona-url being associated with, and possibly the actual owner=20=20 > of, a given email address. This is a lot of verification work to=20=20 > be done. Further, while the transition to DIX will move people to=20=20 > a persona-url-based identifier, and away from an email-based=20=20 > identifier, verified email addresses will still be required by each=20=20 > Service Provider that relies on the validity of an email address=20=20 > belonging to a given persona. > > > > It has been offered that external solutions already exist to solve=20=20 > the problem of email address verification, and as such, the=20=20 > challenge of such verification should _not_ be included in the DIX=20=20 > spec. Two common approaches that I have seen (that already exist=20=20 > outside of DIX) are as follows: > > > > Approach 1.) Use a 3rd party signed claim about the email address,=20=20 > where the service provider trusts the third party making the=20=20 > assertion. > > This is probably the most secure solution, since this would use=20=20 > some form of cryptographic signatures to assert validity. However,=20=20 > IMHO _many_ people are not going to go through the hassle of=20=20 > getting a "verified" email address. It will probably cost money=20=20 > (I'm thinking of Verisign), and the average person won't really=20=20 > understand the benefit of getting "verified", at least initially.=20=20= =20 > Plus, it=92s one extra hassle for a person who already =93owns=94 their= =20=20 > email address. > > > > Approach 2.) The ServiceProvider does some sort of email=20=20 > verification once it receives the email address for the first=20=20 > time. e.g. - SP sends an email to =20=20 > saying "you signed up for geeknews.com, please click this link to=20=20 > complete your signup". This is not a terrible solution (many=20=20 > companies employ this today for email verification), although I=20=20 > have heard arguments against using such mechanisms. In the end,=20=20 > however, this solution requires end-user work at potentially every=20=20 > new Service Provider, which is annoying to the user, and may hinder=20=20 > anti-phishing initiatives (by continuing to confuse end-users=20=20 > trying to decipher legitimate from forged emails). > > > > It would be better if the end-user only needed to establish email=20=20 > ownership once (with their IdP), in a way that all ServiceProviders=20=20 > could then trust and verify (and that didn't necessarily involve a=20=20 > certificate-based 3rd party signed assertions that may or may not=20=20 > cost money/be difficult to use). > > > > Thus, I propose a third approach that allows domain owners to=20=20 > assert ownership over email addresses, and then link that ownership=20=20 > to a DIX persona-url via the DIX protocol (or DIX-like mechanisms). > > > > Approach 3.) Automatic Email Verification by a Service Provider > > > > We know that a given email is always owned by the domain that the=20=20 > email sits in. For example, microsoft.com is the authoritative=20=20 > domain for the email address . Likewise,=20=20 > sxip.com is authoritative for sxip.com email addresses, and so on.=20=20= =20 > Therefore, the domain owner is the best entity to verify an email=20=20 > address! In lieu of a signed 3rd party assertion, or an email with=20=20 > a "verify-me" link, domain owners can facilitate email verification=20=20 > in the following way: > > > > 3.1) Service Provider receives a Fetch-Response with an email=20=20 > address that the SP wishes to verify. Assume=20=20 > the following: > > > > a1) The proposal introduces a new service called the=20=20 > "email_verification_service" that receives requests to validate a=20=20 > given email address. This service can run on any machine in any=20=20 > domain (more on this in later sections). > > > > a2) The DIX IdP's "Fetch-Response" contains a field called=20=20 > "email_verifier_hash" that is an SHA hash of 1.) Beth's persona's=20=20 > email address, and 2.) A secret number (preferably long) that only=20=20 > the email_verification_service knows. For example: SHA1=20 > (email_address + email_verification_secret_id) =3D=3D> SHA1=20 > ("beth@example.com" + "A939....3939") =3D=3D> [email_verifier_hash].=20= =20=20 > To clarify, only the email_authentication_service knows what the=20=20 > email_verification_secret_id is. Conversely, the=20=20 > "email_verifier_hash" is given to the IdP upon account creation=20=20 > (once), and freely passed around between IdP, SP, and=20=20 > email_verifier_service. > > > > 3.2a) To verify the email address , the=20=20 > ServiceProvider navigates to http://example.com (the domain=20=20 > specified in Beth=92s email address), and follows the DIX discovery=20=20 > protocol to find a DIX.html file or the root document. *** This is=20=20 > despite the fact that Beth specified a different IdP during her=20=20 > regular DIX auth session.*** > > 3.2b) If http://example.com has no DIX capability, then fallback to=20=20 > email verification approaches 1 or 2 above, or possibly deny the=20=20 > login, or take some other measure. > > > > 3.3a) If http://example.com has DIX capability, then the root=20=20 > document (or DIX.html) might contain regular DIX Links, but will=20=20 > also contain a new link that indicates an endpoint URL that has=20=20 > email authority for the specified example.com domain. For example,=20=20 > the Link could be something like: REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"=20=20 > HREF=3D"http://www.example.com/smtp/endpoint">. Alternatively,=20=20 > Beth's domain (example.com) might delegate this authority to an=20=20 > endpoint in a different domain using something like REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"=20=20 > HREF=3D"http://www.verifier.com/smtp/endpoint">. Whatever the case,=20= =20 > the example.com domain owner asserts this link since the domain=20=20 > owner should have control of the DIX.html or root html document in=20=20 > its domain. > > > > 3.3b) The designated 'email-endpoint' HREF is used as a service=20=20 > endpoint URL to determine if a given email address/persona-url=20=20 > combo is valid. This email_verification query would look something=20=20 > like this: > > > > ServiceProvider sends email-verification-endpoint (which is, e.g.,=20=20 > http://www.verifier.com/smtp/endpoint) the following: > > a.) SHA1(email_address + email_verification_id), which is=20=20 > equivalent to the email_verifier_hash provided in the fetch=20=20 > response from the IdP. > > b.) persona-url=3Dhttp://homesite.org/493838 =3D=3D> Also provided in the= =20=20 > fetch response from the IdP. > > > > The email_verification_endpoint will perform a lookup based on the=20=20 > supplied information (email_verifier_hash and persona-url), and=20=20 > respond with something like "DIX:true" if the persona url actually=20=20 > "owns" the indicated email address. Otherwise, the response should=20=20 > be something like "DIX:false", or perhaps "DIX:unknown" if the=20=20 > verification_server is not sure(?). > > > > ** Notice that an eavesdropper will not know which email is being=20=20 > verified ** > > *** By proving (via domain ownership) that a given persona-url is=20=20 > linked to a given email address, the email_verification_service can=20=20 > vouch that a given persona-url controls or doesn't control a given=20=20 > email address.*** > > > > > > Potential Problems (and resolutions) > > -------- > > P1.) What if the secret email_verification_id is guessed or=20=20 > compromised? > > [Answer] First, the secret verification id is never passed out to=20=20 > remote sites, and should be different for each email address. If=20=20 > an attacker somehow figured out the secret email_verification_id,=20=20 > the attacker would still need to know the associated persona-url=20=20 > that matched the specified email address. > > > > In the worst case, if an attacker knew all 3 pieces of info (email=20=20 > address, persona-url, and secret key), he would only be able to=20=20 > figure out if a single email is valid for a given persona-url. It=20=20 > wouldn't tell the attacker anything more about the email address in=20=20 > question, nor about the persona's other personal info, nor about=20=20 > any other email addresses that may or may not exist. The secret=20=20 > key is really used to mask the email address so that a casual=20=20 > eavesdropper will not know which email is being verified, and to=20=20 > prevent spam trolling on the email_verification_service. > > > > P2.) Couldn't someone else's email_verification_service vouch for=20=20 > my email address without my permission? > > [Answer] No. The email_verification_protocol specifies that a=20=20 > Service Provider perform a DIX discovery at the root domain of the=20=20 > specified email address. So, example.com is the first place to go=20=20 > in order to verify any "example.com" email address. Only the=20=20 > specified domain of an email address can delegate to a different=20=20 > domain for email_verification (via DIX discovery). > > > > P3.) What if I don't control my domain's root page (i.e., a=20=20 > yahoo.com email address)? > > [Answer] Worst case, you would need to fallback on solution 1 or 2=20=20 > above, or urge the entity that does control your domain to embrace=20=20 > DIX. > > > > P4.) How does the email_verification_service assert control over a=20=20 > given email address in the first place? > > [Answer] Basically, a user who actually controls an email address=20=20 > needs to login to the email_verification_service to get the process=20=20 > started. The mechanism employed for login is=20=20 > email_verification_service implementation-defined. The=20=20 > email_verification_service could have some non-DIX method of=20=20 > allowing a given user to login with their email address (perhaps=20=20 > using the same login/password that the email account uses, since=20=20 > the domain owner already knows this anyway). In any event, after=20=20 > somehow logging in, the user tells the email_verification_service=20=20 > what persona-url is linked to their specific email address(es), and=20=20 > the email_verification_service does the rest through the protocol. > > > > P5.) If the IdP and the email_verification service aren't the same=20=20 > thing (i.e., separate domains or servers), how do the IdP and the=20=20 > Email_Verification_Service share the secret email_verification_id=20=20 > for comparison purposes? > > [Answer] They don't. The IdP is given an SHA Hash of the "email=20=20 > address" + the secret email_verification_id. This hash value can=20=20 > then be sent out to various Service Providers, since this hash=20=20 > value is just another DIX parameter that gets filled in when a user=20=20 > creates a new IdP account. It is feasible that an=20=20 > email_verification_service could somehow use a DIX store method to=20=20 > propagate this information, but this requires further thought. > > > > SUMMARY > > ------- > > The main purpose of the email_verification_service is that a domain=20=20 > owner should be the one to vouch for who controls an email=20=20 > address. In addition, DIX ServiceProviders that use the proposed=20=20 > email_verification_service can automatically determine if a given=20=20 > persona-url is linked to a given email, and can trust that=20=20 > determination because it is made by the owners of the domain that=20=20 > controls the email address. In the final analysis, no continuing=20=20 > end-user interaction is required for each ServiceProvider that=20=20 > wishes to validate an email address. Plus, email_verification as=20=20 > laid out in this post is not a requirement. SP=92s could use=20=20 > alternative methods to verify an email if, for instance, a given=20=20 > email domain doesn=92t support the email verification service, or the=20= =20 > SP determines that a stronger method of email verification should=20=20 > be used. > > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 08 11:05:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoM52-0006Mf-6r; Thu, 08 Jun 2006 11:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoM50-0006MP-Ji for dix@ietf.org; Thu, 08 Jun 2006 11:05:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoM50-0005HB-I6 for dix@ietf.org; Thu, 08 Jun 2006 11:05:50 -0400 Received: from nz-out-0102.google.com ([64.233.162.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoM2v-00019d-0k for dix@ietf.org; Thu, 08 Jun 2006 11:03:41 -0400 Received: by nz-out-0102.google.com with SMTP id 40so402548nzk for ; Thu, 08 Jun 2006 08:03:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=fnweDiJP5ZKEZWso8fDXzqP4CbiaFBLzjbcJJZ8iuWssHxqUK3OSnP5Rr8C8//fhhBRo4qm9zsg+owYQJcutwkn307CtTc6ZOxOol+7F0UEv2QMsdybBmihL1R6jLCrebDE+sNSMzIC12Tt7KkWxvz3TBpHmxC0XIW2PpDc9iPE= Received: by 10.36.247.27 with SMTP id u27mr2516602nzh; Thu, 08 Jun 2006 08:03:40 -0700 (PDT) Received: from Genesis ( [69.209.158.147]) by mx.gmail.com with ESMTP id 36sm1391472nza.2006.06.08.08.03.39; Thu, 08 Jun 2006 08:03:39 -0700 (PDT) From: "David Fuelling" To: "'Digital Identity Exchange'" Subject: RE: [dix] Email Verification with Dix - a Possible Method? Date: Thu, 8 Jun 2006 11:03:36 -0400 Message-ID: <005801c68b0c$b7f912a0$f864a8c0@Genesis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: thread-index: AcaKw43d8w8MlhJlS7GWyxoUAhR+VAASNhvQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -2.5 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Dick, Great points, especially wrt to secure DNS. DH> Interesting concept to distribute email verification. A modification DH> on it would be *if* we get secure DNS, that the domain would be able DH> to have a public key available and it could digitally sign the email DH> to the persona URL. This lets the world not have to *trust* a DH> centralized email verification service. Just to clarify (not sure if you actually meant this or not) that the scheme I had in mind would allow an email_verification_service at every domain (potentially). If a given domain didn't want to actually run the verification service, they could delegate the responsibility to whomever, via dix discovery. There wouldn't be a centralized verification service (unless everybody delegated to the same service). You're right, though...secure DNS could make the whole thing much more secure (although, in the current DNS system, it seems like it would be pretty difficult for a random attacker somewhere on the net to spoof a conversation between a random email address domain and a random SP. It seems to me that the attacker would probably need to have compromised the SP or the email_verification_service, or an ISP thereof to perform a DNS spoofing attack)....though I'm not an expert in that realm. David sappenin@gmail.com > -----Original Message----- > From: Dick Hardt [mailto:dick@sxip.com] > Sent: Thursday, June 08, 2006 2:19 AM > To: info@sappenin.com; Digital Identity Exchange > Subject: Re: [dix] Email Verification with Dix - a Possible Method? > > Hi David > > Interesting concept to distribute email verification. A modification > on it would be *if* we get secure DNS, that the domain would be able > to have a public key available and it could digitally sign the email > to the persona URL. This lets the world not have to *trust* a > centralized email verification service. > > Having said that, I think there is a good likelyhood that trusted > email verification services will be offered for free, which means > that A1 may become widely adopted if it is as simple as todays email > process, but that the user only has to do it once. Since only one (or > maybe a few) sites do the verification, each domain does not need to > do any config and the user can have any email address. > > To pick up on the value of verified email, there is another use of an > verified email address (or for the privacy conscience, a verified > hash of an email address). ACLs. It is a total pain to give certain > people access to a resource. Many of the private space wikis use > email invites. Taking that a step further, you enter in the email > addresses of who you would like to have access (email is an easy ID > for people), and your invitees prove they own that email address -- > essentially it is the attribute that grants them access. > > -- Dick _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 08 12:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNYa-0000Oh-5K; Thu, 08 Jun 2006 12:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoNYY-0000Oc-FL for dix@ietf.org; Thu, 08 Jun 2006 12:40:26 -0400 Received: from nz-out-0102.google.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoNYX-0003I4-Vm for dix@ietf.org; Thu, 08 Jun 2006 12:40:26 -0400 Received: by nz-out-0102.google.com with SMTP id q3so451300nzb for ; Thu, 08 Jun 2006 09:40:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index; b=XBAHhoVG8mn19HxnVFO1UUPYlm0fayNQnD2kJMmUIz43zCu7SbbUwkq0ryNbZ8XZR5WdZkEi/+ZLcvYXmFCe9rI3UiFZ7oScth/DXu48TJ6eMauACmyxkNGsQtnoWshQm1k3ALv87kb9LcUY59aftRnMesigWPiwDUy7e47xxRA= Received: by 10.36.215.18 with SMTP id n18mr2637418nzg; Thu, 08 Jun 2006 09:40:25 -0700 (PDT) Received: from Genesis ( [69.209.158.147]) by mx.gmail.com with ESMTP id 15sm2917689nzp.2006.06.08.09.40.23; Thu, 08 Jun 2006 09:40:24 -0700 (PDT) From: "David Fuelling" To: "'Digital Identity Exchange'" Subject: RE: [dix] Email Verification with Dix - a Possible Method? Date: Thu, 8 Jun 2006 12:40:19 -0400 Message-ID: <000d01c68b1a$3bad9500$f964a8c0@Genesis> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcaLGjqwlyHc6ZOYS7yEaPbGAstm3w== X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0035478089==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0035478089== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C68AF8.B49BF500" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C68AF8.B49BF500 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Dick, Great points, especially wrt to secure DNS. DH> Interesting concept to distribute email verification. A modification DH> on it would be *if* we get secure DNS, that the domain would be able DH> to have a public key available and it could digitally sign the email DH> to the persona URL. This lets the world not have to *trust* a DH> centralized email verification service. Just to clarify (not sure if you actually meant this or not) that the scheme I had in mind would allow an email_verification_service at every domain (potentially). If a given domain didn't want to actually run the verification service, they could delegate the responsibility to whomever, via dix discovery. There wouldn't be a centralized verification service (unless everybody delegated to the same service). You're right, though...secure DNS could make the whole thing much more secure (although, in the current DNS system, it seems like it would be pretty difficult for a random attacker somewhere on the net to spoof a conversation between a random email address domain and a random SP. It seems to me that the attacker would probably need to have compromised the SP or the email_verification_service, or an ISP thereof to perform a DNS spoofing attack)....though I'm not an expert in that realm. David sappenin@gmail.com > -----Original Message----- > From: Dick Hardt [mailto:dick@sxip.com] > Sent: Thursday, June 08, 2006 2:19 AM > To: info@sappenin.com; Digital Identity Exchange > Subject: Re: [dix] Email Verification with Dix - a Possible Method? > > Hi David > > Interesting concept to distribute email verification. A modification > on it would be *if* we get secure DNS, that the domain would be able > to have a public key available and it could digitally sign the email > to the persona URL. This lets the world not have to *trust* a > centralized email verification service. > > Having said that, I think there is a good likelyhood that trusted > email verification services will be offered for free, which means > that A1 may become widely adopted if it is as simple as todays email > process, but that the user only has to do it once. Since only one (or > maybe a few) sites do the verification, each domain does not need to > do any config and the user can have any email address. > > To pick up on the value of verified email, there is another use of an > verified email address (or for the privacy conscience, a verified > hash of an email address). ACLs. It is a total pain to give certain > people access to a resource. Many of the private space wikis use > email invites. Taking that a step further, you enter in the email > addresses of who you would like to have access (email is an easy ID > for people), and your invitees prove they own that email address -- > essentially it is the attribute that grants them access. > > -- Dick ------=_NextPart_000_000E_01C68AF8.B49BF500 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Dick,

 

Great points, = especially wrt to secure DNS. 

 

DH> Interesting = concept to distribute email verification. A modification =

DH> on it would = be *if* we get secure DNS, that the domain would be able =

DH> to have a = public key available and it could digitally sign the email =

DH> to the = persona URL. This lets the world not have to *trust* a

DH> centralized = email verification service.

 

Just to clarify = (not sure if you actually meant this or not) that the scheme I had in mind would = allow an email_verification_service at every domain (potentially).  If a = given domain didn't want to actually run the verification service, they could = delegate the responsibility to whomever, via dix discovery.  There wouldn't be a = centralized verification service (unless everybody delegated to the same = service). 

 

You're right, though...secure DNS could make the whole thing much more secure = (although, in the current DNS system, it seems like it would be pretty difficult for a = random attacker somewhere on the net to spoof a conversation between a random = email address domain and a random SP.  It seems to me that the attacker = would probably need to have compromised the SP or the = email_verification_service, or an ISP thereof to perform a DNS spoofing attack)....though I'm not an = expert in that realm.

 

David

sappenin@gmail.com

 

> -----Original Message-----

> From: Dick = Hardt [mailto:dick@sxip.com]=

> Sent: = Thursday, June 08, 2006 2:19 AM

> To: = info@sappenin.com; Digital Identity Exchange

> Subject: Re: = [dix] Email Verification with Dix - a Possible = Method?

> =

> Hi = David

> =

> Interesting = concept to distribute email verification. A = modification

> on it would be = *if* we get secure DNS, that the domain would be = able

> to have a = public key available and it could digitally sign the = email

> to the persona = URL. This lets the world not have to *trust* a

> centralized = email verification service.

> =

> Having said = that, I think there is a good likelyhood that = trusted

> email = verification services will be offered for free, which = means

> that A1 may = become widely adopted if it is as simple as todays = email

> process, but = that the user only has to do it once. Since only one = (or

> maybe a few) = sites do the verification, each domain does not need = to

> do any config = and the user can have any email address.

> =

> To pick up on = the value of verified email, there is another use of = an

> verified email = address (or for the privacy conscience, a verified

> hash of an = email address). ACLs. It is a total pain to give = certain

> people access = to a resource. Many of the private space wikis = use

> email invites. = Taking that a step further, you enter in the email

> addresses of = who you would like to have access (email is an easy = ID

> for people), = and your invitees prove they own that email address = --

> essentially it = is the attribute that grants them access.

> =

> -- = Dick

 

------=_NextPart_000_000E_01C68AF8.B49BF500-- --===============0035478089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0035478089==-- From dix-bounces@ietf.org Thu Jun 08 13:10:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoO1F-0006y2-UX; Thu, 08 Jun 2006 13:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoO1E-0006xx-DJ for dix@ietf.org; Thu, 08 Jun 2006 13:10:04 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoO1A-0008As-ES for dix@ietf.org; Thu, 08 Jun 2006 13:10:04 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k58H9xhw011273; Thu, 8 Jun 2006 10:09:59 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 10:09:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [dix] Email Verification with Dix - a Possible Method? Date: Thu, 8 Jun 2006 10:09:50 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B55910@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dix] Email Verification with Dix - a Possible Method? Thread-Index: AcaKtBeOpMnjjmMMSEmESA2MMASNTAAajCrA From: "Hallam-Baker, Phillip" To: , "Digital Identity Exchange" X-OriginalArrivalTime: 08 Jun 2006 17:09:51.0463 (UTC) FILETIME=[5AC2BF70:01C68B1E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 23e0dc5390f90c078cbc69ce4ec79f98 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0564988155==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0564988155== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68B1E.5A642454" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68B1E.5A642454 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take a look at Domain Keys Identified Mail. ________________________________ From: Sappenin Technologies LLC [mailto:info@sappenin.com]=20 Sent: Thursday, June 08, 2006 12:29 AM To: dix@ietf.org Subject: [dix] Email Verification with Dix - a Possible Method? =09 =09 This post offers a discussion about incorporating some sort of email = verification into the DIX protocol, either in the main DIX spec itself, = or along-side DIX in a sub or related spec. In particular, I propose an = email verification solution that allows domain owners to assert = ownership over an email address, and link that ownership to a DIX = persona-url. To be clear, I view the method proposed in this post as = one method (of many possibilities) that DIX ServiceProviders _could_ use = to high effectiveness. =20 I'm not sure to what degree "email verification in DIX" has been = discussed on this list, but I'd like to offer a few arguments in favor = of my proposed scheme (or something like it), as well as a sample flow = of how such a scheme might work in the context of DIX. Any feedback = and/or comments are welcome. =20 david info@sappenin.com =20 -- =20 First, the primary reason that DIX should have the capability to = validate email addresses in particular (and not necessarily other = "verifiable" pieces of information) is that most websites today use an = email-address as a unique identifier (think username). When these sites = transition to DIX, they (the sites) will rely on a persona-url being = associated with, and possibly the actual owner of, a given email = address. This is a lot of verification work to be done. Further, while = the transition to DIX will move people to a persona-url-based = identifier, and away from an email-based identifier, verified email = addresses will still be required by each Service Provider that relies on = the validity of an email address belonging to a given persona. =20 It has been offered that external solutions already exist to solve the = problem of email address verification, and as such, the challenge of = such verification should _not_ be included in the DIX spec. Two common = approaches that I have seen (that already exist outside of DIX) are as = follows: =20 Approach 1.) Use a 3rd party signed claim about the email address, = where the service provider trusts the third party making the assertion. This is probably the most secure solution, since this would use some = form of cryptographic signatures to assert validity. However, IMHO = _many_ people are not going to go through the hassle of getting a = "verified" email address. It will probably cost money (I'm thinking of = Verisign), and the average person won't really understand the benefit of = getting "verified", at least initially. Plus, it's one extra hassle for = a person who already "owns" their email address. =20 Approach 2.) The ServiceProvider does some sort of email verification = once it receives the email address for the first time. e.g. - SP sends = an email to saying "you signed up for = geeknews.com, please click this link to complete your signup". This is = not a terrible solution (many companies employ this today for email = verification), although I have heard arguments against using such = mechanisms. In the end, however, this solution requires end-user work = at potentially every new Service Provider, which is annoying to the = user, and may hinder anti-phishing initiatives (by continuing to confuse = end-users trying to decipher legitimate from forged emails). =20 It would be better if the end-user only needed to establish email = ownership once (with their IdP), in a way that all ServiceProviders = could then trust and verify (and that didn't necessarily involve a = certificate-based 3rd party signed assertions that may or may not cost = money/be difficult to use). =20 Thus, I propose a third approach that allows domain owners to assert = ownership over email addresses, and then link that ownership to a DIX = persona-url via the DIX protocol (or DIX-like mechanisms). =20 Approach 3.) Automatic Email Verification by a Service Provider =20 We know that a given email is always owned by the domain that the email = sits in. For example, microsoft.com is the authoritative domain for the = email address . Likewise, sxip.com is = authoritative for sxip.com email addresses, and so on. Therefore, the = domain owner is the best entity to verify an email address! In lieu of = a signed 3rd party assertion, or an email with a "verify-me" link, = domain owners can facilitate email verification in the following way: =20 3.1) Service Provider receives a Fetch-Response with an email address = that the SP wishes to verify. Assume the following: =20 a1) The proposal introduces a new service called the = "email_verification_service" that receives requests to validate a given = email address. This service can run on any machine in any domain (more = on this in later sections). =20 a2) The DIX IdP's "Fetch-Response" contains a field called = "email_verifier_hash" that is an SHA hash of 1.) Beth's persona's email = address, and 2.) A secret number (preferably long) that only the = email_verification_service knows. For example: SHA1(email_address + = email_verification_secret_id) =3D=3D> SHA1("beth@example.com" + = "A939....3939") =3D=3D> [email_verifier_hash]. To clarify, only the = email_authentication_service knows what the email_verification_secret_id = is. Conversely, the "email_verifier_hash" is given to the IdP upon = account creation (once), and freely passed around between IdP, SP, and = email_verifier_service. =20 3.2a) To verify the email address , the = ServiceProvider navigates to http://example.com (the domain specified in = Beth's email address), and follows the DIX discovery protocol to find a = DIX.html file or the root document. *** This is despite the fact that = Beth specified a different IdP during her regular DIX auth session.*** 3.2b) If http://example.com has no DIX capability, then fallback to = email verification approaches 1 or 2 above, or possibly deny the login, = or take some other measure. =20 3.3a) If http://example.com has DIX capability, then the root document = (or DIX.html) might contain regular DIX Links, but will also contain a = new link that indicates an endpoint URL that has email authority for the = specified example.com domain. For example, the Link could be something = like: . Alternatively, Beth's = domain (example.com) might delegate this authority to an endpoint in a = different domain using something like . Whatever the case, the = example.com domain owner asserts this link since the domain owner should = have control of the DIX.html or root html document in its domain. =20 3.3b) The designated 'email-endpoint' HREF is used as a service = endpoint URL to determine if a given email address/persona-url combo is = valid. This email_verification query would look something like this: =20 ServiceProvider sends email-verification-endpoint (which is, e.g., = http://www.verifier.com/smtp/endpoint) the following: a.) SHA1(email_address + email_verification_id), which is equivalent to = the email_verifier_hash provided in the fetch response from the IdP. b.) persona-url=3Dhttp://homesite.org/493838 =3D=3D> Also provided in = the fetch response from the IdP. =20 The email_verification_endpoint will perform a lookup based on the = supplied information (email_verifier_hash and persona-url), and respond = with something like "DIX:true" if the persona url actually "owns" the = indicated email address. Otherwise, the response should be something = like "DIX:false", or perhaps "DIX:unknown" if the verification_server is = not sure(?). =20 ** Notice that an eavesdropper will not know which email is being = verified ** *** By proving (via domain ownership) that a given persona-url is = linked to a given email address, the email_verification_service can = vouch that a given persona-url controls or doesn't control a given email = address.*** =20 =20 Potential Problems (and resolutions) -------- P1.) What if the secret email_verification_id is guessed or = compromised? [Answer] First, the secret verification id is never passed out to = remote sites, and should be different for each email address. If an = attacker somehow figured out the secret email_verification_id, the = attacker would still need to know the associated persona-url that = matched the specified email address. =20 =20 In the worst case, if an attacker knew all 3 pieces of info (email = address, persona-url, and secret key), he would only be able to figure = out if a single email is valid for a given persona-url. It wouldn't = tell the attacker anything more about the email address in question, nor = about the persona's other personal info, nor about any other email = addresses that may or may not exist. The secret key is really used to = mask the email address so that a casual eavesdropper will not know which = email is being verified, and to prevent spam trolling on the = email_verification_service. =20 P2.) Couldn't someone else's email_verification_service vouch for my = email address without my permission? [Answer] No. The email_verification_protocol specifies that a Service = Provider perform a DIX discovery at the root domain of the specified = email address. So, example.com is the first place to go in order to = verify any "example.com" email address. Only the specified domain of an = email address can delegate to a different domain for email_verification = (via DIX discovery). =20 P3.) What if I don't control my domain's root page (i.e., a yahoo.com = email address)? [Answer] Worst case, you would need to fallback on solution 1 or 2 = above, or urge the entity that does control your domain to embrace DIX. =20 P4.) How does the email_verification_service assert control over a = given email address in the first place? [Answer] Basically, a user who actually controls an email address needs = to login to the email_verification_service to get the process started. = The mechanism employed for login is email_verification_service = implementation-defined. The email_verification_service could have some = non-DIX method of allowing a given user to login with their email = address (perhaps using the same login/password that the email account = uses, since the domain owner already knows this anyway). In any event, = after somehow logging in, the user tells the email_verification_service = what persona-url is linked to their specific email address(es), and the = email_verification_service does the rest through the protocol. =20 P5.) If the IdP and the email_verification service aren't the same = thing (i.e., separate domains or servers), how do the IdP and the = Email_Verification_Service share the secret email_verification_id for = comparison purposes? [Answer] They don't. The IdP is given an SHA Hash of the "email = address" + the secret email_verification_id. This hash value can then = be sent out to various Service Providers, since this hash value is just = another DIX parameter that gets filled in when a user creates a new IdP = account. It is feasible that an email_verification_service could = somehow use a DIX store method to propagate this information, but this = requires further thought. =20 SUMMARY ------- The main purpose of the email_verification_service is that a domain = owner should be the one to vouch for who controls an email address. In = addition, DIX ServiceProviders that use the proposed = email_verification_service can automatically determine if a given = persona-url is linked to a given email, and can trust that determination = because it is made by the owners of the domain that controls the email = address. In the final analysis, no continuing end-user interaction is = required for each ServiceProvider that wishes to validate an email = address. Plus, email_verification as laid out in this post is not a = requirement. SP's could use alternative methods to verify an email if, = for instance, a given email domain doesn't support the email = verification service, or the SP determines that a stronger method of = email verification should be used. =20 ------_=_NextPart_001_01C68B1E.5A642454 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Take a look at Domain Keys Identified=20 Mail.

From: Sappenin Technologies LLC=20 [mailto:info@sappenin.com]
Sent: Thursday, June 08, 2006 = 12:29=20 AM
To: dix@ietf.org
Subject: [dix] Email = Verification with=20 Dix - a Possible Method?

This post offers a = discussion=20 about incorporating some sort of email verification into the DIX = protocol,=20 either in the main DIX spec itself, or along-side DIX in a sub or = related=20 spec.  In particular, I propose an email verification solution = that=20 allows domain owners to assert ownership over an email address, and = link that=20 ownership to a DIX persona-url.  To be clear, I view the method = proposed=20 in this post as one method (of many possibilities) that DIX = ServiceProviders=20 _could_ use to high effectiveness.

 

I'm not sure to what = degree "email=20 verification in DIX" has been discussed on this list, but I'd like to = offer a=20 few arguments in favor of my proposed scheme (or something like it), = as well=20 as a sample flow of how such a scheme might work in the context of = DIX. =20 Any feedback and/or comments are welcome.

 

david

info@sappenin.com

 

--

 

First, the primary = reason that DIX=20 should have the capability to validate email addresses in particular = (and not=20 necessarily other =93verifiable=94 pieces of information) is that most = websites=20 today use an email-address as a unique identifier (think = username).  When=20 these sites transition to DIX, they (the sites) will rely on a = persona-url=20 being associated with, and possibly the actual owner of, a given email = address.  This is a lot of verification work to be done.  = Further,=20 while the transition to DIX will move people to a persona-url-based=20 identifier, and away from an email-based identifier, verified email = addresses=20 will still be required by each Service Provider that relies on the = validity of=20 an email address belonging to a given = persona.

 

It has been offered that = external=20 solutions already exist to solve the problem of email address = verification,=20 and as such, the challenge of such verification should _not_ be = included in=20 the DIX spec.  Two common approaches that I have seen (that = already exist=20 outside of DIX) are as follows:

 

Approach 1.) Use a = 3rd=20 party signed claim about the email address, where the service provider = trusts=20 the third party making the assertion.

This is probably the = most secure=20 solution, since this would use some form of cryptographic signatures = to assert=20 validity.  However, IMHO _many_ people are not going to go = through the=20 hassle of getting a "verified" email address.  It will probably = cost=20 money (I'm thinking of Verisign), and the average person won't really=20 understand the benefit of getting "verified", at least = initially.  Plus,=20 it=92s one extra hassle for a person who already =93owns=94 their = email=20 address.

 

Approach 2.) The = ServiceProvider=20 does some sort of email verification once it receives the email = address for=20 the first time.  e.g. - SP sends an email to=20 <bill.gates@microsoft.com> saying "you signed up for = geeknews.com,=20 please click this link to complete your signup".  This is not a = terrible=20 solution (many companies employ this today for email verification), = although I=20 have heard arguments against using such mechanisms.  In the end, = however,=20 this solution requires end-user work at potentially every new Service=20 Provider, which is annoying to the user, and may hinder anti-phishing=20 initiatives (by continuing to confuse end-users trying to decipher = legitimate=20 from forged emails).

 

It would be better if = the end-user=20 only needed to establish email ownership once (with their IdP), in a = way that=20 all ServiceProviders could then trust and verify (and that didn't = necessarily=20 involve a certificate-based 3rd party signed assertions that may or = may not=20 cost money/be difficult to use).

 

Thus, I propose a third = approach=20 that allows domain owners to assert ownership over email addresses, = and then=20 link that ownership to a DIX persona-url via the DIX protocol (or = DIX-like=20 mechanisms).

 

Approach 3.) Automatic = Email=20 Verification by a Service Provider

 

We know that a given = email is=20 always owned by the domain that the email sits in.  For example,=20 microsoft.com is the authoritative domain for the email address=20 <bill.gates@microsoft.com>.  Likewise, sxip.com is = authoritative=20 for sxip.com email addresses, and so on.  Therefore, the domain = owner is=20 the best entity to verify an email address!  In lieu of a signed = 3rd=20 party assertion, or an email with a "verify-me" link, domain owners = can=20 facilitate email verification in the following=20 way:

 

3.1) Service Provider = receives a=20 Fetch-Response with an email address <beth@example.com> that the = SP=20 wishes to verify.  Assume the = following:

 

           = =20 a1) The proposal introduces a new service called the=20 "email_verification_service" that receives requests to validate a = given email=20 address.  This service can run on any machine in any domain (more = on this=20 in later sections).

 

a2) The DIX IdP's = "Fetch-Response"=20 contains a field called "email_verifier_hash" that is an SHA hash of = 1.)=20 Beth's persona's email address, and 2.) A secret number (preferably = long) that=20 only the email_verification_service knows.  For example:=20 SHA1(email_address + email_verification_secret_id) =3D=3D>=20 SHA1("beth@example.com" + "A939....3939") =3D=3D> = [email_verifier_hash]. =20 To clarify, only the email_authentication_service knows what the=20 email_verification_secret_id is.  Conversely, the = "email_verifier_hash"=20 is given to the IdP upon account creation (once), and freely passed = around=20 between IdP, SP, and = email_verifier_service.

 

3.2a) To verify the = email address=20 <beth@example.com>, the ServiceProvider navigates to = http://example.com=20 (the domain specified in Beth=92s email address), and follows the DIX = discovery=20 protocol to find a DIX.html file or the root document. *** This is = despite the=20 fact that Beth specified a different IdP during her regular DIX auth=20 session.***

3.2b) If = http://example.com has no=20 DIX capability, then fallback to email verification approaches 1 or 2 = above,=20 or possibly deny the login, or take some other=20 measure.

 

3.3a) If = http://example.com has=20 DIX capability, then the root document (or DIX.html) might contain = regular DIX=20 Links, but will also contain a new link that indicates an endpoint URL = that=20 has email authority for the specified example.com domain.  For = example,=20 the Link could be something like:  <LINK=20 REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"=20 HREF=3D"http://www.example.com/smtp/endpoint">.  = Alternatively, Beth's=20 domain (example.com) might delegate this authority to an endpoint in a = different domain using something like <LINK=20 REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"=20 HREF=3D"http://www.verifier.com/smtp/endpoint">.  Whatever the = case, the=20 example.com domain owner asserts this link since the domain owner = should have=20 control of the DIX.html or root html document in its=20 domain.

 

3.3b) The designated=20 'email-endpoint' HREF is used as a service endpoint URL to determine = if a=20 given email address/persona-url combo is valid.  This = email_verification=20 query would look something like this:

 

ServiceProvider sends=20 email-verification-endpoint (which is, e.g.,=20 http://www.verifier.com/smtp/endpoint) the=20 following:

a.) SHA1(email_address + = email_verification_id), which is equivalent to the email_verifier_hash = provided in the fetch response from the = IdP.

b.)=20 persona-url=3Dhttp://homesite.org/493838 =3D=3D> Also provided in = the fetch=20 response from the IdP.

 

The = email_verification_endpoint=20 will perform a lookup based on the supplied information = (email_verifier_hash=20 and persona-url), and respond with something like "DIX:true" if the = persona=20 url actually "owns" the indicated email address.  Otherwise, the = response=20 should be something like "DIX:false", or perhaps "DIX:unknown" if the=20 verification_server is not sure(?).

 

** Notice that an = eavesdropper=20 will not know which email is being verified = **

*** By proving (via = domain=20 ownership) that a given persona-url is linked to a given email = address, the=20 email_verification_service can vouch that a given persona-url controls = or=20 doesn't control a given email address.***

 

 

Potential Problems (and=20 resolutions)

--------

P1.) What if the secret=20 email_verification_id is guessed or = compromised?

[Answer] First, the = secret=20 verification id is never passed out to remote sites, and should be = different=20 for each email address.  If an attacker somehow figured out the = secret=20 email_verification_id, the attacker would still need to know the = associated=20 persona-url that matched the specified email address. =20

 

In the worst case, if an = attacker=20 knew all 3 pieces of info (email address, persona-url, and secret = key), he=20 would only be able to figure out if a single email is valid for a = given=20 persona-url.  It wouldn't tell the attacker anything more about = the email=20 address in question, nor about the persona's other personal info, nor = about=20 any other email addresses that may or may not exist.  The secret = key is=20 really used to mask the email address so that a casual eavesdropper = will not=20 know which email is being verified, and to prevent spam trolling on = the=20 email_verification_service.

 

P2.) Couldn't someone = else's=20 email_verification_service vouch for my email address without my=20 permission?

[Answer] No.  The=20 email_verification_protocol specifies that a Service Provider perform = a DIX=20 discovery at the root domain of the specified email address.  So, = example.com is the first place to go in order to verify any = "example.com"=20 email address.  Only the specified domain of an email address can = delegate to a different domain for email_verification (via DIX=20 discovery).

 

P3.) What if I don't = control my=20 domain's root page (i.e., a yahoo.com email=20 address)?

[Answer] Worst case, you = would=20 need to fallback on solution 1 or 2 above, or urge the entity that = does=20 control your domain to embrace DIX.

 

P4.) How does the=20 email_verification_service assert control over a given email address = in the=20 first place?

[Answer] Basically, a = user who=20 actually controls an email address needs to login to the=20 email_verification_service to get the process started.  The = mechanism=20 employed for login is email_verification_service = implementation-defined. =20 The email_verification_service could have some non-DIX method of = allowing a=20 given user to login with their email address (perhaps using the same=20 login/password that the email account uses, since the domain owner = already=20 knows this anyway).  In any event, after somehow logging in, the = user=20 tells the email_verification_service what persona-url is linked to = their=20 specific email address(es), and the email_verification_service does = the rest=20 through the protocol.

 

P5.) If the IdP and the=20 email_verification service aren't the same thing (i.e., separate = domains or=20 servers), how do the IdP and the Email_Verification_Service share the = secret=20 email_verification_id for comparison = purposes?

[Answer]  They = don't. =20 The IdP is given an SHA Hash of the "email address" + the secret=20 email_verification_id.  This hash value can then be sent out to = various=20 Service Providers, since this hash value is just another DIX parameter = that=20 gets filled in when a user creates a new IdP account.  It is = feasible=20 that an email_verification_service could somehow use a DIX store = method to=20 propagate this information, but this requires further=20 thought.

 

SUMMARY

-------

The main purpose of the=20 email_verification_service is that a domain owner should be the one to = vouch=20 for who controls an email address.   In addition, DIX=20 ServiceProviders that use the proposed email_verification_service can=20 automatically determine if a given persona-url is linked to a given = email, and=20 can trust that determination because it is made by the owners of the = domain=20 that controls the email address.  In the final analysis, no = continuing=20 end-user interaction is required for each ServiceProvider that wishes = to=20 validate an email address.  Plus, email_verification as laid out = in this=20 post is not a requirement.  SP=92s could use alternative methods = to verify=20 an email if, for instance, a given email domain doesn=92t support the = email=20 verification service, or the SP determines that a stronger method of = email=20 verification should be used.

 

------_=_NextPart_001_01C68B1E.5A642454-- --===============0564988155== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0564988155==-- From dix-bounces@ietf.org Mon Jun 12 13:39:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqNV-0007pM-GO; Mon, 12 Jun 2006 13:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foh76-0003TF-Mm for dix@ietf.org; Fri, 09 Jun 2006 09:33:24 -0400 Received: from nz-out-0102.google.com ([64.233.162.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foh74-0006fW-Ct for dix@ietf.org; Fri, 09 Jun 2006 09:33:24 -0400 Received: by nz-out-0102.google.com with SMTP id q3so683478nzb for ; Fri, 09 Jun 2006 06:33:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:x-mailer:in-reply-to:x-mimeole:thread-index; b=bnQxWmC8/0GXYD0HLD3zYIlxPw8gEquKcXiYWcN+O5QLKCFM1z5BTDPsN4GLQ1DCm2q92RhLz31G52jBp5FUSD2sEXRgZ+0BZbX8jPBmI5F1ieNUOgf4kX/N29phSS75iJbQsK86q8tb1KTx0M7Nw9q5QSL6Cv5RSJTZU+FdX/o= Received: by 10.36.251.19 with SMTP id y19mr4086256nzh; Fri, 09 Jun 2006 06:33:21 -0700 (PDT) Received: from Genesis ( [69.209.158.147]) by mx.gmail.com with ESMTP id r15sm1989113nza.2006.06.09.06.33.17; Fri, 09 Jun 2006 06:33:20 -0700 (PDT) From: "David Fuelling" To: "'Digital Identity Exchange'" Subject: RE: [dix] Email Verification with Dix - a Possible Method? Date: Fri, 9 Jun 2006 09:33:12 -0400 Message-ID: <01ad01c68bc9$4238bda0$f964a8c0@Genesis> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <198A730C2044DE4A96749D13E167AD37B55910@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaKtBeOpMnjjmMMSEmESA2MMASNTAAajCrAACg22IA= X-Spam-Score: 0.1 (/) X-Scan-Signature: db5e3c253cd02a16aed3d00c4119c88b X-Mailman-Approved-At: Mon, 12 Jun 2006 13:39:03 -0400 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729973464==" Errors-To: dix-bounces@ietf.org This is a multi-part message in MIME format. --===============0729973464== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01C68BA7.BB271DA0" This is a multi-part message in MIME format. ------=_NextPart_000_01AE_01C68BA7.BB271DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Phillip, Thanks for the pointer. If I understand DKIM correctly, it's is primarily intended to authenticate email message headers and message bodies through the following process (way simplified): 1.) Signed header is included inside of an email message (optionally the entire body is signed). 2.) Message recipient can verify the signature with a PublicKey that sits in the DNS record of the sender's domain. 3.) If the signature verification matches, then the message can be assumed to be from the owner of the domain (and most likely actually from the owner of the address). In the context of DIX email address verification, a ServiceProvider will want to verify that an email address (by somehow querying the domain that owns that address) is associated with a particular persona-url (as opposed to straight message verification in traditional DKIM). Therefore, when a ServiceProvider gets an email address from an IdP (via a DIX fetch-response), there will still need to be 3 pieces of information included: 1.) A persona-url, 2.) An email address to associate with the persona-url, 3.) A DKIM signature that is created from the (email-address+persona-url+privateKey of the domain owner). This email_verification_signature (what I called an email_verification_hash in my original message) in the fetch-response could then be validated by a simple lookup of the PublicKey in the email address domain's DNS record. Using DKIM does seem to be a good approach when it comes to the verification step - it sort of replaces the "email_verification_service" running as a web-service and uses DNS instead (It feels similar to how an email auth scheme might function in a Secure-DNS world, actually). Of course, even DKIM would be susceptible (slightly) to spoofing until we get secure-DNS. I guess the big question is which method (DKIM, or my earlier idea, or something else) would be easier to implement/adopt on a mass scale? DKIM seems like a cleaner alternative, but it involves DNS modifications and Public/Private Keys, which are much more advanced concepts than editing HTML files on a homepage. Plus, if the verification service is a web-based application (not centralized, but running on each domain), then it could be secured today using SSL/TLS. DNS does not (currently) offer that kind of security. Anyway, thanks for pointing DKIM out..it's definitely something worth considering here. david sappenin@gmail.com _____ From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com] Sent: Thursday, June 08, 2006 1:10 PM To: info@sappenin.com; Digital Identity Exchange Subject: RE: [dix] Email Verification with Dix - a Possible Method? Take a look at Domain Keys Identified Mail. _____ From: Sappenin Technologies LLC [mailto:info@sappenin.com] Sent: Thursday, June 08, 2006 12:29 AM To: dix@ietf.org Subject: [dix] Email Verification with Dix - a Possible Method? This post offers a discussion about incorporating some sort of email verification into the DIX protocol, either in the main DIX spec itself, or along-side DIX in a sub or related spec. In particular, I propose an email verification solution that allows domain owners to assert ownership over an email address, and link that ownership to a DIX persona-url. To be clear, I view the method proposed in this post as one method (of many possibilities) that DIX ServiceProviders _could_ use to high effectiveness. I'm not sure to what degree "email verification in DIX" has been discussed on this list, but I'd like to offer a few arguments in favor of my proposed scheme (or something like it), as well as a sample flow of how such a scheme might work in the context of DIX. Any feedback and/or comments are welcome. david info@sappenin.com -- First, the primary reason that DIX should have the capability to validate email addresses in particular (and not necessarily other "verifiable" pieces of information) is that most websites today use an email-address as a unique identifier (think username). When these sites transition to DIX, they (the sites) will rely on a persona-url being associated with, and possibly the actual owner of, a given email address. This is a lot of verification work to be done. Further, while the transition to DIX will move people to a persona-url-based identifier, and away from an email-based identifier, verified email addresses will still be required by each Service Provider that relies on the validity of an email address belonging to a given persona. It has been offered that external solutions already exist to solve the problem of email address verification, and as such, the challenge of such verification should _not_ be included in the DIX spec. Two common approaches that I have seen (that already exist outside of DIX) are as follows: Approach 1.) Use a 3rd party signed claim about the email address, where the service provider trusts the third party making the assertion. This is probably the most secure solution, since this would use some form of cryptographic signatures to assert validity. However, IMHO _many_ people are not going to go through the hassle of getting a "verified" email address. It will probably cost money (I'm thinking of Verisign), and the average person won't really understand the benefit of getting "verified", at least initially. Plus, it's one extra hassle for a person who already "owns" their email address. Approach 2.) The ServiceProvider does some sort of email verification once it receives the email address for the first time. e.g. - SP sends an email to saying "you signed up for geeknews.com, please click this link to complete your signup". This is not a terrible solution (many companies employ this today for email verification), although I have heard arguments against using such mechanisms. In the end, however, this solution requires end-user work at potentially every new Service Provider, which is annoying to the user, and may hinder anti-phishing initiatives (by continuing to confuse end-users trying to decipher legitimate from forged emails). It would be better if the end-user only needed to establish email ownership once (with their IdP), in a way that all ServiceProviders could then trust and verify (and that didn't necessarily involve a certificate-based 3rd party signed assertions that may or may not cost money/be difficult to use). Thus, I propose a third approach that allows domain owners to assert ownership over email addresses, and then link that ownership to a DIX persona-url via the DIX protocol (or DIX-like mechanisms). Approach 3.) Automatic Email Verification by a Service Provider We know that a given email is always owned by the domain that the email sits in. For example, microsoft.com is the authoritative domain for the email address . Likewise, sxip.com is authoritative for sxip.com email addresses, and so on. Therefore, the domain owner is the best entity to verify an email address! In lieu of a signed 3rd party assertion, or an email with a "verify-me" link, domain owners can facilitate email verification in the following way: 3.1) Service Provider receives a Fetch-Response with an email address that the SP wishes to verify. Assume the following: a1) The proposal introduces a new service called the "email_verification_service" that receives requests to validate a given email address. This service can run on any machine in any domain (more on this in later sections). a2) The DIX IdP's "Fetch-Response" contains a field called "email_verifier_hash" that is an SHA hash of 1.) Beth's persona's email address, and 2.) A secret number (preferably long) that only the email_verification_service knows. For example: SHA1(email_address + email_verification_secret_id) ==> SHA1("beth@example.com" + "A939....3939") ==> [email_verifier_hash]. To clarify, only the email_authentication_service knows what the email_verification_secret_id is. Conversely, the "email_verifier_hash" is given to the IdP upon account creation (once), and freely passed around between IdP, SP, and email_verifier_service. 3.2a) To verify the email address , the ServiceProvider navigates to http://example.com (the domain specified in Beth's email address), and follows the DIX discovery protocol to find a DIX.html file or the root document. *** This is despite the fact that Beth specified a different IdP during her regular DIX auth session.*** 3.2b) If http://example.com has no DIX capability, then fallback to email verification approaches 1 or 2 above, or possibly deny the login, or take some other measure. 3.3a) If http://example.com has DIX capability, then the root document (or DIX.html) might contain regular DIX Links, but will also contain a new link that indicates an endpoint URL that has email authority for the specified example.com domain. For example, the Link could be something like: . Alternatively, Beth's domain (example.com) might delegate this authority to an endpoint in a different domain using something like . Whatever the case, the example.com domain owner asserts this link since the domain owner should have control of the DIX.html or root html document in its domain. 3.3b) The designated 'email-endpoint' HREF is used as a service endpoint URL to determine if a given email address/persona-url combo is valid. This email_verification query would look something like this: ServiceProvider sends email-verification-endpoint (which is, e.g., http://www.verifier.com/smtp/endpoint) the following: a.) SHA1(email_address + email_verification_id), which is equivalent to the email_verifier_hash provided in the fetch response from the IdP. b.) persona-url=http://homesite.org/493838 ==> Also provided in the fetch response from the IdP. The email_verification_endpoint will perform a lookup based on the supplied information (email_verifier_hash and persona-url), and respond with something like "DIX:true" if the persona url actually "owns" the indicated email address. Otherwise, the response should be something like "DIX:false", or perhaps "DIX:unknown" if the verification_server is not sure(?). ** Notice that an eavesdropper will not know which email is being verified ** *** By proving (via domain ownership) that a given persona-url is linked to a given email address, the email_verification_service can vouch that a given persona-url controls or doesn't control a given email address.*** Potential Problems (and resolutions) -------- P1.) What if the secret email_verification_id is guessed or compromised? [Answer] First, the secret verification id is never passed out to remote sites, and should be different for each email address. If an attacker somehow figured out the secret email_verification_id, the attacker would still need to know the associated persona-url that matched the specified email address. In the worst case, if an attacker knew all 3 pieces of info (email address, persona-url, and secret key), he would only be able to figure out if a single email is valid for a given persona-url. It wouldn't tell the attacker anything more about the email address in question, nor about the persona's other personal info, nor about any other email addresses that may or may not exist. The secret key is really used to mask the email address so that a casual eavesdropper will not know which email is being verified, and to prevent spam trolling on the email_verification_service. P2.) Couldn't someone else's email_verification_service vouch for my email address without my permission? [Answer] No. The email_verification_protocol specifies that a Service Provider perform a DIX discovery at the root domain of the specified email address. So, example.com is the first place to go in order to verify any "example.com" email address. Only the specified domain of an email address can delegate to a different domain for email_verification (via DIX discovery). P3.) What if I don't control my domain's root page (i.e., a yahoo.com email address)? [Answer] Worst case, you would need to fallback on solution 1 or 2 above, or urge the entity that does control your domain to embrace DIX. P4.) How does the email_verification_service assert control over a given email address in the first place? [Answer] Basically, a user who actually controls an email address needs to login to the email_verification_service to get the process started. The mechanism employed for login is email_verification_service implementation-defined. The email_verification_service could have some non-DIX method of allowing a given user to login with their email address (perhaps using the same login/password that the email account uses, since the domain owner already knows this anyway). In any event, after somehow logging in, the user tells the email_verification_service what persona-url is linked to their specific email address(es), and the email_verification_service does the rest through the protocol. P5.) If the IdP and the email_verification service aren't the same thing (i.e., separate domains or servers), how do the IdP and the Email_Verification_Service share the secret email_verification_id for comparison purposes? [Answer] They don't. The IdP is given an SHA Hash of the "email address" + the secret email_verification_id. This hash value can then be sent out to various Service Providers, since this hash value is just another DIX parameter that gets filled in when a user creates a new IdP account. It is feasible that an email_verification_service could somehow use a DIX store method to propagate this information, but this requires further thought. SUMMARY ------- The main purpose of the email_verification_service is that a domain owner should be the one to vouch for who controls an email address. In addition, DIX ServiceProviders that use the proposed email_verification_service can automatically determine if a given persona-url is linked to a given email, and can trust that determination because it is made by the owners of the domain that controls the email address. In the final analysis, no continuing end-user interaction is required for each ServiceProvider that wishes to validate an email address. Plus, email_verification as laid out in this post is not a requirement. SP's could use alternative methods to verify an email if, for instance, a given email domain doesn't support the email verification service, or the SP determines that a stronger method of email verification should be used. ------=_NextPart_000_01AE_01C68BA7.BB271DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phillip,

 

Thanks for the pointer.  If I understand DKIM correctly, it’s is primarily = intended to authenticate email message headers and message bodies through the = following process (way simplified):

 

1.)     = Signed header is included inside of an email message = (optionally the entire body is signed).

2.)     = Message recipient can verify the signature with a PublicKey = that sits in the DNS record of the sender’s = domain.

3.)     = If the signature verification matches, then the message can = be assumed to be from the owner of the domain (and most likely actually = from the owner of the address).

 

In the context of DIX email address = verification, a ServiceProvider will want to verify that an email address (by somehow querying the domain that owns that address) is associated with a = particular persona-url (as opposed to straight message verification in traditional = DKIM).

 

Therefore, when a ServiceProvider = gets an email address from an IdP (via a DIX fetch-response), there will still = need to be 3 pieces of information included:  1.) A persona-url, 2.) An = email address to associate with the persona-url, 3.) A DKIM signature that is = created from the (email-address+persona-url+privateKey of the domain = owner).  This email_verification_signature (what I called an email_verification_hash = in my original message) in the fetch-response could then be validated by a = simple lookup of the PublicKey in the email address domain’s DNS = record.

 

Using DKIM does seem to be a good = approach when it comes to the verification step – it sort of replaces the = “email_verification_service” running as a web-service and uses DNS instead (It feels similar to how = an email auth scheme might function in a Secure-DNS world, actually).  Of = course, even DKIM would be susceptible (slightly) to spoofing until we get = secure-DNS. 

 

I guess the big question is which = method (DKIM, or my earlier idea, or something else) would be easier to = implement/adopt on a mass scale?  DKIM seems like a cleaner alternative, but it = involves DNS modifications and Public/Private Keys, which are much more advanced concepts than editing HTML files on a homepage.  Plus, if the = verification service is a web-based application (not centralized, but running on each domain), then it could be secured today using SSL/TLS.  DNS does = not (currently) offer that kind of security.

 

Anyway, thanks for pointing DKIM = out….it’s definitely something worth considering = here.

 

david

sappenin@gmail.com=

 

 

From: = Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Thursday, June 08, = 2006 1:10 PM
To: info@sappenin.com; = Digital Identity Exchange
Subject: RE: [dix] Email Verification with Dix - a Possible Method?

 

Take a look at Domain Keys = Identified Mail.

 

=

 

From: Sappenin Technologies LLC [mailto:info@sappenin.com]
Sent: Thursday, June 08, = 2006 12:29 AM
To: dix@ietf.org
Subject: [dix] Email = Verification with Dix - a Possible Method?

This post offers a discussion about incorporating = some sort of email verification into the DIX protocol, either in the main DIX spec itself, or along-side DIX in a sub or related spec.  In particular, = I propose an email verification solution that allows domain owners to = assert ownership over an email address, and link that ownership to a DIX persona-url.  To be clear, I view the method proposed in this post = as one method (of many possibilities) that DIX ServiceProviders _could_ use to = high effectiveness.

 

I'm not sure to what degree "email verification = in DIX" has been discussed on this list, but I'd like to offer a few arguments in favor of my proposed scheme (or something like it), as well = as a sample flow of how such a scheme might work in the context of DIX.  = Any feedback and/or comments are welcome.

 

david

info@sappenin.com

 

--

 

First, the primary reason that DIX should have the capability to validate email addresses in particular (and not = necessarily other “verifiable” pieces of information) is that most websites = today use an email-address as a unique identifier (think username).  When = these sites transition to DIX, they (the sites) will rely on a persona-url = being associated with, and possibly the actual owner of, a given email = address.  This is a lot of verification work to be done.  Further, while the transition to DIX will move people to a persona-url-based identifier, = and away from an email-based identifier, verified email addresses will still be = required by each Service Provider that relies on the validity of an email address belonging to a given persona.

 

It has been offered that external solutions already = exist to solve the problem of email address verification, and as such, the = challenge of such verification should _not_ be included in the DIX spec.  Two = common approaches that I have seen (that already exist outside of DIX) are as = follows:

 

Approach 1.) Use a 3rd party signed claim = about the email address, where the service provider trusts the third party = making the assertion.

This is probably the most secure solution, since this = would use some form of cryptographic signatures to assert validity.  = However, IMHO _many_ people are not going to go through the hassle of getting a "verified" email address.  It will probably cost money = (I'm thinking of Verisign), and the average person won't really understand = the benefit of getting "verified", at least initially.  Plus, it’s one extra hassle for a person who already “owns” = their email address.

 

Approach 2.) The ServiceProvider does some sort of = email verification once it receives the email address for the first = time.  e.g. - SP sends an email to <bill.gates@microsoft.com> saying "you = signed up for geeknews.com, please click this link to complete your signup".  This is not a terrible solution (many companies = employ this today for email verification), although I have heard arguments against = using such mechanisms.  In the end, however, this solution requires = end-user work at potentially every new Service Provider, which is annoying to the = user, and may hinder anti-phishing initiatives (by continuing to confuse = end-users trying to decipher legitimate from forged = emails).

 

It would be better if the end-user only needed to = establish email ownership once (with their IdP), in a way that all = ServiceProviders could then trust and verify (and that didn't necessarily involve a = certificate-based 3rd party signed assertions that may or may not cost money/be difficult = to use).

 

Thus, I propose a third approach that allows domain = owners to assert ownership over email addresses, and then link that ownership = to a DIX persona-url via the DIX protocol (or DIX-like = mechanisms).

 

Approach 3.) Automatic Email Verification by a = Service Provider

 

We know that a given email is always owned by the = domain that the email sits in.  For example, microsoft.com is the = authoritative domain for the email address <bill.gates@microsoft.com>.  = Likewise, sxip.com is authoritative for sxip.com email addresses, and so on.  Therefore, the domain owner is the best entity to verify an email address!  In lieu of a signed 3rd party assertion, or an email with = a "verify-me" link, domain owners can facilitate email = verification in the following way:

 

3.1) Service Provider receives a Fetch-Response with = an email address <beth@example.com> that the SP wishes to = verify.  Assume the following:

 

         =    a1) The proposal introduces a new service called the "email_verification_service" that receives requests to = validate a given email address.  This service can run on any machine in any = domain (more on this in later sections).

 

a2) The DIX IdP's "Fetch-Response" contains a field called "email_verifier_hash" that is an SHA hash of 1.) Beth's = persona's email address, and 2.) A secret number (preferably long) that only the email_verification_service knows.  For example: SHA1(email_address = + email_verification_secret_id) =3D=3D> = SHA1("beth@example.com" + "A939....3939") =3D=3D> [email_verifier_hash].  To = clarify, only the email_authentication_service knows what the = email_verification_secret_id is.  Conversely, the "email_verifier_hash" is given to = the IdP upon account creation (once), and freely passed around between IdP, SP, = and email_verifier_service.

 

3.2a) To verify the email address = <beth@example.com>, the ServiceProvider navigates to http://example.com (the domain = specified in Beth’s email address), and follows the DIX discovery protocol to = find a DIX.html file or the root document. *** This is despite the fact that = Beth specified a different IdP during her regular DIX auth = session.***

3.2b) If http://example.com has no DIX capability, = then fallback to email verification approaches 1 or 2 above, or possibly deny = the login, or take some other measure.

 

3.3a) If http://example.com has DIX capability, then = the root document (or DIX.html) might contain regular DIX Links, but will = also contain a new link that indicates an endpoint URL that has email = authority for the specified example.com domain.  For example, the Link could be something like:  <LINK REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"= HREF=3D"http://www.example.com/smtp/endpoint">.  = Alternatively, Beth's domain (example.com) might delegate this authority to an endpoint = in a different domain using something like <LINK REL=3D"urn:ietf:params:DIX:email-verification_service_endpoint"= HREF=3D"http://www.verifier.com/smtp/endpoint">.  = Whatever the case, the example.com domain owner asserts this link since the domain = owner should have control of the DIX.html or root html document in its = domain.

 

3.3b) The designated 'email-endpoint' HREF is used as = a service endpoint URL to determine if a given email address/persona-url = combo is valid.  This email_verification query would look something like = this:

 

ServiceProvider sends email-verification-endpoint = (which is, e.g., http://www.verifier.com/smtp/endpoint) the = following:

a.) SHA1(email_address + email_verification_id), = which is equivalent to the email_verifier_hash provided in the fetch response = from the IdP.

b.) persona-url=3Dhttp://homesite.org/493838 = =3D=3D> Also provided in the fetch response from the = IdP.

 

The email_verification_endpoint will perform a lookup = based on the supplied information (email_verifier_hash and persona-url), and = respond with something like "DIX:true" if the persona url actually "owns" the indicated email address.  Otherwise, the = response should be something like "DIX:false", or perhaps "DIX:unknown" if the verification_server is not = sure(?).

 

** Notice that an eavesdropper will not know which = email is being verified **

*** By proving (via domain ownership) that a given persona-url is linked to a given email address, the = email_verification_service can vouch that a given persona-url controls or doesn't control a given = email address.***

 

 

Potential Problems (and = resolutions)

--------

P1.) What if the secret email_verification_id is = guessed or compromised?

[Answer] First, the secret verification id is never = passed out to remote sites, and should be different for each email = address.  If an attacker somehow figured out the secret email_verification_id, the = attacker would still need to know the associated persona-url that matched the = specified email address. 

 

In the worst case, if an attacker knew all 3 pieces = of info (email address, persona-url, and secret key), he would only be able to = figure out if a single email is valid for a given persona-url.  It = wouldn't tell the attacker anything more about the email address in question, nor = about the persona's other personal info, nor about any other email addresses that = may or may not exist.  The secret key is really used to mask the email = address so that a casual eavesdropper will not know which email is being verified, = and to prevent spam trolling on the = email_verification_service.

 

P2.) Couldn't someone else's = email_verification_service vouch for my email address without my = permission?

[Answer] No.  The email_verification_protocol = specifies that a Service Provider perform a DIX discovery at the root domain of = the specified email address.  So, example.com is the first place to go = in order to verify any "example.com" email address.  Only = the specified domain of an email address can delegate to a different domain = for email_verification (via DIX discovery).

 

P3.) What if I don't control my domain's root page = (i.e., a yahoo.com email address)?

[Answer] Worst case, you would need to fallback on = solution 1 or 2 above, or urge the entity that does control your domain to = embrace DIX.

 

P4.) How does the email_verification_service assert = control over a given email address in the first = place?

[Answer] Basically, a user who actually controls an = email address needs to login to the email_verification_service to get the = process started.  The mechanism employed for login is = email_verification_service implementation-defined.  The email_verification_service could have = some non-DIX method of allowing a given user to login with their email = address (perhaps using the same login/password that the email account uses, = since the domain owner already knows this anyway).  In any event, after = somehow logging in, the user tells the email_verification_service what = persona-url is linked to their specific email address(es), and the = email_verification_service does the rest through the protocol.

 

P5.) If the IdP and the email_verification service = aren't the same thing (i.e., separate domains or servers), how do the IdP and = the Email_Verification_Service share the secret email_verification_id for comparison purposes?

[Answer]  They don't.  The IdP is given an = SHA Hash of the "email address" + the secret = email_verification_id.  This hash value can then be sent out to various Service Providers, since = this hash value is just another DIX parameter that gets filled in when a user creates a new IdP account.  It is feasible that an email_verification_service could somehow use a DIX store method to = propagate this information, but this requires further = thought.

 

SUMMARY

-------

The main purpose of the email_verification_service is = that a domain owner should be the one to vouch for who controls an email address.   In addition, DIX ServiceProviders that use the = proposed email_verification_service can automatically determine if a given = persona-url is linked to a given email, and can trust that determination because it = is made by the owners of the domain that controls the email address.  In = the final analysis, no continuing end-user interaction is required for each ServiceProvider that wishes to validate an email address.  Plus, email_verification as laid out in this post is not a requirement.  SP’s could use alternative methods to verify an email if, for = instance, a given email domain doesn’t support the email verification service, = or the SP determines that a stronger method of email verification should be = used.

 

------=_NextPart_000_01AE_01C68BA7.BB271DA0-- --===============0729973464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0729973464==-- From dix-bounces@ietf.org Mon Jun 12 17:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptYN-0004w3-2g; Mon, 12 Jun 2006 17:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FptYL-0004vW-Ru for dix@ietf.org; Mon, 12 Jun 2006 17:02:29 -0400 Received: from copa.geek.net.au ([203.217.18.13] helo=srve.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FptYK-0005nz-5N for dix@ietf.org; Mon, 12 Jun 2006 17:02:29 -0400 Received: from BLANK (203-217-18-9.perm.iinet.net.au [203.217.18.9]) by srve.com (8.13.6/8.12.11) with ESMTP id k5CL2BMo006762 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 12 Jun 2006 21:02:11 GMT Date: Tue, 13 Jun 2006 07:02:20 +1000 From: Chris Drake X-Priority: 3 (Normal) Message-ID: <163761340.20060613070220@pobox.com> To: "David Fuelling" Subject: Re[2]: [dix] Email Verification with Dix - a Possible Method? In-Reply-To: <01ad01c68bc9$4238bda0$f964a8c0@Genesis> References: <198A730C2044DE4A96749D13E167AD37B55910@MOU1WNEXMB04.vcorp.ad.vrsn.com> <01ad01c68bc9$4238bda0$f964a8c0@Genesis> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'Digital Identity Exchange' X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi David, DKIM is one of at least 3 different serverside email verification protocols - the other lesser one is SenderID aka CallerID from Microsoft, and the really big one is SPF. Yahoo and gmail are the only people doing DKIM that I know of (check your own gmail headers - you can see it in there: DomainKey-Signature: a=rsa-sha1; q=dns; ... S/MIME is better than all the above, since it's client-side instead of serverside (cannot be spoofed by other users of the same ISP or webmail provider) - but S/MIME itself relies on some earlier "click here to confirm you own this email address" check, none of which probably use SPF/DKIM/SenderID OpenPGP is like S/MIME - but without any address verification (unless you can find a root CA who signs OpenPGP keys? I guess some do) Spamassassin is a free tool which can check all these things, so it's a no-brainer to require valid SPF/DKIM/SenderID - or at least reject when spoofed SPF/DKIM/SenderID is found. Kind Regards, Chris Drake _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 13 10:58:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAM2-0002n0-5e; Tue, 13 Jun 2006 10:58:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAM0-0002mv-Jc for dix@ietf.org; Tue, 13 Jun 2006 10:58:52 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqALz-0002Tr-9m for dix@ietf.org; Tue, 13 Jun 2006 10:58:52 -0400 Received: by py-out-1112.google.com with SMTP id s49so1941040pyc for ; Tue, 13 Jun 2006 07:58:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=EBuYTdbnTpCngg9IFu5dg43odMyAEZ0Bmk0OevRz7M+k7iT91RK0/+rKmEb8JhGSUVAgsSdk4jI9jb7CYl3AbYcxd4h/PyDZdyWJZFEDaH9tkNWyqWg/7ekl3I9Yz0vN0167PxQoYJgrxBYaUF3ZlY92+6UKu1rxgoMD2P2IKck= Received: by 10.35.115.18 with SMTP id s18mr4133044pym; Tue, 13 Jun 2006 07:58:50 -0700 (PDT) Received: from Genesis ( [69.209.158.147]) by mx.gmail.com with ESMTP id y21sm233381pyd.2006.06.13.07.58.48; Tue, 13 Jun 2006 07:58:49 -0700 (PDT) From: "David Fuelling" To: "'Digital Identity Exchange'" Subject: RE: Re[2]: [dix] Email Verification with Dix - a Possible Method? Date: Tue, 13 Jun 2006 10:58:47 -0400 Message-ID: <001901c68ef9$e0d45310$f964a8c0@Genesis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaOY4H3Bxn1R1WfTY2ArLcRtTiAgwAkQ93g In-Reply-To: <163761340.20060613070220@pobox.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > DKIM is one of at least 3 different serverside email verification > protocols - the other lesser one is SenderID aka CallerID from > Microsoft, and the really big one is SPF. Yahoo and gmail are the > only people doing DKIM that I know of (check your own gmail headers - > you can see it in there: DomainKey-Signature: a=rsa-sha1; q=dns; ... Hey Chris, Thanks for pointing those out. The only wildcard that would probably disqualify something like SPF (for example) is the fact that it is actually meant to verify the Sending Server of an email, not necessarily the email address itself (or if a given email address could be attached to a separate piece of information like a persona-url). In the context of DIX, there won't be a single server sending along email addresses, there will be a myriad of IdP's (read: IP addresses) making email assertions to a myriad of Relying Parties. In the DIX realm, what is needed is some kind of mechanism that will allow an IdP (or a domain owner) to make verifiable assertions about a given email address -- e.g., "example.com domain asserts that beth@example.com is associated with a given persona-url". That way, a relying party can adequately verify the email address assertion. And, since the user authenticated the persona-url (via DIX), then the user must have authority to use the indicated email address. It seems like there are only 3 possible approaches to auto-magically verify that an email address is associated with some other piece of information (without user input): 1.) Put a public key in some standard, known location (e.g., DNS) so that the owner of the domain can sign his/her email assertions, and any Relying Party can trust that the assertion is valid since only the domain owner could - theoretically - place the public key in the "standard, known" location (e.g., DNS). 2.) Attach a signature/certificate to an assertion. The certificate is singed by a third party, and is "Internet Geography" agnostic. The relying party simply has a list of trusted parties, so there is no external verification lookup 3.) Send a symmetric key (like an HMAC) to the Relying Party, and allow them to verify with the key's authority (in the case of email verification, this should, in some way or another, be the domain owner of an email address). This was what I originally proposed, as it doesn't rely on public/private keys, messing with DNS, etc, and can be arbitrarily secured via HTTP(S) or whatever other security mechanism works with HTTP (in the case of DIX). Plus, it's a unique case where we always know who the authority is: The domain owner of a given email address. Best regards, David _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 13 11:21:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAhj-0003WD-Cb; Tue, 13 Jun 2006 11:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAhi-0003RC-2S for dix@ietf.org; Tue, 13 Jun 2006 11:21:18 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAhg-0004mL-M0 for dix@ietf.org; Tue, 13 Jun 2006 11:21:18 -0400 Received: from chris.corp.google.com (chris.corp.google.com [172.24.0.146]) by smtp-out.google.com with ESMTP id k5DFL7lc018620 for ; Tue, 13 Jun 2006 08:21:07 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=StO6GIkWEwBqbOo/r34lLTyJ244Iw9CL+OmTtfqqkZGOwYgt9Wq7Dz1NbeZrJw3Ru ruCLQjEPZC1O4ULOQz3Ug== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by chris.corp.google.com with ESMTP id k5DElJKH015550 for ; Tue, 13 Jun 2006 08:21:01 -0700 Received: by smtp-out2.google.com with SMTP id 7so76925fpr for ; Tue, 13 Jun 2006 08:21:01 -0700 (PDT) Received: by 10.253.2.2 with SMTP id 2mr219328fpb; Tue, 13 Jun 2006 08:21:01 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Tue, 13 Jun 2006 08:21:01 -0700 (PDT) Message-ID: <1b587cab0606130821w20bfa63ewca3f12c02fb9d6d0@mail.google.com> Date: Tue, 13 Jun 2006 16:21:01 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: Re[2]: [dix] Email Verification with Dix - a Possible Method? In-Reply-To: <001901c68ef9$e0d45310$f964a8c0@Genesis> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <163761340.20060613070220@pobox.com> <001901c68ef9$e0d45310$f964a8c0@Genesis> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/13/06, David Fuelling wrote: > > DKIM is one of at least 3 different serverside email verification > > protocols - the other lesser one is SenderID aka CallerID from > > Microsoft, and the really big one is SPF. Yahoo and gmail are the > > only people doing DKIM that I know of (check your own gmail headers - > > you can see it in there: DomainKey-Signature: a=3Drsa-sha1; q=3Ddns; ..= . > > Hey Chris, > > Thanks for pointing those out. The only wildcard that would probably > disqualify something like SPF (for example) is the fact that it is actual= ly > meant to verify the Sending Server of an email, not necessarily the email > address itself (or if a given email address could be attached to a separa= te > piece of information like a persona-url). In the context of DIX, there > won't be a single server sending along email addresses, there will be a > myriad of IdP's (read: IP addresses) making email assertions to a myriad = of > Relying Parties. > > In the DIX realm, what is needed is some kind of mechanism that will allo= w > an IdP (or a domain owner) to make verifiable assertions about a given em= ail > address -- e.g., "example.com domain asserts that beth@example.com is > associated with a given persona-url". That way, a relying party can > adequately verify the email address assertion. And, since the user > authenticated the persona-url (via DIX), then the user must have authorit= y > to use the indicated email address. > > It seems like there are only 3 possible approaches to auto-magically veri= fy > that an email address is associated with some other piece of information > (without user input): > > 1.) Put a public key in some standard, known location (e.g., DNS) so that > the owner of the domain can sign his/her email assertions, and any Relyin= g > Party can trust that the assertion is valid since only the domain owner > could - theoretically - place the public key in the "standard, known" > location (e.g., DNS). > > 2.) Attach a signature/certificate to an assertion. The certificate is > singed by a third party, and is "Internet Geography" agnostic. The relyi= ng > party simply has a list of trusted parties, so there is no external > verification lookup > > 3.) Send a symmetric key (like an HMAC) to the Relying Party, and allow t= hem > to verify with the key's authority (in the case of email verification, th= is > should, in some way or another, be the domain owner of an email address). > This was what I originally proposed, as it doesn't rely on public/private > keys, messing with DNS, etc, and can be arbitrarily secured via HTTP(S) o= r > whatever other security mechanism works with HTTP (in the case of DIX). > Plus, it's a unique case where we always know who the authority is: The > domain owner of a given email address. I'm missing context here, but this sounds to me like it allows the relying party to masquerade as the authority. Cheers, Ben. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 13 14:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDd8-0002a3-Bq; Tue, 13 Jun 2006 14:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqDd7-0002Zy-GC for dix@ietf.org; Tue, 13 Jun 2006 14:28:45 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqDd6-0006tR-9B for dix@ietf.org; Tue, 13 Jun 2006 14:28:45 -0400 Received: by py-out-1112.google.com with SMTP id e30so1961189pya for ; Tue, 13 Jun 2006 11:28:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=LgLQXgFNK+NORZBKQIucU1MZH1G7Nu6BcQFaPq35T/1WtZQu8pUy7gcUzsDkvqauXciOlG3t7siXzlsMxTakBFiQMUQoQsl1qC7dawL9UDiKDzZGBxll4LWbpAMnxQT5a5BxHibC5bouC3NnAORjkq68q/XkYNRBeD+//ualHt0= Received: by 10.35.60.16 with SMTP id n16mr119414pyk; Tue, 13 Jun 2006 11:28:43 -0700 (PDT) Received: from Genesis ( [69.209.158.147]) by mx.gmail.com with ESMTP id m78sm812145pye.2006.06.13.11.28.41; Tue, 13 Jun 2006 11:28:42 -0700 (PDT) From: "David Fuelling" To: "'Digital Identity Exchange'" Subject: RE: Re[2]: [dix] Email Verification with Dix - a Possible Method? Date: Tue, 13 Jun 2006 14:28:44 -0400 Message-ID: <002e01c68f17$3500c320$f964a8c0@Genesis> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1b587cab0606130821w20bfa63ewca3f12c02fb9d6d0@mail.google.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaO/QumBdsUiWlpRLCeD2A4NjE2GQAGeGqA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 See my original post here: http://www1.ietf.org/mail-archive/web/dix/current/msg00694.html > I'm missing context here, but this sounds to me like it allows the > relying party to masquerade as the authority. > > Cheers, > > Ben. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 13 16:55:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFuk-0005LW-9L; Tue, 13 Jun 2006 16:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqFui-0005LQ-Np for dix@ietf.org; Tue, 13 Jun 2006 16:55:04 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqFuh-0008VH-Bl for dix@ietf.org; Tue, 13 Jun 2006 16:55:04 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k5DKt0IT002791; Tue, 13 Jun 2006 13:55:00 -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); Tue, 13 Jun 2006 13:54:52 -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: Re[2]: [dix] Email Verification with Dix - a Possible Method? Date: Tue, 13 Jun 2006 13:54:52 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B55B1A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re[2]: [dix] Email Verification with Dix - a Possible Method? Thread-Index: AcaOY4g/qXasin5vQe+HuA1EtEfM9gAsqVTw From: "Hallam-Baker, Phillip" To: "Digital Identity Exchange" , "David Fuelling" X-OriginalArrivalTime: 13 Jun 2006 20:54:52.0218 (UTC) FILETIME=[9DE739A0:01C68F2B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > From: Chris Drake [mailto:christopher@pobox.com]=20 > Hi David, >=20 > DKIM is one of at least 3 different serverside email=20 > verification protocols - the other lesser one is SenderID aka=20 > CallerID from Microsoft, and the really big one is SPF. =20 > Yahoo and gmail are the only people doing DKIM that I know of=20 > (check your own gmail headers - you can see it in there: > DomainKey-Signature: a=3Drsa-sha1; q=3Ddns; ... Actually SenderID and SPF are the same as far as the sender is = concerned. There are people who have the peculiar notion that the SENDER = of an email should be able to prevent the RECIPIENT from using evil = proprietary software to scan their email. Tough. I make it a point to scan each and every email received from open source = types using the PRA. As you might guess I have very little time for the specific doctrine of = open source theology that caused the split. The Microsoft license was = fully compliant with the traditional IETF terms. > S/MIME is better than all the above, since it's client-side=20 > instead of serverside (cannot be spoofed by other users of=20 > the same ISP or webmail provider) - but S/MIME itself relies=20 > on some earlier "click here to confirm you own this email=20 > address" check, none of which probably use SPF/DKIM/SenderID Actually S/MIME and OpenPGP both have issues which is why Jon Callas and = myself were invovled. They are both very good for a certain application, they are not very = well suited for the specific application addressed by DKIM. I have proposed a scheme which is a synthesis of an extended DKIM and = SMIME/PGP. The basic idea is to use DKIM for authentication, augmenting = it with a means of accessing a certificate for the key discovered in the = DNS so that a receiver can obtain information about the sender. S/MIME and PGP are used to protect the confidentiality of outbound = email. There is a small amount of glue. In point of fact either message = format is just as good as the other or as near so as makes little odds. = The reason for insisting on support for both is that I am completely = sick of people thinking that there is still a standards war going on. = And so for that matter is PGP Inc which has been selling a pretty nice = SMIME implementation for years.=20 Support for end user keying is layered in using XKMS 2.0 which is a W3C = standard that supports key discovery, trusted key discovery and = provisioning. I presented a paper on this scheme to the 2006 NIST PKI conference. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 16 08:39:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDbT-0000wi-5f; Fri, 16 Jun 2006 08:39:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDbS-0000wd-1z for dix@ietf.org; Fri, 16 Jun 2006 08:39:10 -0400 Received: from mx6.kent.ac.uk ([129.12.21.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrDbQ-0000tA-Qf for dix@ietf.org; Fri, 16 Jun 2006 08:39:10 -0400 Received: from dhcp2935.ukc.ac.uk ([129.12.41.53]) by mx6.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1FrDbK-0001aD-BC for dix@ietf.org; Fri, 16 Jun 2006 13:39:02 +0100 Message-ID: <4492A667.7090909@kent.ac.uk> Date: Fri, 16 Jun 2006 13:39:03 +0100 From: David Chadwick Organization: University of Kent User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: dix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UKC-Mail-System: No virus detected X-UKC-SpamCheck: X-UKC-MailScanner-From: d.w.chadwick@kent.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [dix] Ietf 66 meeting 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 Will there be a DIX meeting at IETF 66, as there isnt one currently scheduled on the agenda thanks David _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 16 17:56:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMIm-0003HV-82; Fri, 16 Jun 2006 17:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMIk-0003HQ-Sg for dix@ietf.org; Fri, 16 Jun 2006 17:56:26 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMIj-0007QK-K4 for dix@ietf.org; Fri, 16 Jun 2006 17:56:26 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5GLuPYb010413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 16 Jun 2006 17:56:25 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5GLuV0Z087712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 16 Jun 2006 15:56:31 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5GLuOnU031844 for ; Fri, 16 Jun 2006 15:56:24 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5GLuNJN031820 for ; Fri, 16 Jun 2006 15:56:24 -0600 From: John McGarvey To: Digital Identity Exchange Message-ID: Date: Fri, 16 Jun 2006 16:00:41 -0600 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 06/16/2006 16:00:43 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [dix] John McGarvey is out of the office. X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469950691==" Errors-To: dix-bounces@ietf.org --===============1469950691== Content-type: multipart/alternative; Boundary="0__=08BBFB1CDFEB6F498f9e8a93df938690918c08BBFB1CDFEB6F49" Content-Disposition: inline --0__=08BBFB1CDFEB6F498f9e8a93df938690918c08BBFB1CDFEB6F49 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 06/16/2006 and will not return until 07/10/2006. I will respond to your message when I return. --0__=08BBFB1CDFEB6F498f9e8a93df938690918c08BBFB1CDFEB6F49 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 06/16/2006 and will not return until 07/10/2006.

I will respond to your message when I return. --0__=08BBFB1CDFEB6F498f9e8a93df938690918c08BBFB1CDFEB6F49-- --===============1469950691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1469950691==-- From dix-bounces@ietf.org Mon Jun 19 13:31:33 2006 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) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) 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 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 From dix-bounces@ietf.org Mon Jun 19 15:30:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPST-0006Jv-Mt; Mon, 19 Jun 2006 15:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsPSR-0006Jp-Mo for dix@ietf.org; Mon, 19 Jun 2006 15:30:47 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsPSQ-0005oh-BA for dix@ietf.org; Mon, 19 Jun 2006 15:30:47 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5JJUjlq026504 for ; Mon, 19 Jun 2006 13:30:45 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k5JJUjjJ007733 for ; Mon, 19 Jun 2006 13:30:45 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5JJUjiY017522 for ; Mon, 19 Jun 2006 14:30:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5JJUj8G017521 for dix@ietf.org; Mon, 19 Jun 2006 14:30:45 -0500 (CDT) Date: Mon, 19 Jun 2006 14:30:45 -0500 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity Message-ID: <20060619193045.GP5688@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mon, Jun 19, 2006 at 01:31:21PM -0400, Sam Hartman wrote: > 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. [...] Gosh, that sounds like a ticketing service... Like Kerberos, actually. Or we could make a ticketing service out of PKIX technologies. Or out of SAML/XMLdsig/XMLenc. Or something totally new! Or we could try to re-use specs. :) Yes, I see why you suggest Kerberos. One argument I've seen against Kerberos is that it requires online infrastructure, but I think it's now clear that all the good choices in this space do (e.g., PKIX CRL and OCSP servers, online CAs, SACRED servers, etc.). That leaves the argument that Kerberos V KDCs know too many secret keys, but Kerberos V has been getting PK technology added to it too, and in the end the specs will allow users to make the public key vs. shared symmetric key decisions (which I think is a good thing, provided that we inform those making the choices of the relevant trade-offs). However, the strongest arguments against Kerberos, that is, the political ones, are also the most superficial. I don't know how you argue with fashion :) Nico -- _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 19 16:49:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQgx-00075H-Vv; Mon, 19 Jun 2006 16:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQgw-000756-CB for dix@ietf.org; Mon, 19 Jun 2006 16:49:50 -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 1FsQgv-0006x8-60 for dix@ietf.org; Mon, 19 Jun 2006 16:49:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4D217E0079; Mon, 19 Jun 2006 16:49:44 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity References: <20060619193045.GP5688@binky.Central.Sun.COM> Date: Mon, 19 Jun 2006 16:49:44 -0400 In-Reply-To: <20060619193045.GP5688@binky.Central.Sun.COM> (Nicolas Williams's message of "Mon, 19 Jun 2006 14:30:45 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org So, I don't think the KDCs know too many secret keys argument is very good when we are in a space where the state of the art is identity providers knowing plaintext passwords. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 19 16:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQkp-0000V1-Aw; Mon, 19 Jun 2006 16:53:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsQkn-0000UX-IH for dix@ietf.org; Mon, 19 Jun 2006 16:53:49 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsQkj-0007if-8e for dix@ietf.org; Mon, 19 Jun 2006 16:53:49 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5JKriCb007440 for ; Mon, 19 Jun 2006 14:53:44 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k5JKriXY020650 for ; Mon, 19 Jun 2006 14:53:44 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k5JKrinJ017609 for ; Mon, 19 Jun 2006 15:53:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k5JKri5g017608 for dix@ietf.org; Mon, 19 Jun 2006 15:53:44 -0500 (CDT) Date: Mon, 19 Jun 2006 15:53:44 -0500 From: Nicolas Williams To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity Message-ID: <20060619205344.GS5688@binky.Central.Sun.COM> References: <20060619193045.GP5688@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mon, Jun 19, 2006 at 04:49:44PM -0400, Sam Hartman wrote: > So, I don't think the KDCs know too many secret keys argument is very > good when we are in a space where the state of the art is identity > providers knowing plaintext passwords. Point! But again, that would only be a minor argument. Fashion, well, that's may be a tougher nut to crack. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 19 17:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRjT-0007dB-Bk; Mon, 19 Jun 2006 17:56:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRjS-0007cq-Et for dix@ietf.org; Mon, 19 Jun 2006 17:56:30 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRjO-00051R-3u for dix@ietf.org; Mon, 19 Jun 2006 17:56:30 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 323981E8C4C; Mon, 19 Jun 2006 14:56:25 -0700 (PDT) To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity References: From: Eric Rescorla Date: Mon, 19 Jun 2006 14:56:25 -0700 In-Reply-To: (Sam Hartman's message of "Mon, 19 Jun 2006 13:31:21 -0400") Message-ID: <86ac884xo6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Sam Hartman writes: > 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." Sam, Well, it certainly would be straightforward to write up an alternative proposal using some other underlying technology (X.509 ACs, S/MIME, SSL/TLS client auth, etc.). I'm sure that that would have advantages and disadvantages vis-a-vis this proposal. However, I submit that we're not at the point where that level of analysis is helpful; rather, we need to work out what general kind of system architecture we want to have and only then will we have a framework for figuring out what kind of protocol to build. To that end, my next message will focus on trying to work through those issues. -Ekr _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 19 17:59:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRmS-00021k-6a; Mon, 19 Jun 2006 17:59:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsRmQ-0001pi-GA for dix@ietf.org; Mon, 19 Jun 2006 17:59:34 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsRmM-0005HL-62 for dix@ietf.org; Mon, 19 Jun 2006 17:59:34 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Cc: Subject: [dix] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org There'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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 20 14:51:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslJS-0007sJ-K1; Tue, 20 Jun 2006 14:50:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslJR-0007rG-DJ for dix@ietf.org; Tue, 20 Jun 2006 14:50:57 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslJQ-0005Ot-4F for dix@ietf.org; Tue, 20 Jun 2006 14:50:57 -0400 Received: from [192.168.103.124] (adsl-75-5-124-98.dsl.pltn13.sbcglobal.net [75.5.124.98]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 3B2BC1422A0; Tue, 20 Jun 2006 11:50:55 -0700 (PDT) In-Reply-To: <4492A667.7090909@kent.ac.uk> References: <4492A667.7090909@kent.ac.uk> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Ietf 66 meeting Date: Tue, 20 Jun 2006 11:50:51 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Pete Resnick X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I had two different BOF proposals, so I requested a combined BOF called WAE -- Web Authentication Enhancements. Pete Resnick will chair and accept suggestions for agenda topics. Also let him know if you'd like a draft to be mentioned on the agenda so that meeting attendees know they have to read it to be up on the submitted work. Lisa On Jun 16, 2006, at 5:39 AM, David Chadwick wrote: > Will there be a DIX meeting at IETF 66, as there isnt one currently > scheduled on the agenda > > thanks > > David > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 20 17:34:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnrL-0001oP-EH; Tue, 20 Jun 2006 17:34:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnrK-0001oJ-DT for dix@ietf.org; Tue, 20 Jun 2006 17:34:06 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsnrJ-0002ml-10 for dix@ietf.org; Tue, 20 Jun 2006 17:34:06 -0400 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id 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 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-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [dix] RE: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 20 17:47:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso40-0004RV-1z; Tue, 20 Jun 2006 17:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fso3y-0004MC-Dg for dix@ietf.org; Tue, 20 Jun 2006 17:47:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsniy-00021l-IY for dix@ietf.org; Tue, 20 Jun 2006 17:25:28 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fsn1m-0007XE-FH for dix@ietf.org; Tue, 20 Jun 2006 16:41:00 -0400 Received: from [140.247.248.144] ([140.247.248.144]) (authenticated bits=0) by mail1.sxip.com (8.13.5/8.13.5) with ESMTP id k5KKelRJ006784 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Tue, 20 Jun 2006 13:40:48 -0700 (PDT) (envelope-from dick@sxip.com) In-Reply-To: <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> References: <4492A667.7090909@kent.ac.uk> <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> 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] Ietf 66 meeting Date: Tue, 20 Jun 2006 16:40:45 -0400 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: -2.6 (--) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Pete Resnick X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Hi Lisa, when do you think the BOF will be on the schedule? -- Dick On 20-Jun-06, at 2:50 PM, Lisa Dusseault wrote: > I had two different BOF proposals, so I requested a combined BOF > called WAE -- Web Authentication Enhancements. Pete Resnick will > chair and accept suggestions for agenda topics. Also let him know > if you'd like a draft to be mentioned on the agenda so that meeting > attendees know they have to read it to be up on the submitted work. > > Lisa > > On Jun 16, 2006, at 5:39 AM, David Chadwick wrote: > >> Will there be a DIX meeting at IETF 66, as there isnt one >> currently scheduled on the agenda >> >> thanks >> >> David >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 21 10:16:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Vj-0005ur-B5; Wed, 21 Jun 2006 10:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Vi-0005um-AL for dix@ietf.org; Wed, 21 Jun 2006 10:16:50 -0400 Received: from stratton-three-seventy-eight.mit.edu ([18.187.6.123] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3Vh-0007hL-4b for dix@ietf.org; Wed, 21 Jun 2006 10:16:50 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 22 11:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRSE-0002rs-BH; Thu, 22 Jun 2006 11:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRSC-0002p6-Au for dix@ietf.org; Thu, 22 Jun 2006 11:50:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtNZW-0006FO-Po for dix@ietf.org; Thu, 22 Jun 2006 07:42:06 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtNOZ-00031R-Kh for dix@ietf.org; Thu, 22 Jun 2006 07:30:48 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9D4E0E0079; Thu, 22 Jun 2006 07:30:40 -0400 (EDT) From: Sam Hartman To: dix@ietf.org Date: Thu, 22 Jun 2006 07:30:40 -0400 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [dix] Looks like WEA is schedule Friday morning at 9 AM 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 According to the agenda. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 22 17:09:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWR0-0008FA-Ha; Thu, 22 Jun 2006 17:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWQy-0008Eq-Jg for dix@ietf.org; Thu, 22 Jun 2006 17:09:52 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWQx-0003wN-A4 for dix@ietf.org; Thu, 22 Jun 2006 17:09:52 -0400 Received: from [192.168.1.100] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 834C31422CC; Thu, 22 Jun 2006 14:09:50 -0700 (PDT) In-Reply-To: References: <4492A667.7090909@kent.ac.uk> <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BF2EACE-CB1B-4630-9080-828B453BCCA4@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [dix] Ietf 66 meeting Date: Thu, 22 Jun 2006 14:09:45 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Pete Resnick 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 It's there now but the schedule is NOT final. lisa On Jun 20, 2006, at 1:40 PM, Dick Hardt wrote: > Hi Lisa, when do you think the BOF will be on the schedule? > > -- Dick > > On 20-Jun-06, at 2:50 PM, Lisa Dusseault wrote: > >> I had two different BOF proposals, so I requested a combined BOF >> called WAE -- Web Authentication Enhancements. Pete Resnick will >> chair and accept suggestions for agenda topics. Also let him know >> if you'd like a draft to be mentioned on the agenda so that >> meeting attendees know they have to read it to be up on the >> submitted work. >> >> Lisa >> >> On Jun 16, 2006, at 5:39 AM, David Chadwick wrote: >> >>> Will there be a DIX meeting at IETF 66, as there isnt one >>> currently scheduled on the agenda >>> >>> thanks >>> >>> David >>> >>> _______________________________________________ >>> dix mailing list >>> dix@ietf.org >>> https://www1.ietf.org/mailman/listinfo/dix >> >> >> _______________________________________________ >> dix mailing list >> dix@ietf.org >> https://www1.ietf.org/mailman/listinfo/dix >> >> > > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 23 18:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttwo-0001GZ-Kx; Fri, 23 Jun 2006 18:16:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttwm-0000u2-Ih for dix@ietf.org; Fri, 23 Jun 2006 18:16:16 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fttwl-0001Tv-TG for dix@ietf.org; Fri, 23 Jun 2006 18:16:16 -0400 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) Message-Id: <10123324-6DF8-4DF9-B9FC-0E3BE0FF363D@yahoo-inc.com> From: Mark Nottingham Date: Fri, 23 Jun 2006 15:12:48 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Spam-Score: -14.9 (--------------) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1824859500==" Errors-To: dix-bounces@ietf.org --===============1824859500== Content-Type: multipart/alternative; boundary=Apple-Mail-1-994876998 --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-- --===============1824859500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============1824859500==-- From dix-bounces@ietf.org Fri Jun 23 18:17:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttxV-0002vH-2x; Fri, 23 Jun 2006 18:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttxT-0002vC-Lz for dix@ietf.org; Fri, 23 Jun 2006 18:16:59 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttxS-0001UV-FR for dix@ietf.org; Fri, 23 Jun 2006 18:16:59 -0400 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 k5NMGoWS020661 for ; Fri, 23 Jun 2006 22:16:58 GMT Message-ID: <449C6842.90404@neustar.biz> Date: Fri, 23 Jun 2006 15:16:34 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Digital Identity Exchange Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [dix] fyi: SAMLv2: HTTP POST =?windows-1252?q?=93NoXMLdsig=94_Binding?= 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 Given the various issues with XMLdsig and discussions with various folks,= Scott=20 Cantor and I crafted a new SAML HTTP POST binding which doesn't rely on=20 XMLdsig, but specifies optional signing of the conveyed messages, as "blo= bs".=20 We've tentatively named the binding "HTTP-POST-NoXMLdsig". The working dr= aft=20 spec is here.. SAMLv2: HTTP POST =93NoXMLdsig=94 Binding [DRAFT] http://www.oasis-open.org/committees/download.php/18722/draft-hodges-saml= -binding-noxmldsig-01.pdf The basic notion of this draft binding was well-received by the SSTC and = the=20 consensus on a recent SSTC concall was that we'd proceed with putting it = on the=20 SSTC/OASIS equivalent of "the standards track". Note that this spec is a = *working draft* and some details will change, and comments are welcome. This binding could be leveraged/profiled in the DIX context in order to p= rovide=20 the capability for implementors/deployers to optionally use conventional = sign-the-BLOB techniques, or the SXIP/DIX Message Signature/Verification = technique, or no signatures. JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 23 18:29:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu9T-0001a0-6k; Fri, 23 Jun 2006 18:29:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu9R-0001Xm-GR for dix@ietf.org; Fri, 23 Jun 2006 18:29:21 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftu9Q-0004pt-Ss for dix@ietf.org; Fri, 23 Jun 2006 18:29:21 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0BE561E8C1F; Fri, 23 Jun 2006 15:29:20 -0700 (PDT) To: Mark Nottingham 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-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 23 23:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJG-00021I-58; Fri, 23 Jun 2006 23:59:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJE-00020Q-TQ for dix@ietf.org; Fri, 23 Jun 2006 23:59:48 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzJD-00028p-Hz for dix@ietf.org; Fri, 23 Jun 2006 23:59:48 -0400 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 Date: Fri, 23 Jun 2006 18:51:26 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 23 23:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJK-00022s-BD; Fri, 23 Jun 2006 23:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJJ-00022M-Be for dix@ietf.org; Fri, 23 Jun 2006 23:59:53 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzJI-00028x-1Q for dix@ietf.org; Fri, 23 Jun 2006 23:59:53 -0400 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 Date: Fri, 23 Jun 2006 19:12:16 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Fri Jun 23 23:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJM-00024f-KU; Fri, 23 Jun 2006 23:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzJL-00024G-9f for dix@ietf.org; Fri, 23 Jun 2006 23:59:55 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzJI-000290-TT for dix@ietf.org; Fri, 23 Jun 2006 23:59:55 -0400 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 Date: Fri, 23 Jun 2006 19:14:58 -0700 To: Eric Rescorla X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 00:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzUT-0000jT-M9; Sat, 24 Jun 2006 00:11:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtzUR-0000jJ-MQ for dix@ietf.org; Sat, 24 Jun 2006 00:11:24 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzUQ-0002jd-Cf for dix@ietf.org; Sat, 24 Jun 2006 00:11:23 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 4D1B21E8C1F; Fri, 23 Jun 2006 21:11:21 -0700 (PDT) To: Dick Hardt 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-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 00:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftza1-0006C9-2Z; Sat, 24 Jun 2006 00:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftza0-0006C4-FG for dix@ietf.org; Sat, 24 Jun 2006 00:17:08 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtzZz-0002po-4V for dix@ietf.org; Sat, 24 Jun 2006 00:17:08 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7E2D71E8C1F; Fri, 23 Jun 2006 21:17:06 -0700 (PDT) To: Dick Hardt 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-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 10:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9Zc-0000XZ-E4; Sat, 24 Jun 2006 10:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9Za-0000Mo-Uy for dix@ietf.org; Sat, 24 Jun 2006 10:57:22 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu9ZW-00048y-IZ for dix@ietf.org; Sat, 24 Jun 2006 10:57:22 -0400 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 Date: Sat, 24 Jun 2006 07:57:14 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 12:22:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAte-00081M-35; Sat, 24 Jun 2006 12:22:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAtc-000816-Sg for dix@ietf.org; Sat, 24 Jun 2006 12:22:08 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuAtb-0003ma-G1 for dix@ietf.org; Sat, 24 Jun 2006 12:22:08 -0400 Received: from vegeta.corp.google.com (vegeta.corp.google.com [172.24.0.3]) by smtp-out.google.com with ESMTP id k5OGM5so015066 for ; Sat, 24 Jun 2006 09:22:05 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=jOafff6EncCcudCv6wqjunJrhHRP37+tBhUH8wXTVV7hR+6Ma/T96InRPPFH7olLM xVgD6M8+dszd+fZcbC4cg== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by vegeta.corp.google.com with ESMTP id k5OGJtN9016893 for ; Sat, 24 Jun 2006 09:22:01 -0700 Received: by smtp-out2.google.com with SMTP id 33so36178fpx for ; Sat, 24 Jun 2006 09:22:01 -0700 (PDT) Received: by 10.253.14.20 with SMTP id 20mr111822fpn; Sat, 24 Jun 2006 09:22:01 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Sat, 24 Jun 2006 09:22:01 -0700 (PDT) Message-ID: <1b587cab0606240922m6d318bf8w8f93b795e2596fef@mail.google.com> Date: Sat, 24 Jun 2006 17:22:01 +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-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/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? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 12:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAuZ-00010g-Hw; Sat, 24 Jun 2006 12:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAuY-00010b-ET for dix@ietf.org; Sat, 24 Jun 2006 12:23:06 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuAuX-0004Gf-2m for dix@ietf.org; Sat, 24 Jun 2006 12:23:06 -0400 Received: from death.corp.google.com (death.corp.google.com [172.24.0.123]) by smtp-out.google.com with ESMTP id k5OGN3n0008048 for ; Sat, 24 Jun 2006 09:23:03 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=K8Bq6vFRBXL3GlN4w9uzmE9qNjRc+pkwK7jhyvGxodSbD4bhbHJu8l6YgqdQ/i/IC RYnRi2jD9qgb+fOgBY5xQ== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by death.corp.google.com with ESMTP id k5OGN2Ia014505 for ; Sat, 24 Jun 2006 09:23:02 -0700 Received: by smtp-out2.google.com with SMTP id 33so36208fpx 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-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org [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? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 12:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAzI-000583-Tk; Sat, 24 Jun 2006 12:28:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuAzH-00057y-Or for dix@ietf.org; Sat, 24 Jun 2006 12:27:59 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuAzF-0005Dp-Dr for dix@ietf.org; Sat, 24 Jun 2006 12:27:59 -0400 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-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Sat Jun 24 14:18:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuChu-0003ON-BT; Sat, 24 Jun 2006 14:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuCht-0003OI-EJ for dix@ietf.org; Sat, 24 Jun 2006 14:18:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuChs-0006oB-1q for dix@ietf.org; Sat, 24 Jun 2006 14:18:09 -0400 Received: from [127.0.0.1] (stdhcp-234.va.neustar.com [10.31.13.234]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5OIHw5q010617 for ; Sat, 24 Jun 2006 18:18:07 GMT Message-ID: <449D81C4.8060706@neustar.biz> Date: Sat, 24 Jun 2006 11:17:40 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Digital Identity Exchange Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [dix] fyi: SAMLv2 Lightweight Web Browser SSO Profile 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 Continuing in the vein of exploring how to make things easier=20 implementation-wise for web sso relying parties, aka "service providers" = --=20 which is a significant aspect of what's been discussed on this list -- we= 've=20 crafted a "SAMLv2 Lightweight Web Browser SSO Profile": http://www.ietf.org/internet-drafts/draft-hodges-saml-lsso-00.txt This profile builds upon the "HTTP-POST-NoXMLdsig" SAML binding reference= d in a=20 prior message [1]. We understand that the overall problem space being discussed on this list= goes=20 beyond "simple web SSO", but there are several reasons we feel it worthwh= ile to=20 craft a simple, lightweight, SAML web sso profile and contribute it to th= e=20 discussion: * it is a large multi-faceted problem space and we find it valuable to break things down into smaller pieces * we want to explore which "knobs and buttons" in the existing SAML Web= SSO Profile we can "turn down" in order to simplify service provider implementation and deployment effort [2] * we want to explore whether we can craft things such that the solution= s for the other portions of the problem space can leverage a SAML profile such as this * there are a non-trivial number of SAML-based deployments [3] and products [4], so crafting a lightweight SSO mechanism that more closely resembles an existing SAML profile has the benefit of facilitating migration/interoperation for implementors and deployers JeffH [1] fyi: SAMLv2: HTTP POST =93NoXMLdsig=94 Binding http://www1.ietf.org/mail-archive/web/dix/current/msg00720.html [2] e.g. by constraining the set of SAML bindings the web sso profile rel= ies upon, eg the artifact binding -- which requires "callbacks" on the p= art of the sP to the IDP/identity agent -- implementation, and especiall= y deployment is significantly simplified. [3] e.g.: http://shibboleth.internet2.edu/seas.html http://shibboleth.internet2.edu/community.html http://www.openidp.org/ http://www.athensams.net/local_auth/saml/ http://xml.coverpages.org/OblixSouthwestAirlines.html [4] e.g.: http://www.opensaml.org/ http://www.sourceid.org/projects/saml-1.1-toolkit.html http://sourceforge.net/projects/guanxi/ http://www.projectliberty.org/activities/conformant_products.php#SAM= L2 -------- Original Message -------- Subject: I-D ACTION:draft-hodges-saml-lsso-00.txt Date: Thu, 22 Jun 2006 10:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. Title : SAMLv2 Lightweight Web Browser SSO Profile Author(s) : J. Hodges, S. Cantor Filename : draft-hodges-saml-lsso-00.txt Pages : 28 Date : 2006-6-22 =09 This document specifies a SAMLv2 lightweight Web Browser Single Sign-On Profile. This profile is modeled on the OASIS SAMLv2 Web Browser SSO profile, adding various constraints, and using a new lightweight SAMLv2 HTTP POST binding which does not rely on XML Digital Signature -- relying on a more simple-to-implement signature approach instead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hodges-saml-lsso-00.txt --- end _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 12:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Futbe-0007wh-MZ; Mon, 26 Jun 2006 12:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Futbc-0007w7-VO for dix@ietf.org; Mon, 26 Jun 2006 12:06:32 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbc-00049O-Tr for dix@ietf.org; Mon, 26 Jun 2006 12:06:32 -0400 Received: from nf-out-0910.google.com ([64.233.182.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutUZ-0000XK-TB for dix@ietf.org; Mon, 26 Jun 2006 11:59:18 -0400 Received: by nf-out-0910.google.com with SMTP id d4so876926nfe 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" To: dix@ietf.org, ietf-http-auth@lists.osafoundation.org 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-Spam-Score: -2.5 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements 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 > 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 14:55:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwEk-00063z-7Y; Mon, 26 Jun 2006 14:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwEi-00063u-SR for dix@ietf.org; Mon, 26 Jun 2006 14:55:04 -0400 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwEi-0001gA-J6 for dix@ietf.org; Mon, 26 Jun 2006 14:55:04 -0400 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 Date: Mon, 26 Jun 2006 11:54:43 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 2006/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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 15:00:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwKO-00034a-6E; Mon, 26 Jun 2006 15:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwKN-00034V-3m for dix@ietf.org; Mon, 26 Jun 2006 15:00:55 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwKL-0002AL-QA for dix@ietf.org; Mon, 26 Jun 2006 15:00:55 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 995601E8C1F; Mon, 26 Jun 2006 12:00:52 -0700 (PDT) To: Mark Nottingham 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 15:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwdK-00053i-3N; Mon, 26 Jun 2006 15:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuwdI-000539-No for dix@ietf.org; Mon, 26 Jun 2006 15:20:28 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuwdG-0004vP-1K for dix@ietf.org; Mon, 26 Jun 2006 15:20:28 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 7C86D1E8C1F; Mon, 26 Jun 2006 12:20:25 -0700 (PDT) To: Dick Hardt 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-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 15:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxEz-0008Sw-VP; Mon, 26 Jun 2006 15:59:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuxEy-0008SL-8d for dix@ietf.org; Mon, 26 Jun 2006 15:59:24 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuxEu-0001jw-T5 for dix@ietf.org; Mon, 26 Jun 2006 15:59:24 -0400 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 Date: Mon, 26 Jun 2006 12:57:49 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements 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 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 17:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyEZ-0003x0-UU; Mon, 26 Jun 2006 17:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyEY-0003wL-8a for dix@ietf.org; Mon, 26 Jun 2006 17:03:02 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyEV-0006be-RX for dix@ietf.org; Mon, 26 Jun 2006 17:03:02 -0400 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 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-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] RE: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org I 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Mon Jun 26 18:00:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz7x-0007xQ-2X; Mon, 26 Jun 2006 18:00:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz7w-0007wy-5s for dix@ietf.org; Mon, 26 Jun 2006 18:00:16 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuz7s-0003lg-QN for dix@ietf.org; Mon, 26 Jun 2006 18:00:16 -0400 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 Date: Mon, 26 Jun 2006 15:00:08 -0700 To: EKR X-Mailer: Apple Mail (2.750) X-Spam-Status: No, score=-102.6 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 02:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv7Kd-0000XB-Fy; Tue, 27 Jun 2006 02:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6LE-0003gf-1y for dix@ietf.org; Tue, 27 Jun 2006 01:42:28 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6LA-0003ms-Mt; Tue, 27 Jun 2006 01:42:28 -0400 Received: from [12.105.228.215] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d22); Tue, 27 Jun 2006 00:42:15 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Mon, 26 Jun 2006 22:42:11 -0700 To: Digital Identity Exchange From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Tue, 27 Jun 2006 02:45:53 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] BOF plans (Was: Notes on Web authentication enhancements) 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 EKR's note seems to have sparked discussions in the right direction. When he and I talked about the upcoming BOF, I had asked him to start this conversation so that we could drill down to what a potential working group might work on and give some structure to the BOF. Here's what I have in mind: There are folks with assorted ideas about what problems need to be solved and what sorts of solutions need to be applied. I think EKR's message did most of the leg work of separating out the problem spaces. IMO many of the problems can be addressed by separate independent mechanisms that fit together (i.e., they don't require "a grand solution"). My desire is to have the BOF break out these mechanisms and see if we can come up with a list of what problems a working group would solve. Here's a list of questions to guide the endeavor. I expect anyone who wants to propose a problem and/or solution to be able to say how their proposal answers these questions: - 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? - Does the mechanism use or extend currently deployed web authentication mechanisms (client side and server side)? If not, why not? - Is the client able to decide which identifying information goes to the server? - Does the mechanism involve 3rd parties for authentication or identifying info? Does the 3rd party need to be trusted by the relying party? - Does the mechanism use a format for the information that has widely available implementations? - Are you using a mechanism to authenticate the information that has widely available implementations? 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. (Note that I have framed these as implementation questions and not architectural ones. However, keep in mind that the answers you give have serious architectural implications.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 02:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv7Kd-0000X6-BG; Tue, 27 Jun 2006 02:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAA-0001wJ-Sb for dix@ietf.org; Fri, 23 Jun 2006 18:30:06 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtuA9-0005Bg-It for dix@ietf.org; Fri, 23 Jun 2006 18:30:06 -0400 Received: by nf-out-0910.google.com with SMTP id o63so568228nfa 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" 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-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 27 Jun 2006 02:45:53 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 02:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv7Kd-0000XB-Fy; Tue, 27 Jun 2006 02:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv6LE-0003gf-1y for dix@ietf.org; Tue, 27 Jun 2006 01:42:28 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv6LA-0003ms-Mt; Tue, 27 Jun 2006 01:42:28 -0400 Received: from [12.105.228.215] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d22); Tue, 27 Jun 2006 00:42:15 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com> References: <20060619220742.40B85222427@laser.networkresonance.com> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Mon, 26 Jun 2006 22:42:11 -0700 To: Digital Identity Exchange From: Pete Resnick Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Tue, 27 Jun 2006 02:45:53 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] BOF plans (Was: Notes on Web authentication enhancements) 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 EKR's note seems to have sparked discussions in the right direction. When he and I talked about the upcoming BOF, I had asked him to start this conversation so that we could drill down to what a potential working group might work on and give some structure to the BOF. Here's what I have in mind: There are folks with assorted ideas about what problems need to be solved and what sorts of solutions need to be applied. I think EKR's message did most of the leg work of separating out the problem spaces. IMO many of the problems can be addressed by separate independent mechanisms that fit together (i.e., they don't require "a grand solution"). My desire is to have the BOF break out these mechanisms and see if we can come up with a list of what problems a working group would solve. Here's a list of questions to guide the endeavor. I expect anyone who wants to propose a problem and/or solution to be able to say how their proposal answers these questions: - 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? - Does the mechanism use or extend currently deployed web authentication mechanisms (client side and server side)? If not, why not? - Is the client able to decide which identifying information goes to the server? - Does the mechanism involve 3rd parties for authentication or identifying info? Does the 3rd party need to be trusted by the relying party? - Does the mechanism use a format for the information that has widely available implementations? - Are you using a mechanism to authenticate the information that has widely available implementations? 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. (Note that I have framed these as implementation questions and not architectural ones. However, keep in mind that the answers you give have serious architectural implications.) pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 02:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv7Kd-0000X6-BG; Tue, 27 Jun 2006 02:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAA-0001wJ-Sb for dix@ietf.org; Fri, 23 Jun 2006 18:30:06 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtuA9-0005Bg-It for dix@ietf.org; Fri, 23 Jun 2006 18:30:06 -0400 Received: by nf-out-0910.google.com with SMTP id o63so568228nfa 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" 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-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Tue, 27 Jun 2006 02:45:53 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 04:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8W3-0006VQ-69; Tue, 27 Jun 2006 04:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv8W2-0006VL-Gk for dix@ietf.org; Tue, 27 Jun 2006 04:01:46 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv8W1-0005Zi-AB for dix@ietf.org; Tue, 27 Jun 2006 04:01:46 -0400 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 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-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mon, 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 08:25:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCdY-0001F4-7P; Tue, 27 Jun 2006 08:25:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCdV-0001Ez-83 for dix@ietf.org; Tue, 27 Jun 2006 08:25:45 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvCdS-0003DB-QB for dix@ietf.org; Tue, 27 Jun 2006 08:25:45 -0400 Received: from stewie.corp.google.com (stewie.corp.google.com [172.24.0.49]) by smtp-out.google.com with ESMTP id k5RCPbLE014898 for ; Tue, 27 Jun 2006 05:25:37 -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=MMAonqNEMGwoqQGu4XuIWBsSpTmdHka1H7PoNXX/tjGkQ9F9wf2S/EEPQj/l0+Ukf KegEJlAjPP0Wv/rnCGOpg== Received: from smtp-out2.google.com (fpx33.prod.google.com [10.253.24.33]) by stewie.corp.google.com with ESMTP id k5RCIEO3029578 for ; Tue, 27 Jun 2006 05:25:32 -0700 Received: by smtp-out2.google.com with SMTP id 33so45994fpx for ; Tue, 27 Jun 2006 05:25:32 -0700 (PDT) Received: by 10.253.15.10 with SMTP id 10mr73887fpo; Tue, 27 Jun 2006 05:25:32 -0700 (PDT) Received: by 10.253.19.5 with HTTP; Tue, 27 Jun 2006 05:25:31 -0700 (PDT) Message-ID: <1b587cab0606270525i7a10e0daic3988d426bf0a09d@mail.google.com> Date: Tue, 27 Jun 2006 13:25:31 +0100 From: "Ben Laurie" To: "Digital Identity Exchange" Subject: Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/27/06, Pete Resnick wrote: > EKR's note seems to have sparked discussions in the right direction. > When he and I talked about the upcoming BOF, I had asked him to start > this conversation so that we could drill down to what a potential > working group might work on and give some structure to the BOF. > Here's what I have in mind: > > There are folks with assorted ideas about what problems need to be > solved and what sorts of solutions need to be applied. I think EKR's > message did most of the leg work of separating out the problem > spaces. IMO many of the problems can be addressed by separate > independent mechanisms that fit together (i.e., they don't require "a > grand solution"). My desire is to have the BOF break out these > mechanisms and see if we can come up with a list of what problems a > working group would solve. Here's a list of questions to guide the > endeavor. I expect anyone who wants to propose a problem and/or > solution to be able to say how their proposal answers these questions: > > - 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? > - 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. > - Is the client able to decide which identifying information goes to > the server? This is clearly essential from a privacy point of view. > - Does the mechanism involve 3rd parties for authentication or > identifying info? Optionally. > Does the 3rd party need to be trusted by the > relying party? Maybe. The 3rd party might just be a convenience rather than a means to establish authenticity of the assertions. > - Does the mechanism use a format for the information that has widely > available implementations? > - Are you using a mechanism to authenticate the information that has > widely available implementations? > > 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. (Note that I have framed > these as implementation questions and not architectural ones. > However, keep in mind that the answers you give have serious > architectural implications.) > > pr > -- > Pete Resnick > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 > > _______________________________________________ > dix mailing list > dix@ietf.org > https://www1.ietf.org/mailman/listinfo/dix > _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 12:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGLn-00089W-QN; Tue, 27 Jun 2006 12:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGLm-00089R-9w for dix@ietf.org; Tue, 27 Jun 2006 12:23:42 -0400 Received: from wr-out-0506.google.com ([64.233.184.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGLl-0004ZM-2s for dix@ietf.org; Tue, 27 Jun 2006 12:23:42 -0400 Received: by wr-out-0506.google.com with SMTP id i34so137733wra 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" To: "Robert Sayre" 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-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/27/06, 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 12:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGqP-0003jn-Sk; Tue, 27 Jun 2006 12:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGqP-0003ji-8x for dix@ietf.org; Tue, 27 Jun 2006 12:55:21 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGqO-0000qY-0Q for dix@ietf.org; Tue, 27 Jun 2006 12:55:21 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 12:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGsl-0004gu-KL; Tue, 27 Jun 2006 12:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGsk-0004gp-Ec for dix@ietf.org; Tue, 27 Jun 2006 12:57:46 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGsi-0001Nw-UR for dix@ietf.org; Tue, 27 Jun 2006 12:57:46 -0400 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 Subject: Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) 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-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Ben 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 12:58:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGtu-0006gc-6v; Tue, 27 Jun 2006 12:58:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvF79-0005vu-JK for dix@ietf.org; Tue, 27 Jun 2006 11:04:31 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvF78-0004D0-AW for dix@ietf.org; Tue, 27 Jun 2006 11:04:31 -0400 Received: by nf-out-0910.google.com with SMTP id d4so1022249nfe 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" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060619220742.40B85222427@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Tue, 27 Jun 2006 12:58:57 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org Subject: [dix] Re: [Ietf-http-auth] Notes on Web authentication enhancements X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 13:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGut-0007Bu-Jw; Tue, 27 Jun 2006 12:59:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvGus-0007Bo-Mq for dix@ietf.org; Tue, 27 Jun 2006 12:59:58 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvGur-0001gs-5g for dix@ietf.org; Tue, 27 Jun 2006 12:59:58 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Digital Identity Exchange , ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR , Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Tue Jun 27 15:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJ1Y-0006BF-46; Tue, 27 Jun 2006 15:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJ1W-0006BA-BK for dix@ietf.org; Tue, 27 Jun 2006 15:14:58 -0400 Received: from imo-m22.mx.aol.com ([64.12.137.3] helo=imo-m22.mail.aol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJ1V-0005K1-0l for dix@ietf.org; Tue, 27 Jun 2006 15:14:58 -0400 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) MIME-Version: 1.0 To: lear@cisco.com, dix@ietf.org X-AOL-IP: 152.163.181.137 X-Spam-Flag: NO X-Spam-Score: 1.2 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0056425438==" Errors-To: dix-bounces@ietf.org --===============0056425438== Content-Type: multipart/alternative; boundary="--------MailBlocks_8C86835190CEE8E_1384_4_FWM-R33.sysops.aol.com" ----------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-- --===============0056425438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0056425438==-- From dix-bounces@ietf.org Wed Jun 28 02:59:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvU1R-0005V4-DV; Wed, 28 Jun 2006 02:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvU1P-0005UF-LR for dix@ietf.org; Wed, 28 Jun 2006 02:59:35 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvU1O-0004ox-Cc for dix@ietf.org; Wed, 28 Jun 2006 02:59:35 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 12:49:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdET-0005LR-V0; Wed, 28 Jun 2006 12:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdES-0005LM-AZ for dix@ietf.org; Wed, 28 Jun 2006 12:49:40 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvdEQ-0002cd-G8 for dix@ietf.org; Wed, 28 Jun 2006 12:49:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 466E4E007B; Wed, 28 Jun 2006 12:49:39 -0400 (EDT) From: Sam Hartman To: dix@ietf.org Date: Wed, 28 Jun 2006 12:49:39 -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-Spam-Score: 0.1 (/) X-Scan-Signature: fb4923faae7d2b1be4e504c39e80ae8d Subject: [dix] Updated phishing requirements draft X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org --=-=-= Hi. I submitted a 01 version of my phishing requirements draft Sunday evening, but it has not yet popped out the other side so I'm including it below. I've tried to improve it based on review comments. I did not get a chance to address everything; I was focusing on some obvious issues of clarity and on refining my thoughts so that the draft reflects my current understanding of the area. I do thank all those who sent comments both on the list and privately. I also thank those who were willing to walk through the requirements with me and help me confirm that the requirements are sufficient for what I'm trying to achieve. --=-=-= Content-Disposition: inline; filename=draft-hartman-webauth-phishing.txt Network Working Group S. Hartman Internet-Draft MIT Expires: December 27, 2006 June 25, 2006 Requirements for Web Authentication Resistant to Phishing draft-hartman-webauth-phishing-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo proposes requirements for protocols between web identity providers and users and for requirements for protocols between identity providers and relying parties. These requirements minimize the likelihood that criminals will be able to gain the credentials necessary to impersonate a user or be able to fraudulently convince users to disclose personal information. To meet these requirements browsers must change. Websites must never receive information such as passwords that can be used to impersonate the user to third parties. Browsers should perform mutual authentication and flag Hartman Expires December 27, 2006 [Page 1] Internet-Draft Web Phishing Requirements June 2006 situations when the target website is not authorized to accept the identity being offered as this is a strong indication of fraud. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Capabilities of Attackers . . . . . . . . . . . . . . . . 6 3.2. Attacks of Interest . . . . . . . . . . . . . . . . . . . 7 4. Requirements for Preventing Phishing . . . . . . . . . . . . . 8 4.1. Support for Passwords . . . . . . . . . . . . . . . . . . 8 4.2. Trusted UI . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. No Password Equivelents . . . . . . . . . . . . . . . . . 9 4.4. Mutual Authentication . . . . . . . . . . . . . . . . . . 9 4.5. Authentication Tied to Resulting Page . . . . . . . . . . 10 4.6. Restricted Identity Providers . . . . . . . . . . . . . . 11 4.7. Protecting Enrollment . . . . . . . . . . . . . . . . . . 11 5. Is it the right Server? . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Hartman Expires December 27, 2006 [Page 2] Internet-Draft Web Phishing Requirements June 2006 1. Introduction Typically, web sites ask users to send a user name and password in order to log in and authenticate their identity to the website. The user name and plaintext password is often sent over a TLS [RFC4346] encrypted connection. As a result of this, the server learns the password and can pretend to be the user to any other system where the user has used the same password. The security of passwords over TLS depends on making sure that the password is sent to the right, trusted server. TLS implementations typically confirm that the name entered by the user in the URL corresponds to the certificate as described in [RFC2818]. One serious security threat on the web today is phishing. Phishing is a form of fraud where an attacker convinces a user to provide confidential information to the attacker believing they are providing the information to a party they trust with that information. For example, an email claiming to be from a user's bank may direct the user to go to a website and verify account information. The attacker captures the user name and password and potentially other sensitive information. Domain names that look like target websites, links in email, and many other factors contribute to phishers' ability to convince users to trust them. It is useful to distinguish two targets of phishing. Sometimes phishing is targeting web authentication credentials such as user name and password. Sometimes phishing is targeting other confidential information. This memo presents requirements that significantly reduce the effectiveness of the first category of phishing: these requirements guarantee that even if the user authenticates to the wrong server, that server cannot impersonate the user to a third party. However to combat phishing targeted at other confidential information the best we can do is try to help the user detect fraud before they release confidential information. So, the approach taken by these requirements is to handle these two types of phishing differently. Users are given some trusted mechanism to determine whether they are typing their password into a secure browser component that will authenticate them to the web server or whether they are typing their password into a legacy mechanism that will send their password to the server. If the user types a password into the trusted browser component, they have strong assurances that their password has not been disclosed and that the page returned from the web server was generated by a party that either knows their password or who is authenticated by an identity provider who knows their password. The web server can then use confidential information known to the user and web server to enhance the user's trust in its identity beyond what is available given the Hartman Expires December 27, 2006 [Page 3] Internet-Draft Web Phishing Requirements June 2006 social engineering attacks against TLS server authentication. If a user enters their password into the wrong server but discovers this before they give that server any other confidential information, then there exposure is very limited. Hartman Expires December 27, 2006 [Page 4] Internet-Draft Web Phishing Requirements June 2006 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Hartman Expires December 27, 2006 [Page 5] Internet-Draft Web Phishing Requirements June 2006 3. Threat Model This section describes the assumed capabilities of phishers, describes assumptions about web security and describes what vulnerabilities exist. We assume that the browser and operating system are secure and can be trusted by the end user. There are many attacks against browsers and operating systems. However without this assumption we cannot make progress in securing web authentication. So we will assume that browsers and operating systems are secure and note that other work to improve the security of browsers and operating systems is critical to the security of the entire web authentication system. We assume that users have limited motivation to combat phishing. Users cannot be expected to read the source of web pages, understand how DNS works well enough to look out for spoofed domains, or understand URI encoding. Users do not typically understand certificates and cannot make informed decisions about whether the subject name in a certificate corresponds to the entity they are attempting to communicate with. 3.1. Capabilities of Attackers Attackers can convince the user to go to a website of their choosing. Since the attacker controls the web site and since the user chose to go to the website the TLS certificate will verify and the website will appear to be secure. The certificate will typically not be issued to the entity the user thinks they are communicating with, but as discussed above, the user will not notice this. The attacker can convincingly replicate any part of the UI of the website being spoofed. The attacker can also spoof trust markers such as the security lock, URL bar and other parts of the browser UI. There is one limitation to the attacker's ability to replicate UI. The attacker cannot replicate a UI that depends on information the attacker does not know. For example, an attacker could generally replicate the UI of a banking site's login page. However the attacker probably could not replicate the account summary page until the attacker learned the user name and password. The attacker can convince the user to do anything with the phishing site that they would do with the real target site. As a consequence, if we want to avoid the user giving the attacker their password, we must transition to a solution where the user would not give the real target site their password. Instead they will need to cryptographically prove that they know their password without revealing it. Hartman Expires December 27, 2006 [Page 6] Internet-Draft Web Phishing Requirements June 2006 3.2. Attacks of Interest The primary attack of interest is an attack in which the user sends confidential information to an unintended recipient. Another significant attack is an attack in which a recipient gains sufficient credentials to impersonate the user to other recipients. The obvious version of this attack is when the recipient learns the password of the user. However even giving the recipient a time- limited token that can be used to impersonate the user would be an instance of this attack. Note that some authentication systems such as Kerberos [RFC4120] provide a facility to delegate the ability to act as the user to the target of the authentication. Such a facility when used with an inappropriately trusted target would be an instance of this attack. Of less serious concerns at the present time are attacks on data integrity where a phisher provides false or misleading information to a user. Hartman Expires December 27, 2006 [Page 7] Internet-Draft Web Phishing Requirements June 2006 4. Requirements for Preventing Phishing This section describes requirements for web authentication solutions. These solutions are intended to prevent phishing targeted at obtaining web authentication credentials. These requirements will make it more difficult for phishers to target other confidential information. The requirements discussed here are similar to the principles outlined in "Limits to Anti-Phishing" [ANTIPHISHING]. Most of this work was discovered independently but work from that paper has been integrated where appropriate. Google's perspective on phishing is very interesting because of their operational experience. 4.1. Support for Passwords The web authentication solution MUST support passwords and MUST be secure even when passwords are commonly used. In many environments, users need the ability to walk up to a computer they have never used before and log in to a website. Carrying a smart card or USB token significantly increases the deployment cost of the website and decreases user convenience. The smart card is costly to deploy because it requires a process for replacing smart cards, requires support staff to be trained in answering questions regarding smart cards and requires a smart card to be issued when an identity is issued. Smart cards are less convenient because users cannot gain access to protected resources without having their card physically with them. Many public access computers do not have smart cards available and do not provide access to USB ports; when they do they tend not to support smart cards. It is important not to underestimate the training costs (either in money or user frustration) of teaching people used to remembering a user name and password about a new security technology. IT is desirable that a solution support other forms of authentication such as smart cards and one-time passwords as these are useful in some environments. 4.2. Trusted UI Users need the ability to trust components of the UI in order to know that the UI is being presented by a trusted component of the browser. The primary concern is to make sure that the user knows the password is being given to trusted software rather than being filled into an HTML form element that will be sent to the server. There are three basic approaches to establishing a trusted UI. The first is to use a dynamic UI based on a secret known by the UI; the Hartman Expires December 27, 2006 [Page 8] Internet-Draft Web Phishing Requirements June 2006 Google paper [ANTIPHISHING] recommends this approach. A second approach is to provide a UI action that highlights trusted or non- trusted components in some way. This could work similarly to the Expose feature in Apple's OS X where a keystroke visually distinguishes structural elements of the UI. Of course such a mechanism would only be useful if users actually used it. Finally, the multi-level security community has extensive research in designing UIs to display classified, compartmentalized information. It is critical that these UIs be able to label information and that these labels not be spoofable. See Section 5 for another case where confidential information in a UI can be used to build trust. 4.3. No Password Equivelents A critical requirement is that when a user authenticates to a website, the website MUST NOT receive a strong password equivalent [IABAUTH]. A strong password equivalent is anything that would allow a phisher to authenticate as a user with a different identity provider. Weak password equivalents MAY only be sent when a new identity is being enrolled or a password is changed. A weak password equivalent allows a party to authenticate to a given identity provider as the user. There are two implications of this requirement. First, strong cryptographic authentication protocol needs to be used instead of sending the password encrypted over TLS. The zero-knowledge class of password protocols such as those discussed in section 8 of the IAB authentication mechanisms document [IABAUTH] seem potentially useful in this case. Note that mechanisms in this space tend to have significant deployment problems because of intellectual property issues. The second implication of this requirement is that if an authentication token is presented to a website, the website MUST NOT be able to modify the token to authenticate as the user to a third party. The party generating the token must cryptographically bind it to either the website that will receive the token or to a key known only to the user. If tokens are bound to keys, the user MUST prove knowledge of this key as part of the authentication process. The key MUST not be disclosed to the server unless the token is bound to the server and the key is only used with that token. 4.4. Mutual Authentication The Google paper [ANTIPHISHING] describes a requirement for mutual authentication. A common phishing practice is to accept a user name Hartman Expires December 27, 2006 [Page 9] Internet-Draft Web Phishing Requirements June 2006 and password as part of an attempt to make the phishing site authentic. The real target is some other confidential information. The user name and password are captured, but are not verified. After the user name and password are entered, the phishing site collects other confidential information. Authentication of the server at the TLS level and authentication of the client within the TLS session is not sufficient. AS discussed previously the attacker can direct the user to a site that the attacker controls so the TLS authentication will succeed. So an authentication solution for phishing MUST detect the situation where the server ignores or does not participate in the authentication. If authentication is based on a shared secret such as a password, then the authentication protocol MUST prove that the secret or a suitable verifier is known by both parties. Interestingly the existence of a shared secret will provide better protection that the right server is being contacted than if public key credentials are used. By their nature, public key credentials allow parties to be contacted without a prior security association. In protecting against phishing targeted at obtaining other confidential information, this may prove a liability. However public key credentials provide strong protection against phishing targeted at obtaining authentication credentials because they are not vulnerable to dictionary attacks. Such dictionary attacks are a significant weakness of shared secrets such as passwords intended to be remembered by humans. For public key protocols, this requirement would mean that the server typically needs to sign an assertion of what identity it authenticated. 4.5. Authentication Tied to Resulting Page Users expect that whatever party they authenticate to will be the party that generates the content they see. One possible phishing attack is to insert the phisher between the user and the real site as a man-in-the-middle. On today's websites, the phisher typically gains the user's user name and password. Even if the other requirements of this specification are met, the phisher could gain access to the user's session on the target site. This attack is of particular concern to the banking industry. A man-in-the-middle may gain access to the session which may give the phisher confidential information or the ability to execute transactions on the user's behalf. The authentication system MUST guarantee to the user and the target server that the response is generated by the target server and will only be seen by parties authorized by either the target server or the user. This can be done in several ways: Hartman Expires December 27, 2006 [Page 10] Internet-Draft Web Phishing Requirements June 2006 1. Assuming that only certificates from trusted CAs are accepted and the user has not bypassed certificate validation, it is sufficient to confirm that the identity of the server at the TLS level is the same at the HTTP authentication level. In the case of TLS client authentication this is trivially true. 2. Another alternative is to bind the authentication exchange to the channel created by the TLS session. The general concept behind channel binding is discussed in section 2.2.2 of [BTNS]. This paragraph needs to be expanded to point to proposals for doing channel binding with TLS. xxx 3. Redirect based schemes in which the identity provider is told what site to return the user to meets this requirement provided again that certificate validation is done at the TLS layer. 4.6. Restricted Identity Providers Some identity providers will allow anyone to accept their identity. However particularly for financial institutions and large service providers it will be common that only authorized business partners will be able to accept the identity. The confirmation that the the relying party is such a business partner will often be a significant part of the value provided by the identity provider, so it is important that the protocol enable this. For such identities, the user MUST be assured that the target server is authorized by the identity provider to accept identities from that identity provider. Several mechanisms could be used to accomplish this: 1. The target server can provide a certificate issued by the identity provider as part of the authentication. 2. The identity provider can explicitly approve the identity. For example in a redirect-based scheme the identity provider knows the identity of the relying party before providing claims of identity to that party. A similar situation happens with Kerberos. 4.7. Protecting Enrollment One area of particular vulnerability to phishing is enrollment of a new identity in an identity provider. Protecting against phishing targeted at obtaining other confidential information as a new service is established is outside the scope of this document. If confidential information such as credit card numbers are provided as part of account setup, then this may be a target for phishing. However there is one critical aspect in which enrollment impacts the Hartman Expires December 27, 2006 [Page 11] Internet-Draft Web Phishing Requirements June 2006 security of authentication. During enrollment, a password is typically established for an account at an identity provider. The process of establishing a password MUST NOT provide a strong password equivalent to the identity provider. That is, the identity provider MUST NOT gain enough information to impersonate the user to a third party while establishing a password. Hartman Expires December 27, 2006 [Page 12] Internet-Draft Web Phishing Requirements June 2006 5. Is it the right Server? In Section 4, requirements were presented for web authentication solutions to minimize the risk of phishing targeted at web access information. This section discusses in a non-normative manner various mechanisms for determining that the right server has been contacted. Authenticating to the right party is an important part of reducing the risk of phishing targeted at other confidential information. Validation of the certificates used in TLS and verification that the name in the URI maps to these certificates can be useful. As discussed in Section 3, attackers can spoof the name in the URI. However the TLS checks do defeat some attacks. Also, as discussed in Section 4.5, TLS validation may be important to higher-level checks. A variety of initiatives propose to assign trust to servers. This includes proposals to allow users to indicate certain servers are trusted based on information they enter. Also, proposals to allow third parties including parties established for this purpose and existing certificate authorities to indicate trust have been made. These proposals will almost certainly make phishing more difficult. In the case where there is an existing relationship, these requirements provide a way that information about the relationship can be used to provide assurance that the right party has been contacted. In Section 4.2, we discuss how a secret between the user and their local computer can be used to let the user know when a password will be handled securely. A similar mechanism can be used to help the user once they are authenticated to the website. The website can present information based on a secret shared between the user and website to convince the user that they have authenticated to the correct site. This depends critically on the requirements of Section 4.5 to guarantee that the phisher cannot obtain the secret. It is tempting to use this form of trusted UI before authentication. For example, a website could request a user name and then display information based on a secret for that user before accepting a password. The problem with this approach is that phishers can obtain this information, because it can be obtained without knowing the password. However if the secret is displayed after authentication then phishers could not obtain the secret. This is one of the many reasons why it is important to prevent phishing targeted at authentication credentials. Hartman Expires December 27, 2006 [Page 13] Internet-Draft Web Phishing Requirements June 2006 6. Security Considerations This memo discusses the security of web authentication and how to minimize the risk of phishing in web authentication systems. This section discusses the security of the overall system and discusses how components of the system that are not directly within the scope of this document affect the security of web transactions. This section also discusses residual risks that remain even when the requirements proposed here are implemented. The approach taken here is to separate the problem of phishing into phishing targeted at web authentication credentials and phishing targeted at other information. Users are given some trusted mechanism to determine whether they are typing their password into a secure browser component that will authenticate them to the web server or whether they are typing their password into a legacy mechanism that will send their password to the server. If the user types a password into the trusted browser component, they have strong assurances that their password has not been disclosed and that the page returned from the web server was generated by a party that either knows their password or who is authenticated by an identity provider who knows their password. The web server can then use confidential information known to the user and web server to enhance the user's trust in its identity beyond what is available given the social engineering attacks against TLS server authentication. If a user enters their password into the wrong server but discovers this before they give that server any other confidential information, then there exposure is very limited. This model assumes that the browser and operating system are a trusted component. As discussed in Section 3, there are numerous attacks against host security. Appropriate steps should be taken to minimize these risks. If the host security is compromised, the password can be captured as it is typed by the user. This model assumes that users will only enter their passwords into trusted browser components. There are several potential problems with this assumption. First, users need to understand the UI distinction and know what it looks like when they are typing into a trusted component and what a legacy HTML form looks like. Users must care enough about the security of their passwords to only type them into trusted components. The browser must be designed in such a way that the server cannot create a UI component that appears to be a trusted component but is actually a legacy HTML form; Section 4.2 discusses this requirement. IN addition, a significant risk that users will type their password into legacy HTML forms comes from the incremental deployment of any Hartman Expires December 27, 2006 [Page 14] Internet-Draft Web Phishing Requirements June 2006 web authentication technology. Websites will need a way to work with older web browsers that do not yet support mechanisms that meet these requirements. Not all websites will immediately adopt these mechanisms. Users will sometimes browse from computers that have mechanisms meeting these requirements and sometimes from older browsers. They only gain protection from phishing when they type passwords into trusted components. If a password is sometimes used with websites that meet these requirements and sometimes with legacy websites, and if the password is captured by a phisher targeting a legacy website, then that captured password can be used even on websites meeting these requirements. Similarly, if a user is tricked into using HTML forms when they should not, passwords can be exposed. Users can significantly reduce this risk by using different passwords for websites that use trusted browser authentication than for those that still use HTML forms. The risk of dictionary attack is always a significant concern for password systems. Users can (but typically do not) minimize this risk by choosing long, hard to guess phrases for passwords. The risk can be removed once a password is already established by using a zero-knowledge password protocol. However the risk of dictionary attack is always present when setting up a new password or changing a password. Minimizing the number of services that use the same password can minimize this risk. When zero-knowledge password protocols are used, being extra careful to make sure the right server is used when establishing a password can significantly reduce this risk. Hartman Expires December 27, 2006 [Page 15] Internet-Draft Web Phishing Requirements June 2006 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [ANTIPHISHING] Nelson, J. and D. Jeske, "Limits to Anti Phishing", January 2006. Proceedings of the W3c Security and Usability Workshop; ht tp://www.w3.org/2005/Security/usability-ws/papers/ 37-google/' [BTNS] Touch, J., "Problem and Applicability Statement for Better Than Nothing Security", draft-ietf-btns-prob-and-applic-02.txt (work in progress), February 2006. [IABAUTH] Rescorla, E., "A Survey of Authentication Mechanisms", draft-iab-auth-mech-05.txt (work in progress), February 2006. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Hartman Expires December 27, 2006 [Page 16] Internet-Draft Web Phishing Requirements June 2006 Author's Address Sam Hartman Massachusetts Institute of Technology Email: hartmans-ietf@mit.edu Hartman Expires December 27, 2006 [Page 17] Internet-Draft Web Phishing Requirements June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hartman Expires December 27, 2006 [Page 18] --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --=-=-=-- From dix-bounces@ietf.org Wed Jun 28 13:36:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdyA-00059x-AM; Wed, 28 Jun 2006 13:36:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbzk-00064F-ED for dix@ietf.org; Wed, 28 Jun 2006 11:30:24 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbzi-0003bJ-4F for dix@ietf.org; Wed, 28 Jun 2006 11:30:24 -0400 Received: by nf-out-0910.google.com with SMTP id d4so1162229nfe 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-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Wed, 28 Jun 2006 13:36:53 -0400 Cc: dix@ietf.org, ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 13:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fve2G-0008HZ-7e; Wed, 28 Jun 2006 13:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fve2E-0008Gu-7F for dix@ietf.org; Wed, 28 Jun 2006 13:41:06 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fve2D-0000CD-1K for dix@ietf.org; Wed, 28 Jun 2006 13:41:06 -0400 Received: from [127.0.0.1] (stdhcp-187.va.neustar.com [10.31.13.187]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5SHf01v021567; Wed, 28 Jun 2006 17:41:04 GMT Message-ID: <44A2BF23.5060602@neustar.biz> Date: Wed, 28 Jun 2006 10:40:51 -0700 From: Jeff Hodges User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Digital Identity Exchange , Pete Resnick Subject: Re: [dix] Ietf 66 meeting - WAE agenda slot References: <4492A667.7090909@kent.ac.uk> <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> <2BF2EACE-CB1B-4630-9080-828B453BCCA4@osafoundation.org> In-Reply-To: <2BF2EACE-CB1B-4630-9080-828B453BCCA4@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org Lisa Dusseault wrote on Thu 22-Jun: > It [WAE agenda slot] is there now but the schedule is NOT final. ok, is the schedule final now? i.e. is WAE BOF nailed-down for Fri morn 14-Jul? thanks, JeffH _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 14:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvekT-0000CQ-6J; Wed, 28 Jun 2006 14:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvekS-0000CL-Ju for dix@ietf.org; Wed, 28 Jun 2006 14:26:48 -0400 Received: from 216-43-25-66.ip.mcleodusa.net ([216.43.25.66] helo=episteme-software.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvekP-0004CU-Bx for dix@ietf.org; Wed, 28 Jun 2006 14:26:48 -0400 Received: from [12.105.228.215] (127.0.0.1) by episteme-software.com with ESMTP (EIMS X 3.3d22); Wed, 28 Jun 2006 13:26:40 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <44A2BF23.5060602@neustar.biz> References: <4492A667.7090909@kent.ac.uk> <4A9AF5D2-A49B-4653-AF65-01AF3C6D9059@osafoundation.org> <2BF2EACE-CB1B-4630-9080-828B453BCCA4@osafoundation.org> <44A2BF23.5060602@neustar.biz> X-Mailer: Eudora [Macintosh version 7.0a12] Date: Wed, 28 Jun 2006 11:26:36 -0700 To: Jeff Hodges From: Pete Resnick Subject: Re: [dix] Ietf 66 meeting - WAE agenda slot Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Digital Identity Exchange X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On 6/28/06 at 10:40 AM -0700, Jeff Hodges wrote: >ok, is the schedule final now? > >i.e. is WAE BOF nailed-down for Fri morn 14-Jul? As nailed as these things get. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 19:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjaR-0001pS-Tf; Wed, 28 Jun 2006 19:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvjaQ-0001kd-5q for dix@ietf.org; Wed, 28 Jun 2006 19:36:46 -0400 Received: from nvg1-01.yvr.sxip.com ([209.17.181.250] helo=mail2.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvjaO-0006NE-Go for dix@ietf.org; Wed, 28 Jun 2006 19:36:46 -0400 Received: from mail1.sxip.com (marlin.sxip.com [199.60.48.20]) by mail2.sxip.com (8.13.4/8.13.4) with ESMTP id k5SMxgSc077051 for ; Wed, 28 Jun 2006 15:59:42 -0700 (PDT) (envelope-from merrells@sxip.com) 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 Subject: Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) Date: Wed, 28 Jun 2006 15:59:38 -0700 To: Digital Identity Exchange X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 20:55:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkoN-0000v6-M8; Wed, 28 Jun 2006 20:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvkoN-0000v1-2v for dix@ietf.org; Wed, 28 Jun 2006 20:55:15 -0400 Received: from its-mu-mail3.its.rmit.edu.au ([131.170.1.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvkoL-0000YG-Bm for dix@ietf.org; Wed, 28 Jun 2006 20:55:15 -0400 Received: from its-gw-inet57.its.rmit.edu.au (its-gw-inet57.its.rmit.edu.au [131.170.10.77]) by its-mu-mail3.its.rmit.edu.au (8.13.7/8.13.7/mail3) with ESMTP id k5T0stcS009372 for ; Thu, 29 Jun 2006 10:54:56 +1000 (EST) Received: from INET57-MTA by its-gw-inet57.its.rmit.edu.au with Novell_GroupWise; Thu, 29 Jun 2006 10:54:55 +1000 Message-Id: <44A3B174.29CB.0017.3@ems.rmit.edu.au> X-Mailer: Novell GroupWise Internet Agent 7.0 Date: Thu, 29 Jun 2006 10:54:44 +1000 From: "Gavin Baumanis" To: Subject: Re: [Ietf-http-auth] Re: [dix] BOF plans (Was: Notes on Web authentication enhancements) References: <20060619220742.40B85222427@laser.networkresonance.com>à In-Reply-To: <20060619220742.40B85222427@laser.networkresonance.com>à Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 2.1 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422918877==" Errors-To: dix-bounces@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0422918877== Content-Type: multipart/alternative; boundary="=__Part6F4A85C4.0__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6F4A85C4.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I might be completely off the mark, But surely the authentication mechanism could be completely different from the end application? ie. a http(s) module / library could be used for authentication and then parse relevant information / tokens to an IMAP application? >>> 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. --=__Part6F4A85C4.0__= Content-Type: text/html; charset=US-ASCII Content-Description: HTML Content-Transfer-Encoding: 7bit
I might be completely off the mark,
But surely the authentication mechanism could be completely different from the end application?
 
ie. a http(s) module / library could be used for authentication and then parse relevant information / tokens to an IMAP application?
 

>>>
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.

 
--=__Part6F4A85C4.0__=-- --===============0422918877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix --===============0422918877==-- From dix-bounces@ietf.org Wed Jun 28 23:40:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvnNm-0004j5-3t; Wed, 28 Jun 2006 23:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvnNl-0004iw-8H for dix@ietf.org; Wed, 28 Jun 2006 23:39:57 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvnNj-0006ZL-Q4 for dix@ietf.org; Wed, 28 Jun 2006 23:39:57 -0400 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 Subject: Re: [dix] Notes on Web authentication enhancements 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-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Wed Jun 28 23:48:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvnWS-0005i4-6R; Wed, 28 Jun 2006 23:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvnWQ-0005hy-Sr for dix@ietf.org; Wed, 28 Jun 2006 23:48:54 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvnWP-0007sv-JO for dix@ietf.org; Wed, 28 Jun 2006 23:48:54 -0400 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 Subject: Re: [dix] BOF plans 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-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 00:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvoVD-0001Ou-BH; Thu, 29 Jun 2006 00:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvoVB-0001Jl-TZ for dix@ietf.org; Thu, 29 Jun 2006 00:51:41 -0400 Received: from narn.hozed.org ([209.234.73.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvoVA-0005yT-KM for dix@ietf.org; Thu, 29 Jun 2006 00:51:41 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by narn.hozed.org with local; Wed, 28 Jun 2006 23:51:39 -0500 id 00008696.44A35C5B.00003518 Date: Wed, 28 Jun 2006 23:51:39 -0500 From: Troy Benjegerdes To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity Message-ID: <20060629045139.GK5847@narn.hozed.org> References: <20060619193045.GP5688@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <20060619193045.GP5688@binky.Central.Sun.COM> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org On Mon, Jun 19, 2006 at 02:30:45PM -0500, Nicolas Williams wrote: > On Mon, Jun 19, 2006 at 01:31:21PM -0400, Sam Hartman wrote: > > 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. [...] > > Gosh, that sounds like a ticketing service... Like Kerberos, actually. > > Or we could make a ticketing service out of PKIX technologies. Or out > of SAML/XMLdsig/XMLenc. Or something totally new! > > Or we could try to re-use specs. > > :) > > Yes, I see why you suggest Kerberos. > > One argument I've seen against Kerberos is that it requires online > infrastructure, but I think it's now clear that all the good choices in > this space do (e.g., PKIX CRL and OCSP servers, online CAs, SACRED > servers, etc.). However, not all good choices in this space have such tight time sychronization constraints as kerberos does. I think any proposal for digital identity based on kerberos needs to also propose some mechanism for relaxing the synchronized clock constraints that all the existing kerberos implementations I am aware of impose. I would really like to be able to use kerberos as a mechanism for authenticating to a wireless mesh network. But in practice, some percentage of the time there will be some node that has a fast or slow running clock, or just got rebooted and has a clock set to 2004. If you can solve authentication with a device with a fast or slow running clock, then maybe we could make this same infrastructure useable for some future deep space network in which relativistic effects on clocks and time start making a difference. I suppose the real question I am asking is can kerberos be securely extended to use relative timestamps instead of absolute timestamps, or does this somehow fundamentally break the security model? _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 01:21:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvoxh-0007iG-0f; Thu, 29 Jun 2006 01:21:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvoxf-0007iA-DG for dix@ietf.org; Thu, 29 Jun 2006 01:21:07 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvoxc-000832-3z for dix@ietf.org; Thu, 29 Jun 2006 01:21:07 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2006 22:21:03 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5T5L3eb012961 for ; Wed, 28 Jun 2006 22:21:03 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5T5L3CU012848 for ; Wed, 28 Jun 2006 22:21:03 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp4172.cisco.com [10.61.80.75]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5T5FtRA028808 for ; Wed, 28 Jun 2006 22:15:56 -0700 Message-ID: <44A3633C.80300@cisco.com> Date: Thu, 29 Jun 2006 07:21:00 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Updated phishing requirements draft References: In-Reply-To: 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=877; t=1151558463; x=1152422463; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[dix]=20Updated=20phishing=20requirements=20draft; X=v=3Dcisco.com=3B=20h=3DbHfn+Wi9qKEgmFr54rdZGVUfPM0=3D; b=nF7U9dy1BSHDSzrtLwOvU/Ygx1EXLcJd/0oDBavGBhOZbemhWjwmGtfYaHiDc6oVNCL+KzzH b1oaMmNQoh1KvKXZbfDw6s8Y2yrnLAjtm6STn1NGnI0ka84usGXxXcHG; X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Sam, I understand your objection to the solution depending on smart cards, but I think it still MUST support some form of external authentication component - not just X.509 based smart cards. For one, a substantial threat is the computer itself. If it is compromised one way to prevent access to services is by requiring such an external authentication. These cards also provide a trusted UI and should be listed as a possibility in your next section. Furthermore, in section 4.5, (1) simply having X.509 server certificates is not sufficient defense due to iDNS (homoglyphic?) attacks and the like. I think there is no perfect way to accomplish 4.5. Section 4.6 assumes that there is a third party identity provider. This needn't be the case, but if it is, it is sufficient to have a name, a nonce, and a public/private key pair, is it not? Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 02:00:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpZu-0004LP-08; Thu, 29 Jun 2006 02:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpZt-0004LG-9s for dix@ietf.org; Thu, 29 Jun 2006 02:00:37 -0400 Received: from marlin.sxip.com ([199.60.48.20] helo=mail1.sxip.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvpZr-00025X-Vj for dix@ietf.org; Thu, 29 Jun 2006 02:00:37 -0400 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-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on marlin.sxip.com X-Scanned-By: MIMEDefang 2.54 on 199.60.48.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [dix] Google Account Authorization - slightly off topic 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 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 _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 08:43:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvsA-0008Qb-Ux; Thu, 29 Jun 2006 08:43:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvvs9-0008QT-Pz for dix@ietf.org; Thu, 29 Jun 2006 08:43:53 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvvs8-0000t6-H9 for dix@ietf.org; Thu, 29 Jun 2006 08:43:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 843EEE0079; Thu, 29 Jun 2006 08:43:55 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [dix] Updated phishing requirements draft References: <44A3633C.80300@cisco.com> Date: Thu, 29 Jun 2006 08:43:55 -0400 In-Reply-To: <44A3633C.80300@cisco.com> (Eliot Lear's message of "Thu, 29 Jun 2006 07:21:00 +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-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, Eliot> I understand your objection to the solution depending on smart cards, Eliot> but I think it still MUST support some form of external authentication Eliot> component - not just X.509 based smart cards. For one, a substantial Eliot> threat is the computer itself. If it is compromised one way to prevent Eliot> access to services is by requiring such an external authentication. Eliot> These cards also provide a trusted UI and should be listed as a Eliot> possibility in your next section. Many X.509 smart cards have no UI at all. I agree smart cards need to be supported. The goal of 4.1 is to say that we must support passwords and that solutions that only work with smart cards are not sufficient. Eliot> Furthermore, in section 4.5, (1) simply having X.509 server certificates Eliot> is not sufficient defense due to iDNS (homoglyphic?) attacks and the Eliot> like. I think there is no perfect way to accomplish 4.5. Server certs are not sufficient for humans to verify for the reasons you site. However if a name is included in another protocol message then the binding between that name and the server cert can be secured. I think it is quite possible to accomplish 4.5 in the case where you have an existing relationship with a site based on shared secrets. Eliot> Section 4.6 assumes that there is a third party identity provider. This Eliot> needn't be the case, but if it is, it is sufficient to have a name, a Eliot> nonce, and a public/private key pair, is it not? Please restarte; I don't understand what you are getting at. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 08:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvvC-0001D9-JF; Thu, 29 Jun 2006 08:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvvvA-0001B4-TQ for dix@ietf.org; Thu, 29 Jun 2006 08:47:00 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvvv9-0001CF-MU for dix@ietf.org; Thu, 29 Jun 2006 08:47:00 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AAD5CE0079; Thu, 29 Jun 2006 08:46:59 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [dix] An HTTP-based solution for digital identity References: <20060619193045.GP5688@binky.Central.Sun.COM> <20060629045139.GK5847@narn.hozed.org> Date: Thu, 29 Jun 2006 08:46:59 -0400 In-Reply-To: <20060629045139.GK5847@narn.hozed.org> (Troy Benjegerdes's message of "Wed, 28 Jun 2006 23:51:39 -0500") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 >>>>> "Troy" == Troy Benjegerdes writes: Troy> However, not all good choices in this space have such tight time Troy> sychronization constraints as kerberos does. I think any proposal for Troy> digital identity based on kerberos needs to also propose some mechanism Troy> for relaxing the synchronized clock constraints that all the existing Troy> kerberos implementations I am aware of impose. Modern Kerberos does not have that constraint between the client and the KDC. (Or between the client and server). It does have that constraint between the KDC and server--which is kind of ironic given there are no message flows directly between the KDC and server. Yes, I should add that to the work necessary to use Kerberos in this situation. I think relaxing the time constraint is doable. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 08:54:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvw2H-0005xP-OK; Thu, 29 Jun 2006 08:54:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvw2G-0005xK-DW for dix@ietf.org; Thu, 29 Jun 2006 08:54:20 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvw2F-0002cP-4V for dix@ietf.org; Thu, 29 Jun 2006 08:54:20 -0400 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-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 09:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwJX-0002WB-UC; Thu, 29 Jun 2006 09:12:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwJW-0002W1-Jt for dix@ietf.org; Thu, 29 Jun 2006 09:12:10 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwJV-00041K-AS for dix@ietf.org; Thu, 29 Jun 2006 09:12:10 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2006 06:12:08 -0700 X-IronPort-AV: i="4.06,192,1149490800"; d="scan'208"; a="431837677:sNHT30922882" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5TDC83H015823 for ; Thu, 29 Jun 2006 06:12:08 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5TDC89s003238 for ; Thu, 29 Jun 2006 06:12:08 -0700 (PDT) Received: from [212.254.247.3] (ams3-vpn-dhcp4172.cisco.com [10.61.80.75]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5TD6xFk007151 for ; Thu, 29 Jun 2006 06:07:00 -0700 Message-ID: <44A3D1A5.7050906@cisco.com> Date: Thu, 29 Jun 2006 15:12:05 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Digital Identity Exchange Subject: Re: [dix] Updated phishing requirements draft References: <44A3633C.80300@cisco.com> In-Reply-To: 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=2061; t=1151586728; x=1152450728; 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]=20Updated=20phishing=20requirements=20draft; X=v=3Dcisco.com=3B=20h=3DbHfn+Wi9qKEgmFr54rdZGVUfPM0=3D; b=Roxq/Ul4bpHifIc4sB28gURInLAE0+OOuSSkHNptFGau8YrVqd2UlSMEptiMA7+dzvd/H9So 7kdGd1WWVoZSsDMBZfXHL59q2hFe4lFS01kR3GCm9mvSgnzjSK5fs9Rq; X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Sam Hartman wrote: > Many X.509 smart cards have no UI at all. I agree smart cards need to > be supported. The goal of 4.1 is to say that we must support > passwords and that solutions that only work with smart cards are not > sufficient. > Once again I think we agree, but in as much as you're using MUSTs for one and "desirable" for another I wasn't sure. I sure as heck don't like the idea of a smart card without a UI, and an anti-phishing defense is useless unless there is mutual authentication, as you clearly point out. > Eliot> Furthermore, in section 4.5, (1) simply having X.509 server certificates > Eliot> is not sufficient defense due to iDNS (homoglyphic?) attacks and the > Eliot> like. I think there is no perfect way to accomplish 4.5. > > Server certs are not sufficient for humans to verify for the reasons you site. > However if a name is included in another protocol message then the binding between that name and the server cert can be secured. > Perhaps I'm not well enough versed to understand why this would be the case, unless the other end can prove itself in some meaningful way in the next phase that the user would actually understand. And even then I'm not sure that solves MITM. > I think it is quite possible to accomplish 4.5 in the case where you > have an existing relationship with a site based on shared secrets. > > Eliot> Section 4.6 assumes that there is a third party identity provider. This > Eliot> needn't be the case, but if it is, it is sufficient to have a name, a > Eliot> nonce, and a public/private key pair, is it not? > Consider your classic case of a Secure Computing 3DES encryption with serial along with a secure "name" that has associated with it a pkp that was generated during enrollment/registration. There is no 3rd party, with the possible exception of enrollment time and other OAMP operations. The drawback is that the "name" in question needs to be known by both ends. Classically this is the username. Eliot _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 09:54:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwyK-0005tu-LL; Thu, 29 Jun 2006 09:54:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvwyJ-0005tp-Hs for dix@ietf.org; Thu, 29 Jun 2006 09:54:19 -0400 Received: from colibri.verisign.com ([65.205.251.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvwyI-0000WZ-7L for dix@ietf.org; Thu, 29 Jun 2006 09:54:19 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id 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-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org > [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. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix From dix-bounces@ietf.org Thu Jun 29 13:33:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw0Oh-0002UZ-SR; Thu, 29 Jun 2006 13:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw0Og-0002UU-7a for dix@ietf.org; Thu, 29 Jun 2006 13:33:46 -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 1Fw0Of-00038v-1R for dix@ietf.org; Thu, 29 Jun 2006 13:33:46 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 55AC2E0079; Thu, 29 Jun 2006 13:33:49 -0400 (EDT) From: Sam Hartman To: Digital Identity Exchange Subject: Re: [dix] Updated phishing requirements draft References: <44A3633C.80300@cisco.com> <44A3D1A5.7050906@cisco.com> Date: Thu, 29 Jun 2006 13:33:49 -0400 In-Reply-To: <44A3D1A5.7050906@cisco.com> (Eliot Lear's message of "Thu, 29 Jun 2006 15:12:05 +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-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: dix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Digital Identity Exchange List-Id: Digital Identity Exchange List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dix-bounces@ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Perhaps I'm not well enough versed to understand why this would be the Eliot> case, unless the other end can prove itself in some meaningful way in Eliot> the next phase that the user would actually understand. And even then Eliot> I'm not sure that solves MITM. It can be made to solve MITM. My argument is that there are a number of cases where the other end can prove its identity in a sufficiently meaningful way at a higher level. If it knows the same secret as I do, then it's one of the people who knows that secret. If only two people know the secret and I'm one of them, well I probably know who it is. If the other end then tells me the name of its cert, I check that name and confirm I trust the CA, then I have met the requirements of 4.5. >> I think it is quite possible to accomplish 4.5 in the case >> where you have an existing relationship with a site based on >> shared secrets. >> Eliot> Section 4.6 assumes that there is a third party identity provider. This Eliot> needn't be the case, but if it is, it is sufficient to have a name, a Eliot> nonce, and a public/private key pair, is it not? >> All this is true. I don't see how it has anything to do with 4.6. _______________________________________________ dix mailing list dix@ietf.org https://www1.ietf.org/mailman/listinfo/dix