[whatwg] Certificates & Browsers. Was:] HTML5 - Addressing the Password Craze?

[Anders Rundgren]

Hi David,
Thank you for your elaborate replay although you did not really
comment on my proposal but rather proposed something else.

>Why not just issue a TLS 1 certificate?

I agree with all you things you say about this technology but let me
begin with another, for the WHATWG applicable comment:

==================================================
  The "standards" for PKI provisioning using browsers are in a real mess.
  Xenroll, KeyGen and a JavaScript CRMF do not really make this
  part as simple as it must be in order to challenge passwords.
==================================================

Anyway, my proposal was about offering a "migration path" to other
authentication schemes, as well as improving the current de-facto standard.

Regarding certificates: the provisioning, mobility and pretty proprietary
card schemes (like no preinstalled drivers in Windows) will make this
transition period rather long.  That none of the browser vendors support
digital signatures (in a reasonable way), is another reason why PKI
deployment is hampered.

Personally, I believe PKI will stay marginal [*] until you can keep your IDs
in a mobile phone.  The US PIV card (to take an example), only allows
you to keep a single Federal ID which is not particularly useful for the
Internet where you will continue to have multiple and mostly entirely
independent IDs.

thanx
Anders

*] There are 10M+ of citizens certificates in Europe, but you cannot
use them at particularly many places due to the problems cited.

////
Internet Explorer 2 and later support it.  Netscape Navigator 2 and 
later support it.  All versions of Opera support it.  All versions of 
FireFox support it.  All versions of Safari support it.  In fact, the 
vast majority of libraries and user agents that support TLS or even SSL 
websites also support TLS 1 client certificates.

When you issue the certificate, most browsers offer a convenient way to 
send it to the client.  It is installed into the local certificate 
store, or potentially a hardware device such as a smart card.  Later, 
the user authenticates to the user agent, and then is given the option 
of providing the certificate to a site that asks for it.  You can either 
issue a certificate specifically for your site, or you can have them go 
get a (freely available, in at least some cases) client certificate from 
a vendor like VeriSign.  These are typically called "e-mail signing 
certificates" or "digital ID's" by the companies that sell them.

There are a couple big benefits here.  First, you are using an existing 
user agent feature, that every user agent is likely to support.  So you 
just have to talk the user through installing the certificate into IE.

Secondly, web server side, it is a radio button in IIS 4 or later (not 
sure about earlier versions), or a single line in Apache to enable the 
feature.

Thirdly, if the ID becomes compromised, you can issue a revoke request, 
and issue a new ID.  This means the certificate that you issued before 
immediately becomes invalid, and so if the user loses the certificate or 
has it stollen, it takes no effort.

Fourthly, if the computer has a smart card reader (about USD $20) and a 
smart card, the certificate can be installed onto the smart card.  If 
this is done, then the user must provide a valid PIN in conjunction with 
the physical card in order to send data using the identities installed 
onto the card.  This adds a physical layer of security that is not 
possible with a name/password system.

And the worse problem than the number of systems using user id/password 
on a form to authenticate (and not at least using digest) is that many 
of these don't use TLS, and so the password is sent plain text or plain 
text equivalent across the network.  Additionally, many of these systems 
send the username and password pair by e-mail, which means not only is 
the user name and password sent across the internet, but also that it is 
stored in one or more well known locations on the user's computer for at 
least some period of time.  Since most operating systems don't provide 
any mechanism to lock down a directory so that only one module or 
application can access it, and since the most protection most user 
agents offer to e-mail files is the non-protection of a randomly 
generated file name, this is actually the worst part of the security risk.

Failing TLS, most servers (including IIS and Apache) and user agents 
support Kerberos, NTLM and a host of other options, and there are 
several publicly available specifications for what is called "Federated 
Identity."  The problem with all of these is that various parties have 
interests in pushing their own view of how a federated identity should 
work, usually to further their own goals.

Also, keep in mind that a federated identity system also poses privacy 
risks for the user.  When the user connects to your site, you must 
contact the federation and ask if they are who they say that they are.  
This means the federation knows both who you are, and what site you are 
trying to access.  This is why they aren't popular.

TLS doesn't have that problem, because you retrieve a certificate 
revocation list versus asking if a specific certificate is valid.  All 
that verisign (as an example) knows is that a TLS website asked for a 
revocation list, they don't ever know what user it was who was trying to 
access the site.

The issue with a federated log on is you must log on and log off from 
the federation site.  Sites have to check with that site to see if your 
token is valid or not, so any token based authentication inherently 
compromises your privacy (at least potentially).

Anders Rundgren wrote:
> Dear all,
> As you probably have noticed, practically every site offers a login.for their
> members, customers, citizens etc. etc.
>
> There are two problems here.
> 1.   User-id/password management has become a real nuisance. Once this was
> an issue for computer professionals only, now it affects everyone from children
> to grandma.
>
> 2. There are other and better authentication methods available that become hard
> to migrate to without making life hard for end-users by asking them to use another
> login method.  The site has no way of detecting the user's options.
>
> It appears, that it may be possible to add some kind of negotiation/option
> elements at the HTML level, that if supported by the underlying system could
> offer a standardized and potentially more powerful version of the password
> caches or external login form "hijacker software" that we currently use. 
> Tentative functionality for the AHE (Authentication Helper Extension):
>
> - Find out if the AHE is installed/available
>
> - If the AHE is available, find out if the site in question is in the list
>
> - If in the list, put out a dialog box giving the user an option to login, decline
>   or manually enter login information. 
>
> - If the site so requests, the user's authentication options (in case form based
>   authentication was used) can be transferred during login, giving the site an
>   option to ask/require the user to upgrade their authentication.  This could
>   involve anything from digest-authentication to certificates.  The latter
>   current lacks a decent provision method but there is some work 
>   going on in this area as well.  MS CardSpaces is also an option.
>
> - The authentication stuff would be possible to store in an USB token or
>   even better in a mobile phone.  This is of course outside of HTML5
>   but will be natural to support within 3-5 years from now.
>
> - The scheme would (if properly implemented) be able to thwart phishing
>   since a user-id/password (or other auth solution) could be tied to a
>   SSL root + host name (or even better host domain).
>
> In essence the desired result is a portable (mobile) multi-site authentication
>  support mechanism that should not only make the web easier, but also
> long-term considerably more secure.  
>
> Other Options?
> ==========
> The other option is addressing this problem at the transport level but I think
> form-based authentication is a better entrance point since it is already in place.
> There is no problem [at all] of having a mechanism [in the proposed scheme]
> that switches from form-based authentication to transport-level authentication
> like using TLS-client-certificates, while the opposite is impossible.
>
> Sincerely
> Anders Rundgren
>
>
>
>
>