From y.oiwa@aist.go.jp Sun Jun 5 10:06:53 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473D011E809D; Sun, 5 Jun 2011 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9r6TdnbR1n; Sun, 5 Jun 2011 10:06:52 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6511E809B; Sun, 5 Jun 2011 10:06:44 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p55H6eDW026639; Mon, 6 Jun 2011 02:06:40 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1307293601; bh=Mml2AqTlUsDw4XeO2CDdd6yNNvq9cbqtV8GWNgHH23w=; h=From:Date:Message-ID; b=RkFy9itZre+AH5Xliw5+JgP4yMYLpYEvG/kNtr2qwhwAnY1JV4HY2QWpWZS0BtKDm mGAyoyG5MCexQi8y/Tg+hiaJhYVIKYICoCrBgSCLPpQWq9tGvSENNLv6j/9t5HFzpU kNGf6r1maVzEiD+QgXYvXAJI3Ot24mJosGdOGgXA= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p55H6e0e002272; Mon, 6 Jun 2011 02:06:40 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id p55H6c42025520; Mon, 6 Jun 2011 02:06:38 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: http-auth@ietf.org From: Yutaka OIWA Date: Mon, 06 Jun 2011 02:06:38 +0900 Message-ID: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: [websec] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 17:06:53 -0000 Dear all at http-auth mailing list, (Cc: Peter, Sean, Harry, and related mailing lists subscribers) following the discussions in the Prague http-auth Bar-BoF in March, and the W3C Identity in Browser workshop in the last month, now I would like to re-call the formation of BoF for http-auth in IETF. The workshop was really hot and enjoying, and there were so many useful inputs to both Web community and IETF, I believe. Some materials presented and discussed there are available at . # Harry, are the *output* materials of the workshop already available to public? Currently I'm preparing a start-up version of problem statement document and proposed BoF agenda. However, very unfortunately, the last week I had a severe fever heat and could not work well (I'm really sorry about that). I'm going to submit them to the list within two days, and if possible comments to the last version of the agenda proposal, available at , are welcome. I'm currently working based on that. Thanks, Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From hhalpin@w3.org Sun Jun 5 14:32:55 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00AE21F8502; Sun, 5 Jun 2011 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aDtcp3IEv-J; Sun, 5 Jun 2011 14:32:54 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6296121F8500; Sun, 5 Jun 2011 14:32:53 -0700 (PDT) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1QTKw8-0004Ua-Eq; Sun, 05 Jun 2011 17:32:44 -0400 Received: from 87.149.171.109 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Sun, 5 Jun 2011 22:32:44 +0100 (BST) Message-ID: <6cdda6a1c5901b19823e4e2cf54b7e90.squirrel@webmail-mit.w3.org> In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> Date: Sun, 5 Jun 2011 22:32:44 +0100 (BST) From: "Harry Halpin" To: http-auth@ietf.org, y.oiwa@aist.go.jp User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Mon, 06 Jun 2011 08:55:58 -0700 Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [websec] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 21:32:55 -0000 > Dear all at http-auth mailing list, > (Cc: Peter, Sean, Harry, and related mailing lists subscribers) > > following the discussions in the Prague http-auth Bar-BoF in March, > and the W3C Identity in Browser workshop in the last month, now I > would like to re-call the formation of BoF for http-auth in IETF. The > workshop was really hot and enjoying, and there were so many useful > inputs to both Web community and IETF, I believe. Some materials > presented and discussed there are available at > . > > # Harry, are the *output* materials ofn the workshop already available to > public? > The workshop already links to all papers and slides on the website. There will be a final report released in about 2 weeks. The public-identity@w3.org will be list I use to get input to the draft final report, to join email "subscribe" in subject line to public-identity-request@w3.org. From my memory there was interest in MutualAuth, primarily from the financial industry and banks, who really did seem to want it. The browser vendors were of course skeptical of anything in chrome, but other discussions such as Dirk Balfanz's do to auth in the OS layer could provide an alternative. [1] http://www.w3.org/2011/identity-ws/ > Currently I'm preparing a start-up version of problem statement document > and > proposed BoF agenda. However, very unfortunately, the last week I had a > severe fever heat and could not work well (I'm really sorry about that). > I'm going to submit them to the list within two days, and if possible > comments to the last version of the agenda proposal, available at > , > are welcome. I'm currently working based on that. > > Thanks, > > Yutaka > > -- > Yutaka OIWA, Ph.D. Research > Scientist > Research Center for Information Security > (RCIS) > National Institute of Advanced Industrial Science and Technology > (AIST) > Mail addresses: , > > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] > > From bkihara.l@gmail.com Tue Jun 7 03:09:26 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C682411E80C4; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvnhDgiyA-kw; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2879711E80BF; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: by pwi5 with SMTP id 5so2893093pwi.31 for ; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=r1sHsORBGJUl1zuAXFf0vNvc3svdFmbZ3pj+423sxUQ=; b=m5g80NQo+cZGXo7GQ3niMzh/3TUIf3a3BFBabP1EoOUnD0p9TLwchA14NXRGdRVKly oKEbGvrW4Di298cnsMsYKuXOj8zWtM+iTBb/2qBCUu2If+kMSVmYiU8myvOgDxjv4IDo Rqm2dobVVJzo6BivHkfo2bBjMWMUQ1lRrTx0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V786vpDuw6ktQcsrXSmiLUmtoWyZySIEWy99/XQmuJDVrcSzkBzV73ZGJMSebu/aqA N8D9ZCJwkyEmGdaA9cGCplOFLLoZfQERL/DT6Ex+S7gxr5QZjK89CZtL5gKvW+Bi2/6k CH1fNirDyvX/mnyHUUAqFBuMUDM96UxjpA20Q= MIME-Version: 1.0 Received: by 10.142.248.35 with SMTP id v35mr38393wfh.245.1307441365610; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) Received: by 10.142.164.3 with HTTP; Tue, 7 Jun 2011 03:09:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 19:09:25 +0900 Message-ID: From: "KIHARA, Boku" To: saag@ietf.org, websec@ietf.org, oauth@ietf.org, public-identity@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Fwd: [http-auth] REST-GSS I-D posted X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:09:26 -0000 FYI ---------- Forwarded message ---------- From: Nico Williams Date: 2011/6/7 Subject: [http-auth] REST-GSS I-D posted To: http-auth@ietf.org http://www.ietf.org/id/draft-williams-rest-gss-00.txt This is to go with the slides and paper presented almost two weeks ago at the W3C workshop on identity in the browser: http://www.w3.org/2011/identity-ws/agenda.html I would like to add some co-authors. =A0Anyone interested? Cheers, Nico -- _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth From y.oiwa@aist.go.jp Thu Jun 9 07:32:05 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D611E80D2; Thu, 9 Jun 2011 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.22 X-Spam-Level: X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRSF5auJShTb; Thu, 9 Jun 2011 07:32:04 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 206E811E808B; Thu, 9 Jun 2011 07:32:03 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p59EVvaL008115; Thu, 9 Jun 2011 23:31:57 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1307629919; bh=u16ceoPm/IlX33yKZnBYTIYs6XdPEtqsSWqcKkgqocY=; h=From:Date:Message-ID; b=G8lemk+AekwTsTmib4Z0v6RV932tIWdhJP63QHC5g5sQuh0WIqDkEUhOvlb2Gdje7 GxpOQGbYKNilYKCfsuI71uw2JYdGeXlOYKx3UbuAuXF6TikjeKsgaO82WkgqAhjiSB r3qIuizE9QmRkk3rc20ah6LRduubS9bgc7uU20C8= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p59EVvWt023363; Thu, 9 Jun 2011 23:31:57 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id p59EVtXV012071; Thu, 9 Jun 2011 23:31:55 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: http-auth@ietf.org References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> From: Yutaka OIWA Date: Thu, 09 Jun 2011 23:31:55 +0900 In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> (Yutaka OIWA's message of "Mon\, 06 Jun 2011 02\:06\:38 +0900") Message-ID: <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [websec] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:32:05 -0000 Dear all, Regarding http-auth, I finally updated the proposed BoF agenda. The text is appended to this mail. A "draft" of the problem statement document, referred to by the agenda, is currently available at . We're currently preparing an Internet-Draft formatted version. Comments for both documents are really welcome and appreciated. Cheers, --------- Description: The current authentication methods used in the Web system are prone to various serious vulnerabilities, including password eavesdropping, password stealing, session hijack, and phishing. Currently, the HTTP core protocol only provides basic plaintext password authentication and MD5-based hashed password authentication, both of which are insecure against eavesdropping and password dictionary attack. There are some other authentication protocols which integrate with existing authentication frameworks such as GSS and SASL, but these were not widely accepted outside the area where the frameworks are already used. TLS, which is the underlying transport of HTTPS, provides client certificate-based authentication but that has some but not massive use cases, mainly due to deployment and usability problems. Also, both current HTTP authentications and TLS client authentication lack several control features, which makes modern Web applications hard to deploy. For example, both authentication mechanisms do not have ability to dissolve authentication association (log-out) from the server side, nor ability to directly accept a guest (unauthenticated) user in the same URL as those for authenticated users. These lack of features make people tends to use HTML forms for authentication, which are by nature insecure against eavesdropping and Phishing attacks. Furthermore, although TLS has a almost-mandatory server authentication feature, it in the real world did not completely prevent impersonation attacks. To mitigate this, we should consider introduction of techniques which let users know by themselves whether the accessed server matches with their intentions, without relying on central authority or careful attentions of users. These problems should be solved as soon as possible to mitigate the impact of Web authentication-related frauds to the Internet users. However, to solve this problem, the resulting technologies should be carefully designed so that these will be well deployable to the real-world applications. Without this, we will end up with inventing one more useless technology, which is obviously unfortunate. Recently we have several new proposals for securing Web/HTTP authentications. In addition, we also have several proposed technologies in surrounding areas, such as delegated authorization (e.g. OAuth) or delegated authentication (OpenID). Combining those technologies with such secure authentication, with careful consideration about security binding, should contribute to the whole Web security improvements. Additionally, the work of the HTTPBIS working group is about to finish, and it will require some maintenance works for the HTTP existing authentication mechanism, at least the registrations to IANA. The purpose of the proposed BoF is to pursue creation of IETF working groups on various HTTP authentication issues. The possible topics of the future working group may include some of the following topics: * Introduction of much more secure authentication mechanisms as extensions to the HTTP, considering use with Web and non-Web accesses. These technologies should protect users from being stolen their authentication by malicious eavesdropper or phishers, or being impersonated by man-in-the-middle attacks, or forged authentication result by malicious servers. * Introduction of technologies which will enable more sophisticated use of HTTP authentication from recent Web applications. * Introduction of better secure authentication mechanisms which can be used with non-Web HTTP accesses with existing authentication frameworks. ("non-Web" here includes HTTP accesses made from scripting code running inside Web browsers.) * Introduction of proper channel-binding technologies to HTTP authentication layer, which can be combined with higher-layer authentication/authorization mechanisms. * Research on the secure and more easily usable ways of (possibly mutual) Web/HTML authentications using several kinds of authentication credentials, and required protocol-side support for them. * Maintenance of existing HTTP authentication extensions (other than Basic and Digest), either checking its httpbis-conformance or making it historic. * Proposing addition of the above authentication schemes to the IANA registry as proposed by httpbis new HTTP 1.1 specification. The working group should be careful about the impact of the introduced security mechanisms to privacy issues, as strong authentication sometimes conflicts with people's privacy concerns. Both BoF and possible future working group expect well coordination with W3C's effort on the related topics. It shall also be in coordination with related IETF working groups, including websec, abfab and oauth. BoF proposed agenda: * Discussions on HTTP authentication problem statement * Discussions for working group activity scope * Discussions for working group schedules (including handling of "research items") Logistical informations: BoF Chairs: TBD BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD) People expected: 50 Length of session: 90min Conflicts to avoid: Working Groups in the APP and SEC areas WebEX: no Responsible AD: Peter Saint-Andre (tentative) Goal: to pursue creation of IETF working groups Drafts: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more to be added Mailing List: HTTP http-auth mailing list Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/ -------- -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From julian.reschke@gmx.de Thu Jun 9 07:41:06 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9C21F8480 for ; Thu, 9 Jun 2011 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.169 X-Spam-Level: X-Spam-Status: No, score=-104.169 tagged_above=-999 required=5 tests=[AWL=-1.570, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny8grw9NIe4q for ; Thu, 9 Jun 2011 07:41:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4D57021F847A for ; Thu, 9 Jun 2011 07:41:04 -0700 (PDT) Received: (qmail invoked by alias); 09 Jun 2011 14:41:02 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp064) with SMTP; 09 Jun 2011 16:41:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18FrCU+9d8F0BT4qZs6WrwkE2eNpxWblpTVujxLg3 zzOpbSyDTjUPOd Message-ID: <4DF0DB72.9090601@gmx.de> Date: Thu, 09 Jun 2011 16:40:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: http-auth@ietf.org, y.oiwa@aist.go.jp References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Sean Turner , public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:41:06 -0000 On 2011-06-09 16:31, Yutaka OIWA wrote: > ... > password stealing, session hijack, and phishing. Currently, the HTTP > core protocol only provides basic plaintext password authentication > and MD5-based hashed password authentication, both of which are > ... That's kind of misleading; the core HTTP protocol doesn't define any concrete authentication schemes at all; it just offers a framework (header fields, status codes etc). > ... > Both BoF and possible future working group expect well coordination > with W3C's effort on the related topics. It shall also be in > coordination with related IETF working groups, including websec, abfab > and oauth. > ... I believe you need to add HTTPbis. Best regards, Julian From hallam@gmail.com Sat Jun 11 14:53:41 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F341F0C40; Sat, 11 Jun 2011 14:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pW7mU7V+kSW; Sat, 11 Jun 2011 14:53:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB01F0C35; Sat, 11 Jun 2011 14:53:40 -0700 (PDT) Received: by yie30 with SMTP id 30so413350yie.31 for ; Sat, 11 Jun 2011 14:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sTcMNjiVKkU/azl26PIFGJu8Ro8VurX61Rg3uGhteJ8=; b=glzyuoJhrjGEsOucx0emvU7qiTPG9yw0hyuAi1HCHOWU7T4QJFMM8+o/PEWLZEw5wD Ax1PlXoqCIJCdyUc8IZfk4vpSTR8e0qOR6/aMVvjs4tlQ9XvUNwIN21ExGq1GVY75FVz mDABJgPXvTQ5HC6777gAUV5w0fcvM83ykB1pA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PWov+qw1DeoBnaQNwyBInUDhhSrt1n+t63p/HTNWd1oQlhhAN9rJ6Agz9gD8OHuUx4 Fq+VCMNAzXkwpyWuLVntsnvP4FDTamlM3QHtFL12HaF9/PRa1y51Qdw8u8329f5WCT10 Jwlu0ulwOj3qHxAavi1pq4kpGDqI7/ysl9V7o= MIME-Version: 1.0 Received: by 10.101.52.7 with SMTP id e7mr3462730ank.85.1307829218554; Sat, 11 Jun 2011 14:53:38 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 14:53:38 -0700 (PDT) In-Reply-To: <4DF0DB72.9090601@gmx.de> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> <4DF0DB72.9090601@gmx.de> Date: Sat, 11 Jun 2011 17:53:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=001636ed7313ffb37304a576b79c Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 21:53:42 -0000 --001636ed7313ffb37304a576b79c Content-Type: text/plain; charset=ISO-8859-1 I have a different proposal. Lets take the high value authentication use cases out of the browser completely. Back in 1993 when Digest was designed, a Web browser could be written in about ten thousand lines of code. Today a modern browser has a code footprint that is larger than the memory plus pagefile of machine I used to work on at CERN. The modern browser is contaminated with plugins and active code. The worst disservice that Netscape did to the Web was when they added Javascript to Navigator unilaterally. Once a program conflates code and data it is never going to be possible to make it secure. The alternative would be to have a mini-browser whose sole purpose was to be used to confirm high value transactions. This could be on the same machine as the browser or a totally different machine such as a mobile phone. If we start small with an application whose sole purpose is security we have a good chance of getting some secure implementations. This type of approach is not going to be acceptable for every possible application or for every user. But the same is true of smart-cards, tokens and the like. So imagine that we had such a capability (I have a draft, I am just working on getting preliminary feedback), what would we want HTTP authentication to look like? At that point what I would want most from the browser is to be able to authenticate the browser and the machine it is running on in a manner that is secure and robust. Cookies try to do this but again the implementation was shoddy. Where I think this conversation tends to go off the rails is when people get the idea that the problem is the lack of an authentication protocol or an authentication framework API. We have both of them, we have cartloads of both of them. The other point where I think the conversation went into a dead end was five years ago when people started to sniff out the possibility of a something that turned out to be Facebook. All those people who were wittering on about 'Identity' were not trying to solve the problem of how users authenticate or manage attributes they were trying to solve the problem of how they could win the spot in the industry that Facebook now occupies. The missing like here in my view is the account identifier and the mechanism by which it is mapped to a service. The market has already decided that the federated account identifier for Internet login will look like an email address. So Alice is going to be something like alice@example.com. The problem with the current authentication infrastructure is that Alice now has hundreds of accounts under that account name being maintained all over the Web and example.com really has no control over how they are used. One side effect of that lack of control is the type of idiocy I encountered trying to report a bug in Visual Studio yesterday. First I had to register to create a Windows Live ID. Which was irritating since I already have registered several products with Microsoft. But never mind. So I register for that and then I am told that I have to register my Windows Live account again and verify my email a second time. Plus give all the same personal details again. Now the reason that Microsoft ended up in that situation is quite easy to see. They have a bunch of divisions run as silos and one does not exchange information with another. But they do have management degrees coming down from the top telling one division to use another's dog food. If my hallam@gmail.com accounts were all managed by gmail.com there would be no need for any callback mechanism whatsoever. Nor would there have been any need for the Windows Live account or the crazy register then register all over again. If we could accept the simple idea that use of an authentication account should work the exact same way as use of an email account, this type of problem can be eliminated. You don't expect to be able to use gmail.com for email unless gmail.com has a Web server. So why do people try to write protocols that are designed to allow people to use gmail.com for authentication when gmail.com is not involved in the running of the authentication service in question? --001636ed7313ffb37304a576b79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a different proposal. Lets take the high value authentication use ca= ses out of the browser completely.

