Subject: [websec] re-call for IETF http-auth BoF

From: Yutaka OIWA <[email-masked]>
Date: Mon, 06 Jun 2011 02:06:38 +0900

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
<http://www.w3.org/2011/identity-ws/>.

# 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
<http://www.ietf.org/mail-archive/web/http-auth/current/msg00770.html>,
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: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: "Harry Halpin" <[email-masked]>
Date: Sun, 5 Jun 2011 22:32:44 +0100 (BST)

> # 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
[email-masked] will be list I use to get input to the draft final
report, to join email "subscribe" in subject line to
[email-masked]. 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/

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 09 Jun 2011 23:31:55 +0900

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/
--------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jun 2011 16:40:50 +0200

On 2011-06-09 16:31, Yutaka OIWA wrote:
> ...
> ...

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).

 > ...
> ...

I believe you need to add HTTPbis.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Jun 2011 17:53:38 -0400

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 [email-masked].

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 [email-masked] 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?

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 12 Jun 2011 17:18:11 +0100

> I believe you need to add HTTPbis.

+1.

I would also add Kitten.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 14 Jun 2011 16:59:54 +1200

Phillip Hallam-Baker <[email-masked]> 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 Williams <[email-masked]>
Date: Tue, 14 Jun 2011 11:17:02 -0500

+1.

> 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=user,r=fyko+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=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
      s=QSXCR+Q6sek8bf92,i=4096

C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46
      Host: A.example
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
      p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=

S->C: HTTP/1.1 200
      Content-Type: application/rest-gss-login
      Content-Length: nnn

      A
      v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

Does that work for you?

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jun 2011 17:36:14 +0100

This is about http auth (and I'm glad to see the discussion) but can we keep it to just that list? 
Ta.
S

On 14 Jun 2011, at 17:17, Nico Williams <[email-masked]> wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: "KIHARA, Boku" <[email-masked]>
Date: Wed, 15 Jun 2011 18:44:37 +0900

+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 <[email-masked]>:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 15 Jun 2011 23:32:32 +0900

> 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.

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: Thomas Fossati <[email-masked]>
Date: Sat, 25 Jun 2011 10:59:07 +0200

> 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.  

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: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Jun 2011 15:43:00 -0400

> hand-over-the-password should killed and eaten to prevent them from passing

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.

> 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/