Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 46B5C8058A for ; Tue, 18 Dec 2007 12:14:24 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D28F3142254 for ; Tue, 18 Dec 2007 12:14:25 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-50 required=4 tests=[AWL=1.300, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZVQzecrMlKU for ; Tue, 18 Dec 2007 12:14:19 -0800 (PST) Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7EED914227E for ; Tue, 18 Dec 2007 12:14:19 -0800 (PST) Received: from [156.154.5.164] (unknown [156.154.5.164]) by ns3.neustar.com (Postfix) with ESMTP id 52018175BD; Tue, 18 Dec 2007 20:14:16 +0000 (GMT) Message-ID: <47682A17.1040609@neustar.biz> Date: Tue, 18 Dec 2007 12:14:15 -0800 From: =JeffH User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: IETF Security Area Advisory Group , IETF HTTP Auth Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ietf-http-auth] [security-services] fyi: Technical Comparison: OpenID and SAML (Draft 05) X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2007 20:14:24 -0000 Of possible interest... blogpost: (Draft) Technical Comparison: OpenID and SAML document: Technical Comparison: OpenID and SAML - Draft 05 http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html Abstract This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, and presented from the perspectives of end-users, implementors, tna deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g. which is "better"; rather, it attempts to present an objective technical comparison. =JeffH Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9EE3480C86 for ; Thu, 6 Dec 2007 00:33:09 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AFF5C1422F0 for ; Thu, 6 Dec 2007 00:33:10 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-50 required=4 tests=[AWL=0.867, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvO3JO+dh-5k for ; Thu, 6 Dec 2007 00:33:04 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by laweleka.osafoundation.org (Postfix) with ESMTP id BE048142207 for ; Thu, 6 Dec 2007 00:33:04 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB68X3cx021381 for ; Thu, 6 Dec 2007 08:33:03 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lB68X2p7062997 for ; Thu, 6 Dec 2007 01:33:03 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB68X22c008668; Thu, 6 Dec 2007 02:33:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB68X1UM008667; Thu, 6 Dec 2007 02:33:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 6 Dec 2007 02:33:01 -0600 From: Nicolas Williams To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Message-ID: <20071206083301.GC8628@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> <20071205235420.GA8344@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ietf-http-auth@osafoundation.org, Sam Hartman X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 08:33:09 -0000 On Wed, Dec 05, 2007 at 04:07:33PM -0800, Roy T. Fielding wrote: > It would be a lot more useful to have a paper or small set > of references that explains why all these assertions are > believed to be true. If you have such a thing, please post it. Let me give some context that might help: - First, my presentation was very strongly influenced by draft-hartman-webauth-phishing-06.txt. - Second, my primary message to the Liberty folks was this: SAML, CardSpace, OpenID, etcetera, all such web authentication frameworks will fail to prevent phishing if the don't ensure that the server that the browser is connected to is not an MITM, because if phishers cannot steal authentication credentials but can still get in the middle, then they can still steal from users (e.g., by surreptitiously making bank transfers). Phishers will mount MITM attacks if that's all they can do. - Third, my secondary message, was about UIs and federations. This I did not deliver quite so succinctly, but that's fine given that the target audience focus on the protocol aspects of web authentication. I also had very limited time to present. This secondary message is based on an insight I got from Sam: that in the face of confusables and so on, the only thing that untrained users can rely on is their expectations of what they should find at some website. E.g., at your bank's site you expect a login page, and once logged in you expect to see specific account balances. Now, such expectations alone cannot defeat phishers who are mounting an MITM attack, and anyways, once the user gives their credentials to the phisher the game is lost anyways. The next step is to reinforce the process by adding authentication and MITM detection to try to address that problem, but we still need to provide something that can meet expectations and in a way that the phisher gets nothing useful. The next insight is that if we have lots of smallish federations around, then the thing that the user can expect at any one site, such as their bank, is that the browser will have authenticated them as a specific identity. Users already expect to see the authenticated name of the server in their browser status bar + lock icon, but this alone is not enough as there may be confusables and CAs/registrars cannot help as much as we'd like. But small federations, by virtue of being small, can much more easily prevent sites with confusable names from participating than CAs/registrars can. The UI element I have in mind is a status-bar-like element that shows the federation used to do authentication (and possibly also the user's identity in that federation). - To summarize: federation + a UI element showing the user's identity as authenticated to the server + mutual user<->server authentication + MITM prevention/detection = a decent solution to phishing. The (federation + UI element showing... + mutual auth) part deals with non-MITM phishers. The MITM prevention/detection part rounds out the picture. - There are several ways to detect/prevent MITMs in these apps (which, today, pretty much all use TLS). Three of these are: - push authentication down into TLS - get rid of TLS and push cryptographic session protection up to the application layer - use channel binding of authentication at the application layer to the TLS channels making up the session Of these I believe the channel binding solution is the best. But given the efforts to add GSS-API support to TLS I think we cannot discount the first item either. Finally, in the OASIS WSS TC / SOAP world I wouldn't discount the push-session-crypto-up approach. - Note that the federation enrolment case can still be susceptible to phishing. I.e., this scheme, if it works, pushes the opportunity for phishing to an area that's much less frequent that normal user web browsing activity. Nico -- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3B9D680C04 for ; Wed, 5 Dec 2007 16:17:39 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 44BFF14233F for ; Wed, 5 Dec 2007 16:17:40 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-50 required=4 tests=[AWL=0.872, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktm8Of5jH1ez for ; Wed, 5 Dec 2007 16:15:46 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by laweleka.osafoundation.org (Postfix) with ESMTP id D9F2E142215 for ; Wed, 5 Dec 2007 16:15:45 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB60FhYt008265 for ; Thu, 6 Dec 2007 00:15:44 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lB60FhbJ001834 for ; Wed, 5 Dec 2007 17:15:43 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB60Fgx2008448; Wed, 5 Dec 2007 18:15:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB60FgUt008447; Wed, 5 Dec 2007 18:15:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 5 Dec 2007 18:15:42 -0600 From: Nicolas Williams To: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Message-ID: <20071206001541.GD8343@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> <20071205235420.GA8344@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ietf-http-auth@osafoundation.org, Sam Hartman X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 00:17:39 -0000 On Wed, Dec 05, 2007 at 04:07:33PM -0800, Roy T. Fielding wrote: > It would be a lot more useful to have a paper or small set > of references that explains why all these assertions are > believed to be true. If you have such a thing, please post it. It would also be useful to have the time to write such a thing. Perhaps Sam can step in for me and explain at length. I don't know if there's a recording of my presentation. I'll inquire. Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 99E7280C3D for ; Wed, 5 Dec 2007 16:09:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A63C6142313 for ; Wed, 5 Dec 2007 16:09:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IzIzaBeyJqa for ; Wed, 5 Dec 2007 16:08:58 -0800 (PST) Received: from spaceymail-a1.g.dreamhost.com (lax-green-bigip-5.dreamhost.com [208.113.200.5]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5B710142215 for ; Wed, 5 Dec 2007 16:08:58 -0800 (PST) Received: from [130.129.19.89] (dhcp-1359.ietf70.org [130.129.19.89]) by spaceymail-a1.g.dreamhost.com (Postfix) with ESMTP id A4A06818AE; Wed, 5 Dec 2007 16:07:29 -0800 (PST) In-Reply-To: <20071205235420.GA8344@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> <20071205235420.GA8344@Sun.COM> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Roy T. Fielding" Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Date: Wed, 5 Dec 2007 16:07:33 -0800 To: Nicolas Williams X-Mailer: Apple Mail (2.752.2) Cc: ietf-http-auth@osafoundation.org, Sam Hartman X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2007 00:09:03 -0000 It would be a lot more useful to have a paper or small set of references that explains why all these assertions are believed to be true. If you have such a thing, please post it. ....Roy Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9294B80C3B for ; Wed, 5 Dec 2007 15:54:32 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9E234142313 for ; Wed, 5 Dec 2007 15:54:33 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-50 required=4 tests=[AWL=0.877, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-BhIFTk38pF for ; Wed, 5 Dec 2007 15:54:27 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by laweleka.osafoundation.org (Postfix) with ESMTP id C3C7B142215 for ; Wed, 5 Dec 2007 15:54:27 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB5NsQaN018288 for ; Wed, 5 Dec 2007 23:54:26 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lB5NsPJ9055670 for ; Wed, 5 Dec 2007 16:54:26 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB5NsLCR008423; Wed, 5 Dec 2007 17:54:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB5NsLAV008422; Wed, 5 Dec 2007 17:54:21 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 5 Dec 2007 17:54:21 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Message-ID: <20071205235420.GA8344@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129003519.GF2540@Sun.COM> User-Agent: Mutt/1.5.7i Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 23:54:32 -0000 [re-send] On Wed, Nov 28, 2007 at 07:22:41PM -0500, Sam Hartman wrote: > >>>>> "Eliot" == Eliot Lear writes: > > Eliot> Roy T. Fielding wrote: > >> Perhaps. I don't believe that CAs are careful enough in > >> issuing certificates, and it is certainly the case that not all > >> TLS sites bother to pay the tax for CA-signed certs. This > >> algorithm should not be dependent on them. Perhaps what I am > >> looking for is a mechanism that doesn't require Mutual Auth > >> (aside from proving knowledge of a shared secret), but can > >> still detect MITM. > > Eliot> Fundamentally phishing is possible because of an absence of > Eliot> mutual authentication. I guess I don't understand what > Eliot> problem you are attempting to solve. > > He's attempting to take advantage of membership in a federation to > avoid dependence on CAs. I.E. section 4.6 of my draft. > > My text in this regard needs to be improved significantly. Nico > Williams managed to state it much more clearly in a presentation he > gave to Liberty and I need to incorporate his restatements. My presentation to the Liberty Staff is here: http://mediacast.sun.com/share/nico/liberty-staff-tls-channel-binding-short.pdf See also my blog: http://blogs.sun.com/nico The short version is this: - we need to mutually authenticate users and servers - there must be a link between the authentication of users to servers and servers to users - this link must be such that users can determine whether to trust the server according to what "federation" was used to authenticate the user to the server - "federation" matters because federations are (must) be smaller than the capital-I Internet and, therefore, are able to effectively white-/black-list member sites. I.e., a "Bank of Foo" federation should only allow my identity in that federation to be used to authenticate to sites that the "Bank of Foo" federation administrators trust. The "Bank of Foo" federation can check for confusables, etc... in applicant members because they have few members compared to the number of domains that exist in each TLD (say). A "Bloggers Union of Foobar" federation might have many, many more members, and thus be less able to keep out phishers, but users would know not to trust, with important non-blogging data, sites to which they authenticate with "Bloggers Union of Foobar" identities. - That last point brings up something important: UIs matter. The UI in this proposal *must* make it clear to the user not just the name of the site (think: status bar) but the identity/federation used to authenticate the user. - The binding/mutuality of user<->server authentication is necessary to prevent MITM attacks. Nico -- Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5319D80C3B for ; Wed, 5 Dec 2007 15:06:06 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 5ED59142279 for ; Wed, 5 Dec 2007 15:06:07 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-50 required=4 tests=[AWL=0.882, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuZ-leMVoepv for ; Wed, 5 Dec 2007 15:06:02 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by laweleka.osafoundation.org (Postfix) with ESMTP id DA208142209 for ; Wed, 5 Dec 2007 15:06:01 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lB5N60EO014460 for ; Wed, 5 Dec 2007 23:06:00 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lB5N5xRd016406 for ; Wed, 5 Dec 2007 16:05:59 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lB5N5xh2008349; Wed, 5 Dec 2007 17:05:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lB5N5w61008348; Wed, 5 Dec 2007 17:05:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 5 Dec 2007 17:05:58 -0600 From: Nicolas Williams To: Sam Hartman Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt Message-ID: <20071205230558.GA8343@Sun.COM> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053732.075BC33C21@delta.rtfm.com> <191786E3-2734-481F-BF75-45F06A4CB8F0@gbiv.com> <474BDEED.9050809@cisco.com> <20071129003519.GF2540@Sun.COM> <20071129003738.GA2589@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129003738.GA2589@Sun.COM> User-Agent: Mutt/1.5.7i Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 23:06:06 -0000 On Wed, Nov 28, 2007 at 06:37:38PM -0600, Nicolas Williams wrote: > [re-send without my slides attached, so it makes it to the list faster.] http://mediacast.sun.com/share/nico/liberty-staff-tls-channel-binding-short.pdf Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 37D8980BFF for ; Wed, 5 Dec 2007 10:15:57 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E35501421FF for ; Wed, 5 Dec 2007 10:15:57 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-50 required=4 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVxx8y-VJ0na for ; Wed, 5 Dec 2007 10:15:49 -0800 (PST) Received: from [130.129.84.230] (unknown [130.129.84.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F0D6142223 for ; Wed, 5 Dec 2007 10:14:47 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) To: HTTP authentication list Message-Id: <02589436-91D0-4CDE-8E68-12E4E446E391@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-9--472047647 From: Lisa Dusseault Date: Wed, 5 Dec 2007 10:14:44 -0800 X-Mailer: Apple Mail (2.752.3) X-Mailman-Approved-At: Wed, 05 Dec 2007 11:07:29 -0800 Subject: [Ietf-http-auth] Narrative notes from bar BoF X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2007 18:15:58 -0000 --Apple-Mail-9--472047647 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 6:00pm to 7:30 pm, Vancouver 70th IETF, narrative notes Eliot Lear: volunteer to put some goals, if we can agree on them, into a draft charter. Phil Hallam-Baker: ... We need to have identifiers that consistently identify us across the Web. Lisa Dusseault: Does everybody agree we need leveraged identities? Jeff Hodges: That's called single sign-on Eliot Lear: authentication has a role to play in devaluing the assets of botnet controllers. Sam Hartman: I can host a workshop on this Yutaka Oiwa: For a web system, the ultimate goal is authentication of Web system, not only HTTP request, but actually the response: authenticate the *response* and the user reacts to that. Sam: I like Nico's extensions for integrating this as they're modular. Not mechanism-specific. Lisa: Any disagreement with the goal that we're not inventing new authentication mechanism? Phil: Go further, it's not a goal to invent a new authentication *framework* since we already have some. Leif Johansson: you have to be careful about layering ... Joseph Salowey: there are a lot of ways you can layer these things, this doesn't mean you'll do all these things together Kurt Zeilenga: We want to reuse mechanisms from existing frameworks. [agreement] Sam: If we can change my phishing draft to express goals for this effort, let's change it (as long as they're phishing related goals) Leif: Enterprise goal of reusing frameworks, is a goal but not a phishing goal. Chris Newman: There may be some priorities. I think the anti- phishing goal is more important than some others. [agreement] Lisa: I've heard other groups with the goal of making new authentication that works without upgrading browsers with new code. Sam: I don't think that's consistent with security. Lisa: Right. I don't think you can have all of: browser backward- compatibility, leveraged identities and phishing protection. Jeff: Anyway, other organizations have covered this space. SAML, OpenID. Chris: It is likely the outcome of this effort will require browser changes. [Agreement] Sam: It is a goal that this supports things other than browsers. CalDAV, WebDAV. [agreement.] Sam: Let's not break any mechanism that support that case, but not go out of our way to solve it: Eliot: Very small federation inside the house may be in scope. Sam: Specific example. To scale down kerberos or digest, you would need an initial way to get your account setup. That's mechanism specific, but to scale down to small number of users, you'dneed a way to do that. Requirements for that use case may be in scope, but changes to existing mechanisms like Digest or Kerberos should not be inscope for this forum. Eliot: The neighbour managing the routing case, which is "have I seen you before" Leif: This is lightweight federation Stephen Farrell: What about scaling up, people who have not met each other being able to interact? Sam: The mechanism work shouldn't be in scope, but the requirements are in scope. Joseph Salowey: That means that we have to pick only existing mechanisms that solve these requirements? Leif: Can you push the work onto another group like Kerberos? Sam: Your mechanism needs to have an enrollment strategy that does specific things. We're trying to do the glue and not Lisa: Are we choosing what to glue? Sam: We may choose mandatory to implement, but not limit the selection. [agreement] Phil: I've been at a panel where people thought authentication meant two entirely different things. Are we doing contact authentication (like SSL certificates, password enrolment) or initial first-round authentication when you make contact with a Web server and use a one- time password, PKI token and a secondary mechanism to back it up? Cookies, lightweight recycling. Three things to keep separate: enrolment (first contact), authentication and state management. Sam: Our primary focus should be authentication, with possibly work on state management. Leif: We might focus on state management for the purpose of authentication. Not solve the general state management. An in-band mechanism for HTTP might not rely on cookies. Phil: Cardspace is what cookies should have been: under user control and associated with information where the user can choose to release. [no disagreement on the scope possibly covering state maintenance or auth maintenance.] Eliot: do we focus on form authentication in this forum? Sam: Maybe. Chris: I view it as authentication dialog branding as part of the mechanism. There's a reason people choose forms. Joseph: People want to do rich content... Lisa: Saying "authentication dialog branding" is already selecting a user interface, I'm not sure we can do that. We're not sure that branding is the only reason people eschew dialogs, there may also be need for navigation links, links and text for things you can do if you don't log in. Sam: Nico's draft is good for this because it allows existing interfaces to be done securely. Eliot. A workshop that includes W3C and oasis could solve this problem. Phil: Yes, the effort is diffuse and lacks critical mass. Leif: So we carefully scope this. In-band authentication seems to be the commonality. Eliot: Not just the right standards bodies involved, but the right people involved: Google, MS, Mozilla, Apple are in the room. Mark Nottingham: You need users involved: sites like EBay, Amazon, people who have concerns that nobody in this room is talking about. Sam: That's too many people for a workshop. Mark: Building something that works in the security world, but doesn't map to the requirements of users, happens all the time. Tom Yu: Workshop should invite people who can agregate common concerns and present that. Phil: Suggest David Solo from CitiGroup; Peter St Andre: Be exclusive for this workshop. Only people who are crucial. Phil: W3C workshop: require people to write position papers, weeds out the tourists. Sam: I volunteer Eliot and myself and one or two others to organize a workshop. We could also just do a WG and simultaneously get the effort to get participation from other people. Keith Moore: You need a workshop to decide what to do next even if it's a WG. Mark: Will a workshop be substantially different than the BoF in Montreal? Sam: If we're limiting it to IETF scope, then it would not be different and would be worthless. So let's not limit it. Eliot: we need to get the right people and that they understand the scope is not just IETF. Phil: Doing this under "Note Well" rules is important. Lisa: Did we have agreement on authenticating the response? [somebody said this is the same as mutual auth] Sam: No, that is differen than mutual auth. You want to know that the page you get back was really from the party you mutually authenticated to. Eliot: Authentication across transactions, if you will. This was in your phishing draft. Lisa: Any disagreemtent on addressing that? [none at first, but then...] Joseph: Authenticating the data can be difficult, because it might not come from the source that you authenticatied. Sam: Packaging it up is ok. You need to know that the source you vetted provided it. Jeff: Even images, links in pages? Eliot read a bunch of charter notes and confirmed. Cyrus Daboo: What's the expected outcome of the workshop? Sam: Set of tasks to accomplish, where the tasks include writing code, IETF standards, and other organizations standards. Eliot: And web forms? Sam: In one model, you have glop in forms that triggers in-band notification. Eliot: How can we express that without closing down too tightly? The high level goal? Sam: Yes, include the goal to support Web forms, and I'll argue that the solution is the same. Mark. And Web services are covered. Mark. What about OAuth? Sam: My conclusion is that it didn't solve anti-phishing well. Leif: It solves the N-tier problem: Lisa: Explain? Cyrus: WebMail. I need to proxy my credentials from my browser through the Web interface to my email server. Mark: Or you want a mashup to be able to access your photos on Flickr for their cool thing; you give them rights. Jeff: That's only one tier, you're delegating rights, not doing authentication. Sam: it could be a limited use credential. Tom: Are we agreed our task is larger than protocol? We work on conceptual things, cognitive landscape? Mark: Who "we" are is interesting there. Sam: The people sitting around this room need to be involved in more than just the IETF for this to work. Lisa: who will be proposing a BOF? Eliot: Perhaps an outcome of the workshop is charters for work in various SDOs. Cisco sometimes asks academics to do vague things; we can do the analogous thing in asking help for a charter or WG. Sam: I'm not convinced a workshop is strictly necessary. Leif: The workshop could follow on a WG too, to establish consensus with other SDOs. Lisa: I personally was hoping we would do some small yet important fixes, even if we didn't solve the big problems with other SDOs. Derek Atkins: To do the small fixes, do we have the IE and firefox people here? ***Leif: Can we get everybody on the list? Eliot: What would solve your problem Robert Sayre? Robert Sayre: I've been trying to find a solution to shared secret authentication, that we can actually use, and do branding. Sam: I think you could turn HTTP-Nego into something you could use for that. Eliot: What is gating you from addressing the problem you just described? Robert: Every time we get into mutual authentication and message integrity, TLS becomes a requirement. I'm dubious of that. People don't use that. Sam: You believe a mechanism should provide message integrity even without TLS? Robert: The identity should be encrypted, even if the message is not encrypted. Phil: We seem to think the auth here should be username/password. Robert. That's one problem I'm trying to solve. Sam: We're hearing don't gate on a workshop. I'd like to get Robert and somebody from the right part of Apple, the safari group. Cyrus: I'm not from the right part, the CalSched group is trying to do cross-domain scheduling. We don't want to have the spam problem we have in email, so we need federated authetnication and access control to do this. We're not trying to define protocols, but rather requirements for the IETF work. Eliot: How do we bring implementors in? Cyrus: Interops. People demonstrate phishing, see problem in real products. Eliot: Demonstrating problems, not solutions? Everybody accepts there is a problem. Tom: The problem with demonstrating phishing is that will focus people on the details of phishing, not on the conceptual model. Leif: How do you get implementors involved? You have a BOF and you ask if anybody in the room is going to implement the work. Eliot: That's what WAE did and it failed. Lisa: It didn't fail, it just failed to follow through. Sam: It didn't even fail to follow through, Leif has been working on his draft, several of us have been working on pieces and will be ready with a specific proposal for a BoF. Eliot: This argues not even a workshop, but a cabal building a constituency. Mark: Devils advocate, not just getting vendors involved in the beginning. If we get a new protocol introduced on a number of large Web sites, and in Mozilla, that is a path forward. You need a browser and a site. Eliot: You want to have a couple more people than you would otherwise try, because RSI or IIW have a ton of solutions and we have so many pet solutions. They want to drive it through. Mark: I've heard probelms on the table, the hard part is figuring out what's going forward. Eliot; People trying to solve this problem can't have vendors own solutions. The biggest vendor tried to play that. We have sloughs of vendors playing kings of mountains, and diffusion. Leif: We shouldn't hang up non-browser applications on the phishing problem. We may find phishing to be a social problem. Keith: you can't separate the probelms. Leif: The non-browser, HTTP problem is unique to us and we need to solve it. Sam: Please review my draft, section 1.1. Are we headed in the right section. Chris: How do we get convergence? The thing that no other organization is doing is trying to solve the non-browser problem. Sam: I dont' know if anybody else is looking at mutual authentication. Chris: True, but I don't know if mutual auth is a req't of people we'd need to converge. Sam: We can use people like the banks to convince them they need it. Mark: Non-browser auth is in my area, with interesting and hard req'ts. I want to allow 3rd party code to auth against my service, but not to get the user access to those credentials Chris: That's too hard. Lisa; The list is ietf-http-auth@osafoundation.org. Everybody joining or on that list, right? Lisa: Any objections if I post these notes to the list? [none] Eliot: What are we doing next? I haven't heard a consensus view how to proceed. Leif: We could do a BOF around the non-browser auth. Keith: That's a piece the IETF could work on, yes, and get moving, but the workshop is important too. Eliot: Sam, Mark and I will propose how to proceed to this list. We're going to do that through email next week. Eliot: So everybody's going to look at Sam and Leif's documents. --Apple-Mail-9--472047647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
6:00pm to = 7:30 pm, Vancouver 70th IETF, narrative notes

Eliot Lear: = volunteer to put some goals, if we can agree on them, into a draft = charter.
Phil Hallam-Baker: = ... We need to have identifiers that consistently identify us across the = Web.
Lisa Dusseault: = Does everybody agree we need leveraged = identities?=A0
Jeff Hodges: = That's called single sign-on
Eliot Lear: = authentication has a role to play in devaluing the assets of botnet = controllers. =A0
Sam Hartman: I can = host a workshop on this
Yutaka Oiwa: For a = web system, the ultimate goal is authentication of Web system, not only = HTTP request, but actually the response: authenticate the *response* and = the user reacts to that. =A0
Sam: I like Nico's = extensions for integrating this as they're modular.=A0 Not = mechanism-specific.
Lisa: Any = disagreement with the goal that we're not inventing new authentication = mechanism?
Phil: Go further, = it's not a goal to invent a new authentication *framework* since we = already have some.
Leif Johansson: = you have to be careful about layering ...=A0
Joseph Salowey: there are a lot of ways you can layer these = things, this doesn't mean you'll do all these things = together
Kurt Zeilenga: We = want to reuse mechanisms from existing = frameworks.
[agreement]
Sam: If we can = change my phishing draft to express goals for this effort, let's change = it (as long as they're phishing related goals)
Leif: Enterprise goal of reusing frameworks, is a goal but not a = phishing goal.
Chris Newman: = There may be some priorities.=A0 I think the anti-phishing goal is more = important than some others.
[agreement]
Lisa: I've heard = other groups with the goal of making new authentication that works = without upgrading browsers with new code.
Sam: I don't think that's consistent with = security.
Lisa: Right. I = don't think you can have all of: browser backward-compatibility, = leveraged identities and phishing protection.
Jeff: Anyway, other organizations have covered this space. SAML, = OpenID.
Chris: It is = likely the outcome of this effort will require browser = changes.=A0
[Agreement]
Sam: It is a goal = that this supports things other than browsers.=A0 CalDAV, = WebDAV.
[agreement.]
Sam: Let's not = break any mechanism that support that case, but not go out of our way to = solve it:=A0
Eliot: Very small = federation inside the house may be in scope.
Sam: Specific example.=A0 To scale down kerberos or digest, you = would need an initial way to get your account setup. That's mechanism = specific, but to scale down to small number of users, you'dneed a way to = do that.=A0 Requirements for that use case may be in scope, but changes = to existing mechanisms like Digest or Kerberos should not be inscope for = this forum.
Eliot: The = neighbour managing the routing case, which is "have I seen you = before"
Leif: This is = lightweight federation
Stephen Farrell: = What about scaling up, people who have not met each other being able to = interact?
Sam: The mechanism = work shouldn't be in scope, but the requirements are in scope. = =A0
Joseph Salowey: That means that we have to = pick only existing mechanisms that solve these = requirements?
Leif: Can you push = the work onto another group like Kerberos?
Sam: Your mechanism needs to have an enrollment strategy that = does specific things.=A0 We're trying to do the glue and = not=A0
Lisa: Are we = choosing what to glue?
Sam: We may choose = mandatory to implement, but not limit the = selection.
[agreement]
Phil: I've been at = a panel where people thought authentication meant two entirely different = things. Are we doing contact authentication (like SSL certificates, = password enrolment) or initial first-round authentication when you make = contact with a Web server and use a one-time password, PKI token and a = secondary mechanism to back it up?=A0 Cookies, lightweight recycling.=A0 = Three things to keep separate: enrolment (first contact), authentication = and state management.=A0
Sam: Our primary = focus should be authentication, with possibly work on state = management.
Leif: We might = focus on state management for the purpose of authentication. =A0 Not = solve the general state management. An in-band mechanism for HTTP might = not rely on cookies.
Phil: Cardspace is = what cookies should have been: under user control and associated with = information where the user can choose to = release.
[no disagreement = on the scope possibly covering state maintenance or auth = maintenance.]
Eliot: do we focus = on form authentication in this forum?=A0
Sam: Maybe.
Chris: I view it = as authentication dialog branding as part of the mechanism.=A0 There's a = reason people choose forms. =A0
Joseph: People want to do rich = content...=A0
Lisa: Saying = "authentication dialog branding" is already selecting a user interface, = I'm not sure we can do that.=A0 We're not sure that branding is the only = reason people eschew dialogs, there may also be need for navigation = links, links and text for things you can do if you don't log = in.
Sam: Nico's draft is good for this because it = allows existing interfaces to be done securely.
Eliot.=A0 A workshop that includes W3C and oasis could solve this = problem.
Phil: Yes, the = effort is diffuse and lacks critical mass.
Leif: So we carefully scope this.=A0 In-band authentication seems = to be the commonality.
Eliot: Not just = the right standards bodies involved, but the right people involved: = Google, MS, Mozilla, Apple are in the room.
Mark Nottingham: You need users involved: sites like EBay, = Amazon, people who have concerns that nobody in this room is talking = about.=A0
Sam: That's too = many people for a workshop.
Mark: Building = something that works in the security world, but doesn't map to the = requirements of users, happens all the time.=A0
Tom Yu: Workshop should invite people who can agregate common = concerns and present that.
Phil: Suggest = David Solo from CitiGroup;=A0
Peter St Andre: Be = exclusive for this workshop.=A0 Only people who are = crucial.
Phil: W3C = workshop: require people to write position papers, weeds out the = tourists.
Sam: I volunteer = Eliot and myself and one or two others to organize a workshop.=A0 =A0 We = could also just do a WG and simultaneously get the effort to get = participation from other people.
Keith Moore: You need a workshop to decide what to do next even = if it's a WG.=A0
Mark: Will a = workshop be substantially different than the BoF in = Montreal?
Sam: If we're = limiting it to IETF scope, then it would not be different and would be = worthless.=A0 So let's not limit it.
Eliot: we need to get the right people and that they understand = the scope is not just IETF.
Phil: Doing this = under "Note Well" rules is important.