Back in 1993 when Digest was designed, a Web browser co= uld be written in about ten thousand lines of code. Today a modern browser = has a code footprint that is larger than the memory plus pagefile of machin= e I used to work on at CERN.

The modern browser is contaminated with plugins and act= ive code. The worst disservice that Netscape did to the Web was when they a= dded Javascript to Navigator unilaterally. Once a program conflates code an= d data it is never going to be possible to make it secure.


The alternative would be to have a mini-= browser whose sole purpose was to be used to confirm high value transaction= s. This could be on the same machine as the browser or a totally different = machine such as a mobile phone.

If we start small with an application whose sole purpos= e is security we have a good chance of getting some secure implementations.=

This type of approach is not going to be acceptab= le for every possible application or for every user. But the same is true o= f smart-cards, tokens and the like.=A0


So imagine that we had such a capability= (I have a draft, I am just working on getting preliminary feedback), what = would we want HTTP authentication to look like?

At that point what I would want most from the browser is to be able to auth= enticate the browser and the machine it is running on in a manner that is s= ecure and robust. Cookies try to do this but again the implementation was s= hoddy.

Where I think this conversation tends to go off the rai= ls is when people get the idea that the problem is the lack of an authentic= ation protocol or an authentication framework API. We have both of them, we= have cartloads of both of them.=A0

The other point where I think the conversation went int= o a dead end was five years ago when people started to sniff out the possib= ility of a something that turned out to be Facebook. All those people who w= ere wittering on about 'Identity' were not trying to solve the prob= lem of how users authenticate or manage attributes they were trying to solv= e the problem of how they could win the spot in the industry that Facebook = now occupies.


The missing like here in my view is the = account identifier and the mechanism by which it is mapped to a service.

The market has already decided that the federated ac= count identifier for Internet login will look like an email address. So Ali= ce is going to be something like alice= @example.com.


The problem with the current authenticat= ion infrastructure is that Alice now has hundreds of accounts under that ac= count name being maintained all over the Web and example.com really has no control over how they are used.=A0

One side effect of that lack of control is the type of = idiocy I encountered trying to report a bug in Visual Studio yesterday. Fir= st I had to register to create a Windows Live ID. Which was irritating sinc= e I already have registered several products with Microsoft. But never mind= . So I register for that and then I am told that I have to register my Wind= ows Live account again and verify my email a second time. Plus give all the= same personal details again.

Now the reason that Microsoft ended up in that situatio= n is quite easy to see. They have a bunch of divisions run as silos and one= does not exchange information with another. But they do have management de= grees coming down from the top telling one division to use another's do= g food.

If my hallam@gmail.= com accounts were all managed by gmail.com= there would be no need for any callback mechanism whatsoever. Nor woul= d there have been any need for the Windows Live account or the crazy regist= er then register all over again.


