Re: [http-auth] re-call for IETF http-auth BoF
Yutaka OIWA <y.oiwa@aist.go.jp> Thu, 09 June 2011 14:32 UTC
Return-Path: <y.oiwa@aist.go.jp>
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 <y.oiwa@aist.go.jp>
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 <turners@ieca.com>
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 <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=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 <http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs/IETF80/http-auth/AdditionalMaterials/DraftProblemStatement>. 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: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5]
- Re: [http-auth] [saag] re-call for IETF http-auth… Yutaka OIWA
- Re: [http-auth] [saag] re-call for IETF http-auth… Tim
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Harry Halpin
- Re: [http-auth] [saag] re-call for IETF http-auth… Hannes Tschofenig
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Tim
- Re: [http-auth] [saag] re-call for IETF http-auth… Marsh Ray
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Stephen Farrell
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] [saag] re-call for IETF http-auth… Marsh Ray
- Re: [http-auth] [saag] re-call for IETF http-auth… Nico Williams
- Re: [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] re-call for IETF http-auth BoF Julian Reschke
- [http-auth] Fwd: re-call for IETF http-auth BoF Yutaka OIWA
- Re: [http-auth] [websec] re-call for IETF http-au… Phillip Hallam-Baker
- Re: [http-auth] [websec] re-call for IETF http-au… Alexey Melnikov
- Re: [http-auth] [saag] [websec] re-call for IETF … Peter Gutmann
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [websec] [saag] re-call for IETF … Stephen Farrell
- Re: [http-auth] [websec] [saag] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … KIHARA, Boku
- [http-auth] Fwd: [saag] [websec] re-call for IETF… KIHARA, Boku
- Re: [http-auth] [websec] Fwd: [saag] re-call for … Thomas Roessler
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Yutaka OIWA
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Peter Gutmann
- Re: [http-auth] [saag] [websec] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Josh Howlett
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Marc Williams
- Re: [http-auth] [saag] [websec] Fwd: re-call for … SHIMIZU, Kazuki
- Re: [http-auth] [saag] [websec] Fwd: re-call for … GOGWIM, JOEL GODWIN
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Nico Williams
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Henry B. Hotz
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yutaka OIWA
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yutaka OIWA
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Yaron Sheffer
- Re: [http-auth] [websec] [saag] Fwd: re-call for … Marsh Ray
- Re: [http-auth] [websec] [saag] Fwd: re-call for … Stephen Farrell
- Re: [http-auth] [saag] [websec] Fwd: re-call for … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Phillip Hallam-Baker
- Re: [http-auth] [websec] [saag] re-call for IETF … Thomas Fossati
- Re: [http-auth] [websec] [saag] re-call for IETF … Nico Williams
- Re: [http-auth] [saag] [websec] re-call for IETF … Henry B. Hotz