Lisa: Did we have agreement on authenticating the = response?
[somebody said = this is the same as mutual auth]
Sam: No, that is differen than mutual auth.=A0 You want to know = that the page you get back was really from the party you mutually = authenticated to. =A0
Eliot: = Authentication across transactions, if you will. This was in your = phishing draft.
Lisa: Any = disagreemtent on addressing that?=A0 [none at first, but = then...]
Joseph: = Authenticating the data can be difficult, because it might not come from = the source that you authenticatied.
Sam: Packaging it up is ok.=A0 You need to know that the source = you vetted provided it.
Jeff: Even images, = links in pages?
Eliot read a bunch of charter notes and = confirmed.
Cyrus Daboo: What's the expected outcome of = the workshop?
Sam: Set of tasks = to accomplish, where the tasks include writing code, IETF standards, and = other organizations standards.

Eliot: And web = forms?
Sam: In one model, = you have glop in forms that triggers in-band = notification.=A0
Eliot: How can we = express that without closing down too tightly?=A0 The high level = goal?=A0
Sam: Yes, include = the goal to support Web forms, and I'll argue that the solution is the = same.
Mark. And Web = services are covered.
Mark. What about = OAuth?
Sam: My conclusion = is that it didn't solve anti-phishing well.
Leif: It solves the N-tier problem: =A0
Lisa: Explain?
Cyrus: WebMail. I = need to proxy my credentials from my browser through the Web interface = to my email server.
Mark: Or you want = a mashup to be able to access your photos on Flickr for their cool = thing; you give them rights.
Jeff: That's only = one tier, you're delegating rights, not doing = authentication.
Sam: it could be a = limited use credential.

