Subject: [TLS] HTTPS client-certificate-authentication in browsers

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 14:06:59 +0200

Hi Guys,
I don't really know who "owns" this question but presumably you do...

HTTPS client-certificate-authentication in browsers
===================================================
I don't believe that TLS CCA (Client Certificate Authentication) in the
form of HTTPS as implemented in current browsers has much of a future.

In fact, quite a bunch of the entities in the EU working with consumer PKI
have replaced HTTPS CCA with an application level scheme which wasn't such
a big deal since they anyway were forced writing a browser PKI client more
or less from scratch since the ones shipped with browsers doesn't support
PKI as defined by banks and government (like mandatory PIN codes also
for on-line enrolled keys).

That the TLS CCA protocol doesn't even support "Logout" haven't made
it a logical choice for web developers either.  Well, there are some
workarounds but they are by no means straightforward, supported
out-of-the-box by server authentication schemes, and are (of course)
entirely undocumented.

The button "Clear SSL state" in MSIE is an indication how horribly bad it
can go when security experts design systems for "people".

There's no way you can hide the fact that TLS CCA is only truly useful
securing tunnels between "boxes".

Anders

---

From: Henry Story <[email-masked]>
Date: Mon, 25 Jul 2011 14:31:52 +0200

Hi Anders, I kind of lurk here, but I don't think that client side
CAs are impossible to get right in the browsers. They are pretty close
to doing things right. Logout from the browsers would not be that difficult
to do. I kept thinking that the W3C project http://webid.info/ could stimulate
the improvement of these pieces.

But I would be interested in feedback from this list on the subject.

Henry

On 25 Jul 2011, at 14:06, Anders Rundgren wrote:

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

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 14:58:54 +0200

> But I would be interested in feedback from this list on the subject.

Hi Henry,

If there had been a *single* mainstream service of US origin who used
HTTPS CCA this would be fixed in record time.

The tenths of millions of users of "homegrown" PKI authentication schemes
in the EU and Asia apparently don't think HTTPS CCA is particularly useful,
neither do I.  TLS' session context is incompatible with web sessions.

For our mutual interest, PKI for consumers, it doesn't really matter what
the end-solution will be, but an educated guess is that will not build
on HTTPS CCA, but on HTTPS with + an application.  This is BTW pretty
much what has happened with HTTP auth versus form-based auth.

Fortunately this can be introduced without redeploying PKI so it is a
true "migration solution".

Anders

---

From: Henry Story <[email-masked]>
Date: Mon, 25 Jul 2011 15:05:52 +0200

> HTTPS CCA this would be fixed in record time.

What about the army? They are pretty big in the US, representing a huge portion
of the budget I believe.

> neither do I.  

I believe that is only because of the naming problem. Distinguished Names of companies
don't scale to the world.

> TLS' session context is incompatible with web sessions.

Why?  A TLS Session can work very well with web sessions. You can 
just make your TLS session be a web session.

> much what has happened with HTTP auth versus form-based auth.

yes, but there is no argument for why this is the case. And you don't 
even consider http://webid.info/

> true "migration solution".

IT's odd that people want to move away from something that is close to working.
I wonder why... What is the agenda?

    Henry

Social Web Architect
http://bblfish.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Jul 2011 09:37:07 -0400

> I don't really know who "owns" this question but presumably you do...

I've forwarded your message to the [email-masked] list because folks
there might also be interested.

https://www.ietf.org/mailman/listinfo/http-auth

Peter

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

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 15:38:35 +0200

> What about the army? They are pretty big in the US, representing a huge portion

Yes, but the army has IT-staff that takes care of "issues", consumers
do not.  The army is also much less fuzzy about inconvenience.

> don't scale to the world.

There are actually several other problems that are much worse.
On my wife's firefox the bank have deployed two certs and
both of the show up when she is going to login.  If she
takes the one marked "non-repudiation" you get a security
error that only experts understand.

> just make your TLS session be a web session.

AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever
on a TLS session.

> even consider http://webid.info/

WebID isn't diminished by this.  It just gets better :-)

> I wonder why... What is the agenda?

They have given up on this.
"Close to working" isn't good enough.

Anders

---

From: Henry Story <[email-masked]>
Date: Mon, 25 Jul 2011 16:18:09 +0200

> do not.  The army is also much less fuzzy about inconvenience.

Most of all the army have a huge namespace, so that one certificate can do
a lot of work. This proves that if one can grow the user of a certificate
the benefits will grow too. So the first issue to solve with certs is
to make them useful across the whole internet. That then changes the game.

If you look at what Facebook connect is doing you will see how that works.
And it also proves that the attempt to be completely anonymous is not what
people are looking for.

> error that only experts understand.

Firefox has the worst UI of all. Banks should set up incentives
for people to move to more secure browsers. They also have enough
money to pay for the changes directly.

The bank should probably have signed those certificates with different
distinguished names, then it could have asked for the right one.

Does the bank also really have to throw such an ugly exception? Could it
not be more intelligent in the web server on how that is processed?
> AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever

They are two different things. I think you  cannot logout the client from
the server, though recently you pointed to some javascript that could allow that.

This may be something the server vendors need to work on. The question first has
to be asked: is this a necessary limitation, or is it just not implemented well?

> WebID isn't diminished by this.  It just gets better :-)

Well WebID type auth can be used in BrowserId, as I explained in detail 
http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424#5424

But TLS client certs have a very nice advantage is that they are very efficient, and work in many
other areas too, especially server to server. So other means are good, but don't give up TLS -
well improve it.

> "Close to working" isn't good enough.

I agree. They need to finish the job. But they won't do it unless it is shown why it is useful.
And there it just needs a few companies to make a good demo.

Henry

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 16:33:49 +0200

> https://www.ietf.org/mailman/listinfo/http-auth

