Subject: [http-auth] Fwd: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 12:12:10 -0700

FYI, there is a relevant thread happening on other lists...

-------- Original Message --------
Subject: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis
(httpbis)
Date: Wed, 22 Feb 2012 10:39:49 -0800
From: Paul Hoffman <[email-masked]>
To: Stephen Farrell <[email-masked]>
CC: Peter Saint-Andre <[email-masked]>, [email-masked],
The IESG <[email-masked]>, IETF-Discussion <[email-masked]>

On Feb 22, 2012, at 10:35 AM, Stephen Farrell wrote:

> Regardless of that you do have a fair point that asking
> apps folks to do stuff that'll please security folks might
> be asking for trouble:-)
> 
> However, the counter to that is that security folks doing
> stuff without enough apps input might produce something that
> won't get adopted which also doesn't produce the right end
> result.
> 
> Anyway, I think this topic, if tackled, won't lack
> interested participants and will get plenty of security
> and apps input no matter how we organise it.

Peter St.Andre's suggestion of a separate WG to deal specifically with
HTTP authentication seems like the best way to be sure both sets of
parties are fully involved. If the IESG charters it within the next few
months, the HTTP 2.0 work can be informed by any changes (if any) that
are needed.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Feb 2012 13:25:41 -0600

> FYI, there is a relevant thread happening on other lists...

I agree that a separate WG would be better.

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Feb 2012 13:27:17 -0600

> I agree that a separate WG would be better.

And to explain why: I can't subscribe to every WG list.  I don't care
about all things HTTP, but I care very much about web authentication.

That's another thing, I'd say this should be about web authentication,
not necessarily HTTP authentication, though the work it does might
well be exclusively new HTTP authentication methods.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 22 Feb 2012 11:55:08 -0800

> about all things HTTP, but I care very much about web authentication.

+1  (I'm already subscribed to too many lists to track.  If the web auth stuff were in one place -- even an existing list -- I could trim some of them.)

> well be exclusively new HTTP authentication methods.

+1

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Feb 2012 13:42:20 -0700

On 2/22/12 12:55 PM, Henry B. Hotz wrote:
>> And to explain why: I can't subscribe to every WG list.  I don't
>> care about all things HTTP, but I care very much about web
>> authentication.
> 
> +1  (I'm already subscribed to too many lists to track.  If the web
> auth stuff were in one place -- even an existing list -- I could trim
> some of them.)

This list seems to be the right place.

>> That's another thing, I'd say this should be about web
>> authentication, not necessarily HTTP authentication, though the
>> work it does might well be exclusively new HTTP authentication
>> methods.
> 
> +1

Good point.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Nico Williams <[email-masked]>
Date: Wed, 22 Feb 2012 15:09:08 -0600

Also, the reasons I want to focus on web authentication instead of HTTP:

 - technically it *is* web authentication that we need to fix, not
   HTTP authentication, even if fixing HTTP authentication turns
   out to be all we end up doing

 - my own proposal, REST-GSS, is to do authentication at the
   application layer, not in HTTP

Nico
--

---

From: "KIHARA, Boku" <[email-masked]>
Date: Thu, 23 Feb 2012 17:09:39 +0900

>   out to be all we end up doing

+1 What we need is secure web, not secure HTTP.

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 24 Feb 2012 00:01:12 +0900

Dear Nico, Peter and all,

>    out to be all we end up doing

Yes, agreed on our main goal.
At the same time, we have been considered the following things when
we first proposed the current HTTP-auth name:

 - Although the main goal is web security, there is also a need
   either to develop or to apply web-based technologies to the
   non-web authentications as well.  We should not limit our focus on the
   technologies which are "unwantedly limited" to Web authentications
   (if there is a technical reason to do so, it is OK.)

 - Considering the "web" layer, the focus may include other working areas
   as well: abfab (although they name themselves "beyond the web"), W3C,
   other standardizing bodies as well.  HTTP is clearly the primary area of
   IETF.

I think that name of Web auth is natural considering our main goal,
but in problem stating and chartering phases we will have to work out
clear topic definitions.

Oppositely, if we rephrase it to Web authentication, it may be including
some more interesting topics like relation between authentication and off-line
contents (or other long-lived contents).
Let's go on and have discussions soon.
Any ideas for such expanded topics?

>    application layer, not in HTTP

I personally thought that yours is not in the HTTP but on the HTTP,
so it is OK even under the current name :-)