Tom: Are we agreed our task is larger than protocol? We work on = conceptual things, cognitive landscape?
Mark: Who "we" are is interesting there.
Sam: The people sitting around this room need to be involved in = more than just the IETF for this to work.

Lisa: who will be = proposing a BOF?
Eliot: Perhaps an = outcome of the workshop is charters for work in various SDOs.=A0 Cisco = sometimes asks academics to do vague things; we can do the analogous = thing in asking help for a charter or WG.
Sam: I'm not convinced a workshop is strictly = necessary.
Leif: The workshop = could follow on a WG too, to establish consensus with other = SDOs.

Lisa: I personally was hoping we would do some small yet = important fixes, even if we didn't solve the big problems with other = SDOs.
Derek Atkins: To = do the small fixes, do we have the IE and firefox people = here?


***Leif: Can we = get everybody on the list?
Eliot: What would solve your problem Robert = Sayre?
Robert Sayre: I've = been trying to find a solution to shared secret authentication, that we = can actually use, and do branding.
Sam: I think you could turn HTTP-Nego into something you could = use for that.
Eliot: What is = gating you from addressing the problem you just = described?
Robert: Every time = we get into mutual authentication and message integrity, TLS becomes a = requirement.=A0 I'm dubious of that.=A0 People don't use = that.
Sam: You believe a = mechanism should provide message integrity even without = TLS?
Robert: The = identity should be encrypted, even if the message is not = encrypted.
Phil: We seem to = think the auth here should be username/password.
Robert.=A0 That's one problem I'm trying to = solve.

