Subject: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?)

From: "Ryan Hurst" <[email-masked]>
Date: Tue, 7 Feb 2012 15:35:24 -0800

Forking thread as I fee compelled to discuss client certificates but I am
not sure its related to the original thread.

I also worked on some moderately successful client certificate solutions,
their success however was only possible because of the pain tolerance for
the communities they served; by objective measures they just were not good
enough and in my opinion the reasons are pretty straight forward, they are:

1. There is no way to "log out", by authenticating the user as part of the
TLS session the authentication is cached with the session; browsers all
(rightfully so) implement session caching, this means that to log out one
in-essence needs to close the entire browser and in a world of tabs this is
a total non-starter (as an FYI there is a hack to do this in IE but it's far
from perfect - see
http://www.unmitigatedrisk.com/archive/2007/03/12/29.aspx)

2. Usability, the bar for a usable system on the public internet is
significantly different than that in a corporate or government environment;
the basic separation of pin collection and credential selection alone makes
the usability characteristics of the client authentication experience too
poor to adopt broadly.

3. Theming and Branding, however hard it is for us as technologists to
accept the ability for site the create an authentication experience that is
consistent with the rest of their site is mandatory for adoption in these
scenarios.

4. Reasonable certificate lifecycle management for un-managed environments,
I think this has been solved to a great extent with Windows 7 and the
WS-TRUST enrollment work they did; it works very well but that's just Window
and just Windows 7.

5. Hardware support for smart cards, there is a resistance in the smart card
community to normalize on a single card edge; PIV is probably the most
reasonable one that is out there but it presumes management done in an
environment like the DOD (admin keys, proprietary management apis, etc);
There are lots of potential solutions but when at Microsoft I worked with
folks on a specification (that is supported in Windows 7 and up) to try to
address this - http://www.unmitigatedrisk.com/archive/2010/04/09/227.aspx 

On a related not, BrowerID goes a long way to address some of these concerns
(though it has work to do yet).

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, February 07, 2012 2:26 PM
To: Joe St Sauver
Cc: [email-masked]
Subject: Re: [therightkey] Will the real RPF please stand up?

At 12:05 PM -0800 2/7/12, Joe St Sauver wrote:
>...
>
>This is actually a fascinating question, and one where the answer you 
>get for "Why don't people deploy client certs?" varies from person to 
>person. I attempt to capture a little of that in a talk I did a week or 
>so ago at Internet2/ESNet Joint Techs in Baton Rouge:
>
>"Client Cert Deployment Models and Hardware Tokens/Smart Cards"
>http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf
>
>It wasn't possible to do an exhaustive analysis of that question in a 
>20 minute slot, but you can at least get an idea of what we're seeing...

I think there are multiple reasons why client certs have not taken off,
based on 20+ years of experience in the area. We provided a client cert
system for a financial firm in the early 90's. It was easy to use,
bootstrapped from the password-based system that the firm used. 
But, because there were no good tools to allow users to move certs and
private keys among client machines, it was eventually turned off.

>...
>
>FWIW, even the Feds issue multiple certs, if only because some need to 
>be non-repudiable (e.g., for signing) while others need to be escrowed 
>for potential recovery (or authorized monitoring) of encrypted content 
>(at least in a Federal environment).

The 3-cert CAC is not what I was suggesting. (And the reasons there are
separate certs for sigs vs. key transport is because users need to perform
key recovery for themselves for old e-mail, rather than for
monitoring.) What I was advocating is certs with different IDs, each
appropriate for a well-defined set of contexts, issued by CAs that are
authoritative for identity in specific contexts.

>That said, given my druthers, I'd prefer a single client cert to use 
>for MOST purposes, just as I prefer to use a single PGP/GPG key -- it's 
>easier, and reduces correspondent confusion.

It is easier, but is undermines privacy and raises the question of what CA
is appropriate for ALL contexts.

>...
>
>I'd also assert that the cost of the cert is trivial relative to the 
>cost of the secure storage device that might hold the cert (e.g., a USB 
>format hard token, or a smart card and reader).

The cost of managing a cert has a lot to do with the nature of the
relationship between the issuer and subject, and the liability that the CA
incurs as a result of issuing  the cert. For example, I have relationships
with credit card issuers. They make money when I use my cards. If they
issued certs to me, that could be used in lieu of plastic, because they
believed the security could be better, I probably would not pay for the
cert.

>...
>I concur that multiple certs equal user confusion unless you can really 
>make it pretty darn clear (e.g., [email-masked] or
>[email-masked], for example).

not the sort of IDs I had in mind. I have an identity with Visa, with Amex,
with UA, US, Hertz, Avis, etc. Each is authorized to identify me in certain
contexts, and my ID is context specific. I also have a relationship entities
who provide e-mail services, and they are the best entities to act as CAs
when my e-mail address is the subject name. It's not about signing vs.
encryption, but more about what entity is authoritative for identifying me.

>...
>
>An interesting approach, BTW, is the one that CILogon takes, leveraging 
>federated authentication to mint certs for secure access to cyber 
>infrastructure -- see http://www.cilogon.org/ for more information 
>about this approach, if interested.

federated authentication systems using certs generally seem to be motivated
because folks can make cross-certification work properly. 
other federated auth systems seem to be based on having one org trust
another to assert and identity for a user know to the second, but not the
first. that's a recipe for secruity problems.

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 11:57:23 -0500

Ryan,

That's a good list of additional problems associated with widespread 
use of client certs.

Note that re the "branding" issue, there is a cert extension that 
allows for logos to be embedded in certs, although the focus for this 
is really server vs. client certs.

Steve

---

From: "Ryan Hurst" <[email-masked]>
Date: Wed, 8 Feb 2012 09:18:12 -0800

Steve,

Thank you.

I actually contributed to RFC 3709 and I believe made Windows the first
platform to support it, that said the branding element I am referring to in
this case is different.

When designing a user experience one picks colors, typefaces, layout and
workflow; for example consider Coke "red" and type typical Coke typography;
if the authentication experience is not consistent with the design goals of
a site adoption will only happen when security is seen more important that
design and ease of use.

As long as that is the case in this world of consumerization of IT I don't
expect client certificates to be used outside of closed communities.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Wednesday, February 08, 2012 8:57 AM
To: Ryan Hurst
Cc: 'Joe St Sauver'; [email-masked]
Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the
real RPF please stand up?)

Ryan,

That's a good list of additional problems associated with widespread use of
client certs.

Note that re the "branding" issue, there is a cert extension that allows for
logos to be embedded in certs, although the focus for this is really server
vs. client certs.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Feb 2012 17:49:16 +0000

> expect client certificates to be used outside of closed communities.

Client certs do not need to interfere with the branding experience.

For example, http://www.browserauth.net/ shows how to use them without
touching the site's ability to fully control the user experience.

---

From: "Ryan Hurst" <[email-masked]>
Date: Wed, 8 Feb 2012 10:49:59 -0800

Ben -

I am familiar with Google's Origin Bound Certificate (OBC) work, it in many
respects is similar to the BrowserID proposal; and you are right that this
happens at a layer below the user experience if there is no pin/password
protecting the key.

That said, unless something has changed recently (I have spent the last few
years focusing on securing ad networks) since it's done as part of the TLS
negotiation the authentication is persisted in the TLS session cache meaning
a mechanism is still needed to "log-out" or "reset that session" and I don't
believe one exists today.

One problem I have with both BrowserID and OBC is that they don't really
solve the initial authentication problem, this is true to a lesser extent
for BrowserID because at least until recently they didn't even have a
concept of a password.

But as I understand OBC initial authentication happens via a traditional
methods (aka passwords) and it is persisted via the "origin certificates";
this approach is better cryptographically than BrowserID in that you get the
cryptographic binding of user authentication to the session-plus today
BrowserID relies on Javascript based cryptography implementations which has
a ton of shortcomings.

With that said, on the surface OBC feels like it's not really trying to
address authentication but a gap in cryptographic cookie support.

One of the things I like about BrowserID as an approach is that I agree with
others that the portability of key material in today's world is important
and by them including the vetting of the ownership of an email in their key
provisioning workflow they kind of address this problem.

To be clear I am a fan of anything that moves the ball forward here, though
I really wish as an industry we could align behind a problem statement and
work towards it together instead of having so many competing approaches but
it is human nature ;)

Ryan

From: Ben Laurie [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2012 9:49 AM
To: Ryan Hurst
Cc: Stephen Kent; Joe St Sauver; [email-masked]
Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the
real RPF please stand up?)

Steve,

Thank you.

Ryan

-----Original Message-----

Ryan,

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 8 Feb 2012 19:19:50 +0000

On 8 February 2012 18:49, Ryan Hurst <[email-masked]> wrote:

> One of the things I like about BrowserID as an approach is that I agree
> with others that the portability of key material in today’s world is
> important and by them including the vetting of the ownership of an email in
> their key provisioning workflow they kind of address this problem.
>

Then you might like the work I did on portability of key material:
http://www.links.org/files/nigori-overview.pdf.

There's also a detailed spec and code.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 08 Feb 2012 22:18:34 +0000

<no hats and all that>

On 02/08/2012 07:19 PM, Ben Laurie wrote:
> On 8 February 2012 18:49, Ryan Hurst<[email-masked]>  wrote:
>

On the OBC theme, I do like that. (Though I think signalling
it via an HTTP authentication scheme would be an improvement as
well but that's a detail.)

One thing that could be done with OBC would be to not try to
move the private keys, but rather provide a standard way to
bind different OBC public keys on the user's different
devices to the same server account.

So, e.g. to associate two devices to the same account the
user would be sent to https://example.com/.well-known/obc-bind
and after TLS mutual auth would be shown e.g. a short-lived
code that could then be entered on a form at the same URL
accessed from another device. The UI for that needn't be
standard so servers could innovate fairly freely there I
think.

If the user can bind various devices to the same server
account then I think a bunch of account registration and
recovery options become available without having to ever
move a private key and also without having to bake the
registration part into the TLS authentication scheme.

It still doesn't do logout though, but personally I don't
really get why that's such a deal. I suspect that if we
did have logout then malware would just adapt and overall
we'd not be that much better off. Maybe I don't get the
real requirement there though.

 > http://www.links.org/files/nigori-overview.pdf.

I don't get how this differs at all from any centralised
login service nor, if its just a key store, why it'd prove
any more popular than sacred was, though maybe that's long
enough ago that things have changed enough (the EKE patent
expired in the meantime at least;-)

S.

---

From: "Ryan Hurst" <[email-masked]>
Date: Wed, 8 Feb 2012 20:58:43 -0800

Stephen,

I agree with all your points on OBC, especially the ability to register
multiple keys for the same user; keys are cheap and if we used a primary key
like an email address instead of a key this becomes easier; of course as we
go down this path OBC looks like more like BrowserID implemented tied into
the TLS stack (which has positive KFD properties).

As for the signaling topic, Phillip is often discussing the need to express
policy in a secure way; DNS and DNSSEC often come up in those conversations
-- one could imagine expressing that signaling policy there also.

As I write this though it feels odd to see a solution span so many layers,
so intimately; that said I have seen (and done) worse ;)

On the topic of logging out, I think it's mainly a 99% vs. 1% problem, we
being the technological 1% understand the value of closing the browser most
users do not, they have been programed for two decades that if they want to
stop someone from using their account to logout, not to close all
applications and starting all over again. It's common for users to say they
feel "trapped" or "lost" when searching for the thing they know must be
there and is not, or when it's there but doesn't do what they expect.

Having a "logon" concept that has no explicit "logoff" that maps to their
views and expectations creates a bad user experience and encourages bad
behavior - staying on forever.

Ryan
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, February 08, 2012 2:19 PM
To: Ben Laurie
Cc: Ryan Hurst; Joe St Sauver; [email-masked]; Stephen Kent
Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the

<no hats and all that>

On 02/08/2012 07:19 PM, Ben Laurie wrote:
>> One of the things I like about BrowserID as an approach is that I 
>> agree with others that the portability of key material in today's 
>> world is important and by them including the vetting of the ownership 
>> of an email in their key provisioning workflow they kind of address this
problem.

On the OBC theme, I do like that. (Though I think signalling it via an HTTP
authentication scheme would be an improvement as well but that's a detail.)

One thing that could be done with OBC would be to not try to move the
private keys, but rather provide a standard way to bind different OBC public
keys on the user's different devices to the same server account.

So, e.g. to associate two devices to the same account the user would be sent
to https://example.com/.well-known/obc-bind
and after TLS mutual auth would be shown e.g. a short-lived code that could
then be entered on a form at the same URL accessed from another device. The
UI for that needn't be standard so servers could innovate fairly freely
there I think.

If the user can bind various devices to the same server account then I think
a bunch of account registration and recovery options become available
without having to ever move a private key and also without having to bake
the registration part into the TLS authentication scheme.

It still doesn't do logout though, but personally I don't really get why
that's such a deal. I suspect that if we did have logout then malware would
just adapt and overall we'd not be that much better off. Maybe I don't get
the real requirement there though.

 > http://www.links.org/files/nigori-overview.pdf.

I don't get how this differs at all from any centralised login service nor,
if its just a key store, why it'd prove any more popular than sacred was,
though maybe that's long enough ago that things have changed enough (the EKE
patent expired in the meantime at least;-)

S.