-- 
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: Stephen Farrell <[email-masked]>
Date: Thu, 23 Feb 2012 15:06:44 +0000

So I've a question for people on this list.

How many of you would be able to authoritatively say whether
or not some new http authentication technology that might be
produced in a separate http authentication wg would actually
be adopted? (Where "authoritatively say" has the usual
qualifications that we're not discussing specific product
plans etc. etc.)

I'm not sure myself but am concerned that we not spin up a
security WG the output of which gets more-or-less ignored by
the major vendors/implementers.

I don't know if that's the case or not, but, assuming that
this list has many of the people who'd work in such a WG, I'd
like to have a better feel for that  so's we don't do the
wrong thing.

I realise that if such a WG were chartered, then new folks
would also come along as well, so this is just looking for
another input, and isn't intended to produce any definitive
answer to anything.

S

PS: I guess its possible some people might prefer to answer
this off-list (or partly off-list). If so, maybe mail Peter
and myself and we can summarise back to the list later.

On 02/22/2012 07:12 PM, Peter Saint-Andre wrote:
> From: Paul Hoffman<[email-masked]>
> To: Stephen Farrell<[email-masked]>
> CC: Peter Saint-Andre<[email-masked]>, [email-masked],
> The IESG<[email-masked]>, IETF-Discussion<[email-masked]>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 23 Feb 2012 17:27:49 +0200

Hi

IMO the drivers here are the web browsers, because UI is the hard issue. If we standardize New Super Cool Authentication for HTTP (or the applications) it would be relatively easy for someone to write mod_nsca for Apache and whatever add-ons are called for IIS. Similarly, modifying wget or CURL to support it should also be a short exercise.

Getting it in browsers from mobile phones to big screens in such a way that carefully tailored HTML5 cannot be made to mimic the UX is a far greater challenge.

So in my opinion, if we can get at least some of the browser implementors to do it (Yukata Oiwa's modified Firefox is a start, I guess) then the servers will follow. 
Once we get past that, the next hurdle would be to convince web designers to actually use it. But that's for the future, and really depends on how browsers implement it.

It's all riding on the browsers.

Yoav

On Feb 23, 2012, at 5:06 PM, Stephen Farrell wrote:

> Scanned by Check Point Total Security Gateway.

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Feb 2012 10:01:32 -0600

> qualifications that we're not discussing specific product

Likelihood of adoption hinges on a lot of things, of which browser
adoption is but one critical element.

The biggest issue will be how hard it is for websites to adopt the new
thing, whatever it is.  Site operators will need to deploy new
software, change enrollment processes, change verifier handling
processes, join federations, perhaps...

Maybe we should think outside the box.  Maybe we can have trusted
third parties issuing (setting) cookies for the sites they trust.
Danger, Will Robinson.  I know.  But given that cookies are what we
have...  And if we did channel binding of cookies (see Dirk B.'s OBC
proposal)...  I think it could work.  It's not my cup of tea, but... I
want a solution that works and gets adopted.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Feb 2012 17:24:59 -0800

To answer Stephen's question:  I have no special influence with browser makers.

> adoption is but one critical element.

Yes.  However I tend to think it's the biggest critical element.  Everyone doing an authentication scheme always starts with the question of what the browsers will support.  

Even a custom plug-in appears to be too steep a barrier for most developers.  It doesn't seem to be the development effort per-se, but a generic concern about being too far from the well-used capabilities.  That said I think a plug-in implementation for the majority of the browsers, coupled with Apache/IIS support that wasn't too much harder than TLS server certs to set up might fly.  But only *IF* there were a commitment by more than one browser maker to build it in in the future.

---

From: Cui Yang <[email-masked]>
Date: Fri, 24 Feb 2012 06:18:33 +0000

>It's all riding on the browsers.

+1. It had better focus on browsers in current step.

Yang
--
  Yang Cui,  Ph.D.
  Huawei Technologies, China
  [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Thursday, February 23, 2012 11:28 PM
To: Stephen Farrell
Cc: [email-masked]
Subject: Re: [http-auth] Fwd: Re: WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis)

Hi

Yoav

---

From: Harry Halpin <[email-masked]>
Date: Fri, 24 Feb 2012 12:44:27 +0100

> Yes.  However I tend to think it's the biggest critical element.  Everyone doing an authentication scheme always starts with the question of what the browsers will support.

The W3C has a pretty good track record lately of figuring out what can 
get in browsers, also would like to see forward movement on Web 
Authentication in close co-operation with the IETF.

Improved authentication was the original point of the Identity in the 
Browser in the workshop [1], but browser vendors did not see a clear 
path forward. However, there was clear demand for better JS crypto, so 
after many iterations, we now have the Web Cryptography Working Group to 
produce a unified JS API for crypto primitives in the browser [2]. Note 
that this JS API has agreement to be implemented from all major browser 
vendors and the WG launches first week of March.

However, I consider this work to be a stepping stone to fixing the 
larger Web authentication and identity problem on the Web. My personal 
intuition is that some of the capabilities enabled by the Crypto API 
could be easily combined with work around OAuth flows and possibly 
BrowserID (now Mozilla Persona [3]) to really help authentication on the 
Web without the impossible task of standardizing browser UX.

  Another interesting path discussed heavily at the workshop was 
co-ordination of authentication with the platform identity managers 
outside the Web (thus bypassing the DOM problems), but then you have to 
co-ordinate not only browsers, but operating systems.

We have booked a room at IETF Paris to discuss these approaches 
informaly, and as soon as I know the room/date, I'll forward this out.  
Perhaps something as closely co-ordinated as the RTCWeb/WebRTC work 
could come out of this.

   cheers,
       harry

[1] http://www.w3.org/2011/identity-ws/report.html
[2] http://www.w3.org/2011/11/webcryptography-charter.html
[3] 
http://www.h-online.com/open/news/item/Mozilla-revamps-BrowserID-as-Persona-1442304.html

---

From: Henry Story <[email-masked]>
Date: Fri, 24 Feb 2012 16:14:50 +0100

On 24 Feb 2012, at 12:44, Harry Halpin wrote:

> The W3C has a pretty good track record lately of figuring out what can get in browsers, also would like to see forward movement on Web Authentication in close co-operation with the IETF.
> 
> Improved authentication was the original point of the Identity in the Browser in the workshop [1], but browser vendors did not see a clear path forward. However, there was clear demand for better JS crypto, so after many iterations, we now have the Web Cryptography Working Group to produce a unified JS API for crypto primitives in the browser [2]. Note that this JS API has agreement to be implemented from all major browser vendors and the WG launches first week of March.
> 
> However, I consider this work to be a stepping stone to fixing the larger Web authentication and identity problem on the Web. My personal intuition is that some of the capabilities enabled by the Crypto API could be easily combined with work around OAuth flows and possibly BrowserID (now Mozilla Persona [3]) to really help authentication on the Web without the impossible task of standardizing browser UX.
> 
> Another interesting path discussed heavily at the workshop was co-ordination of authentication with the platform identity managers outside the Web (thus bypassing the DOM problems), but then you have to co-ordinate not only browsers, but operating systems.
> 
> We have booked a room at IETF Paris to discuss these approaches informaly, and as soon as I know the room/date, I'll forward this out.  Perhaps something as closely co-ordinated as the RTCWeb/WebRTC work could come out of this.

I live near Paris, and will be here too for the first day, though I have to go to a EU security conference in Switzerland that week too. Perhaps this would be a good opportunity to meet people from the group to chat with, and perhaps to present WebID too, for which the spec is http://webid.info/spec/ - WebID relies very strongly on TLS and many IETF standards.

	Henry

> [3] http://www.h-online.com/open/news/item/Mozilla-revamps-BrowserID-as-Persona-1442304.html
> 

Social Web Architect
http://bblfish.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Feb 2012 17:14:05 -0700

> I live near Paris, and will be here too for the first day, though I have to go to a EU security conference in Switzerland that week too. Perhaps this would be a good opportunity to meet people from…

As you can see, the schedule is quite full:

https://datatracker.ietf.org/meeting/83/agenda.html

Perhaps a get-together on Sunday evening (March 25) would make sense.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yutaka OIWA <[email-masked]>
Date: Tue, 28 Feb 2012 16:29:13 +0900

> Perhaps a get-together on Sunday evening (March 25) would make sense.

I'm really looking forward to see all of you soon.
I'm planning to be there from Saturday evening.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Feb 2012 09:49:11 +0200

I'll be there from Sunday noon, so Sunday evening works for me.