Sam: We're hearing don't gate on a workshop.=A0 I'd like to get = Robert and somebody from the right part of Apple, the safari = group.
Cyrus: I'm not = from the right part, the CalSched group is trying to do cross-domain = scheduling.=A0 We don't want to have the spam problem we have in email, = so we need federated authetnication and access control to do this.=A0 = We're not trying to define protocols, but rather requirements for the = IETF work.
Eliot: How do we bring implementors = in?
Cyrus: Interops.=A0 People demonstrate = phishing, see problem in real products.=A0
Eliot: Demonstrating problems, not solutions?=A0 Everybody = accepts there is a problem.=A0
Tom: The problem with demonstrating phishing is that will focus = people on the details of phishing, not on the conceptual = model.
Leif: How do you = get implementors involved? You have a BOF and you ask if anybody in the = room is going to implement the work.
Eliot: That's what WAE did and it failed.
Lisa: It didn't fail, it just failed to follow = through.
Sam: It didn't = even fail to follow through, Leif has been working on his draft, several = of us have been working on pieces and will be ready with a specific = proposal for a BoF.
Eliot: This argues = not even a workshop, but a cabal building a = constituency.
Mark: Devils = advocate, not just getting vendors involved in the beginning.=A0 If we = get a new protocol introduced on a number of large Web sites, and in = Mozilla, that is a path forward. =A0 You need a browser and a site. = =A0
Eliot: You want to have a couple more people = than you would otherwise try, because RSI or IIW have a ton of solutions = and we have so many pet solutions.=A0 They want to drive it = through.=A0
Mark: I've heard = probelms on the table, the hard part is figuring out what's going = forward. =A0
Eliot; People = trying to solve this problem can't have vendors own solutions.=A0 The = biggest vendor tried to play that.=A0 We have sloughs of vendors playing = kings of mountains, and diffusion. =A0

