Subject: [http-auth] HTTP-Auth activity in oncoming IETF Paris Meeting

From: Yutaka OIWA <[email-masked]>
Date: Mon, 23 Jan 2012 20:29:09 +0900

Dear HTTP-AUTH Members,

I would like to propose another http-auth meeting-up at IETF Paris.
Main topic might be face-to-face discussion on our problem-space
survey in IETF Sec-area Wiki

http://trac.tools.ietf.org/area/sec/trac/wiki/HttpAuthentication/ProblemSpace

so that we can update the problem statement I-D and go forward for possible
future chartering.  Suggestions about scheduling, format of meeting, topics or
anything other are really welcome.

I am thankful for several comments and updates for the Wiki contents, and
currently I am looking for people who can update the contents especially
regarding Negotiate and other authentication mechanisms which enable
bridging between HTTP and existing authentication frameworks such as
GSS, SASL or Kerberos.  Any volunteers or candidates?

Since Vancouver we have talked with several people and had presentation sessions
in both IIW and W3C TPAC in California.  I'd like to update our project status soon.

I'm looking forward to seeing you in Paris!

-- 
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: Yoav Nir <[email-masked]>
Date: Mon, 23 Jan 2012 14:52:08 +0200

Hi

I think a big obstacle to converging on a charter item for a new or existing working group, is that there are so many possible solutions all over the map. We've heard proposals for the authentication in TLS, in HTTP, and in HTML (or more likely javascript)

If you would like this to lead to charterable work, I suggest you concentrate on one of these avenues (I think the HTTP), and have a good explanation why not the others. Then confine the discussion to that avenue only.

As I have said in QC, once there's a charter item in some group, you'll get plenty of crypto suggestions. We got 4 competing proposals in IPsecME, so I suggest to keep the crypto out of the discussion for now. Just try to get consensus that we need to work on an HTTP-based method for authentication.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yutaka OIWA
Sent: 23 January 2012 13:29
To: [email-masked]
Cc: Alexey Melnikov; Mark Nottingham; Thomas Roessler
Subject: [http-auth] HTTP-Auth activity in oncoming IETF Paris Meeting

Dear HTTP-AUTH Members,

I would like to propose another http-auth meeting-up at IETF Paris.
Main topic might be face-to-face discussion on our problem-space survey in IETF Sec-area Wiki

so that we can update the problem statement I-D and go forward for possible future chartering.  Suggestions about scheduling, format of meeting, topics or anything other are really welcome.

I am thankful for several comments and updates for the Wiki contents, and currently I am looking for people who can update the contents especially regarding Negotiate and other authentication mechanisms which enable bridging between HTTP and existing authentication frameworks such as GSS, SASL or Kerberos.  Any volunteers or candidates?

Since Vancouver we have talked with several people and had presentation sessions in both IIW and W3C TPAC in California.  I'd like to update our project status soon.

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

Scanned by Check Point Total Security Gateway.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 14:01:08 +0100

> As I have said in QC, once there's a charter item in some group, you'll get plenty of crypto suggestions. We got 4 competing proposals in IPsecME, so I suggest to keep the crypto out of the discuss…

+1

Also: maybe concentrate on what's broken first?

- no way to logout (need a Javascript API -> W3C Webapps WG?)

- fix implementations (parsing WWW-Authenticate)

- maintain a test suide (W3C Test IG?)

- fix I18N for Basic auth

- fix UI issue (better support for HTML-form-based logon to HTTP auth)

...and so on...

---

From: Harry Halpin <[email-masked]>
Date: Mon, 23 Jan 2012 15:23:58 +0100

On 01/23/2012 02:01 PM, Julian Reschke wrote:
>> I think a big obstacle to converging on a charter item for a new or 
>> existing working group, is that there are so many possible solutions 
>> all over the map. We've heard proposals for the authentication in 
>> TLS, in HTTP, and in HTML (or more likely javascript)
>>
>> If you would like this to lead to charterable work, I suggest you 
>> concentrate on one of these avenues (I think the HTTP), and have a 
>> good explanation why not the others. Then confine the discussion to 
>> that avenue only.
>>
>> As I have said in QC, once there's a charter item in some group, 
>> you'll get plenty of crypto suggestions. We got 4 competing proposals 
>> in IPsecME, so I suggest to keep the crypto out of the discussion for 
>> now. Just try to get consensus that we need to work on an HTTP-based 
>> method for authentication.
>>
>> Yoav
>
> +1
>