Thanx Peter,

I'm a bit of a skeptic when it comes to new or extended auth
protocols based on the transport layer, for usage in browsers.
It seems more flexible supplying meta-data at the app-level.

"Web Programmers" do not really understand TLS and that is
also a factor to consider.

I agree that this may be "unclean" but HTTPS CCA has been
neglected, and there are alternatives already in production
that looks much "prettier".

There is another issue that is related.  In the EU web signing
is fairly popular but not supported at all by for example Microsoft.

Regards,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 16:43:16 +0200

On 2011-07-25 16:18, Henry Story wrote:
<snip>
> the server, though recently you pointed to some javascript that could allow that.

I did but I also used a scheme where I had a login site on one port
and the rest on another port.  I found this working more by accident.

It may be security-broken and browser-incompatible etc.

> to be asked: is this a necessary limitation, or is it just not implemented well?

This may be above my knowledge but I think it is impossible to do this on
the server only.  Why?  Otherwise it had already been done.

<snip>
Anders

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jul 2011 11:25:27 -0400 (EDT)

> form of HTTPS as implemented in current browsers has much of a future.

<shameless plug>

I have been thinking of a "SNI" for the client side, and then decoupling
PKIX from the TLS auth to allow other forms of TLS server/client authentication:

http://www.ietf.org/internet-drafts/draft-wouters-tls-oob-pubkey-00.txt

I actually had the CNI as part of the draft first. I'll do a quick 10 minute
talk on Thursday on this.

A client name identifier would allow mutual identification with an authentication
scheme picked by each end based on a qualifier.

Paul

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 01:51:43 +0200 (MEST)

> form of HTTPS as implemented in current browsers has much of a future.

It works perfectly fine and we've been using it >10 years for
all of our intranet (50.000 employees these days) web servers
accessed via HTTPS, using TLS client certs for Single Sign-On.
(similar to how Kerberos is used by others).

> for on-line enrolled keys).

I think you're confusing things.

What you're looking at here is scenarios for individually authenticated
transactions.  That is an entirely different problem domain and not
addressed by TLS at all.  You would have to address that with
a browser plugin that accesses a completely different PKI credential
that has signature qualities, with a clearly defined protocol that
describes what data gets signed, and which requires seperate per-transaction
authorization for every signature operation.

> it a logical choice for web developers either.

Huh?  I have no clue what you're talking about.

If the server wants to perform a logout operation,
it can delete the TLS session cache entry on the server.

But the Single Sign-On capability of the TLS client cert means
that as long as the client credential is still available to the
TLS client, the client will perform "transparent" reauthentication.

> can go when security experts design systems for "people".

Is your intention to get prompted again?
>From a usability standpoint, we prefer the "select automatically"
setting and spare our users the client certificate selection popup.

> securing tunnels between "boxes".

The purpose of the TLS CCA is the same as the purpose of Kerberos,
to provide a non-disclosing Single Sign-On convenience.

-Martin

---

From: Henry Story <[email-masked]>
Date: Tue, 26 Jul 2011 04:34:09 +0200

On 26 Jul 2011, at 01:51, Martin Rex wrote:

>> [snip]

The way to solve both of those issues is just a better User Interface.
At the Identity in the Browser W3C Workshop earlier this year [1]
we pointed to the work of Aza Raskin who showed very simply and clearly
what needed to be done:

   http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

The user in the browser should be aware for ever tab what client certificate
he is using for the content he is seeing, just as he is aware of the server 
identity. This would make logging out, a one click affair controlled from
the browser - the only place where that can be done correctly.

   Is there anything we can do to persuade browser vendors to put 
more energy into solving this issue?

	Henry

[1] http://bblfish.net/blog/2011/05/25/

Social Web Architect
http://bblfish.net/

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 26 Jul 2011 15:17:33 +1200

Henry Story <[email-masked]> writes:

>Is there anything we can do to persuade browser vendors to put more energy
>into solving this issue?

A number of HCI people have been trying this for years and years.  After years
of nothing happening, the only answer appears to be "fork the browser and do
it yourself".

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 26 Jul 2011 06:15:58 +0200

> (similar to how Kerberos is used by others).

I'm sure about that.  My perspective are consumers.

> authorization for every signature operation.

There was even a Danish e-government standard for PKI authentication
that rides on top of server-auth-only HTTPS.  They also have a
companion scheme doing web signatures which indeed uses another
key.  There are lots of similar systems out there.

Are all these guys morons?  I believe they are rather dissatisfied
with how HTTPS CCA works.  So am I.

> TLS client, the client will perform "transparent" reauthentication.

Doesn't this actually lead to what I'm saying from a practical
point of view?  What you can do at the TLS layer is BTW very little
at least if you are using Servlets.  For other authentication
methods logout (HttpSession.invalidate) works as expected.

There is nothing authoritative to read either on this subject
that works for all browsers and servers.  Unless you are a
MOD-SSL hacker you probably get nowhere.

> setting and spare our users the client certificate selection popup.

I don't really want to know what it does actually.  The mere existence
of such a button signals that something is terribly wrong :-)

> to provide a non-disclosing Single Sign-On convenience.

But Kerberos is built on using a ticket after primary auth and
that's exactly what most "Web Programmers" would like to do
because then you just have to invalidate the ticket to force
reauth.  Services should time-out but most HTTPS CCA-
based services do not.  I noted this first when logging in to
the Swedish Tax authority.  They are all morons?  Maybe.
But the TLS WG has nothing to offer AFAICT.

Anders
"Web Programmer" and some more...

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 17:10:04 +0200 (MEST)

Henry Story wrote:
> > > The button "Clear SSL state" in MSIE is an indication how horribly bad
> > > it can go when security experts design systems for "people".
> > 