Leif: We shouldn't = hang up non-browser applications on the phishing problem.=A0 We may find = phishing to be a social problem.
Keith: you can't separate the probelms.
Leif: The non-browser, HTTP problem is unique to us and we need = to solve it.
Sam: Please review my draft, section 1.1. Are = we headed in the right section.

Chris: How do we = get convergence? The thing that no other organization is doing is trying = to solve the non-browser problem.
Sam: I dont' know if anybody else is looking at mutual = authentication.=A0
Chris: True, but I = don't know if mutual auth is a req't of people we'd need to = converge.
Sam: We can use = people like the banks to convince them they need = it.
Mark: Non-browser auth is in my area, with = interesting and hard req'ts.=A0 I want to allow 3rd party code to auth = against my service, but not to get the user access to those = credentials=A0
Chris: That's too = hard.

Lisa; The list is ietf-http-auth@osafoundation.org.=A0 Everybody = joining or on that list, right?
Lisa: Any = objections if I post these notes to the list?=A0 = [none]

Eliot: What are we doing next?=A0 I haven't heard a consensus = view how to proceed.
Leif: We could do = a BOF around the non-browser auth.=A0
Keith: That's a piece the IETF could work on, yes, and get = moving, but the workshop is important too.

Eliot: Sam, Mark = and I will propose how to proceed to this list.=A0 We're going to do = that through email next week. =A0

