From y.oiwa@aist.go.jp Sun Jun 5 10:06:53 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@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: public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: [http-auth] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: HTTP authentication methods 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: http-auth@ietfa.amsl.com Delivered-To: http-auth@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 Cc: public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [http-auth] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods 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 Hannes.Tschofenig@gmx.net Mon Jun 6 03:09:17 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD711E8109 for ; Mon, 6 Jun 2011 03:09:17 -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 PnhM-kfEjR1a for ; Mon, 6 Jun 2011 03:09:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0BD2E11E80EC for ; Mon, 6 Jun 2011 03:09:15 -0700 (PDT) Received: (qmail invoked by alias); 06 Jun 2011 10:08:36 -0000 Received: from unknown (EHLO [10.255.135.94]) [192.100.123.77] by mail.gmx.net (mp059) with SMTP; 06 Jun 2011 12:08:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+oAo0oU8SoJg2JdIL24mDbKFbWVepWy36oFqzi1b qx5lAmAocu8vze Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> Date: Mon, 6 Jun 2011 11:30:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> To: http-auth@ietf.org, y.oiwa@aist.go.jp X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:09:17 -0000 Hi Yutaka,=20 it is definitely a good idea to get ourselves organized to continue our = work in securing the Web.=20 For me, the main questions are:=20 * What is the biggest problem?=20 You, for example, point to the usage of forms for user = authentication in Web pages in the agenda proposal. The NSTIC fans seem to believe that passwords are the problem to = begin with. =20 * What solution approach is most promising? (or multiple approaches) You seem to suggest to standardize a strong-password based = authentication mechanism in = http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 NSTIC fans seem to believe that the approach is towards stronger = credentials (non-password-based) and the usage of federated log-ins.=20 Again others believe that we will never agree on a single = authentication protocol and hence we need a framework that allows = passwords to be plugged in dynamically. Browser vendors are interested, as you may recall from the Identity = in the Browser discussion, in standardizing username/password form = indications so that the user does not need to type their username & = password too often into forms - but the browser does it instead.=20 * How do we motivate the different stakeholders to implement and deploy = our favorite solutions? (There is also the usability issue for the = user.) Whatever you come up with changes are needed on the client, and on = the server side. That requires a lot of cooperation. Ciao Hannes On Jun 5, 2011, at 8:06 PM, Yutaka OIWA wrote: > Dear all at http-auth mailing list, > (Cc: Peter, Sean, Harry, and related mailing lists subscribers) >=20 > 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 > . >=20 > # Harry, are the *output* materials of the workshop already available = to public? >=20 > 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. >=20 > Thanks, >=20 > Yutaka >=20 > --=20 > 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] > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From y.oiwa@aist.go.jp Mon Jun 6 08:33:04 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D49021F8478 for ; Mon, 6 Jun 2011 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.84 X-Spam-Level: X-Spam-Status: No, score=0.84 tagged_above=-999 required=5 tests=[AWL=0.930, 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 E2jdQcUpG-53 for ; Mon, 6 Jun 2011 08:33:02 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDAA21F8442 for ; Mon, 6 Jun 2011 08:33:02 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p56FWjLN026691; Tue, 7 Jun 2011 00:32:45 +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=1307374366; bh=FaYIzwbSV/7vEaxB8ij5UFeWgGjxujwlsyCQu3bA+K4=; h=From:Date:Message-ID; b=JMuT7/5+G2DJYF5ZcWHd9/fXvqevJTu7mUDREpCZryT7IhVgiI7VXI6sUMHotJuGA braed47C4OpGFMiPV6niiO8bYpOUGh3yG5Id++p7Samw0BYUOSwtbA+aacCHlR+p2t lOsY1Py08h0oaP9u1v1tsqd2m4D/QWycCClsOios= Received: from smtp3.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p56FWj3b012167; Tue, 7 Jun 2011 00:32:45 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp3.aist.go.jp with ESMTP id p56FWjtH016273; Tue, 7 Jun 2011 00:32:45 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: Hannes Tschofenig References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> From: Yutaka OIWA Date: Tue, 07 Jun 2011 00:32:44 +0900 In-Reply-To: (Hannes Tschofenig's message of "Mon\, 6 Jun 2011 11\:30\:48 +0300") Message-ID: <87pqmrdlgj.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: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 15:33:04 -0000 Dear Hannes, thank you for good questions. Hannes Tschofenig writes: > * What is the biggest problem? > You, for example, point to the usage of forms for user > authentication in Web pages in the agenda proposal. The NSTIC > fans seem to believe that passwords are the problem to begin > with. IMO, the main point is the lack of the protection for the authentication credentials, and the lack of the mutual agreement and assurance about authentication results. For the first point, in current technology, the passwords are almost used as a naked token (including the Digest authentication), which is too weak in current computation environment; there are no protection against steal by the communicated peer, no protection against forwarding, etc. I understand that there will be no single solution to solve the all problem, for example some high-secure applications such as NSTIC or corporate-value banking needs cryptographic strong credentials. But, at the same time, passwords are the only tokens which can be easily portable by human without help of mechanical storages. Both current federated ID management and cloud-based password management, or even issuing/managing client certificates online are relying on the password authentication in some form as a starting point. It is still worth to improve security of initial password authentication with those stories. For the second point, in many high-value applications the security (privacy) of the user-submitted data is equally or even more important as/than the integrity of client authorization (I do NOT mean that the latter is unimportant :-). Strong mutual authentication is a important key for this. Virtually all authentication technologies which are currently available to Web are weak in this aspect, including TLS client certificate authentication. I believe that even for non-password-based authentication this is important to be fixed. I currently do not have a proposal for those non-password stories, but we should really work on this, I believe. As I mentioned and promised in the previous Bar-BoF, my proposal can (and will) be separated to a core mutual authentication framework and a specific algorithm for password-based authentication. I welcome to use the framework part for mutually securing other types of authentications (if algorithmically applicable) as well as password authentications. It can also potentially provide shared keys for channel-binding for higher-layer applications. The third point, not mentioned earlier, is that all kinds of current authentication methods, both password- and non-password-based, are just hard to use compared to Form-based authentication. I'm also working on this "applicability" problem and proposing a solution. > * What solution approach is most promising? (or multiple approaches) > You seem to suggest to standardize a strong-password based > authentication mechanism in > http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 NSTIC > fans seem to believe that the approach is towards stronger > credentials (non-password-based) and the usage of federated > log-ins. Again others believe that we will never agree on a > single authentication protocol and hence we need a framework > that allows passwords to be plugged in dynamically. Browser > vendors are interested, as you may recall from the Identity in > the Browser discussion, in standardizing username/password form > indications so that the user does not need to type their > username & password too often into forms - but the browser does > it instead. I believe we need multiple approaches, depending on the nature of each specific application. In my opinion, password authentication and (better) certificate/private-key authentication are needed as starting points. I don't believe that current TLS client cert auth is the perfect solution for the latter, however. I also would like to see how they can be integrated with federated authentication mechanisms. Pluggable approaches need a little-bit careful consideration about the mutual influences of plug-ins against total security, but my proposal is actually going in that way in some aspects, as mentioned above. # I really want to see someone proposing a draft fixing the # certificate-based authentication to be more secure and useful :-) In my personal opinion, browser-assisted fill-ins are in a different layer, which means that we like to have both at the same time in the future. To easily use my proposed technology we need a good password managers, and to make the browser-stored password secure in all time, (I believe) we need a good underlying protocol e.g. for mutual assurance and portability. My personal intention to proposing BoF and a working group (if people agrees) is to solve the whole problems, not only our proposed ones. Currently I only have our draft to count on, but I really don't want to finish by standardizing ours only. # How should I write an agenda (or a proposed charter) in this situation? # "Start-then-recharter" approach will work? I don't know, however, how much extent of those can be worked on by our proposed group within next several seasons. I hope as much as possible :-) > * How do we motivate the different stakeholders to implement and > deploy our favorite solutions? (There is also the usability issue > for the user.) > Whatever you come up with changes are needed on the client, and > on the server side. That requires a lot of cooperation. This was (is) one of the most hard points for us (I believe not only for our group :-). But, for ensuring mutual authentication integrity, we need at some point to change both peers anyway. For the "technical" usability/deployability problem of the RFC 2617 HTTP authentication, we're actually proposing a solution for that. For gradual transition, our current proposal can be parallel-served with existing form-based authentication framework for transition periods. We also keep trying to keep contact with browser vendors, of course. -- 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 tim-research@sentinelchicken.org Mon Jun 6 10:03:00 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35411E819F for ; Mon, 6 Jun 2011 10:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Fx2qpHuV0C2w for ; Mon, 6 Jun 2011 10:02:59 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 38D4311E81AD for ; Mon, 6 Jun 2011 10:02:59 -0700 (PDT) Received: (qmail 5544 invoked from network); 6 Jun 2011 17:02:57 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jun 2011 17:02:57 -0000 Received: (qmail 5911 invoked from network); 6 Jun 2011 17:04:18 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jun 2011 17:04:18 -0000 Received: (nullmailer pid 7628 invoked by uid 1000); Mon, 06 Jun 2011 17:02:56 -0000 Date: Mon, 6 Jun 2011 10:02:56 -0700 From: Tim To: Hannes Tschofenig Message-ID: <20110606170256.GF1565@sentinelchicken.org> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 17:03:00 -0000 Hi everyone, I'm coming out of lurking-mode to offer some opinions on this. > * What solution approach is most promising? (or multiple approaches) > You seem to suggest to standardize a strong-password based authentication mechanism in http://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 > NSTIC fans seem to believe that the approach is towards stronger credentials (non-password-based) and the usage of federated log-ins. > Again others believe that we will never agree on a single authentication protocol and hence we need a framework that allows passwords to be plugged in dynamically. > Browser vendors are interested, as you may recall from the Identity in the Browser discussion, in standardizing username/password form indications so that the user does not need to type their username & password too often into forms - but the browser does it instead. In general authentication theory terms, using passwords is relying on "something you know" (SYK) whereas certificates rely on "something you have" (SYH). By moving toward password management in the browser, you turn something you know into something you have. The SYH solutions are very attractive from a security perspective and from a usability perspective. If it were sufficiently standardized, browsers can use certificates or random passwords for each site and users don't have to worry about it. (Of course once we move to a SYH password model, then what is the point in using passwords at all again?) However, SYK will always have a place in the world. There are many situations where users simply want to be able to type in something they've memorized. Passwords will never go away completely for this reason. Add into that the fact that far more average users understand username/password systems than certificates, and you will have a hard time convincing the world to switch off of passwords even in applications that would work prefectly well with SYH. To me, the best way forward is to offer seemless integration of SYH and SYK systems, both allowing for federated authentication and all of the advanced features everyone seems to want these days. If you convince application developers and browser vendors to switch to such a framework, then you also eliminate some barriers to entry for switching some sites and users to switch away from passwords (or at least user-chosen passwords). As a first step to this proposed master plan, the new SYK model must be more secure than what we are using now, in order to convince people to move away from web forms to the new system. Protecting against phishing attacks, which are rampant these days, is one great way to do that. tim From nico@cryptonector.com Mon Jun 6 11:37:32 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96AA11E8196 for ; Mon, 6 Jun 2011 11:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hQBrBW8NrQpF for ; Mon, 6 Jun 2011 11:37:32 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3087511E815E for ; Mon, 6 Jun 2011 11:37:32 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id A7F262F406D for ; Mon, 6 Jun 2011 11:37:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=BiqFiwmhhRoqcdP9g2EBV1KfBmbVoTlIcu6rtR1BAUbL Kr4pwX26j42XdOWjxoctDT459YlyviiZu8LWlbXl3AJznWwjxrz9d1gzcTyW/eiY VFCdWjmp+YAhadXTdc4eHBLvSVodIdRxscztOVNO33QeIFEKS9KHvdRkmI/QjAo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=2WERFm1/jbjRA8eB7HysrYVCr58=; b=Ku3drhWo3Eq gq9WoMRDGi6O2M5b9ftzBrlLLMARcW7w3olygQx5Jv2iqxsqCPq1EwQo/shCi/iO L2wx/VM0gSCZrIMl31H44hS93mr09OIu9NBdueuY1OLBtoGD3qhPycsMqzlZSOma LV+5ELBy6NSNJyH18Vn7gCPC4LNo/K98= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 744972F406A for ; Mon, 6 Jun 2011 11:37:31 -0700 (PDT) Received: by vws12 with SMTP id 12so3780352vws.31 for ; Mon, 06 Jun 2011 11:37:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.75.37 with SMTP id z5mr7411982vdv.261.1307385450536; Mon, 06 Jun 2011 11:37:30 -0700 (PDT) Received: by 10.52.112.163 with HTTP; Mon, 6 Jun 2011 11:37:30 -0700 (PDT) Date: Mon, 6 Jun 2011 13:37:30 -0500 Message-ID: From: Nico Williams To: http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [http-auth] REST-GSS I-D posted X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 18:37:33 -0000 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. Anyone interested? Cheers, Nico -- From nico@cryptonector.com Mon Jun 6 14:22:42 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF20511E81BB for ; Mon, 6 Jun 2011 14:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 sRFG77HHU80i for ; Mon, 6 Jun 2011 14:22:39 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3011E8175 for ; Mon, 6 Jun 2011 14:22:39 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 5257F1B405F for ; Mon, 6 Jun 2011 14:22:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=PX1SP74TJNwqilS2QfPvPlWu2sVruYL4v6+/kDIEMc+r 867I9B7y0ueN26f0aND8pdNvj2z8wLrQvL3+3MpHk8OIykHgyykNTAEX7Q5IypGx ZMhSnXyY8wJDofZBK1iE7GqlB+y91HXBGtxOyvphXii9iZ3kgqnsalpR+TBF6QE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=4UC4scKnEk6TY1qZgP1WRJBUBys=; b=sjj9Dj0GO1i LWQQ/IKIxgdet/LkevyHvxMskw7V9Qx+eseDofPZRwlGJ0ig+QeNQnJOtTev3ON2 4jlOOj2JOALOOYDAqtiC/zgL/6yjuAxIEatBbnhoDoAfni6+h9gww35t4NE0fWz/ 1+N5B/cdoDGa5NnHDFPFl1JENDVyB9uQ= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 1F9E31B4058 for ; Mon, 6 Jun 2011 14:22:36 -0700 (PDT) Received: by vws12 with SMTP id 12so3922729vws.31 for ; Mon, 06 Jun 2011 14:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.175.36 with SMTP id bx4mr2040734vdc.21.1307395355427; Mon, 06 Jun 2011 14:22:35 -0700 (PDT) Received: by 10.52.112.163 with HTTP; Mon, 6 Jun 2011 14:22:35 -0700 (PDT) In-Reply-To: <20110606170256.GF1565@sentinelchicken.org> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <20110606170256.GF1565@sentinelchicken.org> Date: Mon, 6 Jun 2011 16:22:35 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 21:22:42 -0000 On Mon, Jun 6, 2011 at 12:02 PM, Tim wro= te: > In general authentication theory terms, using passwords is relying on > "something you know" (SYK) whereas certificates rely on "something you > have" (SYH). =C2=A0By moving toward password management in the browser, y= ou > turn something you know into something you have. Well, I wouldn't call that "general authentication theory" :) Passwords are either something you know, or something you have, or even both. Because let's face it: users can (and do!) write passwords down, and as soon as they are written down they become "something you have". Also, password managers typically have a master password, so, what's, uh the deal? It strikes me as silly to say that passwords are something you know, as if users might never write them down. Indeed, nowadays some security experts urge users to write their passwords down as a way to enable stronger passwords -- not a bad idea, IMO. A bigger problem with passwords as something you have is the need to carry them. If they're in a browser password manager, well, we need a way to export (and import) the thing. Also, there's no way to securely use a password manager on an untrusted system (or, for that matter, to securely use a password on an untrusted system). In other words, this is hardly the biggest problem we have. The biggest problems we have, IMO, are: - local security (malware) - the lack of strong authentication protocols on the web - the lack of mutual authentication (TLS server certs don't cut it) I'd be perfectly happy with passwords if we had ZKPPs or strengthened password protocols. But we don't. DIGEST doesn't cut it, and we have not much else on the web, not with mutual authentication anyways. > The SYH solutions are very attractive from a security perspective and > from a usability perspective. =C2=A0If it were sufficiently standardized, > browsers can use certificates or random passwords for each site and > users don't have to worry about it. (Of course once we move to a SYH > password model, then what is the point in using passwords at all > again?) Passwords do have the benefit that they work everywhere. Smartcards requre that they be carried around. Fortunately users now have powerful computers with them at all times (i.e., mobile phones). Unfortunately these are powerful computers, with all attendant local security problems. (Also, not everyone carries their phones with them at all times. My daughter certainly doesn't, for example. So we need to be careful here.) > However, SYK will always have a place in the world. =C2=A0There are many > situations where users simply want to be able to type in something > they've memorized. =C2=A0Passwords will never go away completely for this > reason. =C2=A0Add into that the fact that far more average users understa= nd > username/password systems than certificates, and you will have a hard > time convincing the world to switch off of passwords even in > applications that would work prefectly well with SYH. One could always used passwords to authenticate to an online CA or keystore (think SACRED). > To me, the best way forward is to offer seemless integration of SYH > and SYK systems, both allowing for federated authentication and all of > the advanced features everyone seems to want these days. =C2=A0If you > convince application developers and browser vendors to switch to such > a framework, then you also eliminate some barriers to entry for > switching some sites and users to switch away from passwords (or at > least user-chosen passwords). I proposed an authentication framework (based on existing ones) two weeks ago. It turns out that even when there's no fundamental objections to a proposal (or even any objections at all), the fact is that it's hard to get momentum going for any real solutions if those would require either significant investment or just significant re-thinking, or any sort of leap-of-faith. (For example, in my proposal there's a leap-of-faith that not only will mutual authentication help, but that it's feasible to have such a thing on an Internet scale. I don't have proof either way -- it's just a conjecture, though many of us believe that it is correct, but that may not be enough. For another example, I believe my proposal is relatively simple to implement, but I've to convince others of this, and that, for the moment, seems difficult. This is not a complaint -- it is an illustration of the difficulty in achieving change here. Lots of smart people have been working on these problems for many years, and yet we're still more or less stuck with mid-90s technology -- it's not for want of effort or good ideas, but that momentum is difficult to change.) > As a first step to this proposed master plan, the new SYK model must > be more secure than what we are using now, in order to convince people > to move away from web forms to the new system. =C2=A0Protecting against > phishing attacks, which are rampant these days, is one great way to do > that. How would you protect against phishing attacks via a new authentication system? I'm serious. I believe it's possible to improve the situation significantly that way, and I have my reasons, but I want to hear yours. Nico -- From nico@cryptonector.com Mon Jun 6 14:44:53 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40A21F8461 for ; Mon, 6 Jun 2011 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Ycqhq+8Zj8-S for ; Mon, 6 Jun 2011 14:44:52 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2791521F8460 for ; Mon, 6 Jun 2011 14:44:52 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id E9CB9428079 for ; Mon, 6 Jun 2011 14:44:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=qrBK0QbHJBWkeJ8CmZhqR/memss4rll5squ8sTQFiT7w NjVVki6B5xX8fja63azSw7m6K97rD5jkRiJah3TZo3Q0U8WkZqDiUziBB3bpLa2I xeUYs7N8MUhJlWQefSHp0zcsitg+cHZ/Oo+juVKfrwdnkz6F7CO2LzU6WxwSMsA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=8Kb6VeLiypfRafTcgEWsu2aH8k8=; b=Z1pBXZKg/3T 8DkbgDrp7+ojd7hfklKZftZ6iGhRgfM4DK3bMNRj/r3WqizVU7eekPS04qRE41XS xLYzTd/2Y8HjB4GajGsGUj0P4aPkEUv/soW7MN1JJ5c917GqmcMsgidVitPCkTcD uwTLBeFIFjYKYUKykempHzsj1MphC1/I= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id A7251428078 for ; Mon, 6 Jun 2011 14:44:51 -0700 (PDT) Received: by vxg33 with SMTP id 33so3941770vxg.31 for ; Mon, 06 Jun 2011 14:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.75.37 with SMTP id z5mr7678139vdv.261.1307396691061; Mon, 06 Jun 2011 14:44:51 -0700 (PDT) Received: by 10.52.112.163 with HTTP; Mon, 6 Jun 2011 14:44:51 -0700 (PDT) In-Reply-To: References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> Date: Mon, 6 Jun 2011 16:44:51 -0500 Message-ID: From: Nico Williams To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 21:44:53 -0000 On Mon, Jun 6, 2011 at 3:30 AM, Hannes Tschofenig wrote: > For me, the main questions are: > > =C2=A0* What is the biggest problem? > =C2=A0 =C2=A0You, for example, point to the usage of forms for user authe= ntication in Web pages in the agenda proposal. > =C2=A0 =C2=A0The NSTIC fans seem to believe that passwords are the proble= m to begin with. You know from the workshop that my view is that web authentication should be pluggable with respect to authentication mechanisms. Passwords are a HUGE problem if you must type them at untrusted entities. (Such as: kiosks, hotel business center desktops, other people's laptops, or even pretty much any computer, given the current state of local security on user desktops and, soon, if not already, mobiles. But also: untrusted web page forms -- the fact that TLS server certs are used, when they are, is not enough.) > =C2=A0* What solution approach is most promising? (or multiple approaches= ) > =C2=A0 =C2=A0 You seem to suggest to standardize a strong-password based = authentication mechanism in http://tools.ietf.org/html/draft-oiwa-http-mutu= alauth-05 > =C2=A0 =C2=A0 NSTIC fans seem to believe that the approach is towards str= onger credentials (non-password-based) and the usage of federated log-ins. > =C2=A0 =C2=A0 Again others believe that we will never agree on a single a= uthentication protocol and hence we need a framework that allows passwords = to be plugged in dynamically. > =C2=A0 =C2=A0 Browser vendors are interested, as you may recall from the = Identity in the Browser discussion, in standardizing username/password form= indications =C2=A0so that the user does not need to type their username & = password too often into forms - but the browser does it instead. My proposal: http://www.w3.org/2011/identity-ws/slides/Williams.pdf http://www.ietf.org/id/draft-williams-rest-gss-00.txt http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_16.pdf > =C2=A0* How do we motivate the different stakeholders to implement and de= ploy our favorite solutions? (There is also the usability issue for the use= r.) > =C2=A0 =C2=A0Whatever you come up with changes are needed on the client, = and on the server side. That requires a lot of cooperation. I'm trying... I'm looking for: people who will want to implement one aspect or another of REST-GSS because it successfully addresses immediate problems for them (this would be, mostly, non-browser HTTP-based applications and the server side of those). I'm also trying other angles. But my approaches may be all wrong. So I too want to hear your opinions on how to get momentum going. One possibility is to build consensus in the IETF and push the W3C from there. I'm not sure that's wise. I think the best approach, for now, is to demo solutions. Since all solutions pretty much require new UIs (and JavaScript APIs) in the browsers, we need to start by implementing demos in the browsers themselves, now. Finally, the incipient JavaScript crypto APIs will be successful in that they will be widely popular. They will not solve the real problems because either users will still be typing secrets at untrusted interfaces (scripts used by untrusted pages) or because there will be no simple way to control access to cryptographic material in software or hardware tokens/smartcards. But I'm afraid that the appearance of success will be enough to staunch progress in any other areas, so it may be a now-or-never situation for any alternatives other than JavaScript crypto APIs. Nico -- From tim-research@sentinelchicken.org Mon Jun 6 15:11:06 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380D111E80F9 for ; Mon, 6 Jun 2011 15:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 NEzwj7F0Eq1r for ; Mon, 6 Jun 2011 15:11:05 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEDA11E8073 for ; Mon, 6 Jun 2011 15:11:05 -0700 (PDT) Received: (qmail 6607 invoked from network); 6 Jun 2011 22:11:04 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Jun 2011 22:11:04 -0000 Received: (qmail 9536 invoked from network); 6 Jun 2011 22:12:24 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 Jun 2011 22:12:24 -0000 Received: (nullmailer pid 9201 invoked by uid 1000); Mon, 06 Jun 2011 22:11:03 -0000 Date: Mon, 6 Jun 2011 15:11:03 -0700 From: Tim To: Nico Williams Message-ID: <20110606221103.GG1565@sentinelchicken.org> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <20110606170256.GF1565@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 22:11:06 -0000 I don't necessarily disagree with many of the things you mentioend (that i've cut). > Passwords do have the benefit that they work everywhere. Smartcards > requre that they be carried around. This is the point I was trying to get at. Until the typical user has a brain implant to handle digital signatures, there will be a place for methods of authentication that don't require hardware. (And even then...) > Fortunately users now have powerful computers with them at all times > (i.e., mobile phones). Unfortunately these are powerful computers, > with all attendant local security problems. (Also, not everyone > carries their phones with them at all times. My daughter certainly > doesn't, for example. So we need to be careful here.) Yes, I think the case for SYH is becoming more and more strong with the way portable devices are going, but there's just so much legacy... > I proposed an authentication framework (based on existing ones) two > weeks ago. It turns out that even when there's no fundamental > objections to a proposal (or even any objections at all), the fact is > that it's hard to get momentum going for any real solutions if those > would require either significant investment or just significant > re-thinking, or any sort of leap-of-faith. (For example, in my > proposal there's a leap-of-faith that not only will mutual > authentication help, but that it's feasible to have such a thing on an > Internet scale. I don't have proof either way -- it's just a > conjecture, though many of us believe that it is correct, but that may > not be enough. For another example, I believe my proposal is > relatively simple to implement, but I've to convince others of this, > and that, for the moment, seems difficult. This is not a complaint -- > it is an illustration of the difficulty in achieving change here. > Lots of smart people have been working on these problems for many > years, and yet we're still more or less stuck with mid-90s technology > -- it's not for want of effort or good ideas, but that momentum is > difficult to change.) Agreed. One of the problems is that there are so many proposals. I can't keep up with them all. I live and breathe web security, but I don't have time to read up on all of the new stuff until a customer actually implements something and I'm asked to test it. For the average developer, figuring out which to use is just as difficult, if not more difficult. In my experience, new technologies are most commonly adopted because they fill a need and they have a low implementation cost, not because they are the best all-around solution. Understanding how a technology works is part of the implementation cost. If you put out the most secure, most feature rich, and most efficient protocol possible, it probably won't be adopted if it isn't super easy to understand, implement, etc. For a guy like me, who spends most of his time in the trenches, it seems like the best approach is to have a firm idea of where you want to go with your framework, but release it in small digestable pieces. For instance, authentication protocols that can be used in very specific scenarios (e.g. one that replaces basic/digest auth, another that improves on client certificates, etc). > How would you protect against phishing attacks via a new > authentication system? I'm serious. I believe it's possible to > improve the situation significantly that way, and I have my reasons, > but I want to hear yours. Well, we've discussed this in the past, and agreed essentially that: 0. We must assume that users will fail to validate the trust of the domain they are visiting (definition of typical phishing attack) 1. Authentication must be conducted outside of the web page, since that will be attacker-controlled. Proposals have been to include it in the browser "chrome", but OS-level authentication could work as well. It is essential that whatever is selected as a GUI widget must not be easily spoofable through fancy web features. 2. In the case of password authentication, the server must prove it knows the password as well. This is what HTTP Mutual can accomplish, though other protocols can accomplish it as well (TLS SRP?) Note that this doesn't eliminate all phishing attack vectors. An attacker could still phish someone by convincing them to hand out their personal information outside of an authenticated session. Is there something I'm missing? tim From marsh@extendedsubset.com Mon Jun 6 15:33:45 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D389B11E811A for ; Mon, 6 Jun 2011 15:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0CqjB7a+EglC for ; Mon, 6 Jun 2011 15:33:45 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id EBAD511E8073 for ; Mon, 6 Jun 2011 15:33:44 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QTiMh-000LCU-J0; Mon, 06 Jun 2011 22:33:43 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C033C6067; Mon, 6 Jun 2011 22:33:41 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/+NvJcHwX4kcJtWOnfmQbYWf4QgLlCZNU= Message-ID: <4DED55C5.1010306@extendedsubset.com> Date: Mon, 06 Jun 2011 17:33:41 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 22:33:46 -0000 On 06/06/2011 04:44 PM, Nico Williams wrote: > But I'm afraid > that the appearance of success will be enough to staunch progress in > any other areas, so it may be a now-or-never situation for any > alternatives other than JavaScript crypto APIs. Don't worry about it, they're not going to work even that well. They wouldn't have stopped the government of Tunisia from MitMing Facebook and inserting Javascript to modify the behavior of the page. They wouldn't have stopped the government of Syria from using a BlueCoat to perform SSL MitM on Facebook with a bogus self-signed cert either. Both governments were arresting and shooting their citizens and hacking their Facebook credentials. Interestingly, Tunisia controls a trusted root CA but didn't bother to use it. Syria doesn't control a widely trusted CA, but doesn't seem to need it either. Sooner or later, people will tire of security theater. We can just try to have the best options available when they do. - Marsh From nico@cryptonector.com Mon Jun 6 16:30:28 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7381F0C50 for ; Mon, 6 Jun 2011 16:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 HElUuM5BIfy9 for ; Mon, 6 Jun 2011 16:30:27 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3578D1F0C4E for ; Mon, 6 Jun 2011 16:30:27 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 011AD598065 for ; Mon, 6 Jun 2011 16:30:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XSjVduDafyOZYra8vDYYte0Fczo5dhTMD+UtOgjotsRV 2900J/sGDxrDOlzgQzY361FIXDco9L5F8I1knDie4vg4ZvuWFQwiW9kadY9C1sa5 8DREoAzjKteV43WtAkXzOm1/UbiMN5GMsAE8BKJ81QMW4eGwCbBC/fwIpppNuF0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=uqVwQBsAa9Xiv5R2L96JUgVjZdo=; b=i6WDrrhL/7n NPfKPpPsBmjMF3l1ytyexLKD1qt9xjlMH5p+EKmYgSv/kPMpuAbWUOuXGtvyl2Uo GxxOGrHA033KrEphvbVcvwpb8xtQJ1WuHDVsCPcCePBDiH1CkiMA5xmvesW/HzFf /5c61fQKVN/01ZGKA+lLzDPh80QS4fI8= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id D8374598057 for ; Mon, 6 Jun 2011 16:30:26 -0700 (PDT) Received: by pwi5 with SMTP id 5so2636361pwi.31 for ; Mon, 06 Jun 2011 16:30:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr2240088pbj.456.1307403026546; Mon, 06 Jun 2011 16:30:26 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Mon, 6 Jun 2011 16:30:26 -0700 (PDT) In-Reply-To: <20110606221103.GG1565@sentinelchicken.org> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <20110606170256.GF1565@sentinelchicken.org> <20110606221103.GG1565@sentinelchicken.org> Date: Mon, 6 Jun 2011 18:30:26 -0500 Message-ID: From: Nico Williams To: Tim Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:30:28 -0000 On Mon, Jun 6, 2011 at 5:11 PM, Tim wrot= e: > Agreed. =C2=A0One of the problems is that there are so many proposals. = =C2=A0I > can't keep up with them all. =C2=A0I live and breathe web security, but I > don't have time to read up on all of the new stuff until a customer > actually implements something and I'm asked to test it. > > For the average developer, figuring out which to use is just as > difficult, if not more difficult. We have fundamentally the following choices: - new TLS auth methods (but... how to upgrade existing TLS firmware, ...?) - new HTTP auth methods (but... how to upgrade the many HTTP stacks?) - new HTTP redirect-based authentication methods (with all the problems those entail) - new auth methods based on TLS user (and server?) certs, such as downloading keys and certs via SACRED, getting short-lived certs from onine CAs (to which one authenticates via, say, a password-based method), or via registration of random self-signed certs (where one uses a password-based method, say, to authenticate in the cert registration protocol) - application-layer auth methods - ?? (out-of-band authentication?) My proposal is to do authentication at the application layer. In most other Internet protocols that's _exactly_ what we do: authentication at the application layer. What we can't do is transport protection at the application layer (for practical reasons as well as because of existing investments in TLS concentrators, etcetera) -- so enter channel binding (see RFCs 5056 and 5929). > In my experience, new technologies are most commonly adopted because > they fill a need and they have a low implementation cost, not because > they are the best all-around solution. =C2=A0Understanding how a technolo= gy > works is part of the implementation cost. =C2=A0If you put out the most > secure, most feature rich, and most efficient protocol possible, it > probably won't be adopted if it isn't super easy to understand, > implement, etc. I believe application-layer authentication can fulfill this because no changes are required to the existing TLS and HTTP stacks. > For a guy like me, who spends most of his time in the trenches, it > seems like the best approach is to have a firm idea of where you want > to go with your framework, but release it in small digestable pieces. > For instance, authentication protocols that can be used in very > specific scenarios (e.g. one that replaces basic/digest auth, another > that improves on client certificates, etc). What if the authentication mechanisms exist, but you're only just awaiting for a way to use them in this one class of applications? >> How would you protect against phishing attacks via a new >> authentication system? =C2=A0I'm serious. =C2=A0I believe it's possible = to >> improve the situation significantly that way, and I have my reasons, >> but I want to hear yours. > > Well, we've discussed this in the past, and agreed essentially that: > > 0. We must assume that users will fail to validate the trust of the > =C2=A0 domain they are visiting (definition of typical phishing attack) Yes! This means that whatever authentication method you use to authenticate the user MUST also authenticate the server. And, because we'll have TLS around forever, we must have channel binding of authentication to the TLS channel. > 1. Authentication must be conducted outside of the web page, since > =C2=A0 that will be attacker-controlled. =C2=A0Proposals have been to inc= lude > =C2=A0 it in the browser "chrome", but OS-level authentication could work > =C2=A0 as well. =C2=A0It is essential that whatever is selected as a GUI = widget > =C2=A0 must not be easily spoofable through fancy web features. Yes! See Sam Hartman's presentation from the W3C workshop two weeks ago. > 2. In the case of password authentication, the server must prove it > =C2=A0 knows the password as well. =C2=A0This is what HTTP Mutual can > =C2=A0 accomplish, though other protocols can accomplish it as well (TLS > =C2=A0 SRP?) Yes! This is really just a restatement of the mutual authentication requirement that you implied above. > Note that this doesn't eliminate all phishing attack vectors. =C2=A0An > attacker could still phish someone by convincing them to hand out their > personal information outside of an authenticated session. Phishing attacks depend on the fact that humans are susceptible to cons. We can't prevent people for falling to cons. HOWEVER, we may be able to make some (not all) classes of phishing and MITM attacks much harder, or impossible -- I believe that we can. > Is there something I'm missing? Channel binding :) Nico -- From nico@cryptonector.com Mon Jun 6 16:32:46 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF941F0C50 for ; Mon, 6 Jun 2011 16:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 dLtavsMlS3Il for ; Mon, 6 Jun 2011 16:32:46 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 33FF01F0C4F for ; Mon, 6 Jun 2011 16:32:46 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 0DD5C678063 for ; Mon, 6 Jun 2011 16:32:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=yFeFLegCwWdxSUZ/j759jq5LtcHSQY+uxKtbv8graIoI UqLhGd06q5opkMteWeHL5XbRaOG5voxUteIy6V/P7hWczYa0rUHOL2VReWNVTS4j cT7S2coH7vP6oiO11+ORAFhNLwWJ43jNvEYMG5uGjq9iEAYYXDrUkvAKlyLkPlc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=WHMQNQVQUT7m8K9Abf+cGOWkuks=; b=XCKoqLbxV+V GGrnhUyJhmHp/yQVscg21zfH758JHwUzepAOwY2SoL8MhBWA6gfE2AKGJYfqyXNT nusMU3cahBMQynp2gag3PBNh8ki0lI4+tiZxiD+Mof03V0VaZjvsf5fTa8IIDA6/ 52Dqj1SJiydMf0h7vH1V0yj80rzAH81o= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id E883F678062 for ; Mon, 6 Jun 2011 16:32:45 -0700 (PDT) Received: by pzk5 with SMTP id 5so2405283pzk.31 for ; Mon, 06 Jun 2011 16:32:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr2178038pbe.121.1307403165618; Mon, 06 Jun 2011 16:32:45 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Mon, 6 Jun 2011 16:32:45 -0700 (PDT) In-Reply-To: <4DED55C5.1010306@extendedsubset.com> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <4DED55C5.1010306@extendedsubset.com> Date: Mon, 6 Jun 2011 18:32:45 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 23:32:47 -0000 On Mon, Jun 6, 2011 at 5:33 PM, Marsh Ray wrote: > On 06/06/2011 04:44 PM, Nico Williams wrote: >> >> =C2=A0But I'm afraid >> that the appearance of success will be enough to staunch progress in >> any other areas, so it may be a now-or-never situation for any >> alternatives other than JavaScript crypto APIs. > > Don't worry about it, they're not going to work even that well. I know they won't work. That's not my fear. My fear is that they will seem to be enough of an improvement over the current mess that we declare victory and go home, leaving us with a serious failure. > They wouldn't have stopped the government of Tunisia from MitMing Faceboo= k > and inserting Javascript to modify the behavior of the page. They wouldn'= t > have stopped the government of Syria from using a BlueCoat to perform SSL > MitM on Facebook with a bogus self-signed cert either. Right. > Both governments were arresting and shooting their citizens and hacking > their Facebook credentials. Interestingly, Tunisia controls a trusted roo= t > CA but didn't bother to use it. Syria doesn't control a widely trusted CA= , > but doesn't seem to need it either. > > Sooner or later, people will tire of security theater. We can just try to > have the best options available when they do. Having them available means having implementations and deployments of code done. That's also the hardest part. Nico -- From stephen.farrell@cs.tcd.ie Mon Jun 6 17:20:37 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9760F21F84BE for ; Mon, 6 Jun 2011 17:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 RbQoKrSShBBO for ; Mon, 6 Jun 2011 17:20:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF6321F845E for ; Mon, 6 Jun 2011 17:20:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A8371153D31; Tue, 7 Jun 2011 01:20:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307406026; bh=lkU/jTYVv9dg+8 tN7lxb6xA8CJ3UE+UqicuqYAdQFLM=; b=4qZ2oH21Q/ZAfOYldA2yG0LeX9TNv+ S85WIGv6Y1W88spQJ+oJDGHrqnYkVuol0w6wgXyxKnNn2JwoCx6vUdT2s3XRXNhG dBOJKjhi2DAgDIab6fQIASk+gVr51Byq7aevfj4FNTgHzbVxdPD7ba5f9PZQx648 tiMNJM83HLf1H1XWmaUS+fZnbiDIrOyTlS3LG3QyVFvVWVU+RlQ9AGeOOOvQ9FfC n+YqXMKnse15unyIIQDuHr6cjylFgpGicM3/8CKZqCLpjseIghYQafFB3ym0b3OY aGmJeBpLT59GUwb59XZzePJXywe7g892zm6uiy3aQ2RZzc6GUHOvcjZQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id FxquTupD2Oti; Tue, 7 Jun 2011 01:20:26 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.20.46]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id ECE2D153D2F; Tue, 7 Jun 2011 01:20:25 +0100 (IST) Message-ID: <4DED6EC9.4040300@cs.tcd.ie> Date: Tue, 07 Jun 2011 01:20:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marsh Ray References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <4DED55C5.1010306@extendedsubset.com> In-Reply-To: <4DED55C5.1010306@extendedsubset.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 00:20:37 -0000 Hiya, On 06/06/11 23:33, Marsh Ray wrote: > On 06/06/2011 04:44 PM, Nico Williams wrote: >> But I'm afraid >> that the appearance of success will be enough to staunch progress in >> any other areas, so it may be a now-or-never situation for any >> alternatives other than JavaScript crypto APIs. > > Don't worry about it, they're not going to work even that well. Just trying to understand this. Why won't what work well? (Compared to Tom, Dick and Harry each doing the same thing in their own favourite way?) Seriously - I think it'll be useful to know/document the limitations of this approach of developing a standard JS crypto API. S. From nico@cryptonector.com Mon Jun 6 18:33:37 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D4E11E8096 for ; Mon, 6 Jun 2011 18:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 4Nc8oJJiDhY3 for ; Mon, 6 Jun 2011 18:33:37 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 48FFD11E8090 for ; Mon, 6 Jun 2011 18:33:37 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id E036E674070 for ; Mon, 6 Jun 2011 18:33:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Vk2ArZ9KWY0ErYrnU+RovvXTKJyn/Tdipwg4W6/2lbEp TVbSJCYPc7gbjyATnP7ygNXQXo6+7O1c0Yj9AvKvXpRvxnWyUBWuBucpigF1QVKi 0z4SyIypmdTKzIVglCIge/Gy1Mbo4FdkgnBox4+QQa2vQHaPgSHgpGSigzvX4/8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=CNmv5n+ONoQO/1Om7dO1XZR2nO4=; b=yAmsdKE9Xg+ JojfRzXclhL6vNEwxdtnfuHMLQt78r0941u8scy8mvJeplL23GfTgibJtqYJ5Dzx VIs1IOVvKhqdSE/Onqt2I++vxBlP+jy2+nLhtxjG6fdlM34zphyMACa5BuFW7PXZ 5bUXptrt5EgROf1n45K/U0jgSU0TkAks= Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id CF0F9674060 for ; Mon, 6 Jun 2011 18:33:36 -0700 (PDT) Received: by pxi20 with SMTP id 20so3651402pxi.27 for ; Mon, 06 Jun 2011 18:33:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr26398pbc.523.1307410416396; Mon, 06 Jun 2011 18:33:36 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Mon, 6 Jun 2011 18:33:36 -0700 (PDT) In-Reply-To: <4DED6EC9.4040300@cs.tcd.ie> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <4DED55C5.1010306@extendedsubset.com> <4DED6EC9.4040300@cs.tcd.ie> Date: Mon, 6 Jun 2011 20:33:36 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 01:33:37 -0000 On Mon, Jun 6, 2011 at 7:20 PM, Stephen Farrell wrote: > On 06/06/11 23:33, Marsh Ray wrote: >> On 06/06/2011 04:44 PM, Nico Williams wrote: >>> =C2=A0But I'm afraid >>> that the appearance of success will be enough to staunch progress in >>> any other areas, so it may be a now-or-never situation for any >>> alternatives other than JavaScript crypto APIs. >> >> Don't worry about it, they're not going to work even that well. > > Just trying to understand this. Why won't what work well? > (Compared to Tom, Dick and Harry each doing the same thing > in their own favourite way?) People are already using JavaScript crypto algorithm implementations. A crypto library implemented by the browsers themselves will at least get the crypto algorithms right and perform better. On the other hand, a JS crypto API cannot prevent misuse of cryptographic algorithms, nor can it do about the fact that it will be used from untrusted scripts. Regarding that last point, suppose a JS crypto API included a PKCS#11-like interface to access a "token" (a smartcard, effectively, either in the browser chrome, or an actual, hardware smartcard)... with such a thing one could prevent untrusted scripts from reading secret keys, but not from _using_ them because the browser will not have enough context to explain what's happening to the user, nor will the user be able to decide for themselves whether they should or should not allow a given script to use a given key. But a JS crypto API can be delivered relatively quickly, and thus it will seem like an accomplishment. It might be a while before consensus develops that indeed, a JS crypto API wasn't much of a solution. > Seriously - I think it'll be useful to know/document the > limitations of this approach of developing a standard > JS crypto API. See above. I said as much at the W3C workshop two weeks ago. The minutes, last I looked, record the fact that there was consensus for adding such APIs, not that there was loud grumbling about their dangers. Nico -- From marsh@extendedsubset.com Mon Jun 6 19:16:53 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5485B11E80A2 for ; Mon, 6 Jun 2011 19:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 QGVQ-tLeKUJ4 for ; Mon, 6 Jun 2011 19:16:52 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id B877411E80A3 for ; Mon, 6 Jun 2011 19:16:52 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QTlqd-000Az6-Vg; Tue, 07 Jun 2011 02:16:52 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 55F22606D; Tue, 7 Jun 2011 02:16:50 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+hhkJdfxLl6HX3XK5BAnZF2aftHYnTZLQ= Message-ID: <4DED8A12.7020305@extendedsubset.com> Date: Mon, 06 Jun 2011 21:16:50 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <4DED55C5.1010306@extendedsubset.com> <4DED6EC9.4040300@cs.tcd.ie> In-Reply-To: <4DED6EC9.4040300@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 02:16:53 -0000 On 06/06/2011 07:20 PM, Stephen Farrell wrote: > > On 06/06/11 23:33, Marsh Ray wrote: >> >> Don't worry about it, they're not going to work even that well. > > Just trying to understand this. Why won't what work well? Well you can probably make the math more efficient. You could certainly improve on the crypto handling ability of a language like Javascript which has neither secure memory overwrite nor constant time comparison operations. But is there any plausible attack scenario where crypto in the web page adds meaningful security? I don't think so. Either: A. TLS is correctly securing the connection, in which case you could just as easily ship the plaintext to the server, or B. TLS is not present or ineffective, in which case it's the attacker who controls what script is running in the page to such an extent that it's not even worth discussing distinctions in the degree of the compromise. I.e., pwned. > (Compared to Tom, Dick and Harry each doing the same thing > in their own favourite way?) > > Seriously - I think it'll be useful to know/document the > limitations of this approach of developing a standard > JS crypto API. Anything done in client-side script happens only at the pleasure of an adversary who can break the security of the page (i.e. source or inject even the smallest fragment in the origin context of the site). Therefore, client-side script is powerless to add real security. This is not academic, obviously script injection is common in the real world. Some of the most common types of malware inject script into pages for the purpose of relaying login credentials (of course they could do almost anything since they are running binary code in the browser, it just happens that injecting script is the easiest way to do it). - Marsh From nico@cryptonector.com Mon Jun 6 19:30:36 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E592C11E8082 for ; Mon, 6 Jun 2011 19:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 r7Oi6Pm9lKRD for ; Mon, 6 Jun 2011 19:30:35 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3611E8080 for ; Mon, 6 Jun 2011 19:30:35 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 075D454078 for ; Mon, 6 Jun 2011 19:30:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=sEynoOrdAg2OcM6ds23NQ 5JVeo7013gS4Wkv5H3vXBqMonBiH1z9VIR5pI+VttXzTafkMQ/A1/2WbN1Ix4+7H CsnbZHLYVlvMXM4u8DcxtnEbDCynW0x54ZZPO+qboY6QnYznxKexyRDn0ahCKggk aOJbAylXV3XD/DSGTFWASs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Tt6o6BfdPjfNiChJzuoY tC49YQM=; b=w3E5okuGEdYL0iPbh2ZhazDX7n6i7VYXwdKVbNUwi4axk//nebZ2 xRCMpKYSuGXz/e7lFTdK2PEpDMo3SJXQWvM+3DqQ+dEIJlhMTF8VDnJtfvmi951c Ao95qzfNlCJFM5WpLK5dPNvUognb6ltDVgng7U2mvuIlf0G03CiFdxc= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id E8B5F54077 for ; Mon, 6 Jun 2011 19:30:34 -0700 (PDT) Received: by pzk5 with SMTP id 5so2470125pzk.31 for ; Mon, 06 Jun 2011 19:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.20.137 with SMTP id n9mr38040pbe.121.1307413834593; Mon, 06 Jun 2011 19:30:34 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Mon, 6 Jun 2011 19:30:34 -0700 (PDT) In-Reply-To: <4DED8A12.7020305@extendedsubset.com> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <4DED55C5.1010306@extendedsubset.com> <4DED6EC9.4040300@cs.tcd.ie> <4DED8A12.7020305@extendedsubset.com> Date: Mon, 6 Jun 2011 21:30:34 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 02:30:36 -0000 On Mon, Jun 6, 2011 at 9:16 PM, Marsh Ray wrote: > On 06/06/2011 07:20 PM, Stephen Farrell wrote: >> On 06/06/11 23:33, Marsh Ray wrote: >>> Don't worry about it, they're not going to work even that well. >> >> Just trying to understand this. Why won't what work well? > > Well you can probably make the math more efficient. You could certainly > improve on the crypto handling ability of a language like Javascript which > has neither secure memory overwrite nor constant time comparison operations. > > But is there any plausible attack scenario where crypto in the web page adds > meaningful security? > > I don't think so. Either: > > A. TLS is correctly securing the connection, in which case you could just as > easily ship the plaintext to the server, or > > B. TLS is not present or ineffective, in which case it's the attacker who > controls what script is running in the page to such an extent that it's not > even worth discussing distinctions in the degree of the compromise. I.e., > pwned. Exactly. There is, however, a third possibility: code signing. That is, we could have a script (and, for that matter, HTML document) signing mechanism, then browsers could trust signed code even if not delivered over TLS. Note though: I'm not advocating code signing. On the web code changes much too often, for one. But the biggest problem is that you'd have to make sure that there's no leakage of untrusted bits into a page such that trusted code could be subverted to perform actions that it should not. Web pages nowadays consist of a great many objects that have to be fethced via HTTP -- this means that code signature verification for all of them would be akin to using HTTP/1.0 (i.e., not pipelining) and TLS w/o session resumption, in that an asymmetric crypto operation would be required for each object. That's a lot of asymmetric crypto!! In short, I don't think code signing on the web is a terribly practical idea, except, maybe, for generally stable libraries. There's also a fourth possibility: that crypto APIs will be used to access PKCS#11-like tokens (soft or hardware). But the browser, and therefore the user, will never know what a script means to do when using a given key, which means that we couldn't gain much security from this fourth possibility. We're left with the two options that Marsh stated, and which more than one of us explained at the W3C workshop (these are obvious problems), which means that JS crypto will add no security. Nico -- From bkihara.l@gmail.com Wed Jun 8 02:00:00 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF111E8128 for ; Wed, 8 Jun 2011 01:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 WQ7fjuDXHa0Q for ; Wed, 8 Jun 2011 01:59:59 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4767A11E810A for ; Wed, 8 Jun 2011 01:59:59 -0700 (PDT) Received: by pvh18 with SMTP id 18so162503pvh.31 for ; Wed, 08 Jun 2011 01:59:58 -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 :content-transfer-encoding; bh=zRtZq+ufWXW6DLpv0wP3qq2NppW2/7R5kR9fXiDFrjg=; b=XyNKT7NvL1GCJRZZ9Rg4UMQAY5w3JYuuLTvJpGF+rC73RfQP0ZR7NAHN8Mv8sCkMiw zPKjMjxWVF/VJ9qenUSLQN/Mx9xaRcQK+b+uMANVluJ22mVz5MRSJq5qNOdr6DNerv6M 8PnuLOVK4mZmvWGxit3N/fcv9LiGBq4ydcrXA= 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:content-transfer-encoding; b=nNA6dQyEHKnPt0qlbCkKOPZdHSyZyUmk9En2f73PPlV3cjgmLd7T+09E0TF3JPYyny DIXrDUzovkZDGFBCB6/o04CdOZm2VM6/gtm4v/2xcJmo5av/yfZU3e53KwJ1QDzvjo/V vObQwdnnl8xiylQsPZWT7BcevmQeODHAFTesQ= MIME-Version: 1.0 Received: by 10.143.97.42 with SMTP id z42mr202546wfl.359.1307523597703; Wed, 08 Jun 2011 01:59:57 -0700 (PDT) Received: by 10.142.164.3 with HTTP; Wed, 8 Jun 2011 01:59:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jun 2011 17:59:57 +0900 Message-ID: From: "KIHARA, Boku" To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] REST-GSS I-D posted X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 09:00:00 -0000 Dear Nico, I'm reading the REST-GSS I-D and have several comments on it. > 2.9. Server Indication of Authentication Requirement > > When the server wishes to indicate that the client must authenticate > in order to access a given resource, then the server MUST respond to > the client's HTTP request with either a redirection to a web page > with a 303 redirect to a login page (this in the case of browser > applications) or a TBD 4xx error indicating that access requires > REST-GSS login and, optionally directing the client to the REST-GSS > login URI by listing that URI in a response header field named 'REST- > GSS-Authenticate'. > I'm not sure whether the 'REST-GSS-Authenticate' field is allowed for only 4xx responses or both 303 and 4xx responses. > 3.1. Server Decides When to Authenticate > C->S: HTTP/1.1 GET /some/resource > Host: A.example > > S->C: HTTP/1.1 303 http://A.example/login.html& > > Authentication required indication browser apps Is the URI 'http://A.example/login.html&' intended for the 'Location' field? What is the clinging ''? If it is the REST-GSS login URI, what is the purpose of this URI here? I think browsers cannot (or should not) detect the REST-GSS login URI because it is merely a part of the redirection URI, and servers do not need the '' because they already know the REST-GSS login URI. > C->S: HTTP/1.1 GET /some/resource > Host: A.example > > S->C: HTTP/1.1 4xx > REST-GSS-URI: http://A.example/rest-gss-login > > Authentication required indication for non-browser apps In this example, the 4xx response has the filed have a field named 'REST-GSS-URI', which is different from 'REST-GSS-Authenticate' mentioned in 2.9. So which is correct or am I referring different things? Sorry for my poor English and small amount of comments, but I hope these he= lp. Regards, -- KIHARA, Boku 2011/6/7 Nico Williams : > 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 Wed Jun 8 03:20:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651B911E8097 for ; Wed, 8 Jun 2011 03:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.375 X-Spam-Level: X-Spam-Status: No, score=0.375 tagged_above=-999 required=5 tests=[AWL=0.465, 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 jcE8X8ryM7Hl for ; Wed, 8 Jun 2011 03:20:49 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCE811E8077 for ; Wed, 8 Jun 2011 03:20:48 -0700 (PDT) Received: from rqsmtp1.aist.go.jp (rqsmtp1.aist.go.jp [150.29.254.115]) by mx1.aist.go.jp with ESMTP id p58AKhOx001254; Wed, 8 Jun 2011 19:20:43 +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=1307528444; bh=Y9Y+FZdiFt9lyy0fsnaq1OqxoBET71PwkT6xKpFQsvc=; h=Message-ID:Date:From; b=lAe2z6PlL5+DpjxpIM0D2Hw9V39Wew435I7qjVbsiFOPfBPy4eOpUL5ptn1+Xcqzu W6tcxeZyr7rPs+gP2GXNISje3Y0M75jbr8AYVz1KTs4DNZwvPaT0OpwyuwHhf6Knpk NHNvZtDt/2IEaJNQ3heC4iwbX1wf21mASXlqrr+0= Received: from smtp1.aist.go.jp by rqsmtp1.aist.go.jp with ESMTP id p58AKhPd014481; Wed, 8 Jun 2011 19:20:43 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp1.aist.go.jp with ESMTP id p58AKgNd024607; Wed, 8 Jun 2011 19:20:42 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4DEF4CFA.6060302@aist.go.jp> Date: Wed, 08 Jun 2011 19:20:42 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: http-auth@ietf.org References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 10:20:50 -0000 Dear all, On 2011/06/06 2:06, Yutaka OIWA wrote: > 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. I put a pre-draft version of problem statement on . I tried to be as neutral to specific technologies as possible, but we may still update this to reflect more comments on the Bar-BoF and IIB as possible. We will wrap this as a I-D format in a few days, but I'd like to reflect your suggestions and comments as much as possible. Please either send your comments here, or personal mails to me are also welcome. Thank you, 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 nico@cryptonector.com Wed Jun 8 08:18:01 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92FF11E80AD for ; Wed, 8 Jun 2011 08:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_17=0.6] 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 EJzxI1oVevnT for ; Wed, 8 Jun 2011 08:18:00 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BD6FE11E80E6 for ; Wed, 8 Jun 2011 08:18:00 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 5813F2F4095 for ; Wed, 8 Jun 2011 08:17:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xwESeUwxvsE++DUeV1HYbm5/WzTKCM5aEkdUt3yqxStO v3077Bw40V/lS3GfLpmCPKBDFj5IRQ0x53aE9/kbkOFZ5I1cpcFf2g/JJi819Aql W6bafcYFPgWYgtQq6Jb5/fzaKRm4eblxQFgeqIvN6VfceuCM/Wjh2B39QzLU64c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/KBZtl5NMj7jahZQvYcFwfKVS0E=; b=fxlGZuxTycJ 7vYs8L/tfleBP/lYGouQCj08O9TU3jTIeNugk4+2yNiLoawdS+rvg3vj2uZ3RHZ9 0xKrB26EFcgq5Wwjahy6c9mmwCuehSAT5brobjfWzcIX06+AoXIKkzB8VVpjpOPX GOrgPOO+P101GqNWjgCwxAQqWsqx1aiQ= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id F12622F408E for ; Wed, 8 Jun 2011 08:17:07 -0700 (PDT) Received: by pwi5 with SMTP id 5so325706pwi.31 for ; Wed, 08 Jun 2011 08:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.10.9 with SMTP id e9mr1041365pbb.255.1307546226889; Wed, 08 Jun 2011 08:17:06 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 8 Jun 2011 08:17:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Jun 2011 10:17:06 -0500 Message-ID: From: Nico Williams To: "KIHARA, Boku" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org Subject: Re: [http-auth] REST-GSS I-D posted X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 15:18:01 -0000 On Wed, Jun 8, 2011 at 3:59 AM, KIHARA, Boku wrote: >> 2.9. =C2=A0Server Indication of Authentication Requirement >> >> =C2=A0 =C2=A0When the server wishes to indicate that the client must aut= henticate >> =C2=A0 =C2=A0in order to access a given resource, then the server MUST r= espond to >> =C2=A0 =C2=A0the client's HTTP request with either a redirection to a we= b page >> =C2=A0 =C2=A0with a 303 redirect to a login page (this in the case of br= owser >> =C2=A0 =C2=A0applications) or a TBD 4xx error indicating that access req= uires >> =C2=A0 =C2=A0REST-GSS login and, optionally directing the client to the = REST-GSS >> =C2=A0 =C2=A0login URI by listing that URI in a response header field na= med 'REST- >> =C2=A0 =C2=A0GSS-Authenticate'. >> > > I'm not sure whether the 'REST-GSS-Authenticate' field is allowed for > only 4xx responses or both 303 and 4xx responses. Only for 4xx responses. But I'm thinking I don't want to add any new 4xx codes, so I think we might want to do the 303 thing in all cases, with non-browser apps having to recognize that the URI being redirected to is the REST-GSS login URI. >> 3.1. Server Decides When to Authenticate >> =C2=A0 =C2=A0 =C2=A0 C->S: HTTP/1.1 GET /some/resource >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Host: A.example >> >> =C2=A0 =C2=A0 =C2=A0 S->C: HTTP/1.1 303 http://A.example/login.html& >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication required= indication browser apps > > Is the URI 'http://A.example/login.html&' intended for > the 'Location' field? Ooops, yes. > What is the clinging ''? If it is the REST-GSS login > URI, what is the purpose of this URI here? I think browsers cannot > (or should not) detect the REST-GSS login URI because it is merely a > part of the redirection URI, and servers do not need the '' > because they already know the REST-GSS login URI. The idea was to make sure the browser could be redirected back to the original resource when login completes. Browsers would be redirected to a login page where there will be a button that causes the browser to initiate and complete REST-GSS login. I'd like the end result to be that the user ends up on the page that had required authentication. >> =C2=A0 =C2=A0 =C2=A0 C->S: HTTP/1.1 GET /some/resource >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Host: A.example >> >> =C2=A0 =C2=A0 =C2=A0 S->C: HTTP/1.1 4xx >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 REST-GSS-URI: http://A.example= /rest-gss-login >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authentication required indication fo= r non-browser apps > > In this example, the 4xx response has the filed have a field named > 'REST-GSS-URI', which is different from 'REST-GSS-Authenticate' > mentioned in 2.9. So which is correct or am I referring different > things? Ah, that's just me going too fast. I'll fix that. Good catch! > Sorry for my poor English and small amount of comments, but I hope these = help. Your English is fine. Thanks for your comments! Nico -- From y.oiwa@aist.go.jp Thu Jun 9 07:32:05 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@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: public-identity@w3.org, websec@ietf.org, saag@ietf.org, Sean Turner Subject: Re: [http-auth] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: HTTP authentication methods 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:47:45 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3282721F84BB for ; Thu, 9 Jun 2011 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.026 X-Spam-Level: X-Spam-Status: No, score=-104.026 tagged_above=-999 required=5 tests=[AWL=-1.427, 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 6wuRvpseQ+Ns for ; Thu, 9 Jun 2011 07:47:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 152A721F84B8 for ; Thu, 9 Jun 2011 07:47:43 -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: [http-auth] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:47:45 -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 yutaka-oiwa-aist-temp@g.oiwa.jp Thu Jun 9 19:22:54 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7611E80BA for ; Thu, 9 Jun 2011 19:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 xlfwMg46B08u for ; Thu, 9 Jun 2011 19:22:54 -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 BE6B811E8076 for ; Thu, 9 Jun 2011 19:22:53 -0700 (PDT) Received: by gxk19 with SMTP id 19so1676237gxk.31 for ; Thu, 09 Jun 2011 19:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.104.3 with SMTP id b3mr2533448ybc.166.1307672573129; Thu, 09 Jun 2011 19:22:53 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.103.4 with HTTP; Thu, 9 Jun 2011 19:22:53 -0700 (PDT) In-Reply-To: References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> <4DF0DB72.9090601@gmx.de> Date: Fri, 10 Jun 2011 11:22:53 +0900 X-Google-Sender-Auth: 2BGXD9S7u8fjlqhNvypyYl4u2QE Message-ID: From: Yutaka OIWA To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [http-auth] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 03:17:17 -0000 I forgot to send a reply to the mailing list, so forwarding for your reference... Sorry for inconvenience. ---------- Forwarded message ---------- From: Yutaka OIWA Date: 2011/6/10 Subject: Re: [http-auth] re-call for IETF http-auth BoF To: Julian Reschke Dear Julian: 2011/6/9 Julian Reschke : > That's kind of misleading; the core HTTP protocol doesn't define any > concrete authentication schemes at all; it just offers a framework (heade= r > fields, status codes etc). Thank you for comment. =A0My intention was RFC 2616+2617 as a core, but the view of your comment seems to be more clear. > I believe you need to add HTTPbis. Yes, I'm sorry. Yutaka From stpeter@stpeter.im Fri Jun 10 11:15:08 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D3F9E800B for ; Fri, 10 Jun 2011 11:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Y0aDjmCpxxFc for ; Fri, 10 Jun 2011 11:15:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 744999E8004 for ; Fri, 10 Jun 2011 11:15:07 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E897F40066; Fri, 10 Jun 2011 12:15:15 -0600 (MDT) Message-ID: <4DF25F29.5030806@stpeter.im> Date: Fri, 10 Jun 2011 12:15:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000602050608090408050609" Cc: Pete Resnick , Sean Turner Subject: [http-auth] possible BoF in Quebec City X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 18:15:08 -0000 This is a cryptographically signed message in MIME format. --------------ms000602050608090408050609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The security area and applications area directors have talked about the possibility of a "Birds of a Feather" (BoF) on HTTP authentication at IETF 81. We have agreement that it would be productive to hold an exploratory BoF, i.e., not a BoF that is intended to immediately form an IETF working group. The goal of this meeting would be to map out the problem space for HTTP authentication and determine if there is energy and interest in working on a clear problem statement and related Internet-Drafts in preparation for a future WG-forming BoF. I have volunteered to be the responsible AD for this BoF, however that doesn't mean that any eventual WG would be formed in the applications area (it's too early to determine the final landing spot for such a WG). I've updated http://trac.tools.ietf.org/bof/trac/wiki/WikiStart with information about the proposed BoF. All proposed BoFs will be discussed by the IESG and IAB next Thursday on our "BoF Coordination Call". If the HTTP Authentication BoF is approved, I'll post again to this list. Finally, I am seeking volunteers to chair this BoF (i.e., moderate the discussion). If you have an interest, please contact me off-list. See you in Quebec City! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000602050608090408050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx MDE4MTUwNVowIwYJKoZIhvcNAQkEMRYEFBqAsejrVylXKFQnjRFao1c4LDHsMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQC2tT3Wz7XKiFkZ4lZh/8GFh6oiexiAa72yjcuUZV/Wmkd2dhKBBVhxTseG HRIwCyLelqfjpbZcUmYqhFoeIFHfsBXfujdA49R9R89b07veXL4T/9jbVePlsCFYL8ZFQCaU Jkx38HxHPNtnsMGvxgEoEd0ZQeDWNVQ7KIbvaK8a59pQrZwelzOAL/O9KUmbTKIgA667EYSk sswxaOjzJcbxs2e9CxAn6/PupYyNh0uGcJU+EgeB1kFqEFM07dSGfMOtdA2yzAfCXIx4GaSt GNNJsdysVYrJYLfSK9UQda2UfQuUUNbGE6Ovy76jmuEce7qvQ6tcfIpqLhCstSiwIj7hAAAA AAAA --------------ms000602050608090408050609-- From yaronf@gmx.com Sat Jun 11 08:09:01 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719EE11E80AE for ; Sat, 11 Jun 2011 08:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DoxfYzTJC0V5 for ; Sat, 11 Jun 2011 08:09:01 -0700 (PDT) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by ietfa.amsl.com (Postfix) with SMTP id 5046811E80B6 for ; Sat, 11 Jun 2011 08:09:00 -0700 (PDT) Received: (qmail invoked by alias); 11 Jun 2011 15:08:58 -0000 Received: from bzq-79-178-38-173.red.bezeqint.net (EHLO [10.0.0.5]) [79.178.38.173] by mail.gmx.com (mp-eu005) with SMTP; 11 Jun 2011 17:08:58 +0200 X-Authenticated: #63966379 X-Provags-ID: V01U2FsdGVkX1/GZ0wv8Y/Gj1bLQf5hqSRn+YJWljsvesydwRSE+E yHVHVG08DBB276 Message-ID: <4DF384FD.10804@gmx.com> Date: Sat, 11 Jun 2011 18:08:45 +0300 From: Yaron Sheffer 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 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [http-auth] Tunisian/Syrian phishing attacks X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 15:09:01 -0000 Hi Marsh, a bit of a late response, but I'd like to offer that these two attacks could in fact have been countered by a combination of several ideas that we're already familiar with. Let's assume the following: 1. Users are authenticated to Facebook with a password, using a zero-knowledge password protocol (ZKPP), with authentication at the TLS or the HTTP layer. 2. In any case, authentication is crypto-bound into the TLS-protected session (OK, let's assume Facebook sessions are TLS-protected...). 3. Passwords are stored in the browser's password manager. The browser doesn't "paste" the password into a form; rather, the browser only releases the password when going through the ZKPP. This is done behind the scenes, the user doesn't get to see the plaintext password or even a row of asterisks. 4. This is further hardened with an HSTS-like mechanism: only use this site if you can perform mutual authentication with it. 5. Also, users are trained *not* to enter their passwords explicitly, and will be suspicious when the see a "please enter your password" page. I suggest that this combination is well protected against phishing attacks, without having to rely on trusted JavaScript code or on fancy user interface elements. Thanks, Yaron > From: Marsh Ray > To: Nico Williams > Cc: http-auth@ietf.org > Subject: Re: [http-auth] [saag] re-call for IETF http-auth BoF > Message-ID:<4DED55C5.1010306@extendedsubset.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 06/06/2011 04:44 PM, Nico Williams wrote: >> But I'm afraid >> that the appearance of success will be enough to staunch progress in >> any other areas, so it may be a now-or-never situation for any >> alternatives other than JavaScript crypto APIs. > Don't worry about it, they're not going to work even that well. > > They wouldn't have stopped the government of Tunisia from MitMing > Facebook and inserting Javascript to modify the behavior of the page. > They wouldn't have stopped the government of Syria from using a BlueCoat > to perform SSL MitM on Facebook with a bogus self-signed cert either. > > Both governments were arresting and shooting their citizens and hacking > their Facebook credentials. Interestingly, Tunisia controls a trusted > root CA but didn't bother to use it. Syria doesn't control a widely > trusted CA, but doesn't seem to need it either. > > Sooner or later, people will tire of security theater. We can just try > to have the best options available when they do. > > - Marsh From hallam@gmail.com Sat Jun 11 14:53:41 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@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: [http-auth] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods 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 nico@cryptonector.com Sat Jun 11 15:42:07 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5FE11E80CD for ; Sat, 11 Jun 2011 15:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 a-dBcdyZHJHR for ; Sat, 11 Jun 2011 15:42:06 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id BBF4311E80CB for ; Sat, 11 Jun 2011 15:42:06 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 6518D678062 for ; Sat, 11 Jun 2011 15:42:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fZgBOsiMPs8o5POTWRreE 8Psi8jj25wcyif98G5iE16dcXGiCL78tCxz/BcYw3ZyBpwWcf+XlLPfx5pNw+haC eeD4O3BTDlS98RykNeLQa7+rODG7UuyVlZy6CtQgw6VISC6sUVa8jk84jJli5BQu u5yQnYKJpWfIvDtXsx5w1k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Xyrn9KDZ2GKp1EhGLyTI 99FmCPM=; b=COYcU3zA5VrxUXZ53l81nwjcQ8b8aby2TV20rQ1NRIeVVS/nEZwn MnM50wbmFAM2uQBIGnuDUV+u7XLVklTPReob7abn45JKGo18HNgqYWaQHcoL/J4j lO85ot8PTmZzH6+tuEeWHKQBu0eMtPub6nPoVFwhLHyk+Q1z33OZhx8= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 452B1678056 for ; Sat, 11 Jun 2011 15:42:06 -0700 (PDT) Received: by pvh18 with SMTP id 18so1836053pvh.31 for ; Sat, 11 Jun 2011 15:42:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.7 with SMTP id k7mr1559676pbd.322.1307832125607; Sat, 11 Jun 2011 15:42:05 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Sat, 11 Jun 2011 15:42:05 -0700 (PDT) In-Reply-To: <4DF384FD.10804@gmx.com> References: <4DF384FD.10804@gmx.com> Date: Sat, 11 Jun 2011 17:42:05 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: http-auth@ietf.org Subject: Re: [http-auth] Tunisian/Syrian phishing attacks X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 22:42:07 -0000 On Sat, Jun 11, 2011 at 10:08 AM, Yaron Sheffer wrote: > Let's assume the following: > 1. Users are authenticated to Facebook with a password, using a > zero-knowledge password protocol (ZKPP), with authentication at the TLS or > the HTTP layer. So, mutual authentication. The specific mechanism doesn't matter, as long as it gives us mutual authentication in a way such that it doesn't suffer from the problems that the TLS server PKI does when it comes to authenticating the service. > 2. In any case, authentication is crypto-bound into the TLS-protected > session (OK, let's assume Facebook sessions are TLS-protected...). So, channel binding. (Because we're not going to throw away our investment in TLS for transport protection, but we need to make sure there's no MITM there.) > 3. Passwords are stored in the browser's password manager. The browser > doesn't "paste" the password into a form; rather, the browser only releases > the password when going through the ZKPP. This is done behind the scenes, > the user doesn't get to see the plaintext password or even a row of > asterisks. Browser chrome, a TCB. What does "releases" here mean? Does it give the password plaintext to an untrusted script that implements the ZKPP? > 4. This is further hardened with an HSTS-like mechanism: only use this site > if you can perform mutual authentication with it. Indeed! > 5. Also, users are trained *not* to enter their passwords explicitly, and > will be suspicious when the see a "please enter your password" page. Right: death to echo-off text input elements in HTML! > I suggest that this combination is well protected against phishing attacks, > without having to rely on trusted JavaScript code or on fancy user interface > elements. This (mutual auth + channel binding) is pretty much what some of us proposed at the W3C IDBROWSER workshop three weeks ago. (Instead of a ZKPP I propose we allow multiple different mechanisms, because there are different mechanisms that people will want to use depending on the context; Kerberos in the enterprise, GSS-EAP in the .edu cases and many others, etcetera.) But here's the gotcha: this can't be implemented in a script served by the site, because there's no way to know what the script intends to do with the password, and we haven't really authenticated the site yet, and if you think the TLS server PKI is enough, then why ask for mutual auth here? We could add a script signing PKI, but chances are it'd end up with the same faults as the TLS server PKI (namely: the CAs don't have any responsibility to the RPs, the public at large). This wouldn't eliminate all phishing attacks, but it would eliminate the kinds of phishing attacks that involve theft of credential by impersonating a service that a user wants to login to. Well, assuming the phisher can't trick the user into typing the password into an echo-off (or simulated echo-off) prompt, which is why browser chrome and things like SAS (secure attention sequence) matter, but still , we'd be making significant progress. Nico -- From yaronf@gmx.com Sat Jun 11 23:50:23 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98A01F0C45 for ; Sat, 11 Jun 2011 23:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_HTML_ONLY=1.457] 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 ZJphqnckGAyo for ; Sat, 11 Jun 2011 23:50:23 -0700 (PDT) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by ietfa.amsl.com (Postfix) with SMTP id A0A351F0C35 for ; Sat, 11 Jun 2011 23:50:22 -0700 (PDT) Received: (qmail invoked by alias); 12 Jun 2011 06:50:20 -0000 Received: from bzq-79-178-38-173.red.bezeqint.net (EHLO [10.0.0.2]) [79.178.38.173] by mail.gmx.com (mp-eu004) with SMTP; 12 Jun 2011 08:50:20 +0200 X-Authenticated: #63966379 X-Provags-ID: V01U2FsdGVkX1+DxYpde4aD7T2569ACvCqHCCMocZ/4hlNLFXN6dE rn5z03MxcRMSfR Message-ID: <4DF461A9.8070803@gmx.com> Date: Sun, 12 Jun 2011 09:50:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <4DF384FD.10804@gmx.com> In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] Tunisian/Syrian phishing attacks X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 06:50:24 -0000 Hi Nico,