If we could accept the simple idea that = use of an authentication account should work the exact same way as use of a= n email account, this type of problem can be eliminated.

You don't expect to be able to use gmail.com for email unless gmail.com has a Web server. So why do people try to write protocols that are desig= ned to allow people to use gmail.com for a= uthentication when gmail.com is not involv= ed in the running of the authentication service in question?
--001636ed7313ffb37304a576b79c-- From alexey.melnikov@isode.com Sun Jun 12 09:18:50 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5911E80AE; Sun, 12 Jun 2011 09:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRvrgPpmGwZ3; Sun, 12 Jun 2011 09:18:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DC04811E80AC; Sun, 12 Jun 2011 09:18:49 -0700 (PDT) Received: from [188.28.0.10] (188.28.0.10.threembb.co.uk [188.28.0.10]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Jun 2011 17:18:48 +0100 Message-ID: <4DF4E6C3.8030206@isode.com> Date: Sun, 12 Jun 2011 17:18:11 +0100 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: Julian Reschke References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> <4DF0DB72.9090601@gmx.de> In-Reply-To: <4DF0DB72.9090601@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:18:50 -0000 Julian Reschke wrote: > On 2011-06-09 16:31, Yutaka OIWA wrote: > >> ... >> password stealing, session hijack, and phishing. Currently, the HTTP >> core protocol only provides basic plaintext password authentication >> and MD5-based hashed password authentication, both of which are >> ... > > That's kind of misleading; the core HTTP protocol doesn't define any > concrete authentication schemes at all; it just offers a framework > (header fields, status codes etc). > > > ... > >> Both BoF and possible future working group expect well coordination >> with W3C's effort on the related topics. It shall also be in >> coordination with related IETF working groups, including websec, abfab >> and oauth. >> ... > > I believe you need to add HTTPbis. +1. I would also add Kitten. From ietf@adambarth.com Mon Jun 13 09:47:12 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB9611E8149 for ; Mon, 13 Jun 2011 09:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.677 X-Spam-Level: X-Spam-Status: No, score=-3.677 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXLVx70PHR80 for ; Mon, 13 Jun 2011 09:47:11 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC311E8154 for ; Mon, 13 Jun 2011 09:47:11 -0700 (PDT) Received: by yie30 with SMTP id 30so1339695yie.31 for ; Mon, 13 Jun 2011 09:47:10 -0700 (PDT) Received: by 10.151.130.7 with SMTP id h7mr6384219ybn.366.1307983630399; Mon, 13 Jun 2011 09:47:10 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id b4sm682987ybo.23.2011.06.13.09.47.08 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 09:47:08 -0700 (PDT) Received: by gxk19 with SMTP id 19so4158929gxk.31 for ; Mon, 13 Jun 2011 09:47:08 -0700 (PDT) Received: by 10.91.207.26 with SMTP id j26mr6395122agq.206.1307983628068; Mon, 13 Jun 2011 09:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 09:46:36 -0700 (PDT) In-Reply-To: <4DCCF025.3070702@gmx.de> References: <4D66CC25.6070202@stpeter.im> <4DCCC54F.6090107@gondrom.org> <4DCCF025.3070702@gmx.de> From: Adam Barth Date: Mon, 13 Jun 2011 09:46:36 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:47:12 -0000 On Fri, May 13, 2011 at 1:47 AM, Julian Reschke wro= te: > Terminology: replace "URL" by "URI" throughout. Done. > Replace "MIME type" by "media type" throughout. Done. > Add proper references. Which references would you like to see added? > =A0 A: Although the DNS has hierarchical delegation, the trust > =A0 relationships between host names vary by deployment. =A0For example, = at > =A0 many educational institutions, students can host content at > =A0 https://example.edu/~student/, but that does not mean a document > =A0 authored by a student should be part of the same origin (i.e., > =A0 represent the same principal) as a web application for managing > =A0 grades hosted at https://grades.example.edu/. > > Comment: Maybe point out that under this arrangement, the URIs for differ= ent > students *will* be in the same origin? Done. > 4. =A0Authority > > It's a bit unfortunate that "authority" is used by RFC 3986 (URI) for > something slightly different. If we don't want to change the term (which = I > assume) then it might be a good idea to clarify that this is not the same > thing as the "authority" component of a URI as defined in > . Done. Thanks! Adam From ietf@adambarth.com Mon Jun 13 10:40:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9F11E80AC for ; Mon, 13 Jun 2011 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.613 X-Spam-Level: X-Spam-Status: No, score=-3.613 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJuETkRQ3UrG for ; Mon, 13 Jun 2011 10:40:53 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4579111E80A9 for ; Mon, 13 Jun 2011 10:40:53 -0700 (PDT) Received: by gxk19 with SMTP id 19so4194356gxk.31 for ; Mon, 13 Jun 2011 10:40:52 -0700 (PDT) Received: by 10.91.121.20 with SMTP id y20mr5757768agm.5.1307986852610; Mon, 13 Jun 2011 10:40:52 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id u64sm2917865yhm.41.2011.06.13.10.40.50 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 10:40:50 -0700 (PDT) Received: by yxt33 with SMTP id 33so854551yxt.31 for ; Mon, 13 Jun 2011 10:40:50 -0700 (PDT) Received: by 10.91.100.2 with SMTP id c2mr3212633agm.179.1307986850068; Mon, 13 Jun 2011 10:40:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 10:40:20 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Mon, 13 Jun 2011 10:40:20 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:40:54 -0000 On Fri, May 27, 2011 at 10:24 PM, Mark Nottingham wrote: > A bit late to the party, but FWIW I like this document. Thanks. > It brings two questions to mind, however: > > * Currently, HTTPbis ticket 270 [1] moves the details of the Upgrade proc= ess in HTTP to p2-semantics [2], which "updates" (not obsoletes) RFC2817 [3= ], the definition of how to upgrade to TLS within HTTP/1.1 (i.e., without c= hanging the scheme). I'm wondering if a stronger statement needs to be made= ; e.g., obsoleting 2817, or marking it historic. It may also be worth menti= oning in your draft as a bad practice. This was actually already in the document somewhat obliquely, but I've made it less oblique by adding a reference to RFC 2817. In some sense, it's not really RFC 2817's fault because if that had become popular, then the rest of the security model would have evolved in a different way. > * It doesn't mention CORS [4], which is a *much* more fine-grained (and a= s I've said many times, undesirably chatty) definition of a trust domain. S= houldn't there be some guidance the relationship between these different co= ncepts, when it's appropriate to use them, etc? I've added a reference to CORS. I don't want to go into too much detail, but explaining that servers can opt into sharing their content more widely seems valuable. Thanks! Adam > 1. > 2. > 3. > 4. > > > On 22/02/2011, at 9:10 AM, Adam Barth wrote: > >> Pursuant to the charter, I've posted an informational draft that >> "describes the same-origin security model overall:" >> >> http://www.ietf.org/id/draft-abarth-principles-of-origin-00.txt >> >> I don't expect this document to be very controversial. =A0I'm sure folks >> will nitpick me over renaming URL to URI and MIME types to media >> types, however. =A0:) >> >> Feedback welcome. >> >> Adam >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > -- > Mark Nottingham =A0 http://www.mnot.net/ > > > > From ietf@adambarth.com Mon Jun 13 10:58:56 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6032A11E80CE for ; Mon, 13 Jun 2011 10:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMuLzrHtYBb8 for ; Mon, 13 Jun 2011 10:58:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6122311E80AC for ; Mon, 13 Jun 2011 10:58:55 -0700 (PDT) Received: by gxk19 with SMTP id 19so4206015gxk.31 for ; Mon, 13 Jun 2011 10:58:54 -0700 (PDT) Received: by 10.236.79.134 with SMTP id i6mr978249yhe.75.1307987934746; Mon, 13 Jun 2011 10:58:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id w66sm2930392yhi.24.2011.06.13.10.58.53 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 10:58:53 -0700 (PDT) Received: by yxt33 with SMTP id 33so867869yxt.31 for ; Mon, 13 Jun 2011 10:58:53 -0700 (PDT) Received: by 10.91.100.2 with SMTP id c2mr3234134agm.179.1307987933259; Mon, 13 Jun 2011 10:58:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 10:58:21 -0700 (PDT) In-Reply-To: <4DE11C88.2090409@lookout.net> References: <4DE11C88.2090409@lookout.net> From: Adam Barth Date: Mon, 13 Jun 2011 10:58:21 -0700 Message-ID: To: Chris Weber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 17:58:56 -0000 On Sat, May 28, 2011 at 9:02 AM, Chris Weber wrote: > Some minor suggestions on section "5.2. =A0Network Access". > > =A0 "Access to network resources varies depending on whether the resource= s > =A0 are in the same origin as the document attempting to access them. > > =A0 Generally, reading information from another origin is forbidden." > > Based on the generality of the content that is allowed - images, script, > style sheets, it almost seems that the above sentence could be reversed t= o > say that "Generally, reading information from another origin is allowed." > =A0Otherwise, you could further demonstrate some of the cases where it is > generally forbidden, such as with XmlHttpRequest. The general case is that it is forbidden. It's only in the enumerated special cases that it is allowed. The number of enumerated cases isn't related to what happens in the general case. > =A0 "However, a document is permitted use some kinds of resources > =A0 retrieved from other origins. =A0For example, a document is permitted > =A0 to execute script, render images, and apply style sheets from any > =A0 origin. =A0Likewise, a document can display a document from another > =A0 origin in a frame." > > The notion of displaying a document in a frame may be misleading in the > context of this paragraph, given that the other examples grant full acces= s > to the creator document's DOM, while the document in the frame does not. That's not accurate. Rendering an image from another origin does not grant fully access to the creator document's DOM, nor does applying style sheets (in modern browsers). > =A0 "Generally, sending information to another origin is permitted. > =A0 However, sending information over the network in arbitrary formats is > =A0 dangerous. =A0For this reason, user agents restrict documents to > =A0 sending information using particular protocols, such as in an HTTP > =A0 request without custom headers." > > I'm feeling a bit hungry here, can you provide some more food for thought= ? > =A0Some simple examples may help. =A0I'm thinking of HTML's postMessage > interface and HTML forms. I added a sentence about the recent issues with WebSockets expanding the allowable set of things an origin can send. Thanks! Adam From ietf@adambarth.com Mon Jun 13 11:10:44 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1E021F84E0 for ; Mon, 13 Jun 2011 11:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3L3lIwkA1hZ for ; Mon, 13 Jun 2011 11:10:43 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E94F911E8103 for ; Mon, 13 Jun 2011 11:10:27 -0700 (PDT) Received: by yxt33 with SMTP id 33so876501yxt.31 for ; Mon, 13 Jun 2011 11:10:27 -0700 (PDT) Received: by 10.91.3.10 with SMTP id f10mr6617282agi.2.1307988627353; Mon, 13 Jun 2011 11:10:27 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id c21sm5849380ana.50.2011.06.13.11.10.26 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 11:10:26 -0700 (PDT) Received: by gxk19 with SMTP id 19so4213577gxk.31 for ; Mon, 13 Jun 2011 11:10:26 -0700 (PDT) Received: by 10.91.207.11 with SMTP id j11mr6643881agq.17.1307988625987; Mon, 13 Jun 2011 11:10:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 11:09:55 -0700 (PDT) In-Reply-To: <4DE11FB8.8050602@lookout.net> References: <4DE11FB8.8050602@lookout.net> From: Adam Barth Date: Mon, 13 Jun 2011 11:09:55 -0700 Message-ID: To: Chris Weber Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 18:10:45 -0000 On Sat, May 28, 2011 at 9:15 AM, Chris Weber wrote: > I wanted to suggest that section "3. Origin" include some examples presented > in a clear and explicit way, such as in a list. > > 3.1 Examples of Resources With the Same Origin > > All of the following resources can be said to have the same origin. > > http://example.com > http://example.com:80 > http://example.com/path/file > http://example.com > > In these cases each URI would be parsed into identical scheme, host, and > port components. > > > 3.2 Examples of Resources With Different Origin > > Each of the following resources can be said to have a different origin from > the others in this list. > > http://example.com > http://example.com:8080 > http://www.example.com > https://example.com:80 > https://example.com > http://google.com > http://ietf.org > > In each case at least one element from the URI scheme, host, and port > component will differ from the others in the list. Done. Thanks, Adam From julian.reschke@gmx.de Mon Jun 13 12:38:54 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890951F0C62 for ; Mon, 13 Jun 2011 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IspXkzYD5Zq9 for ; Mon, 13 Jun 2011 12:38:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8BDF51F0C5E for ; Mon, 13 Jun 2011 12:38:51 -0700 (PDT) Received: (qmail invoked by alias); 13 Jun 2011 19:38:49 -0000 Received: from p508FA89B.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.168.155] by mail.gmx.net (mp051) with SMTP; 13 Jun 2011 21:38:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5AIkNfMq5qAtGill2eY2LBGTIuzKOtRneqEEkdQ ZIfX6SByaCVy/4 Message-ID: <4DF66746.8090402@gmx.de> Date: Mon, 13 Jun 2011 21:38:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Adam Barth References: <4D66CC25.6070202@stpeter.im> <4DCCC54F.6090107@gondrom.org> <4DCCF025.3070702@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:38:54 -0000 On 2011-06-13 18:46, Adam Barth wrote: > On Fri, May 13, 2011 at 1:47 AM, Julian Reschke wrote: >> Terminology: replace "URL" by "URI" throughout. > > Done. > >> Replace "MIME type" by "media type" throughout. > > Done. > >> Add proper references. > > Which references would you like to see added? > ... I believe I was thinking that RFC 3986 and the MIME specs (RFC 2045 etc) should be cited... Best regards, Julian From ietf@adambarth.com Mon Jun 13 12:41:04 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3A011E80A1 for ; Mon, 13 Jun 2011 12:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM780KmkJrm0 for ; Mon, 13 Jun 2011 12:41:03 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7EA911E808C for ; Mon, 13 Jun 2011 12:41:03 -0700 (PDT) Received: by gxk19 with SMTP id 19so4272068gxk.31 for ; Mon, 13 Jun 2011 12:41:03 -0700 (PDT) Received: by 10.236.184.103 with SMTP id r67mr7742757yhm.254.1307994062833; Mon, 13 Jun 2011 12:41:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id g5sm2463087yhm.40.2011.06.13.12.41.01 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 12:41:01 -0700 (PDT) Received: by gxk19 with SMTP id 19so4272046gxk.31 for ; Mon, 13 Jun 2011 12:41:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.162.10 with SMTP id k10mr6792472age.125.1307994061173; Mon, 13 Jun 2011 12:41:01 -0700 (PDT) Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 12:41:01 -0700 (PDT) Received: by 10.90.36.10 with HTTP; Mon, 13 Jun 2011 12:41:01 -0700 (PDT) In-Reply-To: <4DF66746.8090402@gmx.de> References: <4D66CC25.6070202@stpeter.im> <4DCCC54F.6090107@gondrom.org> <4DCCF025.3070702@gmx.de> <4DF66746.8090402@gmx.de> Date: Mon, 13 Jun 2011 12:41:01 -0700 Message-ID: From: Adam Barth To: Julian Reschke Content-Type: multipart/alternative; boundary=00163630ed7762756004a59d19f7 Cc: websec@ietf.org Subject: Re: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin - until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 19:41:04 -0000 --00163630ed7762756004a59d19f7 Content-Type: text/plain; charset=ISO-8859-1 Will do. Thanks. Adam On Jun 13, 2011 12:38 PM, "Julian Reschke" wrote: > On 2011-06-13 18:46, Adam Barth wrote: >> On Fri, May 13, 2011 at 1:47 AM, Julian Reschke wrote: >>> Terminology: replace "URL" by "URI" throughout. >> >> Done. >> >>> Replace "MIME type" by "media type" throughout. >> >> Done. >> >>> Add proper references. >> >> Which references would you like to see added? > > ... > > I believe I was thinking that RFC 3986 and the MIME specs (RFC 2045 etc) > should be cited... > > Best regards, Julian --00163630ed7762756004a59d19f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Will do.=A0 Thanks.

Adam

On Jun 13, 2011 12:38 PM, "Julian Reschke&q= uot; <julian.reschke@gmx.de= > wrote:
> On 2011-06-13 18:46, Adam Barth wr= ote:
>> On Fri, May 13, 2011 at 1:47 AM, Julian Reschke<julian.reschke@gmx.de> wrote:
>>= > Terminology: replace "URL" by "URI" throughout. >>
>> Done.
>>
>>> Replace "MIME t= ype" by "media type" throughout.
>>
>> Don= e.
>>
>>> Add proper references.
>>
>&g= t; Which references would you like to see added?
> > ...
>
> I believe I was thinking that RFC 3986 and = the MIME specs (RFC 2045 etc)
> should be cited...
>
> = Best regards, Julian
--00163630ed7762756004a59d19f7-- From Jeff.Hodges@KingsMountain.com Mon Jun 13 13:41:28 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1F21F84A6 for ; Mon, 13 Jun 2011 13:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.335 X-Spam-Level: X-Spam-Status: No, score=-101.335 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3M4icn-YCQsF for ; Mon, 13 Jun 2011 13:41:28 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 0C45721F84A4 for ; Mon, 13 Jun 2011 13:41:27 -0700 (PDT) Received: (qmail 4934 invoked by uid 0); 13 Jun 2011 20:41:27 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 13 Jun 2011 20:41:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=baphOGimHwCnbgZCeEoEPTjJaVNfsMtI0+zkmG24iJlS9CO+hsC8TppEgt/Y343Zks2PIL1/nqc7EbbZdU6M21gOzHy5clDCjWSdGrS6mwdFkGmvmlFsYUI6qi3wYzmJ; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.200]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QWDwt-0005HL-Gi for websec@ietf.org; Mon, 13 Jun 2011 14:41:27 -0600 Message-ID: <4DF675F7.2050603@KingsMountain.com> Date: Mon, 13 Jun 2011 13:41:27 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [websec] Comments on draft-abarth-principles-of-origin-00, was: Reviews of draft-ietf-websec-origin and principles-of-origin until end of May X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 20:41:28 -0000 Julian asked: > I believe that having two documents make sense; what's the benefit of > merging? Yes, I have the same question now (after belatedly reviewing the document in more detail). I'm thinking Principles of the Same-Origin Policy (PSOP) ought to be a separate doc, because it'll get referenced down the road specifically for this principle stuff, possibly by a wider range of docs than would reference the Origin header spec (which concerns a particular concrete facet of web platform machinery). I also think (on an admittedly quick re-skim) John Kemp's so-called "scope" comments are overall apropos -- I have many of the same thoughts.. Re: [websec] Principles of the Same-Origin Policy http://www.ietf.org/mail-archive/web/websec/current/msg00257.html You (Adam B) are writing from the perspective of one steeped in browser and web application internals, and seemingly for a similar audience it seems. However, I suspect this doc would likely get read by a wider audience, including those who are trying to learn (or write) about how this complex "web platform" beast works. HTH, =JeffH From Jeff.Hodges@KingsMountain.com Mon Jun 13 14:19:15 2011 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964E021F85B2 for ; Mon, 13 Jun 2011 14:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJPT4Tww+6YG for ; Mon, 13 Jun 2011 14:19:15 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by ietfa.amsl.com (Postfix) with SMTP id ED08321F85B1 for ; Mon, 13 Jun 2011 14:19:14 -0700 (PDT) Received: (qmail 29420 invoked by uid 0); 13 Jun 2011 21:19:14 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 13 Jun 2011 21:19:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gH66Ot2P2yIPwE9GiBg+uFl3bdNOPHQVNtH10N0gAfkCfUGzEOtkyyz9VAuN9O/H9dQDiqMh9vf7KlPXLZ2FqlZmBVlxrhwiWC89ndwHFRLTMuOvLtbnPVf8bFU2MTVx; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.200]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QWEXS-0001Tm-AM for websec@ietf.org; Mon, 13 Jun 2011 15:19:14 -0600 Message-ID: <4DF67ED2.9070005@KingsMountain.com> Date: Mon, 13 Jun 2011 14:19:14 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Principles of the Same-Origin Policy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 21:19:15 -0000 Adam Barth replied: > On Sat, May 28, 2011 at 9:02 AM, Chris Weber wrote: >> Some minor suggestions on section "5.2. Network Access". >> >> "Access to network resources varies depending on whether the resources >> are in the same origin as the document attempting to access them. >> >> Generally, reading information from another origin is forbidden." >> >> Based on the generality of the content that is allowed - images, script, >> style sheets, it almost seems that the above sentence could be reversed to >> say that "Generally, reading information from another origin is allowed." >> Otherwise, you could further demonstrate some of the cases where it is >> generally forbidden, such as with XmlHttpRequest. > > The general case is that it is forbidden. It's only in the enumerated > special cases that it is allowed. The number of enumerated cases > isn't related to what happens in the general case. I think it depends on one's perspective. Perhaps it's "generally" forbidden in browser internals, but if one's perspective is from within an HTML page, then heck, I can have ,