You're just scratching the surface of the problem.

Browsers have just one address bar and one chrome element to signal
about the servers and your identity _per_window_. 

The only sensible approach to obtain a secure browser would be to
strictly enforce a single-source policy, i.e. when https:// is used,
*ALL* resources must be served from the exact same server.
That is not currently done, your page may contain resources from
20 different servers and could be using 20 different client certs,
and it is not obvious for the end user which elements on the
page are from which of the servers.

-Martin

---

From: Henry Story <[email-masked]>
Date: Tue, 26 Jul 2011 18:46:36 +0200

> page are from which of the servers.

Yes, I see, that is a good idea. Start by cutting down complexity. Start by making it obvious and simple when all your info comes from one server only. Make responses of that type easy to understand and give them a positive interface.

Then work with artists to see how to present things in more complicated cases, after finding good examples of those, and by seeing how the user would like to be alerted to them.

In any case the same is true with cookies. We should be alerted on where we are leaking information to. 

Henry

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 21:11:03 +0200 (MEST)

> I'm sure about that.  My perspective are consumers.

My perspective is also consumers.
TLS client authentication is about Single Sign-On.
http://en.wikipedia.org/wiki/Single_sign-on

And the most convenient incarnation of it is popup-free single sign-on.

> with how HTTPS CCA works.  So am I.

Not understanding the underlying technology at all and not discussing
with software suppliers how a standardized but hardly used protocol
option works is more than a little naive on my scorecard.

Microsoft foobar'ed client certs in WinHTTP (a component distinct
from MSIE) and fixed it here http://support.microsoft.com/kb/909425
when we asked them to.

When Apple shipped Safari for Windows they did not find that winhttp
fix and made their browser exhibit the exact same bugs.  We told
them in January 2009, but they were still shipping defective
Safaris for Windows in April 2010...

Google Chrome used WinHTTP only for a short time and got rid of the
problem when it dumped WinHTTP.

> point of view?

No.

It doesn't make any flawed assumptions less flawed, of course.

>
> What you can do at the TLS layer is BTW very little

You misunderstand the concept of "Single Sign-On" as offered by TLS.

> of such a button signals that something is terribly wrong :-)

The equivalent for Kerberos (win7 in a windows domain) is "klist purge".
(Although the Kerberos ticket purge does _NOT_ result in the prompting
when new TGTs and new tickets are acquired.

> reauth.

Huh?  That is not how Kerberos works.  Kerberos tickets are
not invalidated at all.  And with Kerberos, you get even less
prompting (more seamless Single Sign-On) than with TLS client certs.

>
> Services should time-out but most HTTPS CCA-based services do not.
> I noted this first when logging in to the Swedish Tax authority.
> They are all morons?  Maybe.

What you are looking for is for a completely different protocol
layer than TLS.  If you want application level session management,
you have to do application level session management.  TLS provides
you a secure tunnel with Single Sign-On and fast session resumption
over later transport connections to the same target (to better match
the connection characteristics of HTTP).

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 26 Jul 2011 21:54:13 +0200

Martin,
You have a rather elitist way of discussing things.

It actually quite hard writing an HTTPS CCA based web app that
has similar login and session characteristics as one using password
authentication.

In your opinion this is an advantage; in my world it represents a
hurdle for adoption.

Anyway, banks are investing huge in app-level PKI authentication
so there is apparently a huge ignorant crow out there.  The there
are some really interesting differences in path building (which of
course is NOT specified at all by TLS) that for example have forced
people importing immediate CAs to PC before being able to login
using a smart card.

It is absolutely clear that the browser and server vendors have no
intention whatsoever cooperating.

Anders

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 22:51:59 +0200 (MEST)

> has similar login and session characteristics as one using password

But that is a clear abuse of the TLS client certificate technology
and _not_ supposed to be usable in this fashion.

> In your opinion this is an advantage; in my world it represents a

If you are _not_ looking for seamless single Sign-On, then
TLS client certs are not the right tool for what you want to
accomplish (square peg, round hole).

> so there is apparently a huge ignorant crow out there.

But if the "frontend" they are using something as security-broken
as a plain web browser, then the technology they would need
is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data
over well-definied application protocol units.

>
> The there are some really interesting differences in path building
> (which of course is NOT specified at all by TLS) that for example
> have forced people importing immediate CAs to PC before being able
> to login using a smart card.

What particular problem are you facing?

The TLS protocol is _very_ clear that a Certificate message must
contain a FULL path, omitting _at_most_ the self-signed certificate
at the end.  There are several TLS implementations out there with
significant brokeness with respect to the Certificate handshke
message (e.g. OpenSSL) which will omit more than just the
self-signed certificate at the end of the certification path,
send certificates out-of-order and even include arbitrary
non-path certificates.  Things that could be trivially checked
and reported as configuration errors on the server side upfront,
instead of dumping garbage on communication peers in clear
violation of the specification.

-Martin

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 27 Jul 2011 02:28:16 +0200

> has similar login and session characteristics as one using password

What's so hard about it?  Designate a URL (e.g.
http://example.com/login) that triggers a request for client-side
certificates.  When the user visits that URL with an acceptable
client-side certificate, set a session cookie, and redirect them back to
the page they were coming from.

When the user is not logged in, show them a login link that points to
the designated URL.

When they are logged in, show them a logout link that takes them to a
URL that clears the session cookie.

Am i missing something that makes this approach difficult or wrong?

	--dkg

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 27 Jul 2011 15:51:20 +1200

>Am i missing something that makes this approach difficult or wrong?

See the reference to the study I posted earlier (one of numerous studies with
similar results) that found that people with PhDs in computer science took
over two hours just to configure a cert for use on their machine, and rated it
as the hardest computer task they'd ever been asked to perform.

You've looked at the trivial part and completely missed the real problem,
which is:

  When the user visits that URL with an acceptable client-side certificate

You're not starting with "a user visiting a URL with an acceptable client-side
certificate", you're starting with "Joe Sixpack sitting in front of a PC (that
has no certificates)".  Your challenge is to design, implement, and
demonstrate successful use of, a mechanism to get from "Joe Sixpack in front
of his computer" to "a user visiting a URL with an acceptable client-side
certificate".

All the evidence we have so far for this, from real-world evaluations, is that
it can't be done except in carefully-controlled environments, at enormous cost
and effort.

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 00:16:46 -0400

> as the hardest computer task they'd ever been asked to perform.

Your reference to people with PhDs in computer science is misleading: a
PhD is a highly specialized degree that does not necessarily imply broad
computing ability.  The point that certificate enrollment is a pain
stands.

-- 
Matt

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Jul 2011 06:22:38 +0200

> Am i missing something that makes this approach difficult or wrong?

Unlike a web application using passwords as authentication method, you
must run the HTTPS login on another port (which typically conflicts
with standard firwewall settings), and if you want logout to work
you need to kill the TLS cache in the client using methods that
at best 1 out of 100 000 "Web Programmers" have ever heard about:

Extract from a web-app of mine:

     if (document.all == null) // FF, Opera, etc
       {
          if (window.crypto) window.crypto.logout();
       }
     else // MSIE 6+
       {
          document.execCommand('ClearAuthenticationCache');
       };

We are (de-facto) stuck with stuff that (from this perspective NB) hasn't
progressed much since Netscape introduced SSL back in 1995.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 27 Jul 2011 17:34:11 +1200

Matt McCutchen <[email-masked]> writes:

>Your reference to people with PhDs in computer science is misleading: a PhD
>is a highly specialized degree that does not necessarily imply broad computing
>ability.

"OK, so you have a PhD. Just don't touch anything" :-).  That was just the
first study, and I mentioned the PhD thing to avoid the "it was carried out on
students, they're not representative" criticism.  Other studies were carried
out on IT students (which I'd say is actually a good sample of very tech-savvy
users, so they'd be non-representative in being too good a fit rather than too
bad a fit), and possibly on random samples of people (I'd have to trawl
through the refs again to see who all the subjects were).  From memory I don't
think any were done on the Joe-Sixpack demographic, probably because the
outcome would be a foregone conclusion ("Failure to enrol: 100%").

Peter.

---

From: Henry Story <[email-masked]>
Date: Wed, 27 Jul 2011 09:23:32 +0200

> Am i missing something that makes this approach difficult or wrong?

I think the logout piece is not very well known. I only just discovered it
a few weeks ago, and have not tried it yet.  Anders pointed this out to me
that the following works in browsers for logout.

( I spent a lot of time looking to see what could be done with throwing 
error conditions on the TLS level, and there most browsers don't seem
to respond correctly )

But apart from that, you are right it is not very complex. Perhaps what slows 
things down a lot are server side certificates, which need to be bought 
(though there is a free CA),  are more complex to set-up. But this kind of 
thing could be automated easily as soon as the usefulness of this method of authentication 
were demonstrated by some large services. Also DNSsec and DANE will remove
some obstacles described by Dan Kaminsky presented by having CAs in the
first place. So things will in fact get simpler from now on.

Even creation of client side certificates is really easy, once one
has located the client libraries, one knows about keygen and one has
the javascript for the IE version. Client side certificates is a one click of a 
button affair in fact.

So there is a big part of eduction that is the issue in the so
called complexity of CCA. There are much more complex things out there,
with thousands of engineers finding no trouble learning those.

-----------------------------
What is missing: the use case
-----------------------------

But what is missing in CCA is the use case. The problem is that if you
use CCA then you can also use password authentication. And because for
the most part CCA only logs you into *one* server - the one that gave you the
Certificate - you gain little advantage over password authentication. And
where there is no benefit to be gained, it is very difficult to explain
something to people - both end users and developers of the feature. Take
this together with the confusion about the idea that one has to keep
one's certificate secure and one has created a huge amount of confusion.

So the important thing is to create a use case that takes client certificates
from where they are, to being one million times more valuable, while remaining
zero cost. This is what http://webid.info/ - a W3C project - allows. By placing a
WebID into the subject alternative name of the X509 we get the following advantages:

 - the same certificate could then be used to login to every site on the web
 - attributes about the user need not be placed in the certificate but can be placed 
   on the web, where they can be access controlled
 - it is dead easy to do certificate revocation: just remove the public key from the profile
   document.

Here the value of certificates really starts to shine. But we need to bootstrap
this to make the point clearly. So please help us by developing more fun usages
of  WebID.

Here is the simplest paper:
   http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html

Henry

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Wed, 27 Jul 2011 09:46:38 +0200

> outcome would be a foregone conclusion ("Failure to enrol: 100%").

Yes, and the reason for this is very simple: every Joe six-pack is intelligent
enough to see that client side certificates gives him no advantage over 
username passwords! Why? For two reasons:

  - Most client side certificates only work only with one site (unless you are in
    the army, or a few places like that)
  - For that site you need a password anyway - in case you loose your certificate

Joe Six Pack has a lot of work, following what's going on TV and following complex
scores between football teams to be bothered learning something that gives no advantage.

( And here we are assuming that the testers would have understood how to make it easy 
  to do 1 click certificate creation, how to do logout properly, and how to develop a 
   web site that takes into account the special features of TLS - which I highly doubt. )

OpenId has the same problem: most sites ask you to login with an OpenID and then once you
have ask you for a username and password! Well how is anyone going to get the point of
OpenId if that is going to be the way they are introduced to it? 

Notice that Facebook Connect by giving access to a social graph provides in their 
authentication system an advantage that cannot be simply bypassed by the Relying Party:
no relying party is going to ask all the logged in users to enter all their social network
right after authentication. 

So this is where WebIDs advantage is: it decentralised Facebook Connect by tying it
to Client Side Certificates - removing one of its most problematic features. But
http://webid.info/ ties an identity into the social web. WebID allows the same CCA
to be used on ANY webiste that implements it, and at the same time to help that
site ( the Relying Party as they are known in this ugly jargon ) to get access to
the social graph of the user - if that user is interested in presenting it.

No as soon as you have those advantages, then the benefit to Joe Sixpack becomes obvious.
He can now login as a fan to any of the football league sites in one click, and comment
on discussions, play games, organise meetings, order tickets for football matches and 
so on. He can create a football social network that is not centralised in one country
or by one organisation. He can use his football fan credentials to login to a football
producer site - in one click - to explain what is wrong with the football they are making.
And if there is a beer advert on TV with a special offer for Fans he can get that in 
one click. 

That is how you convince football fans. Once you have convinced them, you can convince the
developers who are also football fans, because you have convinced their managers who 
can see the point in this. And you also convince the EFF because otherwise Facebook is
going to completely take over all authentication on the web and we really have a big 
brother situation. WebID is Freedom Box friendly.

Henry

- http://webid.info/
- http://www.freedomboxfoundation.org/

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Jul 2011 10:18:59 +0200

Martin,

AFAICT you indirectly say that the de-facto standard for maintaining
(note, not creating) secure sessions on the web, i.e. server-side
HTTPS + session cookies is inferior.

The fact is that exactly $0 has been spent by the people building and
defining the TLS/HTTPS platforms on *researching* the issues I mentioned,
while *hundreds of millions of dollars* has been spent on *code* that
merges client-side PKI and the web in other ways than using HTTPS CCA.

FWIW, InformationCards (now close to an OASIS standard), do not use
HTTPS CCA for authentication to the IDP, but server-side HTTPS and
client-side signed request data.

Anders

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jul 2011 20:34:41 +0200 (MEST)

> HTTPS + session cookies is inferior.

Huh?  I'm completely lost.

If you want to do application-level session management, then you
ought to do application level session management, and NOT try to
mess around and interfere with Single Sign-On functionality at the
transport layer.

Even in closed environments, where TLS client certificates are used
for Single Sign-On, there usually is a fallback capability to use
passwords as well as support for migration from pure-password-based
logons to cert-based logons, and during the transition, both
authentication schemes must be supported in parallel.

So the only sensible application level session management is doing
it uniformly at the application level independent of whether the
user authenticated via password (which he may have to re-enter
occasionally), or via some Single Sign-On functionality -- be it
TLS client certs or HTTP Negotiate, or potentially other schemes
(saml, oauth).

You really don't want having to redesign & update the installed base
whenever you're adding support for a new authentication scheme,
therefore messing around with authentication scheme internals
when all you want to do is application level session management
seems to be an unconditionally bad idea.

> merges client-side PKI and the web in other ways than using HTTPS CCA.

HTTPS CCA is a means to use Single Sign-On (using X.509 certs for
online authentication) and equivalent to using Kerberos with
HTTP Negotiate or Kerberos with other protocols.

You seem to be entirely mislead about the purpose and usage constraints
of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On.
It has _NOTHING_ to do with digital signatures and can not be used
to authorize individual transactions.

The only reliably means to ensure that a "proof of identity" can NEVER
be confused (or maliciously abused) with an explicit authorization
for some transaction is to use distinct PKI credentials, distinct
protocols and distinct credentials management functions.

If PKI credentials, protocols or credentials management for these
completely distinct purposes are conflated, huge risks and damages
will ensue, and people will get hurt badly.

-Martin

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Jul 2011 21:32:45 +0200

> Huh?  I'm completely lost.

Pardon me if I read too much into your response.

> mess around and interfere with Single Sign-On functionality at the

Sure, but the question was to use client-side PKI in such an application.
And most of all, how to do it in a such way the the applications
doesn't get affected.

> authentication schemes must be supported in parallel.

See previous section.

> TLS client certs or HTTP Negotiate, or potentially other schemes

This is exactly what I want. Unfortunately as I have described
earlier, this is easier said than done using the currently only
standardized CCA method.

Without a server-initiated "logout" added to TLS it can never
be done in a portable way.  But as we (all) know the vendors
doesn't care **** about CCA on the web.

> seems to be an unconditionally bad idea.

Of course nobody wants to redesign the applications.

> of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On.

Purpose is an opinion.
IMO, HTTPS CCA as an enterprise SSO-solution sucks ***.
As a one-to-many-independent-RP-sign-in it does OK.

> to authorize individual transactions.

We are not talking about me; we are talking about hundreds of banks.

> will ensue, and people will get hurt badly.

They typically use the same certificate for app-level auth as for
HTTPS CCA.   They do (in the rare case specific signature applications
are supported), provide certificate with the NR bit set for those.

Anders

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jul 2011 22:29:15 +0200 (MEST)

> Sure, but the question was to use client-side PKI in such an application.

TLS does *NOT* provide any PKI functionality to applications,
never did, never will.

If you need that, you'll have to newly build it form ground up,
potentially re-using existing technologies and protocols
(such as PKCS#7/CMS).

> And most of all, how to do it in a such way the the applications

That is a non sequitur.  "Wash me, but don't get me wet".

> earlier, this is easier said than done using the currently only

I'm having serious difficulties to understand what you want, because
you constantly intermix two completely distinct things.

On the one hand, you talk about application level session management,
which has nothing to do with PKI whatsoever.

And on the other hand you're talking about using PKI functionality
from within the application, which has nothing to do whatsoever
with transport-level protection of the communication and 
Single Sign-On.

Just because both, PKI/X.509-based Single Sign-On and application-level
use of PKI for digital signatures both use some common pieces of
technology (X.509), does not make these to issues fall into an
even remotely related problem space.

> doesn't care **** about CCA on the web.

In Single Sign-On scenarios, there is _NO_SUCH_THING_ as a
server logout with respect to the authentication.  The very purpose
of Single Sign-On is that the authentication will be automatically
performed should that be necessary.

What you refer to with "server(-initiated) logout" looks like
very misleading terminology to me.

Any server that is not operating state-less, can decide at any point
in time, at his very own discretion, to forget/flush that backend
state.  That is completely independent from what any clients do
and works even if the network connection of the client breaks down
or the client is inadvertently powered off.

In pre-HTTP legacy protocols, servers used to keep backend state
for as long as the network connection was active.  When using
connection-less transports, such as performing communication
over short-lived request&response HTTP connections, the server
needs to come up with some alternative means to determine
when to delete/flush backend state associated with particular
clients.  And seriously, any such replacement backend-state
management logic needs to work completely independent of the
client's behaviour.  Robust traditional client-server scenarios
with persistent network connections also had provisions to
terminate the network connection on the server end according
to locally configured policy (idle timeouts, connection time limits,
hours of operation, etc.) and without cooperation from the client.

> IMO, HTTPS CCA as an enterprise SSO-solution sucks ***.

If you're doing it _correctly_, it works remarkably smooth.
As I've mentioned it before, we've been doing it for like 12 years
for all employees and pretty much all intranet server/services.

We started out with X.509/PKI-based Single Sign-On for legacy,
persistent connection client-server communication with GSS-API
based Single Sign-On, and it was natural and straightforward to
extend this to TLS CCA for Server/Services accessed through HTTPS.

And from the abstraction standpoint, the applications, both legacy
and HTTP-based, should NEVER bother whether the transport
was connection oriented legacy or HTTPS, and neither should the
application bother whether Single Sign-On was provided through
X.509 certs (what we prefer and have been using since 1996)
or through Kerberos (what some others prefer).

btw. certificate enrollment in Browsers hardly works,
e.g. Windows 7 was shipped with broken certificate enrollment
   last bullet "issues fixed" of http://support.microsoft.com/kb/974431

we've been distributing client certs to MSIE through Crypto-API
exclusively.  For all other browsers, its manual pkcs#12 import.

> We are not talking about me; we are talking about hundreds of banks.

It is extremely unlikely that banks want Single Sign-On, because that would
shift the entire responsibility for fraud on their very own shoulders.

Therefore I consider HTTPS CCA completely irrelevant to banks.

And anyone who talks about using HTTPS CCA for banks likely has 
little clue about the technology of TLS and Web Browsers.

> are supported), provide certificate with the NR bit set for those.

Using the same cert for Single Sign-On as for transaction based
authorization would be braindead and irresponsible.  The key usage
bits in a certificate become completely meaningless if a certificate
is being used for Single Sign-On.  Single Sign-On reduces the
value of any credential to at most "credential present".
Attributing any kind of intent to Single Sign-On authentication
is technically and legally impossible.  And anyone who claims
otherwise lacks technical and legal understanding of the issues.

-Martin

---

From: Henry Story <[email-masked]>
Date: Wed, 27 Jul 2011 23:02:26 +0200

> potentially re-using existing technologies and protocols

Yes, you can for example use X509 as such legacy technology, and with
simple WebArchitecture build a distributed public key infrastructure.
You do this by tying public keys to URIs and building a web of trust through
links between documents, using insights from the work done around the world in
the semantic web space.  When this is done it turns out that one can
magically re-use all the existing technology, including Client Certificates
to ones advantage. All that is explained quickly at http://webid.info/ 
Though if you want the philosophical background to this in detail you can
see the third presentation on my home page.

Henry

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 27 Jul 2011 23:02:41 +0200

Martin,
Lots of banks wants to use CCA for their users.

They find HTTPS' way of doing that intrusive.

On the web you logoff from (or by) the server.

Naturally logoffs must trickle down to clients
if they have logged-in using HTTPS CCA otherwise
they are de-facto logged-in due to the TLS caching.

There are really ugly workarounds but you should not build
secure services based on moderately understood fixes.

That's all.

Anders

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Jul 2011 23:29:38 +0200 (MEST)

> Lots of banks wants to use CCA for their users.

That is a non sequitur.

Banks (here in Germany) have abandoned tradtional TANs based on
the unconditional presumption that client PCs are infested with
malware, and most banks in Germany are currently replacing indexed TANs (iTAN)
presumably based on the perception that malware on clients (trojans/phishing)
has caught up with iTAN procedure complexity.

At this point, with the presumption that all client PCs are
thoroughly infested with malware, going for a Single Sign-On
mechanism would be completely braindead and irresponsible.

> they are de-facto logged-in due to the TLS caching.

"Logoff" is a pure server-side concept with respect to server-side
state.  A logoff concept that requires cooperation from the client
is technical nonsense.  Any server-side destruction of backend-state
associated with particular clients must work completely independent
of what the client does.  Early consensual destruction of backend
state if the client explicitly asks for it is OK.  But any
server-initiated "logoff" concept that involves the client
amounts to technical cluelessness.

And application level state management ought to be ***completely***
independent from the TLS session cache management.  The server
side TLS session cache management must be completely independent
from application level backend state management when you're
using a transport with non-persistent connections (such as HTTPS).

The lower protocol levels of the server must be free to manage
TLS session cache lifetime based on resource availability
and administrative or operational requirements, and short
server-side TLS session lifetimes (several minutes absolute lifetime),
server-side TLS session cache flushing (when performing
debugging on an otherwise productive system, or when updating
the server certificate or changing the list of trusted
client cert signers), as well as temporarily completely
disabling server side TLS session caching MUST NOT interfere
with application level session management.  Any application
that suffers from such server side TLS session cache
characertistics is seriously and thoroughly broken
(lack of abstraction and invalid protocol layering).

-Martin

---

From: Henry Story <[email-masked]>
Date: Wed, 27 Jul 2011 23:35:07 +0200

Anders, can you vote and get others to vote for the following issues
  
Chrome
  • "User Interface Improvement for Client Certificate Usage" 
      http://code.google.com/p/chromium/issues/detail?id=29784
  • "window.crypto.logout() and login() don't work."
     http://code.google.com/p/chromium/issues/detail?id=90676
 
Firefox
  • "Improve SSL client-authentication UI"
    https://bugzilla.mozilla.org/show_bug.cgi?id=396441

Henry

> secure services based on moderately understood fixes.

the problem is that even cookie and password based login suffer form the
same problems. Currently you have to trust the server to have logged you
off. You can't be sure yourself.

Henry

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Wed, 27 Jul 2011 23:56:49 +0200

> amounts to technical cluelessness.

why is that? Why can't the client log itself off. That would be much better
for the user, as he would be in control of his identity.

This could be done easily by a browser both with cookies and with TLS:
 - with cookies: the browser should tie every cookie and state to a user identity. When the
    user switches identity, the cookies stop getting sent. For the server that ends up being
    the equivalent of a log-off.
 - with TLS the client breaks the connection, and re-established a completely new one.

Henry

Social Web Architect
http://bblfish.net/

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 00:37:53 +0200 (MEST)

Henry Story wrote:
> why is that? Why can't the client log itself off.

That falls under "Early consensual destruction of backend state if
the client explicitly asks for it is OK" above.

> That would be much better for the user, as he would be
> in control of his identity.

The user is _always_ in control of his identity.
But you can never get virginity back once you give it up.

Once you revealed your identity to a server, you can not
undo it.

>  - with cookies: the browser should tie every cookie and state
>     to a user identity. When the user switches identity, the cookies
>     stop getting sent.

If you're wondering whether there should be a standard where
a Web Browser should offer a context-specific, easily accessible button
to the user to make the Browser _prompt_ on the next connect to the server
before providing any of the integrated "single Sign-on" functionality
(be it cookies, WWW-Authenticate: headers, HTTP Negotiate, or TLS CCA
 or automatic user&password fill-in to forms).

Making such a functionality accessible to the server probably would
not hurt.  Preferably _without_ javascript or other active content,
and instead controls similar to (e.g. META) for page refresh and
client-side cache flushing.

>
>     For the server that ends up being the equivalent of a log-off.

If a user wants to perform a "logoff", he might be interested in
_both_ happening:

  - the server side backend state getting flushed along with client-side
    state (so that no-one with a copy of the server application sessionid
    can resume the session from elsewhere without having to perform
    an authentcation step).

  - the browser suspending _IN_A_CONTEXT/TARGET_SPECIFIC_FASHION_ any
    single Sign-On functionality (Cookies,WWW-Authenticate,HTTP Negotiate,
    TLS CCA, automatic user&password fill-in) until it is interactively
    reconfirmed to continue

It may be more difficult to standardize a client-side "button" and
the signaling of the "logoff" to the server application so that it
can clean up, than to require the application to offer a "logoff"
button and tell the browser to suspend Single Sign-On for this
context/target.  Closing of a browser window does not necessarily
imply a "logoff" for apps that allow for several parallel and
independent workflows.  The server app usually knows more about
the application architecture than the user does (and whether to
warn the user about unsaved date that will get purged by logoff)

-Martin

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 00:54:23 +0200

> Once you revealed your identity to a server, you can not

Well if you break the connection, and you reconnect without leaking 
any of the previous session information - ignoring the tricky
ip address issue - the server can't know you are the same person, and
so you are a virgin once more. (Which means of course that you loose
all the built up trust you may have worked on before. )

But of course you may wish to login to the site with a different personality.
A lot of people have done this by opening a number of Facebook accounts in order
to understand how that system works.

> or automatic user&password fill-in to forms).

This is what Aza Raskin at Mozilla Labs demonstrated with his Weave project.
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/

I don't think this requires a standard here. It requires the browser to
be able to keep track of different user personas, be able to remember which
persona the user has on different sites, and make it easy for him/her
to logout or change persona on any of these sites. This could mean just sending
different cookies at the next connection (when changing persona) or sending
none - when becoming anonymous again.

> client-side cache flushing.

So as I see it the client does not need to do any of that. He can just
stop using the cookie information. 

Of course it could be nice if he browser could also send a polite logout 
message on a cookie or a TLS session before doing that. But I think it 
would already be a big step forward without this.

>    TLS CCA, automatic user&password fill-in) until it is interactively

agree. 
I just think the second one could be done without the first one being finished.

> context/target.

I don't think you need to standardise the client. Aza Raskin showed a
very appealing UI it seems to me. Others could do that in different ways.

>  Closing of a browser window does not necessarily

well login/logoff is perhaps the wrong terms. Authentication and recognition
of a user is what counts. 

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 06:51:03 +0200

> mechanism would be completely braindead and irresponsible.

So using client certificates for authentication is such a bad idea that
there is no point in looking into issues on how to make it better?

How is the German e-card supposed work then?

When it comes to malware the situation in most cases is that the
PKI underpinnings featured in modern computers haven't progressed
a single step since 1995 when it was introduced.  Elementary
(in principle at least) stuff like putting ACLs on keys so that
only granted applications which has been known for decades is
still considered a research topic.

Leaving this thread, continuing with making PKI for banks and
other a better solution than passwords.

Anders

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 28 Jul 2011 18:11:03 +1200

Martin Rex <[email-masked]> writes:
>Banks (here in Germany) have abandoned tradtional TANs based on the 
>unconditional presumption that client PCs are infested with malware, and 
>most banks in Germany are currently replacing indexed TANs (iTAN) presumably 
>based on the perception that malware on clients (trojans/phishing) has caught 
>up with iTAN procedure complexity.
>
>At this point, with the presumption that all client PCs are thoroughly 
>infested with malware, going for a Single Sign-On mechanism would be 
>completely braindead and irresponsible.

That was my feeling as well.  Moving from TANs (or plain passwords if you're a 
US bank) to client certs is at best pointless and at worst a step backwards in 
security.  Even if you could overcome the monumental usability problems (and 
there's no evidence that we can do this), you end up with a mechanism that's 
even less secure than basic TANs because use of a TAN requires human 
intervention while a MITB (man-in-the-browser) can use your private key to 
sign whatever they want as often as they want without your knowledge.  Client- 
side PKI was designed for an attack model invented by cryptographers to 
justify the use of fun crypto stuff, but it has little (if anything) to do 
with the threats that we're actually facing today.

Peter.

---

From: Henry Story <[email-masked]>
Date: Thu, 28 Jul 2011 10:13:51 +0200

> with the threats that we're actually facing today.

Security like knowledge is not absolute. It is a context relative, modal notion. Above you sound very much like the skeptic, who argues that since we don't know we were not captured by some Alpha Centaurians, who took our brain, put it in a vat, and started feeding us perceptions of the way the world is to make it look like  what we see, since we don't know that, we don't and can't know anything. The answer to that is to see that skeptical claims are not transitive on our claims to knowledge. Just as hopeless security scenarios are not a proof that we are not secure. "A gang of thieves could torture me until I reveal the TAN (Transaction authentication number), so TANs are not secure" would be an example of such reasoning.

So I think we should look at where we are now. Currently the biggest security problem is people using passwords for everything, and often using the same password for every site. One time passwords can work for banks but not for most other  applications. Imagine one time passwords for every site you go into. What would happen? You would end up with one massive site controlling the whole internet, because the biggest site with the most content, would be the only one people would bother having passwords for (sound familiar?) And having one site - or just a few of them - provide all the content, is the beginning of  a modern dictatorship, since that site will inevitably be taken over by the most power hungry interests. So I am weary of arguments that proceed from fear, to denying us technology that can help us bypass monopolies of information. There are huge interests at stake to make us believe those types of arguments, and so we should analyse each one very carefully looking for flaws.

Of course the solution to man in the browser scenarios is keys built in hardware that cannot be read by any application, and also notifications or log files for how and when they are used. Furthermore in higher security contexts they can be combined with other authentication techniques, such as TANs.  But as you point out, it is difficult to get those deployed and useable if one does not first start with less secure but easier to deploy solutions: like software based keychains. This is not such a problem anyway. Operating systems are getting more and more secure. Compare the latest windows, with Windows95 when the web started.  So man in the browser is less of a problem for the moment. By the time it is we will have proven the value of these technologies and have methods for placing the keys into hardware, be it on our computer or in our watch speaking to our computer wirelessly.

So client certs can be used with TANs. Would that make client certs for banks useless? Not necessarily. Not if the client cert can be used to connect to other web sites too (as http://webid.info/ allows you to do) - say shopping web sites. You could use your regularly TAN verified certificate to set up payments quickly on shopping sites.  That is the argument that Client certificates are useless is correct only on the assumption that it is used by one web site only: the web site that gave you the certificate. But that need not be the case. The web site that gave you the certificate should be the one you use one time passwords and certificates on, all the others you would use certificates only. Monetary transactions could be initiated using certificates, but should be finalised only with a TAN transaction at your banking web site. (Or your bank could just send you an SMS, when such a transaction occurs to notify you, and give you some time to deny it, though that would require you to create a new certificate. A one click operation ) If you look at it this way, and you use the network, you can see that this can in fact help improve computer security, since viruses can be detected in many more ways.

Similar verification procedures could be set up in social web examples. Your Freedom box would ask you more regularly for one time passwords - though we can assume it has a hardware based private key. You use a certificate to log into other sites. If messages that other sites send you are done via an HTTP POST to your freedom box, then the damage a virus who has stolen your key can do is going to be limited. 

Those are the types of things should can look into, before shouting all too easily about the death of client side certificates.

Henry

Social Web Architect
http://bblfish.net/

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 28 Jul 2011 10:42:05 +0200

So now we have come to the point where all forms of client-
hosted keys used for authentication must die.

Maybe you guys should join forces with Microsoft who after
completely screwing up PKI and InformationCards, now turn their
hope (and money) to putting all your keys in the "Cloud"?

Platform security is a journey and it is by no means finished.

Mobile phones that are less plagued by legacy and backward
compatibility issues, will meet "the market's" security needs.
Well, I excluded the 0.01% that for unknown reasons believe
that security is more important than "getting the job done".

Anders
A really bad guy :-)

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 29 Jul 2011 14:17:37 -0700

> error that only experts understand.

Anders,

Could you email me those two certs, or tell me their key types (RSA,
DSA, or elliptic curve) and the "key usage" and "extended key usage"
extensions?  I will take a look at the Firefox code that filters
client certificates for SSL client authentication.

I think the filtering algorithm should be:

1. If the key usage extension exists, it must contain the
digitalSignature bit (for the TLS rsa_sign, dsa_sign, and ecdsa_sign
client certificate types).

2. If the extended usage extension exists, it must contain the
id-kp-clientAuth (TLS WWW client authentication) purpose.

Note: this implies if neither the key usage nor the extended key usage
extension exists, the certificate may be used for SSL client
authentication.

Do you agree?

Thanks,
Wan-Teh Chang