thanks for your comments.

I agree several alternative authentication methods make sense, in addition to ZKPP. But for now, I'd rather concentrate on passwords since they make the most sense in the consumer context. If we do it right, we can migrate to PSK later on - if the user doesn't enter the password, they might as well use long binary strings. And maybe Kerberos as well.

But apparently I wasn't clear on the implementation, and that's a critical part. It looks like secure scripts are an impossibility right now (although people are trying: http://en.wikipedia.org/wiki/Caja_project). So I expect the browser internals to take care of authentication, with no scripting and no user interface involved. This is also why I'm avoiding the term "browser chrome" which smells of GUI: if you allow users into the loop, they will always make the rational decision and press Yes.

So here's my amended proposal again:

1. Users are authenticated to Facebook with a password, using a zero-knowledge password protocol (ZKPP), with authentication at the TLS or the HTTP layer.
2. In the future this can be extended to support other strong mutual auth schemes, like PSK or enterprise server+client certificates.
3. In any case, authentication is crypto-bound into the TLS-protected session (OK, let's assume Facebook sessions are TLS-protected...).
4. Passwords are stored in the browser's password manager. The browser doesn't "paste" the password into a form; rather, the browser only uses the password to run the client side of the ZKPP. This is done behind the scenes, the user doesn't get to see the plaintext password or even a row of asterisks. The browser implements ZKPP internally, with no scripts taking part in the process. In particular, browser-based scripts never get to see the password.
5. This is further hardened with an HSTS-like mechanism: only use this site if you can perform mutual authentication with it.
6. As a result of this scheme, users are trained *not* to enter their passwords explicitly, and will be suspicious when the see a "please enter your password" page. More importantly, they will have to work hard to get access to their password, which would discourage them from revealing the password to any arbitrary Web site.

Thanks,
    Yaron


On 06/12/2011 01:42 AM, Nico Williams wrote: 
On Sat, Jun 11, 2011 at 10:08 AM, Yaron Sheffer <yaronf@gmx.com> wrote:

Let's assume the following:
1. Users are authenticated to Facebook with a password, using a
zero-knowledge password protocol (ZKPP), with authentication at the TLS or
the HTTP layer.

So, mutual authentication.  The specific mechanism doesn't matter, as
long as it gives us mutual authentication in a way such that it
doesn't suffer from the problems that the TLS server PKI does when it
comes to authenticating the service.


2. In any case, authentication is crypto-bound into the TLS-protected
session (OK, let's assume Facebook sessions are TLS-protected...).

So, channel binding.  (Because we're not going to throw away our
investment in TLS for transport protection, but we need to make sure
there's no MITM there.)


3. Passwords are stored in the browser's password manager. The browser
doesn't "paste" the password into a form; rather, the browser only releases
the password when going through the ZKPP. This is done behind the scenes,
the user doesn't get to see the plaintext password or even a row of
asterisks.

Browser chrome, a TCB.  What does "releases" here mean?  Does it give
the password plaintext to an untrusted script that implements the
ZKPP?


4. This is further hardened with an HSTS-like mechanism: only use this site
if you can perform mutual authentication with it.

Indeed!


5. Also, users are trained *not* to enter their passwords explicitly, and
will be suspicious when the see a "please enter your password" page.

Right: death to echo-off text input elements in HTML!


I suggest that this combination is well protected against phishing attacks,
without having to rely on trusted JavaScript code or on fancy user interface
elements.

This (mutual auth + channel binding) is pretty much what some of us
proposed at the W3C IDBROWSER workshop three weeks ago.  (Instead of a
ZKPP I propose we allow multiple different mechanisms, because there
are different mechanisms that people will want to use depending on the
context; Kerberos in the enterprise, GSS-EAP in the .edu cases and
many others, etcetera.)

But here's the gotcha: this can't be implemented in a script served by
the site, because there's no way to know what the script intends to do
with the password, and we haven't really authenticated the site yet,
and if you think the TLS server PKI is enough, then why ask for mutual
auth here?  We could add a script signing PKI, but chances are it'd
end up with the same faults as the TLS server PKI (namely: the CAs
don't have any responsibility to the RPs, the public at large).

This wouldn't eliminate all phishing attacks, but it would eliminate
the kinds of phishing attacks that involve theft of credential by
impersonating a service that a user wants to login to.  Well, assuming
the phisher can't trick the user into typing the password into an
echo-off (or simulated echo-off) prompt, which is why browser chrome
and things like SAS (secure attention sequence) matter, but still ,
we'd be making significant progress.

Nico
--
From alexey.melnikov@isode.com Sun Jun 12 09:18:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@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: [http-auth] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods 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 pgut001@login01.cs.auckland.ac.nz Mon Jun 13 21:59:59 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9801F0C8C; Mon, 13 Jun 2011 21:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 tVokf5x1+QYJ; Mon, 13 Jun 2011 21:59:57 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8401F0C82; Mon, 13 Jun 2011 21:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1308027597; x=1339563597; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20julian.reschke@gmx.de|Subject: =20Re:=20[saag]=20[websec]=20[http-auth]=20re-call=20for =20IETF=20http-auth=20BoF|Cc:=20http-auth@ietf.org,=20pub lic-identity@w3.org,=20saag@ietf.org,=0D=0A=20=20=20=20we bsec@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Tue,=2014=20Ju n=202011=2016:59:54=20+1200; bh=MuLKPw/XGt8/FxbjsT18BBlz9z5+VlWKDD31mvISxRs=; b=u8GyTUUZJnA+n4/Ubigmdb/xyqPe90Y+FrYU/aJN5u/o6DVEqGIHpvih zIKzySVlGGNfODw9OzvHpF9/bZ6BqGiQ8ELacqPQZQc+A5qdYyDa8B4W0 8J9sGPdoNSynDqAsmF2ubibn1qSVKQs1s5hLA9of67BBx49E4wPl+hzjx g=; X-IronPort-AV: E=Sophos;i="4.65,362,1304251200"; d="scan'208";a="67285743" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jun 2011 16:59:54 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QWLjG-0004Wb-Hf; Tue, 14 Jun 2011 16:59:54 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QWLjG-0007nd-EG; Tue, 14 Jun 2011 16:59:54 +1200 From: Peter Gutmann To: hallam@gmail.com, julian.reschke@gmx.de In-Reply-To: Message-Id: Date: Tue, 14 Jun 2011 16:59:54 +1200 X-Mailman-Approved-At: Tue, 14 Jun 2011 08:24:55 -0700 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:59:59 -0000 Phillip Hallam-Baker writes: >what would we want HTTP authentication to look like? I have a suggestion for what it shouldn't look like: Any method that hands over the password (or a password-equivalent like a password in hashed form) as current browsers do should be banned outright, and anyone who implements hand-over-the-password should killed and eaten to prevent them from passing on the genes. The only permitted auth.form should be a dynamic, cryptographic mutual auth. that authenticates both the client and the server. There are endless designs for this sort of thing around so the precise form isn't too important, as long as it's not hand-over-the-password. Peter. From nico@cryptonector.com Tue Jun 14 09:17:05 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE651F0C36; Tue, 14 Jun 2011 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6] 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 WLzm717IlfBL; Tue, 14 Jun 2011 09:17:04 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 09A811F0C34; Tue, 14 Jun 2011 09:17:04 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 854A4202044; Tue, 14 Jun 2011 09:17:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=M6DhzyALUZaO3+DFAfH01txiCMUr08aVWvWhf43DgE6z DGGjVL9y0ZqpU0waS18LbaChz6h+Y//sgWriT3aGe5ENzY6DjAJ+DekdCC7M5S0Z bIdlHvcRQZD9OyQE5YLb130BidS59+qUsdU4fA0kR1y6AGJglWHijsmUDKKWdg8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=P8lX6P6P1u63ALqOYW3sNzZWs28=; b=NAkLObol6rO StYoelV3k8oM/zbd7rjLYQndqVYYR5mDt3TV6kN5LdQR7uUpG/LEhRf33SaHK6GQ lEkVM2uaGvfiD9lWAnTTHOxCFM4aaHn3l7VT4YVJQDadfOz9+fH7rkwrDD/Ns39J m/Zbp9ROOA/+6Wexc8OglTYrZ5QiCajg= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 07C9A202043; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) Received: by pwi5 with SMTP id 5so2972364pwi.31 for ; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr3246236pbc.523.1308068222669; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 11:17:02 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:17:05 -0000 On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =C2=A0There are endles= s designs > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. +1, particularly with regard to mutual authentication. It's important to understand that we need mutual authentication using something other than the TLS server cert PKI for authenticating the server. Some aspects of the designs are important. For example: - Is this to be done in TLS? HTTP? Or at the application-layer? IMO: TLS is too low a layer to do authentication in, and doing it in HTTP would require retrofitting too many HTTP stacks. Doing it at the application layer has a number of advantages. - Shall we have just one authentication mechanism? IMO: We can't pick a universal authentication mechanism that will work for everyone, but if it helps get momentum I'd be happy to specify something where we start with one mechanism but nothing prevents us from adding others later. Here's an example showing how to use SCRAM (a successor to DIGEST-MD5, thus not terribly interesting, but pretend for a second that this is a ZKPP) at the application layer and in a RESTful way: C->S: HTTP/1.1 POST /rest-gss-login Host: A.example Content-Type: application/rest-gss-login Content-Length: nnn SCRAM-SHA-1,,MIC n,,n=3Duser,r=3Dfyko+d2lbbFgONRv9qkxdawL S->C: HTTP/1.1 201 Location http://A.example/rest-gss-session-9d0af5f680d4ff46 Content-Type: application/rest-gss-login Content-Length: nnn C r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, s=3DQSXCR+Q6sek8bf92,i=3D4096 C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46 Host: A.example Content-Type: application/rest-gss-login Content-Length: nnn c=3Dbiws,r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, p=3Dv0X8v3Bz2T0CJGbJQyF0X+HI4Ts=3D S->C: HTTP/1.1 200 Content-Type: application/rest-gss-login Content-Length: nnn A v=3DrmF9pqV8S7suAoZWja4dJRkFsKQ=3D Does that work for you? Nico -- From stephen.farrell@cs.tcd.ie Tue Jun 14 09:36:52 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0011E807F; Tue, 14 Jun 2011 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 9r4JtXOoA-DW; Tue, 14 Jun 2011 09:36:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7E9E802E; Tue, 14 Jun 2011 09:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6CE0B171C03; Tue, 14 Jun 2011 17:36:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1308069382; bh=kqIm4 jHDs81NEcSSm4exH0reLW/jZ4nKCmvRSO3SNic=; b=Pw88SLOl1pzIHAWmCqRdJ AwQpCYzBatNawyjEo3KQaeO0cnEU2awaeyjQ0Mo6QZtM6z3aku0jx+auVkdnh6vh hVsNwNrMu5hogIRQTEfqk9br182gkrraCrFSqcTMFrH0sdSOme8lPewQvoARxVNV 8ifVOn6UcZ9WXwnjdwOwm+XTGLoBUwXAs/LWRqhVtpqK0oXPqY8vqW+WtOyztZqh BBOeOesHEQ18oVtiOynZGHQLQiphYHmO0t6tqpoQErYwuPItdbYm2X+pWaFeSwOP 0Vbg4xNUJ8wzIkYyJ1ly1hXPBCbh7SsT4BE30qC61JIMcUkIAjt2pJG2U5W6VPu0 g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Rxrh5psMVZHL; Tue, 14 Jun 2011 17:36:22 +0100 (IST) Received: from [10.52.30.188] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 39620171C02; Tue, 14 Jun 2011 17:36:20 +0100 (IST) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8H7) From: Stephen Farrell Date: Tue, 14 Jun 2011 17:36:14 +0100 To: Nico Williams Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" , Peter Gutmann Subject: Re: [http-auth] [websec] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:36:52 -0000 This is about http auth (and I'm glad to see the discussion) but can we keep= it to just that list?=20 Ta. S On 14 Jun 2011, at 17:17, Nico Williams wrote: > On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann > wrote: >> Phillip Hallam-Baker writes: >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that hand= s >> over the password (or a password-equivalent like a password in hashed for= m) as >> current browsers do should be banned outright, and anyone who implements >> hand-over-the-password should killed and eaten to prevent them from passi= ng on >> the genes. >=20 > +1. >=20 >> The only permitted auth.form should be a dynamic, cryptographic mutual au= th. >> that authenticates both the client and the server. There are endless des= igns >> for this sort of thing around so the precise form isn't too important, as= long >> as it's not hand-over-the-password. >=20 > +1, particularly with regard to mutual authentication. It's important > to understand that we need mutual authentication using something other > than the TLS server cert PKI for authenticating the server. >=20 > Some aspects of the designs are important. >=20 > For example: >=20 > - Is this to be done in TLS? HTTP? Or at the application-layer? >=20 > IMO: TLS is too low a layer to do authentication in, and doing it in > HTTP would require retrofitting too many HTTP stacks. Doing it at the > application layer has a number of advantages. >=20 > - Shall we have just one authentication mechanism? >=20 > IMO: We can't pick a universal authentication mechanism that will work > for everyone, but if it helps get momentum I'd be happy to specify > something where we start with one mechanism but nothing prevents us > from adding others later. >=20 > Here's an example showing how to use SCRAM (a successor to DIGEST-MD5, > thus not terribly interesting, but pretend for a second that this is a > ZKPP) at the application layer and in a RESTful way: >=20 > C->S: HTTP/1.1 POST /rest-gss-login > Host: A.example > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > SCRAM-SHA-1,,MIC > n,,n=3Duser,r=3Dfyko+d2lbbFgONRv9qkxdawL >=20 > S->C: HTTP/1.1 201 > Location http://A.example/rest-gss-session-9d0af5f680d4ff46 > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > C > r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, > s=3DQSXCR+Q6sek8bf92,i=3D4096 >=20 > C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46 > Host: A.example > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > c=3Dbiws,r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, > p=3Dv0X8v3Bz2T0CJGbJQyF0X+HI4Ts=3D >=20 > S->C: HTTP/1.1 200 > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > A > v=3DrmF9pqV8S7suAoZWja4dJRkFsKQ=3D >=20 >=20 > Does that work for you? >=20 > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From nico@cryptonector.com Tue Jun 14 09:48:21 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923AB11E8143 for ; Tue, 14 Jun 2011 09:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-1.476, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6] 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 7L4CRltDzcAM for ; Tue, 14 Jun 2011 09:48:21 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1012611E811E for ; Tue, 14 Jun 2011 09:48:21 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id C560510059 for ; Tue, 14 Jun 2011 09:48:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nY2htyIfN1ILBJWCw2gEk UVHNsxb0AVChztRDLmjeeab75Asyl5J1BSlbUVhfdnelxV/iM1ZN+ynJEfc4EiGb gEtedyeLkoJSwHwLTPZGk6g1Y4YLvgl18p/QYHhvW+QKT+xEvpX6JdIgfQrql5bz eTI2uo46uJtJVU6+MewTnw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3gzmiDV2qKc+r5Q4RcVW SKYcdgc=; b=LO5CJjExw4AKiZ28gD297OBbHNpoxF0DyUwyMRCGdLX/LiMnVuDO 7eojxobQI0DMs/bpXuSwXcPvDHFaoB95LHMQygPukbO5DBrjbyB9GQ1DKBtB3OGf v6Ugk4VjxInLLFvIpR4jve9J69Ke8AdAdAOcLaXYH1+k8gqUe6VsGAQ= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id AB69C10056 for ; Tue, 14 Jun 2011 09:48:20 -0700 (PDT) Received: by pvh18 with SMTP id 18so2981403pvh.31 for ; Tue, 14 Jun 2011 09:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.37.3 with SMTP id u3mr3070081pbj.456.1308070100386; Tue, 14 Jun 2011 09:48:20 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 14 Jun 2011 09:48:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 11:48:20 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "public-identity@w3.org" , "http-auth@ietf.org" Subject: Re: [http-auth] [websec] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:48:21 -0000 On Tue, Jun 14, 2011 at 11:36 AM, Stephen Farrell wrote: > This is about http auth (and I'm glad to see the discussion) but can we keep it to just that list? The two lists I'm cc'ing now are appropriate for this. It wasn't obvious that websec might not be appropriate, though it should have been obvious that saag wasn't -- my MUA hides dups from me, so it's all too easy to hit reply-all. Nico -- From stephen.farrell@cs.tcd.ie Tue Jun 14 14:48:51 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3C11E81D6 for ; Tue, 14 Jun 2011 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.25 X-Spam-Level: X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8uFCtJvX0Pgc for ; Tue, 14 Jun 2011 14:48:50 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC111E81A2 for ; Tue, 14 Jun 2011 14:48:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A241915356D for ; Tue, 14 Jun 2011 22:48:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308088106; bh=yX1wVvyfIbp3mSvYbkQPdlwS 4aNPfWIQluAf8Jo3l5w=; b=AACoKnJnGnLS7TFWgyEP5ju6akQUSEDE6AfKGB7z 2irIrJX3PFxfqssk/ex70yUAf+qcWPfq2smpVaLoq7SKWuKQhuWpFMk0ZIAm5TYP p+y8T6iWWm6pMvkHAqHTO5y/WaS7UHcQ4BAnFNA4sKM4EL3vXZxf+99I3gXtfiGC OA6jG8V7hW0rTfSVtfuwKMdzY8dd+tmMpWyrqdp3tCgimf/UxlcpdgjMFxsBjKHe 6CtjUtIcz2s1d2PpbeqQoENXqbQsrMXBtaMDY/VeFqpo7gWy9OUgHeq9rPJiQOC4 0qqAPSQdUAb91TXCmOYENTKLvGPaA81mfxzvTJwzEG9JHg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id dlpvM73Sckce for ; Tue, 14 Jun 2011 22:48:26 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1EBB915356C for ; Tue, 14 Jun 2011 22:48:16 +0100 (IST) Message-ID: <4DF7D71B.2070004@cs.tcd.ie> Date: Tue, 14 Jun 2011 22:48:11 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [http-auth] Doing it the TLS mutual way... X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 21:48:51 -0000 Ok, here's my idea to throw on the pile. I'm not making a claim that it's perfect, or even better than whatever - the right thing here will be what's technically a sufficient improvement and that gets deployed - but nonetheless, I think this could work if it got traction, though of course its really only a strawman at this point. As it says below, Russ pointed out that this is quite like what the enroll WG tried to do a while back, so I'm clearly not suggesting something novel here either. Anyway if this isn't DoA, then I'd welcome someone else with the time and interest helping to turn it into an I-D with a bit more detail. And of course, this is just done as an individual, (a phrase I hate adding but seemingly necessary sometimes;-) S. A HTTP authentication scheme for public TLS mutual authentication ----------------------------------------------------------------- 2011-06-14a, stephen.farrell@cs.tcd.ie The Problem ----------- - TLS mutual authentication is too hard to deploy on the public Internet. - Password based authentication schemes leave server side databases vulnerable. - EKE/PAKE schemes may help but may require the verifier to store a database of values that are dictionary attackable and these schemes do require a password to be sent to the server at least at account creation and reset time. The Approach ------------ Try to use as much as possible of what we have now (TLS mutual authentication) and just make it more usable. Define a new HTTP authentication scheme that means: I'm going to ask you to do TLS mutual authentication in a moment. If you don't have a key pair for this <> already, then go <> for account creation during which you need to generate a key pair and send me the self-signed cert (SSC) with <> as the issuer and subject name and containing your <>-specific public key. Your <> identifier needs to be in a subjecAltName within that SSC. That can all happen in a couple of roundtrips with no human intervention or complex processing if all that's needed is to ensure key continuity (e.g. setting up some don't care account somewhere). Including key generation, that should be quicker and easier than typing even a well-worn password. If some higher level of assurance of the identifers used is needed, then initial signup might need to be following by validation of various identifiers, for example via a mail round-trip to validate that the client does have access to a particular email account. However, that is out of scope of this scheme and if needed should be handled via some form of workflow for account creation - this scheme is just one step in such a workflow. If you've signed up already then you should have a key pair for this <> so when the server does a STARTTLS equivalent it'll ask for a client cert issued by <> and you can use the SSC you generated earlier. If you want to access your account from another browser then you must first access <> from the first browser. At that point you will be shown a short-lived <> value. You must then go through the signup process from the new browser as usual but also including the <> value in order for us to securely accept that the new SSC also binds to the same <>. If you loose the private key or other state (e.g. SSC) from one browser environment, then so long as you have some other working browser you can re-associate your account with a new SSC from the (probably re-installed) browser that lost state in the normal way - this is just like adding a second browser. If you loose all private keys then you will have to contact support who will handle your account reset manually. The Details ----------- ...are almost all TBD. But this should be doable. Some initial notes below. This probably has to be done after initial server-authenticated TLS to preserve privacy of the account identifier. (With some more signup-time complexity, the server could give the client a secret to use to encrypt the account identifier. Not sure if that'd be worth it.) The server needs to add support for the new scheme and keep a database of public keys (or hashes) and account identifiers, or just SSCs. Servers would need an application layer add-on for account signup and for binding additional SSCs to accounts. TLS is unmodified. Server-side TLS accelerators would need to be modified slightly to play the protocol and pass on the account information in some form usable by current applications. There is no revocation. SSC "validity" should be long term and ignored on the TLS server. General HTTP proxies should not be affected. Browsers would need most change to add the signup logic and the new HTTP authentication scheme. There would need to be some chrome as well. The secret for binding a 2nd SSC to an account could be embedded in a URI which may help usability in some cases. Need to consider how to make sure this doesn't get in the way of existing enterprise TLS mutual auth uses. Need to consider a migration scheme for accounts with existing passwords. The service name could, but need not, be the service URL. Any string chosen by the server deployer should work. Need to check out what enroll did and why that didn't work. Acks ---- Russ Housley pointed out the enroll similarity and the issue of additional assurance of identifiers, e.g. via a mail round-trip. From yutaka-oiwa-aist-temp@g.oiwa.jp Tue Jun 14 15:46:34 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E611E8144 for ; Tue, 14 Jun 2011 15:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.034, 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 Fd4I2+QjZNga for ; Tue, 14 Jun 2011 15:46:34 -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 E5A6611E811E for ; Tue, 14 Jun 2011 15:46:33 -0700 (PDT) Received: by gxk19 with SMTP id 19so5204123gxk.31 for ; Tue, 14 Jun 2011 15:46:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.29.2 with SMTP id g2mr39986ybj.109.1308091593279; Tue, 14 Jun 2011 15:46:33 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.103.4 with HTTP; Tue, 14 Jun 2011 15:46:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 07:46:33 +0900 X-Google-Sender-Auth: bIWuwIZskZKs0zlP1QWrp3ZCdaY Message-ID: From: Yutaka OIWA To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 22:46:34 -0000 2011/6/15 Nico Williams : > On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann > wrote: >> Phillip Hallam-Baker writes: >>>what would we want HTTP authentication to look like? >> >> I have a suggestion for what it shouldn't look like: Any method that han= ds >> over the password (or a password-equivalent like a password in hashed fo= rm) as >> current browsers do should be banned outright, and anyone who implements >> hand-over-the-password should killed and eaten to prevent them from pass= ing on >> the genes. > > +1. +1, although the original statement is a bit too strong in wording for me := -) > =A0- Is this to be done in TLS? =A0HTTP? =A0Or at the application-layer? > > IMO: TLS is too low a layer to do authentication in, and doing it in > HTTP would require retrofitting too many HTTP stacks. =A0Doing it at the > application layer has a number of advantages. IMO, I agree that TLS is too low. However, although the application layer use-case exists, I believe that for general use cases HTTP-auth layer is more appropriate, because the trust relationship becomes much simpler. Backward-compatibility is important, and all intermediates *should* and *in most cases will* work well with new http authentication that completely complies with existing HTTP auth framework design. All they've needed is just forward auth-related headers to the origin serve= r. We've done some experiment around my proposal, and it worked quite well with all existing stacks, including proxies, "SSL accelerators" and load balancers. (Yes, we've carefully designed the protocol so that it can work in this way= .) Do you need some more detail on it? Required code modification is almost the same magnitude in both cases, because we need to change the client, and to add some server-side thing. we can keep all other intermediates as it is. Some client-side change is necessary in both cases to make mutual authentication trustful and unforgeable. In server-side, http-layer authentication can be implemented in either in the server or in the application. From nico@cryptonector.com Tue Jun 14 16:47:16 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D12D11E815B for ; Tue, 14 Jun 2011 16:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 k7mcd89+PD6L for ; Tue, 14 Jun 2011 16:47:15 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5D17F11E8154 for ; Tue, 14 Jun 2011 16:47:15 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id EF1AC67C073 for ; Tue, 14 Jun 2011 16:47:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=H7dAw0HHqu3kH2EQzy4dsVrBPXPQll3J3lhYUOXhR0JF 3iUFqTribMRijlO+2Fc//l56W3t3IuDUM9b86zDukPuBCbGd1boBfOAxSvrbGiqw 2ij7IBUGCIL+M0g/nlVF3lWDgsiDF45ftF/DyP/8EDmGHgFa1vTbDaBeDlK9buY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kVTKv8PKU1WGhM8EzaNKStJUmMc=; b=oNlnXRc8vWI bWUKbPy5vcEfTRWZTZdnePDDxJ0TNMf63p/R1cKGl4s2id1OmUAGpJYygWB5HN0e aNFnCiazJK2igG6NZBLJol7Oa0041xSW6IlxZPHZuif9r0i5LEiCDncnSIkWCKDB uMRR5xPS9Xlf5h86/nyXfBsDs9Mp17vg= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 92CF967C072 for ; Tue, 14 Jun 2011 16:47:14 -0700 (PDT) Received: by pvh18 with SMTP id 18so3162975pvh.31 for ; Tue, 14 Jun 2011 16:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr3566217pbc.523.1308095233938; Tue, 14 Jun 2011 16:47:13 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 14 Jun 2011 16:47:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 18:47:13 -0500 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 23:47:16 -0000 On Tue, Jun 14, 2011 at 5:46 PM, Yutaka OIWA wrote: > 2011/6/15 Nico Williams : >> On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann >> wrote: >>> Phillip Hallam-Baker writes: >>>>what would we want HTTP authentication to look like? >>> >>> I have a suggestion for what it shouldn't look like: Any method that ha= nds >>> over the password (or a password-equivalent like a password in hashed f= orm) as >>> current browsers do should be banned outright, and anyone who implement= s >>> hand-over-the-password should killed and eaten to prevent them from pas= sing on >>> the genes. >> >> +1. > > +1, although the original statement is a bit too strong in wording for me= :-) Why? >> =C2=A0- Is this to be done in TLS? =C2=A0HTTP? =C2=A0Or at the applicati= on-layer? >> >> IMO: TLS is too low a layer to do authentication in, and doing it in >> HTTP would require retrofitting too many HTTP stacks. =C2=A0Doing it at = the >> application layer has a number of advantages. > > IMO, I agree that TLS is too low. > However, although the application layer use-case exists, > I believe that for general use cases HTTP-auth layer is more appropriate, > because the trust relationship becomes much simpler. Can you explain what you mean by "the trust relationship becomes much simpl= er"? > Backward-compatibility is important, and all intermediates *should* and > *in most cases will* work well with new http authentication > that completely complies with existing HTTP auth framework design. Compatibility with existing installed base of HTTP stacks is a huge plus. Application-layer authentication can be implemented using CGI on the server-side, if you want the lowest common denominator, and practically every HTTP server has CGI support (even IIS!). This is a critical feature. > All they've needed is just forward auth-related headers to the origin ser= ver. Application-layer authentication also works whether there's proxies in the path or not. It is end-to-end because it is implemented by the application-layer end-points. This is also a critical feature. > Required code modification is almost the same magnitude in both cases, > because we need to change the client, and to add some server-side thing. With application-layer authentication one could make a CGI reference implementation that can be trivially installed and used on the vast majority of existing servers. With HTTP-layer authentication one must modify the HTTP servers that one uses. That's a huge difference in favor of application-layer authentication. Sure, CGI isn't great, but fast CGI is quite decent, and the important thing is to get deployment momentum -- optimization for each HTTP server can come later. > we can keep all other intermediates as it is. > Some client-side change is necessary in both cases to make mutual > authentication trustful and unforgeable. > In server-side, http-layer authentication can be implemented in either > in the server or in the application. The same is true for application-layer authentication, oddly enough. There is a bit of a dualism between HTTP- and application-layer authentication as long as the HTTP stacks expose enough request/response header interfaces to the application. On the client-side this duality is more complete than on the server-side. There's no reason that the HTTP stack couldn't implement application-layer authentication, and there's no reason that the application couldn't implement HTTP-layer authentication. However, there's no way to implement HTTP-layer authentication with CGI, and that's a big issue. There are other reasons to want application-layer authentication. For example, the application-layer authentication process need not reveal any information about what resources the client wishes to access unless the client tries to access a protected resource before authenticating, whereas with HTTP-layer authentication the client must access a harmless resource to get the same effect. This is another case where the duality of HTTP- and application-layer authentication is not complete. But let's say that the semantics and implementation and deployment considerations authentication at either layer are fully equivalent to those of authentication at the other layer... Then why shouldn't we just flip a coin to pick which layer to add authentication to? It is precisely because the duality mentioned above is not complete that we have good reasons to pick one layer or the other. Nico -- From y.oiwa@aist.go.jp Wed Jun 15 00:48:20 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE511E8094 for ; Wed, 15 Jun 2011 00:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=0.232, 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 1+mcRHg8f+Qy for ; Wed, 15 Jun 2011 00:48:19 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4EF11E8074 for ; Wed, 15 Jun 2011 00:48:19 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p5F7mCo3022040; Wed, 15 Jun 2011 16:48:13 +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=1308124094; bh=k3lxg1HDECyvtYu+7ZyDsI8L/6lNe5z4vhVcXu3sJeY=; h=Message-ID:Date:From; b=HU/mEQKNgp5wojORyoxoh7R0Mw8eP+IRg65iIf8O7QZpxWZNPMGbYZAY8cjuSi7Kc u/fIVOTLd48L6fS/MQ7FB+VQKfKhlbz0YWfwFCrHBd9R92YwiWiUqvOf72XIH6ug1B sPhU56G3GRne+nwX3rvp663wktz8TiRPMFytLajg= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p5F7mCv5010530; Wed, 15 Jun 2011 16:48:12 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id p5F7mB3K027595; Wed, 15 Jun 2011 16:48:12 +0900 (JST) env-from (y.oiwa@aist.go.jp) Message-ID: <4DF863BA.8090803@aist.go.jp> Date: Wed, 15 Jun 2011 16:48:10 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 07:48:20 -0000 Dear Nico, Thank you for very prompt comment. On 2011/06/15 8:47, Nico Williams wrote: >>> +1. >> >> +1, although the original statement is a bit too strong in wording for me :-) > > Why? Oh, just don't mind it in any technical way. I just didn't prefer the wording like killing or eating people or technologies and I have hesitated to put just "+1" with such things :-) Another factor possibly in my mind at that moment were that I personally expect the future transition to be more gradually, and I imagine the transition in some form of "gradually cease to exist", rather than "stop and go another way". Except for those trivial points, I agree that we should let people move to technologies not relying to handing over the "reusable raw authentication tokens", (including passwords, Digest password hashes, private keys and other tokens) to authenticators. >> IMO, I agree that TLS is too low. >> However, although the application layer use-case exists, >> I believe that for general use cases HTTP-auth layer is more appropriate, >> because the trust relationship becomes much simpler. > > Can you explain what you mean by "the trust relationship becomes much simpler"? OK. I'll be happy if you can treat the following comments as possible improvements proposal rather than critics. I like your proposal very much, especially for using it for replacing current authentications for internal communications initiated by script-based Web applications. It seems to be well designed, have enough flexibility (including introduction of mutually-authenticating underlying mechanisms) and useful semantics. You've mentioned in the draft that it can be implemented by client scripts, although browser support is preferred, and it can really improve the security of such applications. Maybe this is one of the reasons why Sam Hartman proposed abfab WG for possible discussion place. However, I have a concern in directly using it for improving the security of Web pages, e.g. against Phishing, which is the assumed use case of our proposal. But before entering to the main topic, I want firstly to discuss some web-page security model. The current model of Web page security is top-to-down hierarchal model. The topmost page, for which the address bar displays its location, must be secure: it must be careful not to refer any malicious external contents including images, applets and scripts, and all forms in that page must post to "trustful" servers. Not to have any XSS vulnerability is needless to say. And, importantly, this is the *necessary and sufficient* requirements for that page. As top-to-down, each scripts and other contents included from that page has the same requirements as necessary and sufficient conditions, too. Assuming this, all that users have to do is to think about whether the first page is trustful or not. And it is almost what they can do at most, with existence of client-side scripting. Phishing pages make this top trust checking difficult for users. Web-page mutual authentication will ensure the trust of this top page in effect. Carefully reading our draft, you may find that the user-agents are allowed to accept only new authentication requested by the top-most pages and ignore others, and the result from the top-page authentication must be displayed. Authentication algorithms are limited to those which provide equally-or-more cryptographically secure authentication, it provides mandatory binding to the originating host to prevent any forwarding, and authentication always happens within the same top-page URL and nothing else, as usual http auth does. These conditions are enough for browsers to trust authentication for the "whole" displayed page, when the above security model is assumed. In this perspective, your proposal seems to be currently too generic and too flexible for this specific purpose. Initiating authentication from the application layer makes more involvement of application-level contents, including iframe, XMLHTTP and others. The browser must be careful not to display any authentication results from any contents which are included by Phishing servers, or from authentication requests forwarded to genuine servers. Also, the GSS-REST login process involves several URLs, which brings it complicates to the security model and possible exploit points. To this purpose, if we're going to use your GSS-REST proposal for securing Web pages, I think we need to carefully define some subset "profile" which we can trust for this specific purpose, and do analysis of it against the security model. For example, it should limit the underlying GSS mechanisms to use, it should limit what resource can request new authentication to users, which set of URLs can be accepted for GSS-login, and in which set of URLs the created session URL can be, and for which resource the corresponding authentication result will be shown in UI. I found some good phrases in your security considerations section, but I think we need even more. I cannot judge whether this kind of restrictions increase or reduce the value of your proposal, because it sacrifices its good properties of flexibility a lot and introduces more complexities. If you're interested to go in this way, I'll be happy in collaboration to discuss what properties are really required for such a "profile". > But let's say that the semantics and implementation and deployment > considerations authentication at either layer are fully equivalent to > those of authentication at the other layer... I agree that HTTP auth and application auth have some duality in general. Also, with above restricted "profile", I agree that those two approaches are, in some sense, in duality. I personally think, at this moment, both proposals have some non-overwraping good use cases and is worth to go on both of them, rather than choosing one. I'd like, at this moment, firstly to investigate to define what kind of abstract properties are required for web authentications, considering for several use cases. The short-term goal of mine is to improve our problem statement document to discuss at Quebec and further. -- 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 nico@cryptonector.com Wed Jun 15 01:49:07 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E992E11E8094 for ; Wed, 15 Jun 2011 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-1.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 JqAWQE9RAWnS for ; Wed, 15 Jun 2011 01:49:07 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id EF6EF11E8092 for ; Wed, 15 Jun 2011 01:49:06 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 88DEB35007A for ; Wed, 15 Jun 2011 01:49:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=ERTlSXfLaVFnqficihcB1Cl5LE2zK1LpxxgCA/Ohxfzb 59r3GSqiLYRB43lEbN7zIlQkRMhAGE0NhkBCXODHD5/2ANqcKcxa7p6Uiow8dP6r nSJYptCM+rXkHyMtfmTCL6wfLMIz5c0AeLX8efAklRqcd0E9xVt6ID2IcOHOjTI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=YaQMyafD7JrOI8jQp0Reo3XxFt0=; b=IPq77bR3vVe ZvAJZPTLG/6+m4V8mnWTxl0nGSqALsiYQIuZHZkHsqAZvZT3FPf1gyVZ017Ut6TG 2cOLfLlGalOihm/MqX+CCdAZFjgL8tOahcxgVqmtLRp1IvlmoI2+RYaVl3aO8ML6 e7bvZ4ZfPGmBcy1Q85EAgkjH+Tm5AwOA= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 630A135005B for ; Wed, 15 Jun 2011 01:49:06 -0700 (PDT) Received: by pwi5 with SMTP id 5so262115pwi.31 for ; Wed, 15 Jun 2011 01:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.33 with SMTP id d1mr98173pbk.389.1308127745887; Wed, 15 Jun 2011 01:49:05 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 15 Jun 2011 01:49:05 -0700 (PDT) In-Reply-To: <4DF863BA.8090803@aist.go.jp> References: <4DF863BA.8090803@aist.go.jp> Date: Wed, 15 Jun 2011 03:49:05 -0500 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 08:49:08 -0000 On Wed, Jun 15, 2011 at 2:48 AM, Yutaka OIWA wrote: > On 2011/06/15 8:47, Nico Williams wrote: >>> IMO, I agree that TLS is too low. >>> However, although the application layer use-case exists, >>> I believe that for general use cases HTTP-auth layer is more appropriat= e, >>> because the trust relationship becomes much simpler. >> >> Can you explain what you mean by "the trust relationship becomes much si= mpler"? > > OK. =C2=A0I'll be happy if you can treat the following comments as possib= le > improvements proposal rather than critics. > > I like your proposal very much, especially for using it for replacing cur= rent > authentications for internal communications initiated by script-based Web > applications. It seems to be well designed, have enough flexibility (incl= uding > introduction of mutually-authenticating underlying mechanisms) and useful > semantics. =C2=A0You've mentioned in the draft that it can be implemented= by client > scripts, although browser support is preferred, and it can really improve= the > security of such applications. =C2=A0Maybe this is one of the reasons why= Sam Hartman > proposed abfab WG for possible discussion place. I don't recall Sam proposing that. As for my comment about scripts, it was in reference to demonstration: by having authentication at the application layer it's trivial to demonstrate the protocol without platform nor browser integration (if we have JS crypto). But I don't believe in trusted scripts, so the script comment is limited to demonstration. > However, I have a concern in directly using it for improving the security= of Web > pages, e.g. against Phishing, which is the assumed use case of our propos= al. > But before entering to the main topic, I want firstly to discuss some web= -page > security model. Do you agree that to defeat phishing (a subset of phishing anyways) we need: mutual authentication and channel binding? If not, what else do you think we need? Or what do we need instead? > The current model of Web page security is top-to-down hierarchal model. T= he > topmost page, for which the address bar displays its location, must be se= cure: > it must be careful not to refer any malicious external contents including > images, applets and scripts, and all forms in that page must post to "tru= stful" > servers. Not to have any XSS vulnerability is needless to say. =C2=A0And, > importantly, this is the *necessary and sufficient* requirements for that= page. I don't agree that that is necessary and sufficient. Consider a phishing attack where a user is directed to a domain that is confusable with one that the user trusts. And imagine that the malicious domain's servers have valid server certificates. The requirements you list above will not help the user detect such malicious services. Moreover, external contents, including scripts, is definitely allowed to be referred to from pages -- it certainly happens all the time > =C2=A0As top-to-down, each scripts and other contents included from that = page has the > same requirements as necessary and sufficient conditions, too. =C2=A0Assu= ming this, > all that users have to do is to think about whether the first page is tru= stful > or not. And it is almost what they can do at most, with existence of clie= nt-side > scripting. =C2=A0Phishing pages make this top trust checking difficult fo= r users. I don't think external content is at the root of phishing. > Web-page mutual authentication will ensure the trust of this top page in = effect. OK, so you agree that mutual authentication is part of this. > Carefully reading our draft, you may find that the user-agents are allowe= d to > accept only new authentication requested by the top-most pages and ignore > others, and the result from the top-page authentication must be displayed= . I don't find that at all. What makes you believe that's the case? And in any case, the problem is bound to be the same for HTTP-layer authentication -- after all, HTTP can't possibly know that some resource you're fetching is related to some other resource you've already fetched. The application has to be in charge of deciding when authentication is required, and the application has to use authentication whenever it's advisable. A browser should use authentication for a page and all contents referenced from it once the user initiated a login. If a secure page references external contents then the user agent has to be able to authenticate the services offering that content. There's no way that HTTP can automatically do this for the user agent. > Authentication algorithms are limited to those which provide equally-or-m= ore > cryptographically secure authentication, it provides mandatory binding to= the Equal to or more than... what? > originating host to prevent any forwarding, and authentication always hap= pens > within the same top-page URL and nothing else, as usual http auth does. T= hese > conditions are enough for browsers to trust authentication for the "whole= " > displayed page, when the above security model is assumed. Remember too that HTTP is used for things that aren't web pages, that aren't HTML. > In this perspective, your proposal seems to be currently too generic and = too > flexible for this specific purpose. Initiating authentication from the > application layer makes more involvement of application-level contents, > including iframe, XMLHTTP and others. The browser must be careful not to = display > any authentication results from any contents which are included by Phishi= ng > servers, or from authentication requests forwarded to genuine servers. = =C2=A0Also, > the GSS-REST login process involves several URLs, which brings it complic= ates to > the security model and possible exploit points. No, I think you've misunderstood. My proposal is just a protocol, browser UI elements (but only for browsers), and XMLHttpRequest extensions. The browser will have to get the UI elements right, particularly in the case of frames. Clearly frames and clickjacking complicate the situation _for the browser_, but not for the authentication _protocol_. The URLs used by REST-GSS are not visible to the user; they complicate nothing. > To this purpose, if we're going to use your GSS-REST proposal for securin= g > Web pages, I think we need to carefully define some subset "profile" whic= h we > can trust for this specific purpose, and do analysis of it against the se= curity > model. =C2=A0For example, it should limit the underlying GSS mechanisms t= o use, it > should limit what resource can request new authentication to users, which= set > of URLs can be accepted for GSS-login, and in which set of URLs the creat= ed > session URL can be, and for which resource the corresponding authenticati= on > result will be shown in UI. =C2=A0I found some good phrases in your secur= ity > considerations section, but I think we need even more. I just started on it. The Security Considerations section, and the section on UIs needs more work, clearly. But there's nothing here that's going to be particularly different than for HTTP-layer authentication. Or perhaps you can show me how you'd handle these problems in HTTP without addressing them in the application (I don't think you can, but maybe I'm simply not creative enough to see what should be obvious to me). > I cannot judge whether this kind of restrictions increase or reduce the v= alue of > your proposal, because it sacrifices its good properties of flexibility a= lot > and introduces more complexities. If you're interested to go in this way,= I'll > be happy in collaboration to discuss what properties are really required = for > such a "profile". Thanks. I think this is a sort of collaboration already, since we're actually going through these issues. >> But let's say that the semantics and implementation and deployment >> considerations authentication at either layer are fully equivalent to >> those of authentication at the other layer... > > I agree that HTTP auth and application auth have some duality in general. > Also, with above restricted "profile", I agree that those two approaches = are, in > some sense, in duality. =C2=A0I personally think, at this moment, both pr= oposals have > some non-overwraping good use cases and is worth to go on both of them, r= ather > than choosing one. I'd like to see more about those use cases for which only HTTP-layer authentication works well or at all. > I'd like, at this moment, firstly to investigate to define what kind of a= bstract > properties are required for web authentications, considering for several = use > cases. The short-term goal of mine is to improve our problem statement do= cument > to discuss at Quebec and further. Let's keep a few things clear too. There's properties of the authentication _protocol_, and properties of the _UIs_ (and APIs). We must address both, but they are not the same thing. Here's a start: 0) We need to distinguish between "secure page" as in "we used TLS" and "secure page" as in "we're logged in (and we used TLS)". For this we'll need new terminology. 1) Required properties of authentication protocols: 1a) mutual authentication; 1b) channel binding (because TLS is here to stay); 1c) must have a notion of login session. 2) Desired properties for authentication protocols: 2a) support for enterprise and Internet-scale authentication mechanisms; 2b) federation. 3) Required properties for _browser UIs_: 3a) must have a non-confusable trust path (e.g., browser chrome, secure attention sequences, particularly when full-screen apps are involved); 3b) must make clear to the user what page elements are authenticated OR must not mix authenticated and non-authenticated contents (this principle addresses the iframe issue, for example); 3c) non-external content references from logged in pages must be obtained using the same logged in session; 3d) external content references from logged in pages either must be disallowed or must require some clue from the page origin as to what to do with them (authenticate? use TLS and here's the external references' servers' TLS certs?); 3e) the UI must allow the user to distinguish between "secure" as in "used TLS with server certs" and "secure" as in "logged in (and used TLS)"; 3f) the UI must allow the user to see the authenticated names of the user and service. 4) Required properties for JavaScript APIs: 4a) the user agent must not expose all or any of the names of the user's credentials to the calling script; 4b) the user agent must not allow the calling script to authenticate to a different server than the one to which the authentication messages are ostensibly being sent, otherwise the script could abuse the user's credentials to login by proxy to other sites and gain control of those new sessions; 4c) ... What have I missed? (Keep in mind it's the middle of the night for me, so I'm sure I missed quite a few things.) Most of the above I either referred to explicitly in my presentation and I-D, or obliquely for lack of time. Thanks for you comments, particularly for elaborating on your trust issue. I don't believe the trust issue is germane to the authentication protocol, but it is germane to how the user agent uses authentication, and to the user agent UIs. Nico -- From bkihara.l@gmail.com Wed Jun 15 02:44:38 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6437F11E810E; Wed, 15 Jun 2011 02:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 akVtq69ceNwG; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C988711E8083; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: by pzk5 with SMTP id 5so123735pzk.31 for ; Wed, 15 Jun 2011 02:44:37 -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 :content-transfer-encoding; bh=Z6RqmxXDDYraRdQTDVasR9YrGFA5q0a4p694l5ZaNAo=; b=H7FdSdYBHUTUvljKTe7f23zaDsYNF3Oo5a8HTHnZpK04xY4wR3AI5BdIoM8g5qxBhV aIAjJ5KJ6NMdnvsdUehfh6WB/nZOiDEN/jIiVdfXOi4Nk5zjDw2R210mfOCxPLMBK11G 81Hbnqe/rAaD63Q8CNHQwjlLatQZC7w7NkqUM= 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:content-transfer-encoding; b=vIgUFkqoK38ynXz9ZFo9A3gtU2j6GXC9cu4wE4baRQUPdK6u0/gr8lrIKnIThqsTmg AZ8vkCBQIDgmeGdWFuQ/kIYGT5T7wIiUuNCyS5hsGQo1x2HcncTJyn9D0s+4PKBjUYj8 AVW4e14RdVPXuxjbNFwa46QMDIksaxjK6QmHU= MIME-Version: 1.0 Received: by 10.142.43.4 with SMTP id q4mr46697wfq.403.1308131077129; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: by 10.142.50.6 with HTTP; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 18:44:37 +0900 Message-ID: From: "KIHARA, Boku" To: Peter Gutmann , http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:44:38 -0000 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. To make the goal clear, let's list what kind of authentication methods should be avoided. One item is methods that hand over passwords, mentioned by Peter. Let me add methods whose UI can be imitated and the result can be forged by malicious sites. Like a padlock icon that insists the session is secured by TLS inside content area, Is a _secure_ authentication method inside content area truly reliable? * a method that hands over a password (or a password-equivalent) * a method whose UI can be imitated by malicious sites. Of course there might be more items, please append. # Peter, sorry for missing Ccs. -- KIHARA, Boku 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. > > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =A0There are endless d= esigns > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From bkihara.l@gmail.com Wed Jun 15 06:42:08 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA311E8149; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 IJ4rgJIDej6Q; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2E11E8126; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) Received: by pvh18 with SMTP id 18so328974pvh.31 for ; Wed, 15 Jun 2011 06:42:07 -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 :content-transfer-encoding; bh=EcJ17BR2lt3kRBLXsf2Q1auz6i3BQSHDKkxW5H1XMDI=; b=jKIexr+LBGmM7+AE6WF901awmITrRutLH/oeeKcoIqEiERN7etShI3SEemdv/nzKUk uW1WoogBOZN811CuumN2ltLznpkZ+iJBshpSWEiq61Q8GzjloGNm2cbPYk5CaameJdEn yMnTcDan9YO2jlDo82+Vs9v87rTsY7T2OUcnQ= 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:content-transfer-encoding; b=DEcpfC8RnCItC4zwi8LUnSmhKkXyn9J5tPMfHkWaRO2Frw/Sau9UsvK3POfMjhjtZF i2wxR2PoT9N/NAqffA4rJE7NLMtTYn9nk8ChGhrgbFrnvZ0tGnoxQ/9Q69TGDFHWxsWo RnTo2QyzzlMgF1BfWT7FgrxVdM4qB4wuEubao= MIME-Version: 1.0 Received: by 10.142.226.15 with SMTP id y15mr100697wfg.232.1308145326248; Wed, 15 Jun 2011 06:42:06 -0700 (PDT) Received: by 10.142.50.6 with HTTP; Wed, 15 Jun 2011 06:42:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 22:42:06 +0900 Message-ID: From: "KIHARA, Boku" To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-identity-request@w3.org, websec@ietf.org, saag@ietf.org Subject: [http-auth] Fwd: [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:42:08 -0000 Missing Ccs? Forwarding: ---------- Forwarded message ---------- From: David S. Misell MBCS CISSP <07710380044@o2.co.uk> Date: 2011/6/15 Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF To: "KIHARA, Boku" One time passwords should still be OK for poor auth methods, There is a series of SecurID based RFCs Kind Regards dave -original message- Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF From: "KIHARA, Boku" Date: 15/06/2011 10:45 am 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. To make the goal clear, let's list what kind of authentication methods should be avoided. One item is methods that hand over passwords, mentioned by Peter. Let me add methods whose UI can be imitated and the result can be forged by malicious sites. Like a padlock icon that insists the session is secured by TLS inside content area, Is a _secure_ authentication method inside content area truly reliable? * a method that hands over a password (or a password-equivalent) * a method whose UI can be imitated by malicious sites. Of course there might be more items, please append. # Peter, sorry for missing Ccs. -- KIHARA, Boku 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. > > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =A0There are endless d= esigns > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From tlr@w3.org Wed Jun 15 06:44:26 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA511E8145; Wed, 15 Jun 2011 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 f1qGXV3OW28X; Wed, 15 Jun 2011 06:44:26 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E911E8126; Wed, 15 Jun 2011 06:44:25 -0700 (PDT) Received: from [88.207.143.141] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1QWqOO-0002p8-OV; Wed, 15 Jun 2011 09:44:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Roessler In-Reply-To: Date: Wed, 15 Jun 2011 15:44:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "KIHARA, Boku" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 15 Jun 2011 07:11:18 -0700 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org, Thomas Roessler Subject: Re: [http-auth] [websec] Fwd: [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:44:26 -0000 Make that public-identity@w3.org, not public-identity-request@w3.org. ;) -- Thomas Roessler, W3C (@roessler) On 2011-06-15, at 15:42 , KIHARA, Boku wrote: > Missing Ccs? Forwarding: >=20 > ---------- Forwarded message ---------- > From: David S. Misell MBCS CISSP <07710380044@o2.co.uk> > Date: 2011/6/15 > Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth = BoF > To: "KIHARA, Boku" >=20 >=20 > One time passwords should still be OK for poor auth methods, There is > a series of SecurID based RFCs > Kind Regards > dave >=20 > -original message- > Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth = BoF > From: "KIHARA, Boku" > Date: 15/06/2011 10:45 am >=20 > 2011/6/14 Peter Gutmann : >> Phillip Hallam-Baker writes: >>=20 >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that = hands >> over the password (or a password-equivalent like a password in hashed = form) as >> current browsers do should be banned outright, and anyone who = implements >> hand-over-the-password should killed and eaten to prevent them from = passing on >> the genes. >=20 > +1. >=20 > To make the goal clear, let's list what kind of authentication methods > should be avoided. One item is methods that hand over passwords, > mentioned by Peter. Let me add methods whose UI can be imitated and > the result can be forged by malicious sites. Like a padlock icon that > insists the session is secured by TLS inside content area, Is a = _secure_ > authentication method inside content area truly reliable? >=20 > * a method that hands over a password (or a password-equivalent) > * a method whose UI can be imitated by malicious sites. >=20 > Of course there might be more items, please append. >=20 > # Peter, sorry for missing Ccs. >=20 > -- > KIHARA, Boku >=20 > 2011/6/14 Peter Gutmann : >> Phillip Hallam-Baker writes: >>=20 >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that = hands >> over the password (or a password-equivalent like a password in hashed = form) as >> current browsers do should be banned outright, and anyone who = implements >> hand-over-the-password should killed and eaten to prevent them from = passing on >> the genes. >>=20 >> The only permitted auth.form should be a dynamic, cryptographic = mutual auth. >> that authenticates both the client and the server. There are endless = designs >> for this sort of thing around so the precise form isn't too = important, as long >> as it's not hand-over-the-password. >>=20 >> Peter. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 From nico@cryptonector.com Wed Jun 15 07:17:28 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA70411E8122; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 N4JRsB65gO8y; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4611E8126; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id D88C72F407A; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=wSwspyTudS/X49eHq4yl+ 9Gk+P/41ChapW+tjx6gLG4BjjfLi53xxzeaRN6v9mnNMs+wPm0pzj+0MAQi23P42 ZLPTiyUmqit33V2T9Ut9yVDh6f95xgneam85zEHT/ZDgs7SkCt+cqm1eyEF2dUvR 2mTzYBJ1tyLJH31dfE1B5g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eUh8lQHLzyvX+JNOWocc CIg63dA=; b=f3qdqyDTSWEulQTzB/GCrO4OfCvtC5GUEsS5FAb/3VHkH64TSqO9 CZ0VuLqrLgxXc8RERWdSntUv6y03RDdOFXeNBBho8m8i+pbIlYcVrw9NshaFUlnW kYs0Gq3Pq8SqnB3uWQWPt0sft8oTsSaBtHNkDq70vPiGu4NZq8FCeKg= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id AC33E2F4076; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) Received: by pvh18 with SMTP id 18so365616pvh.31 for ; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.41.65 with SMTP id d1mr326960pbl.255.1308147447157; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 15 Jun 2011 07:17:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 09:17:26 -0500 Message-ID: From: Nico Williams To: "KIHARA, Boku" Content-Type: text/plain; charset=UTF-8 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org, Peter Gutmann Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:17:29 -0000 On Wed, Jun 15, 2011 at 4:44 AM, KIHARA, Boku wrote: > To make the goal clear, let's list what kind of authentication methods > should be avoided. One item is methods that hand over passwords, > mentioned by Peter. Let me add methods whose UI can be imitated and > the result can be forged by malicious sites. Like a padlock icon that > insists the session is secured by TLS inside content area, Is a _secure_ > authentication method inside content area truly reliable? > > * a method that hands over a password (or a password-equivalent) > * a method whose UI can be imitated by malicious sites. The protocol and UI are not that closely related. I can't think of any method that satisfies the first requirement that couldn't have a secure UI. Nico -- From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 15 07:25:01 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB511E8137 for ; Wed, 15 Jun 2011 07:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, 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 AnKgacAvbku3 for ; Wed, 15 Jun 2011 07:24:59 -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 961D711E8128 for ; Wed, 15 Jun 2011 07:24:59 -0700 (PDT) Received: by yxt33 with SMTP id 33so432931yxt.31 for ; Wed, 15 Jun 2011 07:24:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.253.15 with SMTP id a15mr864982ybi.223.1308147898774; Wed, 15 Jun 2011 07:24:58 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.103.4 with HTTP; Wed, 15 Jun 2011 07:24:58 -0700 (PDT) In-Reply-To: References: <4DF863BA.8090803@aist.go.jp> Date: Wed, 15 Jun 2011 23:24:58 +0900 X-Google-Sender-Auth: ZcMjsNahTZ0ZjkaO1-A6cL_AfjU Message-ID: From: Yutaka OIWA To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:25:01 -0000 Dear Nico, (I'm sorry to you for duplicated posting as I forgot Cc) I think that my point was not correctly explained to you. I'm very sorry that my phrasing are understood in very opposite way. 2011/6/15 Nico Williams : > Do you agree that to defeat phishing (a subset of phishing anyways) we > need: mutual authentication and channel binding? Yes, at least it is required. > If not, what else do you think we need? Or what do we need instead? > >> The current model of Web page security is top-to-down hierarchal model. The >> topmost page, for which the address bar displays its location, must be secure: >> it must be careful not to refer any malicious external contents including >> images, applets and scripts, and all forms in that page must post to "trustful" >> servers. Not to have any XSS vulnerability is needless to say. And, >> importantly, this is the *necessary and sufficient* requirements for that page. > > I don't agree that that is necessary and sufficient. > > Consider a phishing attack where a user is directed to a domain that > is confusable with one that the user trusts. And imagine that the > malicious domain's servers have valid server certificates. The > requirements you list above will not help the user detect such > malicious services. You're correct, but my intention was different. I guess you agree that Phishing is very different kinds of attack compared to XSS, CSRF, SQL injection and many others. Server admins and programmers can and must prevent XSS, CSRF, SQL injection and others, but they cannot prevent Phishers from creating the Phishing site. This is the first point. Then, to prevent Phishing users, not the server owners, must notice that Phishing is on going in some way. Currently users must be very careful, and mutual authentication can take this part. this is the second point. Then, the third point is: the users must have to check only the validity of the topmost page. And all others are server's responsibility to correctly refer all external information which requires. In this way, my requirement list is "what servers must do" and "what servers can do at most". My intent for the "sufficient" was: means "all what they ought to do". > Moreover, external contents, including scripts, is definitely allowed > to be referred to from pages -- it certainly happens all the time Yes, and if they are correctly referred to by the topmost page, it is OK for users. In anyway, the top-most page must be correctly written, as users cannot check all subrequests the page has made. > I don't think external content is at the root of phishing. I didn't said it... >> Web-page mutual authentication will ensure the trust of this top page in effect. > OK, so you agree that mutual authentication is part of this. Yes. >> Carefully reading our draft, you may find that the user-agents are allowed to >> accept only new authentication requested by the top-most pages and ignore >> others, and the result from the top-page authentication must be displayed. > > I don't find that at all. What makes you believe that's the case? Please see almost the last of section 8 "Decision procedure for client", the paragraph starting from "The client software SHOULD...". There is a special mention for interactive clients, which treats sub-requests in a different way than the topmost document. > And in any case, the problem is bound to be the same for HTTP-layer > authentication -- after all, HTTP can't possibly know that some > resource you're fetching is related to some other resource you've > already fetched. The application has to be in charge of deciding when > authentication is required, and the application has to use > authentication whenever it's advisable. > A browser should use authentication for a page and all contents > referenced from it once the user initiated a login. If a secure page > references external contents then the user agent has to be able to > authenticate the services offering that content. There's no way that > HTTP can automatically do this for the user agent. This is related to the second next question possibly... >> Authentication algorithms are limited to those which provide equally-or-more >> cryptographically secure authentication, it provides mandatory binding to the > Equal to or more than... what? ...Than the currently-defined crypto algorithm. >> originating host to prevent any forwarding, and authentication always happens >> within the same top-page URL and nothing else, as usual http auth does. These >> conditions are enough for browsers to trust authentication for the "whole" >> displayed page, when the above security model is assumed. > Remember too that HTTP is used for things that aren't web pages, that > aren't HTML. Yes, and it is actually used in two very different ways. One case is for subrequests, which are effectively part of the "Web page" and it will typically require the same authentication (or none) as the topmost page. For this kind of contents, which is the first main target of our proposal, works quite well with our design, as it works for existing HTTP authentications. The second use case is for application-issued requests (aka XMLHTTP request), which has very application-specific semantics for authentication. In this cases, it is better applications (in browser case, typically scripts which is in or referred to by the topmost document) will determine how they authenticate with resources. For such purpose GSS-REST is really good, OAuth also, and some people tends to use custom auth/authz implementation by their own. Our proposal, technically speaking, can be used as an underlying protocol, but our design and requirements for browsers are not considering this well, as this is not our main target. And in this case, Phishing is not a main target for preventing (the application typically knows which server to connect), but mutual authentication still gives a slight improvement for security, such as against transport-level or TLS-level (such as a false certificate) attacks. Another variant of the second case is completely non-Web applications which uses HTTP as just underlying transport for various reasons (simplicity, sharing code with the above second case, etc.) I appreciate requests for supporting non-browser use cases, and I really do it as a second target. And it is actually much more trivial than supporting browsers. >> In this perspective, your proposal seems to be currently too generic and too >> flexible for this specific purpose. Initiating authentication from the >> application layer makes more involvement of application-level contents, >> including iframe, XMLHTTP and others. The browser must be careful not to display >> any authentication results from any contents which are included by Phishing >> servers, or from authentication requests forwarded to genuine servers. Also, >> the GSS-REST login process involves several URLs, which brings it complicates to >> the security model and possible exploit points. > No, I think you've misunderstood. My proposal is just a protocol, > browser UI elements (but only for browsers), and XMLHttpRequest > extensions. The browser will have to get the UI elements right, > particularly in the case of frames. Clearly frames and clickjacking > complicate the situation _for the browser_, but not for the > authentication _protocol_. The URLs used by REST-GSS are not visible > to the user; they complicate nothing. Yes. I have actually no doubt for the "a protocol" and "XMLHttpRequest" part. My concern is only on the UI element part, which must be really carefully designed to prevent misunderstanding by users. I think we do not need too much details on the some questions below, as I believe that I can understand, mostly agree on your point and go productively. so skipping... > I'd like to see more about those use cases for which only HTTP-layer > authentication works well or at all. Technically we can tunnel both protocols into another layer by defining too-restrictive hard-coded rules (because what you're doing in apps-layer is actually in HTTP request, so we can easily exchange the role of body and headers), but I think we certainly need such restrictions to work well. One point we are in disagreement on this is possibly that you're estimating cost of introducing http-layer auth extension too expensive. Of course, adding new request method (e.g. GET, POST etc.) or new tunneling protocol (Upgrade:) is extremely extensive, because we really have to upgrade all servers and all intermediates. On the contrary, adding new authentication does not change all request binary structure and thus it should go though all existing intermediates. At least ours can be used with all intermediates which can pass Digest authentication. We actually did field experiments in a part of Yahoo! Japan web systems, which has a complex internal structures with intermediate proxies and accelerators, and it worked quite well. Adding auth protocol to the servers is modularized in most production-level Web servers, and also many language platforms (e.g. PHP) actually support passing authentication requests transparently to the apps layer so that application framework can handle authentication. If application are relying on the such platform- or server-provided authentication, ours can be introduced to the server-side with almost no cost. For general cases we need to change some framework part to adopt new authentication, but the cost is comparable to change some framework for new apps-layer authentication. Now I love to go to the next step... > Let's keep a few things clear too. There's properties of the > authentication _protocol_, and properties of the _UIs_ (and APIs). We > must address both, but they are not the same thing. > > Here's a start: Let's go :-) > 0) We need to distinguish between "secure page" as in "we used TLS" > and "secure page" as in "we're logged in (and we used TLS)". For this > we'll need new terminology. > > 1) Required properties of authentication protocols: > > 1a) mutual authentication; > 1b) channel binding (because TLS is here to stay); > 1c) must have a notion of login session. > > 2) Desired properties for authentication protocols: > > 2a) support for enterprise and Internet-scale authentication mechanisms; > 2b) federation. > > 3) Required properties for _browser UIs_: > > 3a) must have a non-confusable trust path (e.g., browser chrome, > secure attention sequences, particularly when full-screen apps are > involved); Agreed to this point. > 3b) must make clear to the user what page elements are authenticated > OR must not mix authenticated and non-authenticated contents (this > principle addresses the iframe issue, for example); Hmm, I can doubt this. In our application story, the top-most page must be authenticated, but the subrequests can be done in either ways. If the top-most page is correctly written (it is the server's responsibility), it refers all HTTPS sub-contents not user-autheticated, and if we can either trust CAs or have "LockCA" feature of Strict Transport Security, the security will not be broken. Currently, HTTP auth _does not_ require all-or-nothing, and HTTPS _does_ require all-or-nothing which make some people irritating :-) Actually, it can be in either design and people can decide. # My personal feeling for the mixed contents on HTTPS is # "not acceptable" for hard contents (e.g. scripts, HTML and style-sheets) # but "acceptable" for just images if they need. This is also related to the next two issues. > 3c) non-external content references from logged in pages must be > obtained using the same logged in session; > 3d) external content references from logged in pages either must be > disallowed or must require some clue from the page origin as to what > to do with them (authenticate? use TLS and here's the external > references' servers' TLS certs?); So, to this part, actually we can have several designs. One important point here is that, even for the applications which needs those strong properties and does it correctly, loosening these rules 3b-3d to non-mandatory will not sacrifice the security of such applications. Even without these they can make it secure by themselves. And loosening these rules will certainly benefit some other applications. (On the contrary, for example, allowing non-mutual authentication to use the same secure UI (which violates (or whatever worse) 3a, 3e and 0) will make secure application a "victim" of forged Phishing attacks.) And loosening these rules will certainly benefit some other applications. So there will be a design choice. For 3d), I agree that we need to provide some additional clues for them so that the pages can use these if wanted, even when we do't let it mandatory.) > 3e) the UI must allow the user to distinguish between "secure" as in > "used TLS with server certs" and "secure" as in "logged in (and used > TLS)"; Yes. > 3f) the UI must allow the user to see the authenticated names of the > user and service. For the user yes, and in federation case also for the service. # But, if this includes script-initiated request cases, it is *not always* true: they can implement more complicated access patterns like OAuth-like delegation, or using temporarily-generated id/credential pair to authenticate to third-party resource servers. In such case showing such internal authentication ID might be inappropriate, although mutual authentication is still very useful. For "4) Required properties for JavaScript APIs", sorry I don't have enough concrete idea at this point. > Thanks for you comments, particularly for elaborating on your trust > issue. I don't believe the trust issue is germane to the > authentication protocol, but it is germane to how the user agent uses > authentication, and to the user agent UIs. Thank you very much, too. Your comments and summarization really help my understanding becoming much clearer. From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 15 07:32:34 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234C11E8122; Wed, 15 Jun 2011 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, 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 n4V5d0z9ErsH; Wed, 15 Jun 2011 07:32:34 -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 CC30111E80A9; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) Received: by yxt33 with SMTP id 33so441341yxt.31 for ; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.13.17 with SMTP id 17mr870058ybm.394.1308148353251; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.103.4 with HTTP; Wed, 15 Jun 2011 07:32:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 23:32:32 +0900 X-Google-Sender-Auth: qJq8zE8oN7vb9v05HcDSM661CcM Message-ID: From: Yutaka OIWA To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org, websec@ietf.org, public-identity@w3.org, saag@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:32:34 -0000 2011/6/15 Nico Williams : >> * a method that hands over a password (or a password-equivalent) >> * a method whose UI can be imitated by malicious sites. > The protocol and UI are not that closely related. =A0I can't think of > any method that satisfies the first requirement that couldn't have a > secure UI. How about a simple form-field extension which encrypts some password with timed challenges? OK, but your point suggests the following rephrasing: * a UI which can be imitated by malicious sites. Although they are not closely related, but we cannot completely ignore the UI issues . I think that protocol designs should, in some extent, consider how such UI is to be provided (especially when and how they are kicked in). How about it? From nico@cryptonector.com Wed Jun 15 07:36:10 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727321F8444 for ; Wed, 15 Jun 2011 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.991 X-Spam-Level: X-Spam-Status: No, score=-2.991 tagged_above=-999 required=5 tests=[AWL=-1.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 AVg-QwQP-SUz for ; Wed, 15 Jun 2011 07:36:09 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 00FD521F84A1 for ; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BF39BB805C for ; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Z/eGIlmxvPC2LwoPFAqxMC0TAkmUCw1itMJMYvZ+w5Qj 6KAy2fuBSKzOZEJRFiu1DwlphIWxMdaMLTpD0IRrQuQco8qzHx+70XfjTcuVmMtb ynhqY5X7WXb46FBWY+zsA5IQnXtgSvbo2ZeSBuyVYgRMdclA5NymopSWuS/5eRc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wpsCN/IVYVz2ZygePacavxraP4E=; b=S/8yYiBiPJX 7zMgCqCYrENrtxGB0wcgQxmADXBt9bzOAOVX2ovX0Ddpb2dAf9QRiXJIy8Mwurzr yzme9YZwePcNNhLV3uwMnwz0lW51g8ErjmtzBtlFB9jpEMrtpZyahssXQ+GT8fh/ 577bPNjarCzNmxch3ZvJGeCXk+sQzvxM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id A3D67B805B for ; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) Received: by pzk5 with SMTP id 5so338870pzk.31 for ; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.34.97 with SMTP id y1mr352749pbi.188.1308148541265; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 15 Jun 2011 07:35:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 09:35:41 -0500 Message-ID: From: Nico Williams To: Yutaka OIWA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org, public-identity@w3.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:36:10 -0000 On Wed, Jun 15, 2011 at 9:32 AM, Yutaka OIWA wrote: > 2011/6/15 Nico Williams : >>> * a method that hands over a password (or a password-equivalent) >>> * a method whose UI can be imitated by malicious sites. > >> The protocol and UI are not that closely related. =C2=A0I can't think of >> any method that satisfies the first requirement that couldn't have a >> secure UI. > > How about a simple form-field extension which > encrypts some password with timed challenges? > > OK, but your point suggests the following rephrasing: > > =C2=A0* a UI which can be imitated by malicious sites. > > Although they are not closely related, but we cannot completely > ignore the UI issues . I think that protocol designs > should, in some extent, consider how such UI is to be provided > (especially when and how they are kicked in). How about it? I think what you want is to say that the user agent must implement a secure UI, or that it must integrate with the platform's secure UIs, if any. The UI is quite distinct from the authentication protocol. I agree that a UI that cannot be imitated is a good and desirable thing, but as long as full-screen applications are allowed you'll need a secure attention sequence instead. Nico -- From nico@cryptonector.com Wed Jun 15 12:54:08 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B706D11E817C for ; Wed, 15 Jun 2011 12:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Vpzn6Kbs6Zqv for ; Wed, 15 Jun 2011 12:54:08 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 27A8611E8146 for ; Wed, 15 Jun 2011 12:54:08 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2D5A550807D for ; Wed, 15 Jun 2011 12:54:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=CogpUNCTCOZzUTzsR9wVp jrBo03UO7H1zwobF9MoiX0qHZwTxhAydjgron6Xa9C9ckh3rCRXy3NZbm/oXVTni EyS7OYPSvJcV0emj21tV1562XIKgMJQn9hbOzIFn2sj2siMdoZSzWDpQ3Stm4j9N qrG33URam9lf3AqHbzv5FI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=wQqm/Q1gt5vYrHfXuh6B FXCpLBY=; b=hAKa9JfsAR6ka26riywOU1vFAsN19OlwDilXfjYnqaEtKKFW6OBA vHp3xKjuWD3eJyclZUgYDj8byCbeu+4Gyeff6PW6gnznuJ2ESFAbObU0zK48JklS 7ub71ojSDEjsjX/GYxK5N/DosU5mKB4PExEx5lJmnX9WCN/lyPAU1Mc= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 702BE508084 for ; Wed, 15 Jun 2011 12:53:25 -0700 (PDT) Received: by gyf3 with SMTP id 3so31947gyf.31 for ; Wed, 15 Jun 2011 12:53:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.163.31 with SMTP id q31mr75579ago.108.1308167604789; Wed, 15 Jun 2011 12:53:24 -0700 (PDT) Received: by 10.90.95.17 with HTTP; Wed, 15 Jun 2011 12:53:24 -0700 (PDT) In-Reply-To: <4DF7D71B.2070004@cs.tcd.ie> References: <4DF7D71B.2070004@cs.tcd.ie> Date: Wed, 15 Jun 2011 14:53:24 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Doing it the TLS mutual way... X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 19:54:08 -0000 On Tue, Jun 14, 2011 at 4:48 PM, Stephen Farrell wrote: > As it says below, Russ pointed out that this is quite like > what the enroll WG tried to do a while back, so I'm clearly > not suggesting something novel here either. Something not too unlike this was presented at the W3C IDBROWSER workshop, and several people have suggested something along these lines at various times (including at that workshop, where even I mentioned something of the sort as a possible alternative to my proposal). > The Problem > ----------- > > - TLS mutual authentication is too hard to deploy on the public > Internet. PKI doesn't gives us strong mutual authentication. Or even strong authentication at all in a PKI with too many root CAs and too many principals to really validate them all. Thus you're not actually proposing a user cert PKI. In other words, this doesn't get us mutual authentication because the servers will continue to be authenticated as weakly as they are today. This could be addressed by having services whose job is to whitelist other services. For example, suppose I'm shopping: I could use a user cert from a shopping federation and my browser could be smart enough to go ask that federation if any given server I'm visiting has the right cert. This would be more than a remote cert validation service. It's at least a remote server cert pinning service, but better than that, it can be a remote whitelist. This would allow us to get strong mutual authentication from TLS. (Yes, the TLS server cert PKI sticks in my craw.) > - Password based authentication schemes leave server side > databases vulnerable. But they could be pass-through schemes such that the RP doesn't have to have access to it, thus you minimize the attack surface. This is the sort of thing that ABFAB WG is working on. (I'm assuming you meant things like DIGEST-MD5 here.) > - EKE/PAKE schemes may help but may require the verifier to store > a database of values that are dictionary attackable and these > schemes do require a password to be sent to the server at least at > account creation and reset time. The above comment applies to this as well. > The Approach > ------------ Options for getting the user certs issued/enrolled would include: - a certification protocol for enrollment and/or remote access to user certs (basically issue a new, short-lived cert when the user authenticates to the "IdP"); - a cert registration protocol for registering self-signed certs as RP-only user certs. SACRED could be another option for remote access to credentials. And yet I don't like this approach, nor any of the possible variants. I much prefer doing authentication at a higher layer, with channel binding to TLS -- this would require zero changes to TLS (particularly when using tls-server-end-point as the channel binding type) and HTTP (at most one might need a new HTTP error code). Application-layer authentication could even be implemented, on the server-side, as CGI programs to get massive adoption to be trivial (no need to upgrade existing code, just install new code). Whereas schemes based on TLS user certs seem to require at least somewhat invasive changes to TLS and HTTP. Still, I'd live with this approach IF we also did something to improve authentication of the service to the user. So far no one who proposes TLS user cert approaches proposes any way to strengthen server authentication, and that has me quite concerned: this may be the only chance we get for many years to improve authentication of the servers to the users -- let's not blow it! Nico -- From stephen.farrell@cs.tcd.ie Wed Jun 15 16:01:40 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7421F847E for ; Wed, 15 Jun 2011 16:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Hsu-sRAWvby4 for ; Wed, 15 Jun 2011 16:01:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9221F847D for ; Wed, 15 Jun 2011 16:01:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1FA7315356F; Thu, 16 Jun 2011 00:01:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308178887; bh=V3TPLw//80xrrq i0pmAQQ21ZjzyljdqThQi2xiAJcJU=; b=Nn3yAS81G4lN3PC7CraQE69RJR2JNh cMPgn0ONCQqeQNB/RHKANwfEODv/0ADOOKsbDvQarxQjLisyVQaiyP7qneh69q5e BUbqXMzgyapxAbPm/YWoX1/S3BvdW4bgr/9CqYxNtDt//uoAHGy7/hCj+yu5QTih kf3mx18enSi0Cypz+bz7S4LfpkS9Ia+0S4+3vvkeCgrb1L/Ugfi14VNLNqukQSdD WAVJyjkurbRHpqdbjV6HZTbVfhf0SA2/4CCvx5GsqEeMHLhv7x+dSA214pe4BYal uaLT0Zsufu0qig8R/4bVhqlEdk2FOhqWaKmVZE37C6HhpCjjwBO88gOg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YphPy+z+YT2n; Thu, 16 Jun 2011 00:01:27 +0100 (IST) Received: from [10.87.48.10] (unknown [86.45.58.227]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A800A171C20; Thu, 16 Jun 2011 00:01:27 +0100 (IST) Message-ID: <4DF939BC.9070401@cs.tcd.ie> Date: Thu, 16 Jun 2011 00:01:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <4DF7D71B.2070004@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Doing it the TLS mutual way... X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 23:01:40 -0000 Hi Nico. Skipping over stuff where I'd agree or maybe quibble a bit to the meaty part: On 15/06/11 20:53, Nico Williams wrote: > And yet I don't like this approach, nor any of the possible variants. > > I much prefer doing authentication at a higher layer, with channel > binding to TLS -- this would require zero changes to TLS (particularly > when using tls-server-end-point as the channel binding type) and HTTP > (at most one might need a new HTTP error code). Application-layer > authentication could even be implemented, on the server-side, as CGI > programs to get massive adoption to be trivial (no need to upgrade > existing code, just install new code). Whereas schemes based on TLS > user certs seem to require at least somewhat invasive changes to TLS > and HTTP. I don't think a TLS change is needed for this approach, other than maybe in terms of the interface between a server's TLS accelerator and the backend, however, there is a fair point that higher layer authentication is different and can be as good. I suspect that the TLS mutual approach might be easier to do, but that's just me arm-waving at this point really. I think that's ok though - I reckon we're at the point of trying to identify options that can meet our security requirements. After that we'll have to see which, if any, of those might get real deployment and then figure out the relevant details. At least that where I think we're at. (And before anyone says it: I do not think we should go off and write up those requirements in an RFC. This is not our first attempt at this and the minutiae of the requirements matter far less than adoption of something that's really better than current password schemes.) > Still, I'd live with this approach IF we also did something to improve > authentication of the service to the user. So far no one who proposes > TLS user cert approaches proposes any way to strengthen server > authentication, and that has me quite concerned: this may be the only > chance we get for many years to improve authentication of the servers > to the users -- let's not blow it! Better server auth is also a fair point - however that might be somewhat less pressing were client credentials not immediately stealable from backend databases. Could be that DANE might provide an approach to help in that respect were we to take this TLS mutual approach. I totally agree that *if* this activity results in something new actually being deployed then we better do a good job because we won't get another chance if we do a bad job. However, I also think that we had better not scare off the punters by demanding more security perfection than is possible. Put another way - actual deployment here trumps most things so long as whatever gets deployed is a real improvement. S. From pgut001@login01.cs.auckland.ac.nz Fri Jun 17 01:39:02 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08122800C; Fri, 17 Jun 2011 01:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 yPC7SWDwqd2K; Fri, 17 Jun 2011 01:39:01 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C415722800B; Fri, 17 Jun 2011 01:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1308299941; x=1339835941; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nico@cryptonector.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[saag]=20[websec]=20[http-auth]=20re-ca ll=20for=20IETF=20http-auth=20BoF|Cc:=20hallam@gmail.com, =20http-auth@ietf.org,=20julian.reschke@gmx.de,=0D=0A=20 =20=20=20public-identity@w3.org,=20saag@ietf.org,=20webse c@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2017=20Jun=20201 1=2020:38:45=20+1200; bh=vzoGqdzEGFYr2A19mGZEcWkLf5wzBjThQhZ+tz4RHkg=; b=UNnW1KZIZeEntiO6/jo+DuF12GZlgxOaepJ2XQ09qNj3BsW8MGE297w9 MXC5RfZBy1WRcuaaUjae2X6FTaL5AuK2RI1Ez+8HGxbsYDu80ynmQ0czr rQ9wRDbkP1k2C7dOu3FePKmteAMDt1f1uIn0+eWEOXJIbNQmcoIoK4tal Y=; X-IronPort-AV: E=Sophos;i="4.65,380,1304251200"; d="scan'208";a="67846850" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Jun 2011 20:38:46 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QXUZh-0007ac-J0; Fri, 17 Jun 2011 20:38:45 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QXUZh-0007S2-RN; Fri, 17 Jun 2011 20:38:45 +1200 From: Peter Gutmann To: nico@cryptonector.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Fri, 17 Jun 2011 20:38:45 +1200 Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 08:39:02 -0000 Nico Williams writes: >Some aspects of the designs are important. Definitely. Before we launch into the inevitable bikeshedding, I think we should set out what it is we're documenting/specifying (since this is copied across several lists, it's a bit hard to see what the target/goal is). Is it a new crypto mutual-auth mechanism? A recommendation to use crypto mutual auth? Is it for browsers/HTTP, or general use? Is it a MUST for a protocol, or a BCP, or an informational RFC? If we're going to go into UI issues then it's probably going to be an informational RFC, which won't have much effect on browser behaviour, while if it's a crytpto mutual-auth protocol for HTTP that'll become a MUST (I hope so!) then we're not really going to be able to lay out requirements for UI design. >Shall we have just one authentication mechanism? *If* the idea is to specify a new auth mechanism and *if* it's for browsers and similar devices, I'd just say "Use EAP with X", it's been studied and spec'd to death, there's lots of implementations, it's pretty simple to do, etc. >at the application layer and in a RESTful way: I would really, *really* prefer to not invent another auth mechanism. There'd have to be a pretty strong argument to not use what we've already got. I happen to like EAP because it's simple, already spec'd out for lots of things (including cellphones via SIMs and other non-browser devices), and you can just say "use this", as long as "this" is profiled a bit to be something more specific than "any EAP mechanism you feel like". Peter. From nico@cryptonector.com Fri Jun 17 08:25:32 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAE11E8182; Fri, 17 Jun 2011 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 Vq6Aw6zSZWpk; Fri, 17 Jun 2011 08:25:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0211E8171; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 82C8B6B0078; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=YaMqgcQ4NriwpkftVtnIwXO6s61pzwNGPOYn3cQcC8Ol ABPGPFKXxcm5rekh6Lf0BAr7JH1tRDypV1CZMInwwOn+/eKmDWrR30QcVY9kzfDH 7DIEoi/FnMjUR5w9bjAweR0rnZ2y9VniMwCUO/ma8iU1BfGCHSqESW+hz7fmyuU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Tfe+v6f1TOC1aW5HqhH3L0mPT3g=; b=AWeT1Np9mEX Hxp+sK5Yu2GfmhRVnB3mJsHfP0daQ+rqkntACBogn64AfxynTCHakSI9oVWDWbc1 JJwNKjHgc+5c8zoyJ+VsjH+My6IQRYR863NPjbAWSIbHzZ5kcVI2wQHeWxuaVz25 uFl6Oj/a5xoaTab3W4LWCbEVXwje91x4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 555936B0070; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) Received: by pzk5 with SMTP id 5so2110761pzk.31 for ; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.59.198 with SMTP id b6mr1157786pbr.6.1308324325731; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) Received: by 10.68.54.197 with HTTP; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jun 2011 10:25:25 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:25:32 -0000 On Fri, Jun 17, 2011 at 3:38 AM, Peter Gutmann wrote: > Nico Williams writes: >>Shall we have just one authentication mechanism? > > *If* the idea is to specify a new auth mechanism and *if* it's for browse= rs > and similar devices, I'd just say "Use EAP with X", it's been studied and > spec'd to death, there's lots of implementations, it's pretty simple to d= o, > etc. CHeck out what ABFAB WG is doing then! ;) (Hint: they're making a GSS-API security mechanism based on EAP. Now, if only there were a way to use that well in HTTP.) >>at the application layer and in a RESTful way: > > I would really, *really* prefer to not invent another auth mechanism. =C2= =A0There'd > have to be a pretty strong argument to not use what we've already got. = =C2=A0I > happen to like EAP because it's simple, already spec'd out for lots of th= ings > (including cellphones via SIMs and other non-browser devices), and you ca= n > just say "use this", as long as "this" is profiled a bit to be something = more > specific than "any EAP mechanism you feel like". Ah, but I'm not proposing that we invent any new mechanisms. Mind you, I'd not mind more mechanism choices, but I'm not proposing new ones. I'm proposing a way to use the set of mechanisms we have in HTTP without modifying HTTP nor TLS. Nico -- From Josh.Howlett@ja.net Fri Jun 17 09:12:09 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC08B11E813B; Fri, 17 Jun 2011 09:12:09 -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 tYBYCYiKSfBC; Fri, 17 Jun 2011 09:12:08 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F611E80DB; Fri, 17 Jun 2011 09:12:08 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7A16C1A9A808_DFB7CD5B; Fri, 17 Jun 2011 16:12:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 5FE831A9A800_DFB7CD5F; Fri, 17 Jun 2011 16:12:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 17 Jun 2011 17:11:40 +0100 From: Josh Howlett To: Nico Williams , Peter Gutmann Thread-Topic: [saag] [websec] [http-auth] re-call for IETF http-auth BoF Thread-Index: AQHMJrOA2X+WbfAeoEeB/qjJgezzBJS4pd8AgAObwgCAAL0xAIAENvOAgABxn4CAAB3LgA== Date: Fri, 17 Jun 2011 16:11:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <848963300C67714B999CDBF7C3D42472@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "public-identity@w3.org" , "websec@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "hallam@gmail.com" Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:12:09 -0000 On 17/06/2011 16:25, "Nico Williams" wrote: >On Fri, Jun 17, 2011 at 3:38 AM, Peter Gutmann > wrote: >> Nico Williams writes: >>>Shall we have just one authentication mechanism? >> >> *If* the idea is to specify a new auth mechanism and *if* it's for >>browsers >> and similar devices, I'd just say "Use EAP with X", it's been studied >>and >> spec'd to death, there's lots of implementations, it's pretty simple to >>do, >> etc. > >CHeck out what ABFAB WG is doing then! ;) Just by way of information for Peter's benefit, we have an ABFAB implementation -- and we've demonstrated ABFAB-based EAP authentication with Firefox and Apache by leveraging their existing support for the HTTP Negotiate scheme. I also agree with Peter's argument, although there are other benefits to EAP that he doesn't mention. It supports a diverse range of authentication methods, which means that deployers are not required to use a particular type of credential - they can use whatever type of credential best suits their needs. In addition, with EAP Pass-Through the web server does not need to understand the credential technology being presented by the user; the web server can be entirely agnostic with respect to the credential technology being used by EAP (modulo some basic security properties that enable GSS magic to happen). >>>at the application layer and in a RESTful way: >> >> I would really, *really* prefer to not invent another auth mechanism. >>There'd >> have to be a pretty strong argument to not use what we've already got. >>I >> happen to like EAP because it's simple, already spec'd out for lots of >>things >> (including cellphones via SIMs and other non-browser devices), and you >>can >> just say "use this", as long as "this" is profiled a bit to be >>something more >> specific than "any EAP mechanism you feel like". > >Ah, but I'm not proposing that we invent any new mechanisms. Mind >you, I'd not mind more mechanism choices, but I'm not proposing new >ones. I'm proposing a way to use the set of mechanisms we have in >HTTP without modifying HTTP nor TLS. Nico's proposal definitely adds significant value to EAP (ABFAB) based authentication, relative to transport-bound Negotiate. I would like to see GSS REST happen. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From nico@cryptonector.com Fri Jun 17 10:19:05 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A482C21F8548 for ; Fri, 17 Jun 2011 10:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 yfR5XqnZaPpa for ; Fri, 17 Jun 2011 10:19:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D844F21F8542 for ; Fri, 17 Jun 2011 10:19:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 1F89567C06D for ; Fri, 17 Jun 2011 10:18:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=utdBTx0qbqf6nMaUmTl4K aHNH56iiwv+Y7sH1dnFVTlGZXEEwj3QU0DdUZUT8TBQ7coKFVlQcvDojpiO80mLp lF+IXQLhXrx+XMkSpr5QLXq9w52yCW7S5W34eZGYHx+06lvCSaxYxF3n+flw8kWq dYarNtdHF0c9BH6f9VMq0k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=qaAQs0YOxI3QxOAoS7dn M82fHGA=; b=MQEZPXM2bjW//BF6RzByY5EfKjOkdAQYmCTZmIUrbl1JhwNy66Jx WFhYRKUXa2mAXKHYBJrEEz9+qISKoEYDCH08o9Dh3dA3FWszUVbrq2B07Nfaupzp CCYbc01lor41Ss+HhOuy81EyCY/pc/HCxtZv2B0GNDi72Vq0T9EGnpk= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id F3E0767C069 for ; Fri, 17 Jun 2011 10:18:44 -0700 (PDT) Received: by pvh18 with SMTP id 18so2276790pvh.31 for ; Fri, 17 Jun 2011 10:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.18.162 with SMTP id x2mr1177624pbd.274.1308331124483; Fri, 17 Jun 2011 10:18:44 -0700 (PDT) Received: by 10.68.54.197 with HTTP; Fri, 17 Jun 2011 10:18:44 -0700 (PDT) In-Reply-To: <4DF939BC.9070401@cs.tcd.ie> References: <4DF7D71B.2070004@cs.tcd.ie> <4DF939BC.9070401@cs.tcd.ie> Date: Fri, 17 Jun 2011 12:18:44 -0500 Message-ID: From: Nico Williams To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Doing it the TLS mutual way... X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:19:05 -0000 On Wed, Jun 15, 2011 at 6:01 PM, Stephen Farrell wrote: > On 15/06/11 20:53, Nico Williams wrote: >> [...] > > I don't think a TLS change is needed for this approach, other than > maybe in terms of the interface between a server's TLS accelerator > and the backend, however, there is a fair point that higher layer I'm guessing concentrators already provide this. But yeah. Also, I suspect that there are subtle changes that are required in order to get credential selection right on the client side with one's chosen TLS implementation, and possibly on the server side to deal with arbitrary credential validation methods (there was a bit of discussion of this latter at the W3C workshop during Q&A for the WebID presentation, brought on by questions/comments by Brad Hill, but Henry Story wasn't present, so there were no detailed answers). > authentication is different and can be as good. I suspect that > the TLS mutual approach might be easier to do, but that's just > me arm-waving at this point really. Perhaps we can ask the WebID folks about their experience here, since they've gone further down this road than anyone else, near as I can tell. > (And before anyone says it: I do not think we should go off and > write up those requirements in an RFC. This is not our first > attempt at this and the minutiae of the requirements matter > far less than adoption of something that's really better than > current password schemes.) I don't think we need to publish a requirements RFC before we do anything else, or even at all. But we need to have some clue as to what the requirements are :) > Better server auth is also a fair point - however that might be > somewhat less pressing were client credentials not immediately > stealable from backend databases. Could be that DANE might > provide an approach to help in that respect were we to take > this TLS mutual approach. A lot of authentication methods can and do protect client credentials from theft. ZKPPs are all the rage right now, and for good reason. And no, the fact that the server's verifiers can be stolen doesn't bother me if people minimize that infrastructure and protect it. This isn't like credit card information (where there's no need to structure the data, thus it ends up all over the place), nor as sensitive as Kerberos KDBs, say. Plus between KDFs like scruypt and decent password quality we can do a very good job of slowing the offline dictionary attacks enough that theft of asymmetric password verifiers is not that big a deal. There's also ABFAB WG's mechanism. There's OAuth (which, I hear, is getting mutual auth soon too). There's Kerberos (always in demand in the enterprise). Etcetera. > I totally agree that *if* this activity results in something new > actually being deployed then we better do a good job because we > won't get another chance if we do a bad job. I suspect that the TLS user cert approach could get traction very quickly if it's true that no changes are needed to TLS stacks. I'll hope, in that case, that we still get to deploy app-layer authentication in some use cases, because if you don't care for user certs (because that's not the authentication infrastructure that you have), there's really no better choice. Nico -- From netsequent@gmail.com Tue Jun 21 12:40:07 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293391F0C6C; Tue, 21 Jun 2011 12:40:07 -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 B24TK66cEcso; Tue, 21 Jun 2011 12:40:06 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3B1F0C64; Tue, 21 Jun 2011 12:40:06 -0700 (PDT) Received: by qyk29 with SMTP id 29so76781qyk.10 for ; Tue, 21 Jun 2011 12:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=i9G+wh1jFDdiulTuF9oUa2J0BjCy7hzfXClQW5iL3yA=; b=ZcvBAqDS4ajnZL4S35G59O3Jvgyrg4MblHiugk8N6z1hx0E50/jpfxIZFpkAzDgeNm /6mph3/9kMv0zg1+2hTSnHV8YorJKpAXhrQvfs3qnyiZZfyl4Clw0B3WYT08mJwPk8cP v38Jds1NOfb8PE9Dc9di3nEytrajmSIbcBLdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=TGzYgcpLM9MY3047KbislqM4VrK0ztpZIveNfgdfvF/oEMylIb/gmQZWradTm227+j 4RWoGsETFf7oftpAAv3w+EU07v+Xa31i0q2YlfPvdAH0UGgML5q4tkQixSd5VFhvhCWD PN53+ADcHKItVG3JQwbYSxlsUN5m+S87Ml5jY= Received: by 10.229.13.152 with SMTP id c24mr5502259qca.87.1308685205849; Tue, 21 Jun 2011 12:40:05 -0700 (PDT) Received: from [10.9.64.146] (mobile-198-228-192-137.mycingular.net [198.228.192.137]) by mx.google.com with ESMTPS id g11sm991331qcm.3.2011.06.21.12.40.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 12:40:04 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> X-Mailer: iPhone Mail (8J2) From: Marc Williams Date: Tue, 21 Jun 2011 15:39:54 -0400 To: Thomas Roessler X-Mailman-Approved-At: Tue, 21 Jun 2011 13:09:12 -0700 Cc: "http-auth@ietf.org" , "websec@ietf.org" , "public-identity@w3.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:40:07 -0000 >> * a method that hands over a password (or a password-equivalent) >> * a method whose UI can be imitated by malicious sites. >> >> Of course there might be more items, please append. A method which pemits zero length password authentication Marc Williams From kazubu.lepidum@gmail.com Wed Jun 22 08:23:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135611E80B8; Wed, 22 Jun 2011 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 zcrI2UG7W9s3; Wed, 22 Jun 2011 08:23:50 -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 D8B5F11E810A; Wed, 22 Jun 2011 08:23:49 -0700 (PDT) Received: by pwj5 with SMTP id 5so716027pwj.31 for ; Wed, 22 Jun 2011 08:23:43 -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:from:date :message-id:subject:to:cc:content-type; bh=6arHhX7E9aXvQiKGZPTZVPKmgqq09jYj5lfsEi15doU=; b=xjzfItAn9U61uQetmqOquLeRsM/2+OSNeTgPyrcJ1092NSTkYcMzsJ5yxt+IoWCn7x AIxqS6C2Ty2TFL8PkqjUM+MSAB+Lg2Rjc5qwohnEt20zjr6Fg3Dvc+aM+6bD34KrIp58 b7qWJeeQ/1mTimpYVWNiE7c7jWF8tnS/TGeU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YvpjL25DvWbCbqEw8aZ1WuVJM9lRnzbdIDuBjmz53tWN5+9mxhU/in5dJ8ttSnwsGY u/Lh/DQc+3np1VbchJP7t9PwLJvwJNSSlj/W/WSlCTut7ZimWbafGDTjxEpTL/QDikT1 JUjCdYVF9Cez8Pg/723sDNCC/3T+5vNCmUE4I= Received: by 10.143.25.29 with SMTP id c29mr174189wfj.381.1308756223182; Wed, 22 Jun 2011 08:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.91.20 with HTTP; Wed, 22 Jun 2011 08:23:23 -0700 (PDT) In-Reply-To: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> From: "SHIMIZU, Kazuki" Date: Thu, 23 Jun 2011 00:23:23 +0900 Message-ID: To: Marc Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:23:50 -0000 I agree. In addition, I think we should avoid not only "zero length password" but also weak passwords (e.g. 12345, qwerty, etc...). This problem may be operation policy issue, however, might be considering. 2011/6/22 Marc Williams : >>> * a method that hands over a password (or a password-equivalent) >>> * a method whose UI can be imitated by malicious sites. >>> >>> Of course there might be more items, please append. > > > > > A method which pemits zero length password authentication > > > Marc Williams > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- SHIMIZU, Kazuki From gogwim@unijos.edu.ng Wed Jun 22 10:03:26 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3D21F856A; Wed, 22 Jun 2011 10:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 oLSjJfc76okH; Wed, 22 Jun 2011 10:03:26 -0700 (PDT) Received: from staffmail.unijos.edu.ng (staffmail.unijos.edu.ng [196.46.147.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3D621F8501; Wed, 22 Jun 2011 10:03:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id 90C07700B529A; Wed, 22 Jun 2011 18:03:16 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng Received: from staffmail.unijos.edu.ng ([127.0.0.1]) by localhost (staffmail.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPNS9Qu5lqs8; Wed, 22 Jun 2011 18:03:12 +0100 (WAT) Received: from imap.unijos.edu.ng (unknown [10.0.0.4]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id 078F4700B5281; Wed, 22 Jun 2011 18:03:12 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost.localdomain [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 4C7263E5EFB; Wed, 22 Jun 2011 18:21:39 +0100 (WAT) Received: from 196.220.229.163 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Wed, 22 Jun 2011 18:21:39 +0100 (WAT) Message-ID: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> Date: Wed, 22 Jun 2011 18:21:39 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "SHIMIZU, Kazuki" User-Agent: SquirrelMail/1.4.4 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: Wed, 22 Jun 2011 10:05:57 -0700 Cc: Marc Williams , "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:03:26 -0000 Supported. Weak and predictable passwords should be avoided. On Wed, June 22, 2011 4:23 pm, SHIMIZU, Kazuki said: > I agree. > > In addition, I think we should avoid not only "zero length password" > but also weak passwords (e.g. 12345, qwerty, etc...). > > This problem may be operation policy issue, > however, might be considering. > > 2011/6/22 Marc Williams : >>>> * a method that hands over a password (or a password-equivalent) >>>> * a method whose UI can be imitated by malicious sites. >>>> >>>> Of course there might be more items, please append. >> >> >> >> >> A method which pemits zero length password authentication >> >> >> Marc Williams >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > -- > SHIMIZU, Kazuki > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nico@cryptonector.com Wed Jun 22 10:08:04 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86C021F859F; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 cIbBj6YnhuBZ; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57C21F859D; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 8501D508084; Wed, 22 Jun 2011 10:08:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=BNsICpi/P438f3WJVmKj4 fktDINNhD3ZaDlQ1c7zmXpL7IRSC00biPXlYBsYeexiMYAIdXK5jlPS7ScoMHOQ3 Z9XVDNzFot+U4GcIDdt9gB1h0L47ofyHPLxk5UWNvjACcyuCyhq4ZlzIePeMfzai pbr4s0sDiFAaXyg46hup7w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bUQC/PFbimCpJ1fVv4po rukJnJY=; b=hWDCtv6iiQfYIs3lyrcPEHsZU+RBtNrpAHFsdxIrke2CO/UEh21R H3IGHXDh5rI0KYkIygF7Iz+9dAcgt0ePoYXVBrk/M3pQ1LK0qByZyY4w7MD7HMpH KFpn2/wvCO6rw0dTrsF8AD4xiKPCYadDP21o9IYuRF27iOjxGJpReW8= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 453E1508081; Wed, 22 Jun 2011 10:08:03 -0700 (PDT) Received: by pzk5 with SMTP id 5so709686pzk.31 for ; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.18.162 with SMTP id x2mr556598pbd.274.1308762482861; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Wed, 22 Jun 2011 12:08:02 -0500 Message-ID: From: Nico Williams To: gogwim@unijos.edu.ng Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:08:04 -0000 On Wed, Jun 22, 2011 at 12:21 PM, GOGWIM, JOEL GODWIN wrote: > Supported. > Weak and predictable passwords should be avoided. If you have ZKPPs then weak passwords are OK. Also, all passwords that users must remember should be considered weak. Nico -- From hotz@jpl.nasa.gov Wed Jun 22 11:01:31 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC0228013; Wed, 22 Jun 2011 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sNUTv1-Ough6; Wed, 22 Jun 2011 11:01:30 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB7228011; Wed, 22 Jun 2011 11:01:30 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5MI1Fmj025813 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 22 Jun 2011 11:01:27 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Wed, 22 Jun 2011 11:01:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> To: "gogwim@unijos.edu.ng" X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:01:31 -0000 I can agree in principle, but in practice the definition of "weak" is = too fuzzy. On Jun 22, 2011, at 10:21 AM, GOGWIM, JOEL GODWIN wrote: > Supported. > Weak and predictable passwords should be avoided. >=20 >=20 > On Wed, June 22, 2011 4:23 pm, SHIMIZU, Kazuki said: >> I agree. >>=20 >> In addition, I think we should avoid not only "zero length password" >> but also weak passwords (e.g. 12345, qwerty, etc...). >>=20 >> This problem may be operation policy issue, >> however, might be considering. >>=20 >> 2011/6/22 Marc Williams : >>>>> * a method that hands over a password (or a password-equivalent) >>>>> * a method whose UI can be imitated by malicious sites. >>>>>=20 >>>>> Of course there might be more items, please append. >>>=20 >>>=20 >>>=20 >>>=20 >>> A method which pemits zero length password authentication >>>=20 >>>=20 >>> Marc Williams >>>=20 >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>>=20 >>=20 >> -- >> SHIMIZU, Kazuki >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 22 19:36:11 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC31F0C41; Wed, 22 Jun 2011 19:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 YaSTON1ZmomP; Wed, 22 Jun 2011 19:36:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A61F0C3D; Wed, 22 Jun 2011 19:36:10 -0700 (PDT) Received: by wwe5 with SMTP id 5so1003860wwe.13 for ; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.11.131 with SMTP id t3mr1375268wbt.113.1308796569317; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.227.128.75 with HTTP; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Thu, 23 Jun 2011 11:36:09 +0900 X-Google-Sender-Auth: NE7KstGKngNb65HXXwY67jWpyog Message-ID: From: Yutaka OIWA To: gogwim@unijos.edu.ng Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:36:11 -0000 2011/6/23 GOGWIM, JOEL GODWIN : > Supported. > Weak and predictable passwords should be avoided. I ideally agree, but in reality I hesitate to agree with it with technical means and backgrounds. In short, here is a security trade-off. Of course, the statement "weak and predictable passwords should be avoided", as literally, can be read as our requirements to users and agreed with no questions. However, the original thread was prepended with "Any protocols that allow". For this purpose, the more the technology gets strong to protect "good (unpredictable)" passwords and passphrases against possible attacks, the more such a protocol cannot reveal "weakness" of passwords to servers too. To detect by the server side to detect predictable passwords using bulky (e.g. 100k or 1M+) list, currently we need either a plain-text password authentication protocol or a plain-text password registration procedure. On the contrary, if we forgive users' "mistake" to use such a weak passwords as user's own, we can introduce much stronger password protocols which do not reveal (at least immediately) the user's password both in registration and authentication time. When we face with this trade-off, I don't want to trash out the latter's possibility. In this background, "forbidding protocols which allow users to (covertly) use weak predictable passwords" means that "servers *always* know the user's plain-text password", which is obviously not happy. We don't want to completely sacrifice well-done user's security in trade with the careless user's security. Of course, even if we introduce such "secure" password registration protocol, I foresee that some people will continue to stick on plain-text password registration for various reasons. For example, if a law had required some servers (e.g. financial entities) to check and reject such predictable passwords, we would have no way to secure it. For such purposes servers will continue to receive raw passwords and computes password-hashes (or whatever equivalent) on the server-side. But I think that providing a possibility to securely registering passwords to servers are one of required things to do for us. But, again at last, I repeat to agree that "users" should avoid weak and predictable passwords with no questions. From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 22 19:52:42 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856941F0C3F; Wed, 22 Jun 2011 19:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.073, 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 NsDXd0-+oIPy; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 709521F0C38; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) Received: by gya6 with SMTP id 6so837314gya.31 for ; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.66.20 with SMTP id o20mr1653832yba.344.1308797560807; Wed, 22 Jun 2011 19:52:40 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.153.19 with HTTP; Wed, 22 Jun 2011 19:52:40 -0700 (PDT) In-Reply-To: <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> Date: Thu, 23 Jun 2011 11:52:40 +0900 X-Google-Sender-Auth: SzZgA12GrfnI-4N8P0vs65rNFfQ Message-ID: From: Yutaka OIWA To: "Henry B. Hotz" Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "gogwim@unijos.edu.ng" , "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:52:42 -0000 2011/6/23 Henry B. Hotz : > I can agree in principle, but in practice the definition of "weak" is too fuzzy. > > On Jun 22, 2011, at 10:21 AM, GOGWIM, JOEL GODWIN wrote: > >> Supported. >> Weak and predictable passwords should be avoided. 2011/6/23 Nico Williams : > Also, all passwords that users must remember should be considered weak. This is a terminology issue, and I present here *my* use of such terminologies in general. = strong secret and weak secret = "strong" secrets are the secret data which has an entropy comparable to other security parameters (e.g. encryption key length etc.) They typically include public-key-cryptography secret keys, DH-key-exchanged shared keys, randomly-generated nonce-like bearer tokens and others. "weak" secrets are the secret data which has not enough entropy compared to encryption etc. PINs, Passwords and passphrases are typical examples. They should not be used for encryptions without some security-amplifications (e.g. password-authenticated key exchanges.) In this meaning, all memorable passwords are weak. = strong passwords/passphrases and weak passwords = I use the term "weak passwords" almost equivalent to predictable passwords or brute-force searchable passwords. The required strength may depend on the context, e.g. whether the passwords search can be off-line, or whether a pre-computed dictionary of hashed passwords can be useful, etc. but many people will agree that "1" and "1234" are weak, and "cA6mqUPgBpe6pQf7" is strong as a password. I prefer using "predictable" and "unpredictable" for this meanings. From yaronf.ietf@gmail.com Thu Jun 23 13:53:23 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAEB11E8190; Thu, 23 Jun 2011 13:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, 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 GTI2B5ofQ3Dd; Thu, 23 Jun 2011 13:53:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2911E817E; Thu, 23 Jun 2011 13:53:22 -0700 (PDT) Received: by wwe5 with SMTP id 5so1555200wwe.13 for ; Thu, 23 Jun 2011 13:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OR7JnsEnLlf48JBmP/54Vv1iqGkXkisHfO+ebmokLVU=; b=kAgUeTtSHIp8nzaxsnJww082UaYrG71ruq9HT+FU2kUU88oFE52DSfgMSc/cMWO9Ak VTW1MQQEwS4haYAhpku1IZqqHdVwe51EuVbw46kYmP4YVhLjF7h9ZRebx2J0ehgtHPvh ucaKHvFtQ5XvysBe1n6ayxTcupPDrEVIOzy2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NfIi1x4vP41vwXY+zpaxGlpZVv5bcFj+YLWIHTRDc5bwzt7PJmK6elr9CpHIRIfuCX zQFNIMKbvl+pwyY5CJgSRvy89eCip6WdG2V2kOIgOhlShUTKWu50bUGt2CGCGWXtNpb8 nJdC3B/YxZdTNfzW1Oe6dgKQ6yij0Y6siPm+8= Received: by 10.227.127.135 with SMTP id g7mr2376880wbs.96.1308862401614; Thu, 23 Jun 2011 13:53:21 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-236-253.red.bezeqint.net [79.183.236.253]) by mx.google.com with ESMTPS id d19sm1507099wbh.42.2011.06.23.13.53.18 (version=SSLv3 cipher=OTHER); Thu, 23 Jun 2011 13:53:21 -0700 (PDT) Message-ID: <4E03A7BD.3080301@gmail.com> Date: Thu, 23 Jun 2011 23:53:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , gogwim@unijos.edu.ng, "saag@ietf.org" Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:53:23 -0000 No, even if you have ZKPP you should avoid ridiculously weak passwords like "qwerty". The reason is, you are still vulnerable to active password guessing, and even if you rate-limit aggressively (e.g. one guess per hour), the attacker might get lucky too early.

So I would distinguish between the 2**20 space of user-memorable passwords, vs. the 2**7 space of too-horrible-to-contemplate passwords.

Thanks,
    Yaron

On 06/22/2011 08:08 PM, Nico Williams wrote: 
On Wed, Jun 22, 2011 at 12:21 PM, GOGWIM, JOEL GODWIN
<gogwim@unijos.edu.ng> wrote:

Supported.
Weak and predictable passwords should be avoided.

If you have ZKPPs then weak passwords are OK.

Also, all passwords that users must remember should be considered weak.

Nico
--
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
From marsh@extendedsubset.com Thu Jun 23 14:05:50 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD111E819D; Thu, 23 Jun 2011 14:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2] 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 3O9sRKyYjg8G; Thu, 23 Jun 2011 14:05:49 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C511E819B; Thu, 23 Jun 2011 14:05:49 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QZr5x-000Fe9-6F; Thu, 23 Jun 2011 21:05:49 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A93A56073; Thu, 23 Jun 2011 21:05:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18l9WmfuTCvaaqQMCGHl4jfTaoGBBgkS34= Message-ID: <4E03AA9B.4030709@extendedsubset.com> Date: Thu, 23 Jun 2011 16:05:31 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yutaka OIWA References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , gogwim@unijos.edu.ng, "saag@ietf.org" Subject: Re: [http-auth] [websec] [saag] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:05:50 -0000 On 06/22/2011 09:36 PM, Yutaka OIWA wrote: > 2011/6/23 GOGWIM, JOEL GODWIN: >> Supported. >> Weak and predictable passwords should be avoided. > > I ideally agree, but in reality I hesitate to agree with it > with technical means and backgrounds. How is the IETF or w3 going to define "weak password" anyway? Even if there were a way, it's common to see users getting hacked these days because the use the same (possibly strong) password at multiple sites. It's best to pick a completely unique, strong password (12 or more characters) for each and every site. But unless you're some kind of savant, this requires writing these passwords down somewhere. But instead, users are taught not to write their passwords down (mostly by employers who don't want it to end up on a sticky note in an obvious place). So users either pick simple passwords and/or they use the same one at every site. > Of course, even if we introduce such "secure" password registration protocol, > I foresee that some people will continue to stick on plain-text password > registration for various reasons. For example, if a law had required > some servers (e.g. financial entities) to check and reject such predictable passwords, > we would have no way to secure it. That would be a bad law. I don't think a protocol design can or should defend against bad laws. At least in the US, financial institutions don't have such laws. They instead have a patchwork of audit requirements, industry standards, best practices, compliance, etc.. Which is probably better than passing laws about password complexity requirements, all things considered. > For such purposes servers will > continue to receive raw passwords and computes password-hashes > (or whatever equivalent) on the server-side. > But I think that providing a possibility to securely registering passwords > to servers are one of required things to do for us. This is far more important than working out ways to accommodate sites that want or need to transfer the password in clear text. Those sites are already able to do that just fine. Ideally the technology would somehow prevent a site from accepting (or doing anything useful with) the user's plaintext password within the page. This would allow the browser to remove any ambiguity for users which would be exploitable by phishing. The simplest message and the one that will "sink in" with the most users is: "You should never type this password into any web page or program except this unmistakable piece of browser chrome. Not to verify your account info, not to reset your password, not to receive tech support from someone you trust, and not even to see free pictures of kittens." It would be amazing if we could get there, but browser vendors and sites conspire against us to defeat it. - Marsh From stephen.farrell@cs.tcd.ie Thu Jun 23 14:21:12 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0F11E814D for ; Thu, 23 Jun 2011 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 sQEWsgXwo33F for ; Thu, 23 Jun 2011 14:21:02 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E8B7811E811B for ; Thu, 23 Jun 2011 14:21:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EBE01171C19; Thu, 23 Jun 2011 22:20:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308864046; bh=+mGc1Zk7YO3JFx B5ZhmyvGxfvPQ9Pi9wyZfAtDYJvT8=; b=YfGyktm1TP9NyjyRVFuELOw2y0YFs2 L5AYa/EBk+ioyL+FjzQgRnlQFyWzulX1ZE93NpT+UX4z8poO1z+UaIGNmJwW0TwF bVt9dhEBdmqYCBQc7dvTKAux3NwPJeUic8isclEny/K9X0sOCGOUIzHfTcmPzK/L AX+Cp0gllxTExu9fNnUVttcPdD0mBd22O06t5u4Sa5DhCaPPK+GC8gtD+mdNjeJe 4q5XnfCbj4Lh8V83XGeYQ1UfqsyzvAqfnDWj/oj1PQz2ba6Mo05cc82oXvHjWnOO TfSz0N2iuUJKH7innp6hCB3QuG21C5+RO1eQLd6jaZ7LRufZZW5U6Nog== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KBTuFy+HenYq; Thu, 23 Jun 2011 22:20:46 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.62.206]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BCBCF171C17; Thu, 23 Jun 2011 22:20:46 +0100 (IST) Message-ID: <4E03AE2E.7090103@cs.tcd.ie> Date: Thu, 23 Jun 2011 22:20:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Marsh Ray References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> <4E03AA9B.4030709@extendedsubset.com> In-Reply-To: <4E03AA9B.4030709@extendedsubset.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] [websec] [saag] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:21:12 -0000 [Can't we reduce the cross-posting on this? I'm getting 3-5 copies of everything to do with this topic.] I think we need to try do a number of things to improve http authentication, one of which may well be to investigate zkpp's, but (AD hat off) I really think we'll be better off if we can reduce the number of (new) passwords as well, hence my proposal to try figure a way to do TLS mutual auth. But spending a lot of time discussing weak passwords in the IETF context is probably somewhat pointless since that's not a protocol issue that I can see. S. On 23/06/11 22:05, Marsh Ray wrote: > On 06/22/2011 09:36 PM, Yutaka OIWA wrote: >> 2011/6/23 GOGWIM, JOEL GODWIN: >>> Supported. >>> Weak and predictable passwords should be avoided. >> >> I ideally agree, but in reality I hesitate to agree with it >> with technical means and backgrounds. > > How is the IETF or w3 going to define "weak password" anyway? > > Even if there were a way, it's common to see users getting hacked these > days because the use the same (possibly strong) password at multiple sites. > > It's best to pick a completely unique, strong password (12 or more > characters) for each and every site. But unless you're some kind of > savant, this requires writing these passwords down somewhere. > > But instead, users are taught not to write their passwords down (mostly > by employers who don't want it to end up on a sticky note in an obvious > place). So users either pick simple passwords and/or they use the same > one at every site. > >> Of course, even if we introduce such "secure" password registration >> protocol, >> I foresee that some people will continue to stick on plain-text password >> registration for various reasons. For example, if a law had required >> some servers (e.g. financial entities) to check and reject such >> predictable passwords, >> we would have no way to secure it. > > That would be a bad law. > > I don't think a protocol design can or should defend against bad laws. > > At least in the US, financial institutions don't have such laws. They > instead have a patchwork of audit requirements, industry standards, best > practices, compliance, etc.. Which is probably better than passing laws > about password complexity requirements, all things considered. > >> For such purposes servers will >> continue to receive raw passwords and computes password-hashes >> (or whatever equivalent) on the server-side. >> But I think that providing a possibility to securely registering >> passwords >> to servers are one of required things to do for us. > > This is far more important than working out ways to accommodate sites > that want or need to transfer the password in clear text. Those sites > are already able to do that just fine. > > Ideally the technology would somehow prevent a site from accepting (or > doing anything useful with) the user's plaintext password within the > page. This would allow the browser to remove any ambiguity for users > which would be exploitable by phishing. > > The simplest message and the one that will "sink in" with the most users > is: "You should never type this password into any web page or program > except this unmistakable piece of browser chrome. Not to verify your > account info, not to reset your password, not to receive tech support > from someone you trust, and not even to see free pictures of kittens." > > It would be amazing if we could get there, but browser vendors and sites > conspire against us to defeat it. > > - Marsh > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From nico@cryptonector.com Thu Jun 23 17:43:42 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9411E8081 for ; Thu, 23 Jun 2011 17:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.853, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 hyfZ9xZ15tSQ for ; Thu, 23 Jun 2011 17:43:41 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id A64B111E809C for ; Thu, 23 Jun 2011 17:43:34 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 676C2B8058 for ; Thu, 23 Jun 2011 17:43:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VCJ+liweRpPOF9I9WvQIj 6lidwFiNBMmduraBrqNLHh4rAi3GwA9HcVnO1Ksm/I9ZwbGoOOLtF72u+u0Bw2O0 pzXwLbHK0IkODz8xreA69Hc+K4L1LLM/d8vqOM7bTbDk+jpozsO4PLrygUtlGH0o 17haQQ95CQCCfD2dMWS9Cw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Mt3i1au5QYO5VrUyBA6X e2vjaQ0=; b=m/9Em97iZvLdGxjqTdhGEVczDIDDyvh7gwjbOvhvo3TOzEA3i11q 414gAiUvkzTTg33mOUZi9MJIogQCP4yC09/poZoEBvD2SNyQaaQO0pxejPTZE/it INf3fedjUzEvekeQGYUE0H8SzWjDP2ZCjtx5Lf+vkfveWEbaMgMvz6w= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 4E992B8057 for ; Thu, 23 Jun 2011 17:43:34 -0700 (PDT) Received: by pwj5 with SMTP id 5so1649601pwj.31 for ; Thu, 23 Jun 2011 17:43:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.230 with SMTP id k6mr178755pbc.341.1308876213957; Thu, 23 Jun 2011 17:43:33 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Thu, 23 Jun 2011 17:43:33 -0700 (PDT) In-Reply-To: <4E03A7BD.3080301@gmail.com> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> <4E03A7BD.3080301@gmail.com> Date: Thu, 23 Jun 2011 19:43:33 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" , gogwim@unijos.edu.ng Subject: Re: [http-auth] [saag] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 00:43:42 -0000 On Thu, Jun 23, 2011 at 3:53 PM, Yaron Sheffer wrote: > No, even if you have ZKPP you should avoid ridiculously weak passwords like > "qwerty". The reason is, you are still vulnerable to active password > guessing, and even if you rate-limit aggressively (e.g. one guess per hour), > the attacker might get lucky too early. Clearly. > So I would distinguish between the 2**20 space of user-memorable passwords, > vs. the 2**7 space of too-horrible-to-contemplate passwords. This is why password quality policies matter even when using ZKPPs. 2^20 search space? -> use ZKPPs. 2^7 search space? -> you're very much out of luck! Nico -- From tim-research@sentinelchicken.org Fri Jun 24 15:13:22 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874FB11E809E for ; Fri, 24 Jun 2011 15:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 YIvisoqcNoNt for ; Fri, 24 Jun 2011 15:13:21 -0700 (PDT) Received: from sentinelchicken.org (mail.sentinelchicken.org [69.168.48.72]) by ietfa.amsl.com (Postfix) with ESMTP id 25C8011E808F for ; Fri, 24 Jun 2011 15:13:20 -0700 (PDT) Received: (qmail 30707 invoked from network); 24 Jun 2011 22:13:16 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by feynman.sentinelchicken.org with ESMTPS (DHE-RSA-AES256-SHA encrypted); 24 Jun 2011 22:13:16 -0000 Received: (qmail 20677 invoked from network); 24 Jun 2011 22:13:30 -0000 Received: from shannon.sentinelchicken.org (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 24 Jun 2011 22:13:30 -0000 Received: (nullmailer pid 23007 invoked by uid 1000); Fri, 24 Jun 2011 22:13:15 -0000 Date: Fri, 24 Jun 2011 15:13:15 -0700 From: Tim To: http-auth@ietf.org Message-ID: <20110624221315.GF1542@sentinelchicken.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [http-auth] CSRF Prevention X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 22:13:22 -0000 Hi all. I wanted to float this one by you all, as we may find it useful to help squash CSRF along with phishing attacks. I'm sure many of you are familiar with CSRF attacks, so I'm not going to give too much background. I'm also sure these have been discussed on numerous IETF security lists in the past, but let me just quickly frame them in the context of how I think of them: To me, CSRF attacks are symptom of a design flaw in the web, or perhaps more accurately, a symptom of the fact that we currently use the web in ways it wasn't designed. CSRF is possible because: A. There is no inherent (or strict) distinction between HTTP requests initiated by content on the same site vs those initiated by content on other sites. In addition, CSRF is often made easier because: B. In practice, there is no distinction between requests that make a material change to site content vs those that just retrieve content. (Often GET and POST requests are treated identically by applications, bluring any meaning we might apply to one or the other in this way.) Because of (B) browsers have no hope in directly preventing CSRF because they can't tell what request types should be allowed cross domain (such as fetching images) and which should not be (such as POSTing forms). An attempt for fixing (A) is simply to have your web application check the Referer header that comes with a request and make sure it matches a trusted domain. However, Referer headers do give some people the privacy heebee jeebees and therefore they get turned off at times, which would cause apps that implement this to break. Also, old versions of Adobe Flash allowed one to send arbitrary HTTP headers cross-domain, so in the early days, this mitigation was thrown out (though in modern times, it may actually be a reasonable solution). Because of this history, web applications and frameworks have been forced to implement cryptographic cookie protocols of their own to validate that requests really did originate from their sites. They embed unpredictable tokens in forms and in URLs and then check those against server-side data in one of several ways. Having web developers and framework developers do crypto has not turned out well in the past, and I presume it will continue to go poorly. One simple fix (from a technical perspective, not a standards perspective), would be to introduce a new HTTP request method (let us call it "ACTION" for the moment), which behaves more or less like POST, but is explicitly required never to be used cross-domain. Then application implementors could just use ACTION in their forms and browsers could enforce protections against CSRF instead of making application developers do it upon receiving the request. In some of my past reading of proposals on how PUT is supposed to behave, I did read something about it having similar restrictions, so perhaps it could be used for this purpose. Failing that, as a final possibility (and the reason I am posting this here) is that we could rely on a better HTTP authentication mechanism to help us enforce CSRF protections. Since Referer logic is already baked in to browsers, and any HTTP authentication mechanism would also need to be baked in to browsers, why not bake something like Referer into the HTTP authentication mechansim to help application developers validate the origin of requests? Essentially, make Referer information more reliable and more privacy sensitive. The most obvious approach would be to require an origin domain parameter in the HTTP authentication mechanism, have it signed, and then let application developers check that upon receipt. However, this has potential privacy problems, just like Referer does. So, to help protect privacy, one could instead include a simple salted hash of the origin domain. Application developers (or more likely, development frameworks) can still check a white list of trusted domains against the hash, or even check for black listed domains if they really wanted to, but it wouldn't immediately reveal what domain was the origin. Referer can continue to be used for non-security (advertisement tracking, whatever) purposes. I know this idea is half-baked, but I thought I would try to start a discussion. Thoughts? tim From hallam@gmail.com Sat Jun 25 12:43:02 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D7611E80EE; Sat, 25 Jun 2011 12:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.193 X-Spam-Level: X-Spam-Status: No, score=-3.193 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 qGcVhVG5NeYA; Sat, 25 Jun 2011 12:43:01 -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 4A53211E80C6; Sat, 25 Jun 2011 12:43:01 -0700 (PDT) Received: by yie30 with SMTP id 30so2200598yie.31 for ; Sat, 25 Jun 2011 12:43:00 -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=MFHdBK32C3XwT8oIhBOB4GMZ4tdBPq24yvGvTqLuBuY=; b=yBzPTU+GMYfQDyt7GV9SCw81lw+d3RYhHGmnt3BWuoUN07Sj5vQJW83Lh3tafBaQt3 F0zeeSfc6SJ7+a+lvArplV9pncBhcgXhgPpwGLx04FgkmaXbnzqSf9uQYlnHaccoVp6f l9/Nf7xZErnnevlA0CQGwNNQCPuBLIc1klkzo= 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=a5GUIM6oFDC8KbslUUFzr14B79ICtigylmiagvPzDTU6hVFg8KgnwZI7Ri3ARHTyAI 9Ds9X5+UxkrICUuVVISMKI7sICU20NlyM93//00Y0WSov6rS0Zo8+i89lmhxBQtr0JDY JXW8kxJuSszt1Cl2eRkNxK32ShM/A4xqS/JKU= MIME-Version: 1.0 Received: by 10.101.148.37 with SMTP id a37mr5041806ano.150.1309030980090; Sat, 25 Jun 2011 12:43:00 -0700 (PDT) Received: by 10.100.111.17 with HTTP; Sat, 25 Jun 2011 12:43:00 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 Jun 2011 15:43:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Peter Gutmann Content-Type: multipart/alternative; boundary=0016e68ee136917d5b04a68e8634 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 19:43:02 -0000 --0016e68ee136917d5b04a68e8634 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 12:59 AM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > > >what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hands > over the password (or a password-equivalent like a password in hashed form) > as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passing > on > the genes. > Take a look at the following draft: https://tools.ietf.org/html/draft-hallambaker-owcp-00 The basic idea is that putting SecurID type schemes on an iPhone is using a Deep Blue to play pong. This is orthogonal in that it is really about replacing the two factor scheme. But a really good backup for two factor could allow us to address some of the issues with single factor. For example, browser generates a strong public keypair, uses same to authenticate to an 'account management service'. This stores single factor passwords on behalf of the user. Really big ones, like 128 bit worth of password. If that type of scheme is used for the 90% of accounts that don't matter to me (no really, I don't care who uses my NYT account, only they care) we can reserve the second factor scheme to the accounts and the transactions where it really matters. > The only permitted auth.form should be a dynamic, cryptographic mutual > auth. > that authenticates both the client and the server. There are endless > designs > for this sort of thing around so the precise form isn't too important, as > long > as it's not hand-over-the-password. > Agree completely. But that is not the problem that is blocking us here. The central issue is how to get deployment and that is hard. If we could maybe get a toehold on this problem by getting a free replacement for second factor out there that is also better, we can maybe get a critical mass we can leverage. -- Website: http://hallambaker.com/ --0016e68ee136917d5b04a68e8634 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 14, 2011 at 12:59 AM, Peter = Gutmann <= pgut001@cs.auckland.ac.nz> wrote:
Phillip Hallam-Baker <hallam@gmail.com> writes:

>what would we want HTTP authentication to look like?

I have a suggestion for what it shouldn't look like: Any method t= hat hands
over the password (or a password-equivalent like a password in hashed form)= as
current browsers do should be banned outright, and anyone who implements hand-over-the-password should killed and eaten to prevent them from passing= on
the genes.

Take a look at the following= draft:

The basic idea is that putting SecurID type schemes on = an iPhone is using a Deep Blue to play pong.


<= /div>
This is orthogonal in that it is really about replacing the two f= actor scheme. But a really good backup for two factor could allow us to add= ress some of the issues with single factor.

For example, browser generates a strong public keypair,= uses same to authenticate to an 'account management service'. This= stores single factor passwords on behalf of the user. Really big ones, lik= e 128 bit worth of password.


If that type of scheme is used for the 9= 0% of accounts that don't matter to me (no really, I don't care who= uses my NYT account, only they care) we can reserve the second factor sche= me to the accounts and the transactions where it really matters.


=A0
The only permitted auth.form should be a dynamic, cryptographic mutual auth= .
that authenticates both the client and the server. =A0There are endless des= igns
for this sort of thing around so the precise form isn't too important, = as long
as it's not hand-over-the-password.

Agree completel= y. But that is not the problem that is blocking us here. The central issue = is how to get deployment and that is hard.

If we could maybe get a toehold on this problem by getting a= free replacement for second factor out there that is also better, we can m= aybe get a critical mass we can leverage.

--0016e68ee136917d5b04a68e8634-- From tho@koanlogic.com Sat Jun 25 01:59:56 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981621F853F; Sat, 25 Jun 2011 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] 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 LEo9iwBsfL0x; Sat, 25 Jun 2011 01:59:55 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45921F853D; Sat, 25 Jun 2011 01:59:55 -0700 (PDT) Received: from host247-5-dynamic.32-79-r.retail.telecomitalia.it ([79.32.5.247]:56588 helo=[192.168.1.5]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QaOiL-0005v9-55; Sat, 25 Jun 2011 04:59:47 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Sat, 25 Jun 2011 10:59:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63B45E28-8167-4820-B7BC-9D02E61D88FE@koanlogic.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.32.5.247 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) X-Mailman-Approved-At: Sat, 25 Jun 2011 15:45:59 -0700 Cc: public-identity@w3.org, http-auth@ietf.org, websec , saag@ietf.org, Peter Gutmann Subject: Re: [http-auth] [websec] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 08:59:56 -0000 On Jun 14, 2011, at 6:17 PM, Nico Williams wrote: > Some aspects of the designs are important. >=20 > For example: >=20 > - Is this to be done in TLS? HTTP? Or at the application-layer? >=20 > IMO: TLS is too low a layer to do authentication in, and doing it in > HTTP would require retrofitting too many HTTP stacks. Doing it at the > application layer has a number of advantages. I've tried to figure out how to get something similar to your REST GSS = -- which I like -- at the HTTP level and, yes, you need to hammer HTTP = clients a bit to teach them how to do the challange-response on a = specially crafted cookie, but then it seems you can switch from = stateless to stateful HTTP (and viceversa) quite robustly. Still there's the related bootstrap problem to solve, i.e. the = authentication phase and implied key agreement. =20 In this respect I've only been able to sketch a TLS-based mechanism, = with a) explicit HTTP redirection, or b) a-priori knowledge of the = authentication URI via .well-known or DNS-SD, which then uses RFC 5705 = to feed both parties with the needed crypto material. Anyway, I still have hazy thoughts about the whole matter, basically = from an architectural standpoint, i.e. about where (which layer) the = secure state management component must be placed. My unanswered (taboo?) question being: would the core HTTP protocol = benefit from introducing secure state handling capabilities ? Or should = HTTP remain stateless ?= From nico@cryptonector.com Sat Jun 25 21:42:17 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FA011E80C7 for ; Sat, 25 Jun 2011 21:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 QxNGgg0369+p for ; Sat, 25 Jun 2011 21:42:16 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id B3C4B11E80C2 for ; Sat, 25 Jun 2011 21:42:16 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 4CB6F2F4059 for ; Sat, 25 Jun 2011 21:42:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AKlDz/4gDWVjE2qzjtwd7zaawxMZgnMTbUR534FpBz04 IL6Tzm3uqusuxVpApdi+YE8aj6eKanwsSbkWFoMZ5fK1htPGryp+HCtfYlEO4xv/ G+5kEYeeWq/bt5fVRy/Xh2S5vyKREcszsvdyILGMumsaVaFC5bBnB6+kAWAkEcA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0LuMjhf01fxkiXFc6BtL/BEKtOA=; b=tOlbs/J2sSJ od8E8MyOhHK8h3MoqJNwohPbZesQ0VIrOoR/wU7Qvh7++1ZIROoNlFUJC4JsPFFC YpNxBBtA27b8SJM4VK5ikGGx4ROx9VMde3EUNrftLhwqE07T5Tiws0ovAEGEXczX UHe/d3Zx1SvRpDt3Dmkeie+FW7041WVw= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 338552F4057 for ; Sat, 25 Jun 2011 21:42:16 -0700 (PDT) Received: by pwj5 with SMTP id 5so2620075pwj.31 for ; Sat, 25 Jun 2011 21:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.15.65 with SMTP id v1mr43055pbc.274.1309063335798; Sat, 25 Jun 2011 21:42:15 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Sat, 25 Jun 2011 21:42:15 -0700 (PDT) In-Reply-To: <63B45E28-8167-4820-B7BC-9D02E61D88FE@koanlogic.com> References: <63B45E28-8167-4820-B7BC-9D02E61D88FE@koanlogic.com> Date: Sat, 25 Jun 2011 23:42:15 -0500 Message-ID: From: Nico Williams To: Thomas Fossati Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [websec] [saag] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 04:42:17 -0000 On Sat, Jun 25, 2011 at 3:59 AM, Thomas Fossati wrote: > On Jun 14, 2011, at 6:17 PM, Nico Williams wrote: >> Some aspects of the designs are important. >> >> For example: >> >> - Is this to be done in TLS? =C2=A0HTTP? =C2=A0Or at the application-lay= er? >> >> IMO: TLS is too low a layer to do authentication in, and doing it in >> HTTP would require retrofitting too many HTTP stacks. =C2=A0Doing it at = the >> application layer has a number of advantages. > > I've tried to figure out how to get something similar to your REST GSS --= which I like -- at the HTTP level and, yes, you need to hammer HTTP client= s a bit to teach them how to do the challange-response on a specially craft= ed cookie, but then it seems you can switch from stateless to stateful HTTP= (and viceversa) quite robustly. I think the main benefit of doing this at the app-layer is that the server-side can be portably implemented as FastCGI and instantly be available on 90+% of servers. I've started implementing in FCGI, incidentally, and I believe I can implement all of REST-GSS this way. Another major benefit of being able to use FastCGI is that you automatically get privilege separation! You can run the app, the web server, and the REST-GSS FastCGI all under different user accounts, with different access, privileges, ... The POST/DELETE/GET can be implemented as a FastCGI responder, the MIC validation as a FastCGI authorizer, and the servers' MICs can be computed and added by a FastCGI filter. On the client-side the situation is not as convenient regardless of whether authentication is *in* HTTP or *above* HTTP: the apps, the browsers, the XMLHttpRequest API -- all need extending, and all need deploying. At best you can save having to extend the HTTP libraries, but in the browser that's not much of a savings, I bet, and even then, people will prefer that HTTP libraries to just implement REST-GSS (as opposed to having to use a separate library in addition). > Still there's the related bootstrap problem to solve, i.e. the authentica= tion phase and implied key agreement. That's what the GSS mechanisms do for you! That's the beauty of this: you're reusing an existing security framework that has just the right semantics: you get to authenticate an initiator (client user) to an acceptor (service) , and preferably also the acceptor to the initiator, and you get to do per-request/response integrity protection (MIC tokens) without having to have ordered message delivery. There's several GSS mechanisms available now, and it's relatively easy to add new ones (see RFC5802). A ZKPP mechanism would be great. A federated ZKPP mechanism would be even better! > In this respect I've only been able to sketch a TLS-based mechanism, with= a) explicit HTTP redirection, or b) a-priori knowledge of the authenticati= on URI via .well-known or DNS-SD, which then uses RFC 5705 to feed both par= ties with the needed crypto material. > > Anyway, I still have hazy thoughts about the whole matter, basically from= an architectural standpoint, i.e. about where (which layer) the secure sta= te management component must be placed. > > My unanswered (taboo?) question being: would the core HTTP protocol benef= it from introducing secure state handling capabilities ? =C2=A0Or should HT= TP remain stateless ? I like keeping things that are meant to be stateless stateless. Implementations of HTTP that don't handle DIGEST or HTTP/Negotiate would have a hard time adjusting, for example. Also, if we do this *in* HTTP then we have the problem that the HTTP method and URI are not specific to the authentication facility -- they are real, and thus they are sent, initially, without having authenticated the service to the user. That's a problem, though maybe it's not a big deal (I'm not sure). Nico -- From hotz@jpl.nasa.gov Mon Jun 27 14:44:47 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD76E11E8172 for ; Mon, 27 Jun 2011 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RYCiBeBBpUWX for ; Mon, 27 Jun 2011 14:44:47 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by ietfa.amsl.com (Postfix) with ESMTP id 399CF11E815A for ; Mon, 27 Jun 2011 14:44:44 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5RLicCa009925 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Mon, 27 Jun 2011 14:44:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Mon, 27 Jun 2011 14:44:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Gutmann X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: public-identity@w3.org, http-auth@ietf.org Subject: Re: [http-auth] [saag] [websec] re-call for IETF http-auth BoF X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 21:44:47 -0000 On Jun 13, 2011, at 9:59 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: >=20 >> what would we want HTTP authentication to look like? >=20 > I have a suggestion for what it shouldn't look like: Any method that = hands=20 > over the password (or a password-equivalent like a password in hashed = form) as=20 > current browsers do should be banned outright, and anyone who = implements=20 > hand-over-the-password should killed and eaten to prevent them from = passing on=20 > the genes. +1 ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From stpeter@stpeter.im Mon Jun 27 19:49:25 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8422321F856F for ; Mon, 27 Jun 2011 19:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.099 X-Spam-Level: X-Spam-Status: No, score=-100.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RD_TO_BAD_TLD=2.5, 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 gZVbnTxN4kJZ for ; Mon, 27 Jun 2011 19:49:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E269821F8489 for ; Mon, 27 Jun 2011 19:49:21 -0700 (PDT) Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EF6F54032B for ; Mon, 27 Jun 2011 20:50:16 -0600 (MDT) Message-ID: <4E094130.8050901@stpeter.im> Date: Mon, 27 Jun 2011 20:49:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [http-auth] RFC 2617 / Erratum # 2600 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 02:49:25 -0000 At http://www.rfc-editor.org/errata_search.php?rfc=2617 can be found the following report: ### Section 3.2.2 says: digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 It should say: digest-uri = "uri" "=" <"> digest-uri-value <"> digest-uri-value = request-uri ; As specified by HTTP/1.1 Notes: This is an error here that the digest-uri-value is not enclosed in quotation marks; see the correct example in Section 3.5: Authorization: Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", . . . ### I've checked the source code for Mozilla and Chrome (but not yet other projects): http://mxr.mozilla.org/mozilla-beta/source/netwerk/protocol/http/nsHttpDigestAuth.cpp http://codesearch.google.com/#OAMlx_jo-ck/src/net/http/http_auth_handler_digest.cc&exact_package=chromium&ct=rc&cd=3&q=qop http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/ffmpeg/patched-ffmpeg-mt/libavformat/httpauth.c&exact_package=chromium&ct=rc&cd=4&q=qop (The TODO notes in the Chrome source are kind of interesting...) This report seems like it might be correct, but I figured I would check with the http-auth list and others before approving this erratum. Peter -- Peter Saint-Andre https://stpeter.im/ From bkihara.l@gmail.com Tue Jun 28 07:26:36 2011 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8A21F86E7 for ; Tue, 28 Jun 2011 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RD_TO_BAD_TLD=2.5] 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 QVcEp8YczKZ0 for ; Tue, 28 Jun 2011 07:26:34 -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 A3D5921F86E0 for ; Tue, 28 Jun 2011 07:26:34 -0700 (PDT) Received: by pwj5 with SMTP id 5so211237pwj.31 for ; Tue, 28 Jun 2011 07:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=slVYzrlG54NDdWtAcGjbNXH2MX4xux1/tkJMeN2Cjy8=; b=PTH6x47lXMsnOPx9A2irtNSXM3ckV3YzWIYRC3mEblzudEp+NXHktFYeLnmkfoFuE3 adnN9IYr8/ZxMtJzDXh++OrjkGeRB3oEPQxSklXmMkR2bLWcQ33EZtBPs/ctGPj3llZb lP5xnHi2/eDobDk8swIje7S6XjPFEJ5wxIac8= MIME-Version: 1.0 Received: by 10.142.212.3 with SMTP id k3mr856157wfg.323.1309271194195; Tue, 28 Jun 2011 07:26:34 -0700 (PDT) Received: by 10.142.200.4 with HTTP; Tue, 28 Jun 2011 07:26:34 -0700 (PDT) In-Reply-To: <4E094130.8050901@stpeter.im> References: <4E094130.8050901@stpeter.im> Date: Tue, 28 Jun 2011 23:26:34 +0900 Message-ID: From: "KIHARA, Boku" To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "http-auth@ietf.org" Subject: Re: [http-auth] RFC 2617 / Erratum # 2600 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 14:26:36 -0000 Seems reasonable. -- KIHARA, Boku 2011/6/28 Peter Saint-Andre : > At http://www.rfc-editor.org/errata_search.php?rfc=3D2617 can be found th= e > following report: > > ### > > Section 3.2.2 says: > > digest-uri =A0 =A0 =A0 =3D "uri" "=3D" digest-uri-value > digest-uri-value =3D request-uri =A0 ; As specified by HTTP/1.1 > > It should say: > > digest-uri =A0 =A0 =A0 =3D "uri" "=3D" <"> digest-uri-value <"> > digest-uri-value =3D request-uri =A0 ; As specified by HTTP/1.1 > > Notes: > > This is an error here that the digest-uri-value is not enclosed in > quotation marks; > see the correct example in Section 3.5: > > Authorization: Digest username=3D"Mufasa", > realm=3D"testrealm@host.com", > nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093", > uri=3D"/dir/index.html", > . . . > > ### > > I've checked the source code for Mozilla and Chrome (but not yet other > projects): > > http://mxr.mozilla.org/mozilla-beta/source/netwerk/protocol/http/nsHttpDi= gestAuth.cpp > > http://codesearch.google.com/#OAMlx_jo-ck/src/net/http/http_auth_handler_= digest.cc&exact_package=3Dchromium&ct=3Drc&cd=3D3&q=3Dqop > > http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/ffmpeg/patched-= ffmpeg-mt/libavformat/httpauth.c&exact_package=3Dchromium&ct=3Drc&cd=3D4&q= =3Dqop > > (The TODO notes in the Chrome source are kind of interesting...) > > This report seems like it might be correct, but I figured I would check > with the http-auth list and others before approving this erratum. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >