Subject: Re: [http-auth] HTTP request header field for acceptable authentication methods

From: bergi <[email-masked]>
Date: Thu, 03 Nov 2011 23:34:33 +0100

Am 02.11.2011 01:59, schrieb Mark Nottingham:
> 
> On 31/10/2011, at 8:27 PM, Dominik Tomaszuk wrote:
> 
>> On 30.10.2011 22:38, bergi wrote:
>>> Currently my and maybe most other web applications with WebID support
>>> have the following flow for user authentication:
>>>
>>> - The user sees your web page with reduced content
>>> - The user follows the login link
>>> - The login resource asks for a client certificate
>>> - The WebID gets bound to the session cookie
>>> - The server sends a redirect to the original page
>>> - Finally the user sees page with the content for that WebID
>>>
>>> For example the Java address book application or most robots want to
>>> access the resource in a RESTful way and will not use the described
>>> flow. I haven't found a way to force the use of a client certificate if
>>> the server doesn't ask for one. I propose to use a HTTP header field to
>>> tell the server that the client is able to authenticate with a WebID. As
>>> such a field could be also useful for other authentication methods I
>>> would chose a generic name. There are already some Accept-* fields I
>>> would follow that pattern. As it's currently not a standard field I
>>> would prefix that field with X-.
> 
> Please, please don't do this. See:
>   http://tools.ietf.org/html/draft-ietf-appsawg-xdash
> 
> 
>>> Multiple values must have the same
>>> format as defined for the Accept field. Also the quality parameter must
>>> be handled by the server.
>>>
>>> Example only with WebID authentication:
>>> X-Accept-Authentication: WebID
>>>
>>> Example with WebID and Basic authentication:
>>> X-Accept-Authentication: WebID, Basic;q=0.9
>>>
>>> What do you think about my proposal?
>> It might be interesting to HTTPBis, part 7: Authentication [1] and HTTPBis Authentication Scheme Registrations [2]
>>
>> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-16
>> [2] http://tools.ietf.org/html/draft-ietf-httpbis-authscheme-registrations-02
> 
> 
> It's not appropriate in the HTTPbis documents, as they're specifically NOT introducing new mechanisms.
> 
> Optional authentication has been widely discussed in the past; you might want to try the http-auth list <https://www.ietf.org/mailman/listinfo/http-auth>.
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 

Thanks!

Maybe we should split this a little bit.

Authentication Scheme

I was thinking about this a little bit more and now I'm not sure if we
should use WebID or WebID-TLS or even something else. From the
terminology point of view WebID-TLS would fit better.

HTTPBis, part 7, section 2.3 [1] points to a link on the IANA web site
which is dead [2]. I haven't found a new URL. Somebody knows if this
page has moved somewhere else?

On the other hand  HTTPBis, part 7, section 2.3.1 [3] says: "..thus an
authentication scheme can not bind information to the TCP session over
which the message was received...". But even if this is true for our
case, the proposed field could and should be used by WebID and existing
HTTP authentication schemes. A registered scheme could avoid name conflicts.

Acceptable authentication schemes request field

Just a summarization: The field Accept-Authentication tells the server
which authentication scheme the clients supports. Valid values are one
or multiple HTTP authentication schemes. Each value can have a quality
factor which must be handled like the one for the Accept field
(described in RFC2616, section 14.1 or HTTPBis, part 3 section 6.1 [4]).

[1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3
[2] http://www.iana.org/assignments/http-authschemes
[3] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1
[4] http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-17#section-6.1

the bergi

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 04 Nov 2011 08:54:54 +0900

Dear Dominik,

# Reply-to set to http-auth mailing list, be careful.

I am actually interested about the idea, as I was considering similar one
for another purpose (footnote *1).

As Mark Nottingham has suggested in another reply in HTTPBIS,
it should not be X- prefixed, and it seems not to be the area of HTTPBIS working
group.  HTTP-AUTH list seems to be appropriate for a moment, and
if it goes rapidly than HTTP-Auth activity, it may possibly be rerouted
to the APPSAWG.

Currently I am submitting an individual draft called
"HTTP Authentication Extensions for Interactive Clients"
<http://tools.ietf.org/html/draft-oiwa-http-auth-extension-00>, and
if you allow me I would like either to include it to the next version of this
draft, or to write a separate draft for that header.

However, there seems to be a few things to be solved before specifying:

0) the name: HTTP does not have the corresponding *-Authentication header.
Should it be either Accept-Authentication, Accept-Authorization, or
Accept-WWW-Authenticate?

1) The header will naturally take tokens for HTTP authentication schemes, which
will have registration entries in "HTTPBis Authentication Scheme Registrations"
you have mentioned, as all other "Accept-*" headers do somewhat similar.
You have included "Basic" in an example, I guessed from that.
However, as far as I know, WebID will not use HTTP Authentication layer, and
thus it will (at least naturally) not have an entry in the registry.  We will
have to find the way to include non-HTTP authentication names in the headers
unambiguously, by
 a) find some distinguishable syntax for holding two separate name-spaces,
 b) find a way to have registration system for non-HTTP authentication,
    either unified or non-conflicting to HTTP-Auth scheme tokens, or
 c) find an (unlikely?) way to reserve a token in the HTTP-Auth registry.

2) Do we really need qvalue here?  Or what q=0 suggests?

Do you have some opinion about these?

(*1) As far as several HTTP-Auth schemes are involved, the HTTP auth framework
     allows servers to provide several possible schemes at once, and
     clients to choose the most strong one.  However, I want to allow
     servers to check whether clients accepts my Mutual authentication scheme,
     otherwise divert to Form authentication possibly for transition purpose.

> On 30.10.2011 22:38, bergi wrote:
(skipped)
>> I propose to use a HTTP header field to
>> would prefix that field with X-. Multiple values must have the same
> Best,
> Dominik 'domel' Tomaszuk

-- 
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: Mark Nottingham <[email-masked]>
Date: Fri, 4 Nov 2011 16:03:30 +1100

> page has moved somewhere else?

That link is dead because HTTPbis hasn't been through the entire process yet; the IANA registries will be established later on.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Nov 2011 12:55:26 +1100

Not sure why you're asking me; perhaps the cc list needs to be trimmed? 

On 05/11/2011, at 12:45 PM, Peter Williams <[email-masked]> wrote:

> So what is webid vs webid-tls?
> 
> Does webid tls exclude ssl v3?
> 
> I ask as only very specific agendas call for the elimination of ssl v3. Only .001%  of the users know the difference, and less than half of those can accurately state it.
> 
> 
> On Nov 4, 2011, at 2:28 AM, "Mark Nottingham" <[email-masked]> wrote:
> 
>> 
>> _______________________________________________
>> foaf-protocols mailing list
>> [email-masked]
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

---

From: Henry Story <[email-masked]>
Date: Sat, 5 Nov 2011 22:45:58 +0100

Perter Williams is our Paranoid Android, please take what he says with a pinch of salt. 

WebID currently specialises on TLS, just because that is what works in current browsers, and because we are an incubator group, and don't have infinite resources to work on a logic to tie these all together. These things can be tied together, we will have some demos soon. The IETF knows very well that multiple specifications can interact together fluidly. One does not have to write the one spec to finish all specs.

Henry

On 5 Nov 2011, at 19:36, Peter Williams wrote:

> The issue of webid, browserid (and the 5 other latest schemes doing the same thing) has become religious, at the cultish level. One sees the cc: trick, as folks seek to make their case. To be fair, browserid community is a bit more disciplined than others, on keeping a lid on broadcast-based prosletizing.
>  
> All I see is 5 new unverified schemes with about a max of 1000 users each (mostly developers), vying for attention in the usual vendor space. Each denies the legitimacy of the other, including such as gmail or yahoo or openid or SAML or ws-fedp, or OAUTH, or OAUTH v2,  or anything else. AS a consumer of such assertions, I reject any  scheme  proposal IF IT HAS THAT POSTURE. The posture means its too immature for adoption by the likes of us (mainstream). We are really not interested in another Google Wave.
>  
> There seems nothing to be done to stop the endless pursuit of assertion protocols. Any scheme that half-works simply induces a counter-scheme to become designed, as folks seek to impose some or other twist on what MUST now be trusted. This seems to be lobbyist-based, as some new infrastrcuture business sees $$ in controlling user logon. For browserid, someone believes that only email providers enable scalable verification. For our users , half of them use gmail and gmail already does the equivalent of a browserid assertion and validation. Its called openid v2. For me, its was trivial to integrate openid (i.e. Google), as Microsoft's ACS ideneity gateway did 100% of the work for us. Integrating microsoft gateway was pretty trivial, too. It want hard to pursuade the security auditor that our work was "reasonable."
>  
> If it helps, perhaps note that we are service provider. We are logically an adoptee of schemes such as browser, assuming they deliver a 100 million users to our door - since we need the problem solved "at a national level". its just the nature of real estate. We have even decided to get out of the login and authentication business (after 40 years). Nothing helped make anyone happy - despite having delivered password management, securid tokencodes, phone-based SMS, passmark anti-fraud neural networks, and even biometrics. We are even designed our own secure USB key, for a while. No user community was/is happy. Every subgroup wants some twist, to suit their personal hot button issue. The user community is almost as fragmented as the vendor community. Of course, noone will pay anything, as its someones else responsibility. Whats more (in our unusual space), no ads are allowed - so even that funding trick is unavailable. Folks cannot even trade off their privacy for free security technology.
>  
> If anyone cares (and I rarely find folks in the religious phase of a movement could give a damn, wanting only to preach to those likely to be "converted") we have stopped accepting any of the third-party schemes, unless its gatewayed to us by the Microsoft Azure ACS service. Fpr the next year or two, they are the gatekeeper on the n schemes, rewriting the n assertion blob formats into one. Its not that there is anything special about the Microsoft Azure service to us, other than its scheme agnostic. What it does is make identity verification less of a "miserable affair", removing the posturing and the carping that is getting in the way of delivering service values.
>  
> Hope the feedback on the list's tone helps.
>  
> > CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> > From: [email-masked]
> > Subject: Re: [foaf-protocols] HTTP request header field for acceptable	authentication methods
> > Date: Sat, 5 Nov 2011 12:55:26 +1100
> > To: [email-masked]
> > 

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Sun, 6 Nov 2011 10:19:20 +0100

On 6 Nov 2011, at 01:22, bergi wrote:

> Maybe in combination with Basic it doesn't make sense, but a user/robot
> could have multiple decentralized identities with different protocols.
> The server may not support all of them, but with the qvalue the client
> could tell what's the protocol of the primary id.
> 
> Example with WebID (primary) + OpenID:
> Accept-Authentication: WebID, OpenID;q=0.9
> 
> In our particular case qvalue=1 could also mean that the server should
> ask for a certificate in "need-mode" otherwise in "want-mode". Some
> client implementations don't handle the "want-mode" in the right way and
> don't even ask for a client certificate. In "need-mode" the client must
> provide a certificate otherwise the server closes the connection with an
> error. The "need-mode" should work with all implementations.

I hasten to add that the NEED mode is the least user-friendly one, when considering Human users. Humans can mistakenly click the cancel button, and not send a certificate, thereby automatically breaking the connection, which usually leaves the client showing a very ugly UserInterface. Want mode is a lot more elegant. But we may have to live for some time with clients that require NEED.

It seems Java has this issue for example
  https://bugs.openjdk.java.net/show_bug.cgi?id=100213

And some versions of Safari also I seem to remember.

Henry

Social Web Architect
http://bblfish.net/