This is going to happen in the Web Cryptography Working Group. The 
charter is finished, W3C WG to begin after patent commitments to charter 
are finalized (expecting mid-February):

http://www.w3.org/2011/11/webcryptography-charter.html

> - maintain a test suide (W3C Test IG?)

The interest group is for sharing test suite design, a test suite should 
still likely happen under the IETF if the IETF is up for it.

> - fix UI issue (better support for HTML-form-based logon to HTTP auth)

As UI is one of the areas that browsers still compete on, standardizing 
UI will simply not happen.

>
> ...and so on...
>
> _______________________________________________
> http-auth mailing list
> [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 15:39:48 +0100

On 2012-01-23 15:23, Harry Halpin wrote:
> ...

That would be cool.

> still likely happen under the IETF if the IETF is up for it.

The IETF so far isn't good in hosting tests; if the W3C had the 
infrastructure earlier (because of HTML testing) it might make sense to 
use that.

> UI will simply not happen.

I was referring to what some people call HTML-form based HTTP 
authentication, which works by sending an HTML login form with a 403 
status, and then use JS + XHR to actually perform HTTP auth based on the 
entered credentials. It appears this "works" in Firefox and Internet 
Explorer, so it might make sense to find out what needs to be done to 
make it work better (as in other browsers, and with a proper 401 status 
code).

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Jan 2012 16:50:55 +0200

>> - fix I18N for Basic auth

Do we really want to touch basic auth?

> UI will simply not happen.

While we can't standardize UI (besides, it is bound to look different on a desktop screen than on a phone), but we can standardize UI requirements. Specifically, we can require that the authentication dialog will be something that cannot be achieved with regular HTML5/Flash/other canvas technologies.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 16:07:13 +0100

> Do we really want to touch basic auth?

It's in use. It suffers from I18N problem. I don't see a simple 
replacement. Why not fix it?

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Mon, 23 Jan 2012 08:18:21 -0800

I too agree that focusing the discussion a little is in order, and
that improved/new HTTP authentication protocols make sense.

However, I would caution that just because the focus may be on HTTP
authentication, that doesn't mean some effort shouldn't be put into
integration with other layers and standards.  That is, browser
interaction with HTTP authentication continues to be pathetic.  Also,
a lot of value can be derived from improving the way XMLHttpRequest
uses HTTP authentication.

cheers,
tim

---

From: Tim <[email-masked]>
Date: Mon, 23 Jan 2012 08:23:08 -0800

> Also: maybe concentrate on what's broken first?

That seems like that might be a good way to narrow the focus to
achievable goals.  That doesn't mean we should necessarily stick with
existing HTTP auth protocols, but at least defining the WG scope as
trying to address existing HTTP auth shortcomings.

> - no way to logout (need a Javascript API -> W3C Webapps WG?)

YES!

> - fix UI issue (better support for HTML-form-based logon to HTTP auth)

Well, we essentially already have this through XMLHttpRequest.  What
we could use is improvements to the XMLHttpRequest interface so more
advanced HTTP authentication protocols could be used, but for
username/password pairs, the current XMLHttpRequest spec works well.

Yes, I know XMLHttpRequest is JavaScript, not HTML, but it fills the
need for a GUI-based login for users.  HTTP authentication already
handles the need for non-GUI/scripted logins.

tim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 17:32:45 +0100

> handles the need for non-GUI/scripted logins.

But unless I'm missing something, it requires using a non-401 response 
to initiate the login. That's cheating, because the server needs to 
special-case clients that can use the form from others.

One way to address this might be an auth-param that allows the recipient 
to display the response body despite it being sent with 401 with a known 
auth scheme.

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Mon, 23 Jan 2012 08:40:25 -0800

> But unless I'm missing something, it requires using a non-401
> response to initiate the login. That's cheating, because the server
> needs to special-case clients that can use the form from others.

Actually, if my memory serves correctly, the only reason this is
necessary is because browsers don't follow the W3C XMLHttpRequest
spec.  They prompt users with a dialog box upon receiving an XHR 401
response whereas the spec explicitly states that they shouldn't do
this under certain conditions.  So it's just an implementation issue
(across the board).

> One way to address this might be an auth-param that allows the
> recipient to display the response body despite it being sent with
> 401 with a known auth scheme.

Yeah, fortunately this shouldn't be necessary if browsers just
followed the XMLHttpRequest spec.

Good thing to point out though,
tim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 17:50:15 +0100

> this under certain conditions.  So it's just an implementation issue

Not sure. The whole point here is that you can open a browser with a URI 
requiring auth, and the right thing happens. In this case, the request 
that needs authentication is not an XHR request.

> followed the XMLHttpRequest spec.

...not sure (see above). This shows it needs to be written down :-).