Eliot: So = everybody's going to look at Sam and Leif's = documents.

= --Apple-Mail-9--472047647-- Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E7CA07F6CD for ; Tue, 4 Dec 2007 12:50:15 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E77D9142211 for ; Tue, 4 Dec 2007 12:50:16 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -17.277 X-Spam-Level: X-Spam-Status: No, score=-17.277 tagged_above=-50 required=4 tests=[AWL=0.322, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDAhD8SiZWFq for ; Tue, 4 Dec 2007 12:50:11 -0800 (PST) Received: from rsmtp2.corp.yahoo.com (rsmtp2.corp.yahoo.com [207.126.228.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8B9E1142210 for ; Tue, 4 Dec 2007 12:50:11 -0800 (PST) Received: from [130.129.55.92] (snvvpn1-10-72-72-c205.corp.yahoo.com [10.72.72.205]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lB4Ko16q044705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Dec 2007 12:50:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=P/MwDaU9WLUvL879FLnJxDx4UkWTQwi0BnrBwQ0S3fVvA8/hmJnWcLQ/qpJctQeY In-Reply-To: References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21DD0B82-7C32-4546-A67A-60CC6D079BA1@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? Date: Tue, 4 Dec 2007 12:49:59 -0800 To: Sam Hartman X-Mailer: Apple Mail (2.752.3) Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 20:50:16 -0000 OK, so let's do it 6pm, meet at the message board, finish before 8. On 2007/12/03, at 8:13 AM, Sam Hartman wrote: > On Tuesday, I could attend 6-8 but I would have to leave at 8 for an > ifare dinner. > I could not attend today at all. > > -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B04B680B78 for ; Mon, 3 Dec 2007 08:13:30 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A228D142204 for ; Mon, 3 Dec 2007 08:13:31 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-50 required=4 tests=[AWL=0.756, BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb611tsfXHDI for ; Mon, 3 Dec 2007 08:13:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-178f.ietf70.org [130.129.23.143]) by laweleka.osafoundation.org (Postfix) with ESMTP id 368DE1421FC for ; Mon, 3 Dec 2007 08:13:26 -0800 (PST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A357E481D; Mon, 3 Dec 2007 11:13:24 -0500 (EST) From: Sam Hartman To: Eliot Lear Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> Date: Mon, 03 Dec 2007 11:13:24 -0500 In-Reply-To: <474F362E.9070706@cisco.com> (Eliot Lear's message of "Thu, 29 Nov 2007 13:59:10 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2007 16:13:30 -0000 On Tuesday, I could attend 6-8 but I would have to leave at 8 for an ifare dinner. I could not attend today at all. Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 43F9280AE4 for ; Sun, 2 Dec 2007 13:40:36 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 1D5081421FF for ; Sun, 2 Dec 2007 13:40:37 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -17.237 X-Spam-Level: X-Spam-Status: No, score=-17.237 tagged_above=-50 required=4 tests=[AWL=0.362, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxZjGvF+rQ3k for ; Sun, 2 Dec 2007 13:40:31 -0800 (PST) Received: from rsmtp1.corp.yahoo.com (rsmtp1.corp.yahoo.com [207.126.228.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A3BCD1421FD for ; Sun, 2 Dec 2007 13:40:31 -0800 (PST) Received: from [10.0.248.81] (snvvpn1-10-72-73-c249.corp.yahoo.com [10.72.73.249]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lB2LeE3O070838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2007 13:40:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=X54m8SazhE2og0RsaLDoYi3+Bj0CPjQj1jzrjxsHsc6luf74r5ywEFkPkGws6ymY In-Reply-To: <4753238E.3070700@isode.com> References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> <4751C951.8070601@isode.com> <2D465556-159A-4C3E-AAD5-815F12EF6724@yahoo-inc.com> <4753238E.3070700@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? Date: Sun, 2 Dec 2007 13:40:07 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 21:40:38 -0000 I have to drive to Bellevue that evening, so capping it at 8 works for me. On 2007/12/02, at 1:28 PM, Alexey Melnikov wrote: > Mark Nottingham wrote: > >> The other option would be Monday, but HTTPBIS runs pretty late, >> and IIRC some people already have plans... > > Indeed. > > I am personally fine with meeting at 6pm on Tuesday, but I would > have to leave around 8pm. > >> On 2007/12/01, at 12:51 PM, Alexey Melnikov wrote: >> >>> Eliot Lear wrote: >>> >>>> Mark Nottingham wrote: >>>> >>>>> How about Tuesday 6pm (unless ltans a potential conflict)? >>>> >>>> Unfortunately everyone else wants to meet for a bar bof at that >>>> time :-( >>> >>> As long as this doesn't overrun the Vcarddav dinner happening >>> later on Tuesday. >>> I believe some people might be interested in attending both. >> > -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 7F32980AB5 for ; Sun, 2 Dec 2007 13:29:02 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 67DCC1421FF for ; Sun, 2 Dec 2007 13:29:03 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-50 required=4 tests=[AWL=0.713, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOjPKpHKJSJL for ; Sun, 2 Dec 2007 13:28:58 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id AD1681421FC for ; Sun, 2 Dec 2007 13:28:57 -0800 (PST) Received: from [130.129.17.12] (dhcp-110c.ietf70.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 2 Dec 2007 21:28:54 +0000 Message-ID: <4753238E.3070700@isode.com> Date: Sun, 02 Dec 2007 21:28:46 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> <4751C951.8070601@isode.com> <2D465556-159A-4C3E-AAD5-815F12EF6724@yahoo-inc.com> In-Reply-To: <2D465556-159A-4C3E-AAD5-815F12EF6724@yahoo-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 21:29:02 -0000 Mark Nottingham wrote: > The other option would be Monday, but HTTPBIS runs pretty late, and > IIRC some people already have plans... Indeed. I am personally fine with meeting at 6pm on Tuesday, but I would have to leave around 8pm. > On 2007/12/01, at 12:51 PM, Alexey Melnikov wrote: > >> Eliot Lear wrote: >> >>> Mark Nottingham wrote: >>> >>>> How about Tuesday 6pm (unless ltans a potential conflict)? >>> >>> Unfortunately everyone else wants to meet for a bar bof at that >>> time :-( >> >> As long as this doesn't overrun the Vcarddav dinner happening later >> on Tuesday. >> I believe some people might be interested in attending both. > Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 924E780AB5 for ; Sun, 2 Dec 2007 13:20:48 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7B5651421FF for ; Sun, 2 Dec 2007 13:20:49 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -17.185 X-Spam-Level: X-Spam-Status: No, score=-17.185 tagged_above=-50 required=4 tests=[AWL=0.414, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiQ0445rCC2z for ; Sun, 2 Dec 2007 13:20:44 -0800 (PST) Received: from rsmtp1.corp.yahoo.com (rsmtp1.corp.yahoo.com [207.126.228.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 189A71421FC for ; Sun, 2 Dec 2007 13:20:44 -0800 (PST) Received: from [10.0.248.81] (snvvpn1-10-72-73-c249.corp.yahoo.com [10.72.73.249]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.8/8.13.8/y.rout) with ESMTP id lB2LKRlo070077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Dec 2007 13:20:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=in-reply-to:references:mime-version:content-type:message-id:cc: content-transfer-encoding:from:subject:date:to:x-mailer; b=MJQpOdYu8aO3XghkbZ+T4UnGEjpbI7Mtd2IMtjoBx/7z2kHSCqeNRNaUd0M0aRDJ In-Reply-To: <4751C951.8070601@isode.com> References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> <4751C951.8070601@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D465556-159A-4C3E-AAD5-815F12EF6724@yahoo-inc.com> Content-Transfer-Encoding: 7bit From: Mark Nottingham Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? Date: Sun, 2 Dec 2007 13:20:18 -0800 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 21:20:48 -0000 The other option would be Monday, but HTTPBIS runs pretty late, and IIRC some people already have plans... On 2007/12/01, at 12:51 PM, Alexey Melnikov wrote: > Eliot Lear wrote: > >> Mark Nottingham wrote: >> >>> How about Tuesday 6pm (unless ltans a potential conflict)? >>> >> Unfortunately everyone else wants to meet for a bar bof at that >> time :-( >> > As long as this doesn't overrun the Vcarddav dinner happening later > on Tuesday. > I believe some people might be interested in attending both. > -- Mark Nottingham mnot@yahoo-inc.com Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id EDDE880A9B for ; Sun, 2 Dec 2007 12:23:12 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D5C111421FF for ; Sun, 2 Dec 2007 12:23:13 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-50 required=4 tests=[BAYES_00=-2.599, FORGED_RCVD_HELO=0.135] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZlLwgdQEinK for ; Sun, 2 Dec 2007 12:23:08 -0800 (PST) Received: from delta.rtfm.com (dhcp-11b6.ietf70.org [130.129.17.182]) by laweleka.osafoundation.org (Postfix) with ESMTP id F0EBB1421F1 for ; Sun, 2 Dec 2007 12:23:07 -0800 (PST) Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5B5BB33C9D; Sun, 2 Dec 2007 09:42:54 -0800 (PST) Date: Sun, 02 Dec 2007 09:42:53 -0800 From: Eric Rescorla To: Yutaka OIWA Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt In-Reply-To: <87ve7khma2.fsf@bluewind.rcis.aist.go.jp> References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053105.380CE33C21@delta.rtfm.com> <87ve7khma2.fsf@bluewind.rcis.aist.go.jp> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071202174254.5B5BB33C9D@delta.rtfm.com> Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 20:23:13 -0000 At Fri, 30 Nov 2007 04:41:41 +0900, Yutaka OIWA wrote: > > Dear Eric and other people discussing the issue recently, > > Thank you very much for the comment. > > Eric Rescorla writes: > > > A few questions/comments: > > > > 1. I don't see why this makes sense to do at the HTTP layer. Wouldn't > > it be more straightforward to do this in TLS rather than adapting > > Digest? I also would note that TLS-SRP has already been approved > > by the IESG. > > In short, We found that TLS-SRP is not well suited for web applications. > > Web authentications are basically application-layer issues. In real > web sites like Google or Yahoo!, there are both unauthenticated > contents and authenticated contents on one server, and also there are > many independent "authentication realms" which request different sets > of authentication credentials. One of these realms (including > "no-authentication" realm) are assigned for each requested Web > resource, which is determined by the HTTP-layer request URI and other > headers. When TLS-SRP is used, however, the authentication starts > before the client tells the server what resource are requested. This > gives great difficulty for designing web sites and inapplicability for > many existing systems. Well, this certainly is a difficulty, but there are a number of ways around this, including: (1) Hosting apps with different security policies on different virtual servers and using the server_name extension to disambiguate. (2) Renegotiate (I realize you don't like this, but see below for why I don't find your argument convincing). So, I don't consider this to be a "great difficulty". More importantly, using any HTTP level mechanism for mutual makes it difficult for the *client* to get the right security properties, because he blindly sends requests to the servers, including ones that potentially contain sensitive information, before the server has authenticated. By contrast any TLS-based mechanism forces the server to authenticate first before any sensitive data is exchanged. (And you can't say you're going to use TLS underneath here because the whole premise is that you don't trust the server's cert). Incidentally, there was a similar problem in RFC 2817, which is part of why it was never really adopted in Web systems. > One might also think that combination of TLS-SRP and TLS renegotiation > can be useful to solve the issue. But it is very unlikely to specify > and implement correctly an appropriate mechanism for Web > authentication using some kinds of tricky "authentication tunneling" > behaviors. I have no idea what this means. > The simple HTTP-layer authentication is much clearer and > better. Furthermore, introduced in HTTP/1.1, there is HTTP Keep-alive > feature that allows more than one HTTP-layer requests on one TLS (or > TCP) transport-layer connections. This adds further complexity for > such specifications. On the contrary. Keep-alive is what makes this an attractive technique. > > 3. There are a large number of PAKE/ZKPP protocols. Can you please > > explain why one would want this protocol versus others? > > There are some criteria which are required for use in our Mutual > Authentication Protocol: > > (1) There are only four messages for one authentication > (including key sharing confirmation). This applies to SRP. > (2) Among those, key sharing is done in first two messages, > and final two messages are only for lightweight key confirmation. > This is required because our scheme uses one shared key for > several requests by re-sending final two messages only. > This reduces overhead for repeatedly performing public-key > cryptographic operations. You don't need to do things this way. Use the exchanged key to MAC the rest of the HTTP traffic with some other system. > (3) Those final two messages must be able to be extended so that we > can put additional confirmation data such as nonces and > validation tokens (v) into that messages. Note that this is > very important point: in our scheme, this modification to the > messages are important to prevent man-in-the-middle attacks. See above. > In addition to this, In KAM3 required secret is asymmetric: the server > only needs "encrypted" (or "hashed") password, and does not need > having the real password value (pi) itself. These are the reasons we > chose ISO-defined variant as a basis. Again, applies to SRP. My understanding is that these are fairly standard features of PAKE systems. > Finally, we currently think that, as far as we know, other patents on > related fields are not applicable for this technique either because it > is out of the claim or there are prior arts (as far as our protocol is > concerned). I can't evaluate this without seeing the protocol. -Ekr Return-Path: X-Original-To: ietf-http-auth@osafoundation.org Delivered-To: ietf-http-auth@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1F4AF80AF8 for ; Sat, 1 Dec 2007 14:54:59 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id F211D142206 for ; Sat, 1 Dec 2007 14:54:59 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[AWL=0.000, BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT1BzBfR0-du for ; Sat, 1 Dec 2007 14:54:54 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id 43234142204 for ; Sat, 1 Dec 2007 14:54:54 -0800 (PST) Received: from [192.168.1.129] (S0106005018446c5d.vc.shawcable.net [24.85.75.120]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 1 Dec 2007 22:54:51 +0000 Message-ID: <4751E631.6080105@isode.com> Date: Sat, 01 Dec 2007 22:54:41 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Yutaka OIWA Subject: Re: [Ietf-http-auth] submitted draft-oiwa-http-mutualauth-01.txt References: <87wss4oisd.fsf@bluewind.rcis.aist.go.jp> <20071127053105.380CE33C21@delta.rtfm.com> <87ve7khma2.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: <87ve7khma2.fsf@bluewind.rcis.aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2007 22:54:59 -0000 Hi Yutaka, [This might be slightly off-topic for this mailing list.] Yutaka OIWA wrote: >>4. I see you've filed an IPR disclosure on this technique. Is your >> own IPR the only IPR which you're aware of? >> >> > >First, we can guarantee that the disclosed patents are the only patent >that the authors (Oiwa, Watanabe, Takagi and Suzuki) have submitted or >even concerned which affect the protocol. > >(Of course, the patent is only for the modification of the protocol > from ISO specification and the application to HTTP authentication. > > Can you describe this in more details? In particular, does your patent cover use of your authentication approach in protocols other than HTTP? > The original ISO KAM3 protocol is out of the patent's scope for the > obvious reason.) > > Return-Path: X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5A0AF80B48 for ; Sat, 1 Dec 2007 12:51:48 -0800 (PST) Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 38E35142211 for ; Sat, 1 Dec 2007 12:51:49 -0800 (PST) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-50 required=4 tests=[BAYES_00=-2.599] Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CZhMq+88lzZ for ; Sat, 1 Dec 2007 12:51:43 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by laweleka.osafoundation.org (Postfix) with ESMTP id ABBCC14220D for ; Sat, 1 Dec 2007 12:51:41 -0800 (PST) Received: from [192.168.1.129] (S0106005018446c5d.vc.shawcable.net [24.85.75.120]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 1 Dec 2007 20:51:38 +0000 Message-ID: <4751C951.8070601@isode.com> Date: Sat, 01 Dec 2007 20:51:29 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eliot Lear Subject: Re: [Ietf-http-auth] Bar BoF in Vancouver? References: <474F1896.2080804@cisco.com> <054BAD5A-D070-4CCA-8485-EC4725AFCD18@yahoo-inc.com> <474F362E.9070706@cisco.com> In-Reply-To: <474F362E.9070706@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-http-auth@lists.osafoundation.org X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2007 20:51:48 -0000 Eliot Lear wrote: >Mark Nottingham wrote: > > >>How about Tuesday 6pm (unless ltans a potential conflict)? >> >> >Unfortunately everyone else wants to meet for a bar bof at that time :-( > > As long as this doesn't overrun the Vcarddav dinner happening later on Tuesday. I believe some people might be interested in attending both.