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]