---

From: Tim <[email-masked]>
Date: Mon, 23 Jan 2012 09:17:57 -0800

> Not sure. The whole point here is that you can open a browser with a
> URI requiring auth, and the right thing happens. In this case, the
> request that needs authentication is not an XHR request.

Ok, to put a finer point on it, the following website login setup
should be possible right now without any nonstandard response codes
and without changes to any specs:

/login.html   - plain HTML page with JavaScript
/authenticate - dynamic page which performs HTTP authentication

The login.html page includes a normal login form.  Upon submitting it,
JavaScript uses XMLHttpRequests to set up the user's HTTP auth session
by sending requests to /authenticate.  For clients that don't support
JavaScript, a simple HTML link which points to /authenticate can be
provided.  

I suppose if you were clever, you could provide an /index.html page
which detects whether or not JavaScript is supported and redirects
users to the appropriate page, maybe using a combination of META
redirect timeouts and JavaScript.

Now, if you want to have *true* integration with forms, we certainly
could pressure browser makers to:

A.  Not pop-up an annoying modal dialog when a 401 is received.
Instead, provide a login prompt in the "chrome" next to the URL bar.

B. Display the page content of a 401 at the same time that the chrome
password prompt appears.

I've spent quite a bit of time searching the HTTP RFCs to locate
anything that forbids this behavior and haven't found anything.  It is
currently just an implementation choice that browsers aren't
displaying the 401 body.

This change would allow /login.html and /authenticate to be merged
into a single page.  Sites that don't want two password prompts to
appear on the same page (chrome+401 body) could continue to use the
split page approach that works right now.

> ...not sure (see above). This shows it needs to be written down :-).

I'm thinking this latter change is what you are referring to, yes?  I
agree it is worth defining these behaviors in more detail and at least
setting down in words what would be a better approach.  I think
improvements to XMLHttpRequest will be important too, to allow for
more advanced HTTP auth protocols in the future.

Thanks,
tim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 18:35:34 +0100

> redirect timeouts and JavaScript.

Yes, and people are doing that (using UA sniffing).

Optimally, we wouldn't need sniffing, and also server login.html with a 
status of 401.

> currently just an implementation choice that browsers aren't

Displaying both a login field somewhere *and* the response body (which 
usually isn't helpful) probably would be confusing.

The browsers may need an indicator that tells them that the response 
body really is worth displaying.

> more advanced HTTP auth protocols in the future.

As far as I can tell, XHR-based login doesn't work with Safari and Opera 
(<http://www.peej.co.uk/articles/http-auth-with-html-forms.html>); it 
would be worthwhile to investigate this (bug or just an implementation 
detail?) and to see whether the situation can be improved.

Best regards, Julian

---

From: Tim <[email-masked]>
Date: Mon, 23 Jan 2012 09:54:00 -0800

> Displaying both a login field somewhere *and* the response body
> (which usually isn't helpful) probably would be confusing.
> 

That certainly doesn't hurt to have.

> (<http://www.peej.co.uk/articles/http-auth-with-html-forms.html>);
> it would be worthwhile to investigate this (bug or just an
> implementation detail?) and to see whether the situation can be
> improved.

In my investigation a couple of years ago, I was able to get Safari
working fine, but not Opera.  (I believe I used the peej.co.uk article
as a reference, as it looks familiar.)  All of the browsers would be a lot
easier to deal with if they followed the XHR spec to the letter, but
some deviate more than others.  Check out the source comments in my
proof of concept implementation:
  http://vsecurity.com/download/tools/fbha-poc_0.1.zip

I did try to contact developers for the top 5 browsers after I did
this investigation, but it is very difficult to get meaningful
dialog going with many of them.  If we have a more comprehensive HTTP
auth story as to why browser makers should follow existing specs, then
maybe it would be easier to get traction. It would be interesting to
test the various scenarios on recent versions of browsers, now that
some time has passed.

tim

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 23 Jan 2012 20:12:49 +0200

Hi Yutaka, 

you may want to take a look at this document:
http://tools.ietf.org/html/draft-tschofenig-secure-the-web-00

Ciao
Hannes

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 23 Jan 2012 18:01:31 -0800

IIRC there was some consensus that real security was not possible unless it interacted with browser chrome.  (Any html form is inherently spoofable, since an evil MITM web site just issues html that looks the same to the user.)

Will there be representation from the major browser vendors present?

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]