Internet Identity

User authentication on the Web is in flux. Passwords are still the dominant authentication method, but social login is gaining ground. Conflicting requirements for anonymity, pseudonymity and identification are being voiced. The US government is trying to create a secure identity ecosystem, is asking federal agencies to accept externally-issued credentials, and is promoting the use of PIV certificates instead of passwords in agency intranets.

Here are our view points, research and proposals in this exciting area of Web technology.

Password-based Authentication

User authentication on the Web has traditionally relied on passwords. Passwords have many virtues, notably those of simplicity and privacy. Passwords will no doubt persist even if alternative authentication methods are deployed successfully, and research on improving password security is warranted. We have done such research ourselves and been granted patents in that area recently, as reported in the white papers:

But it is clear that passwords have serious drawbacks, notably the burden on the user to remember passwords, and the resulting security risks posed by password reuse.

Third-Party Login

An alternative to traditional password-based authentication is third-party login, where a Web site, the relying party, outsources authentication to another site, the identity provider, based on what we call double redirection protocols, such as OpenID. The relying party redirects the user’s browser to the identity provider, which authenticates the user with username and password and redirects the browser back to the relying party, passing along user identity data.

Third-party login is convenient for the user, who has fewer passwords to remember. But it does not eliminate passwords, nor the risk of password reuse; and asking the user to enter a password after a redirection is a bad security practice, which increases the risk of phishing attacks against the identity provider, and fosters bad habits that facilitate phishing attacks on the Web at large.

Third-party also reduces user privacy, since the identity provider is informed of every login to a relying party.

Social login

Social login is a flavor of third-party login, pioneered by Facebook Connect, where the identity provider is a social site and the relying party not only learns the user’s identity, but also gains partial access to the user’s account at the social site so that it can issue updates on the behalf of the user. Social login is a boon to relying party marketeers, who are able to advertise their users’ activities at the relying party to their users’ friends at the social site.

Today social login is implemented using OAuth, which requires the relying party to preregister with the social site. This reduces user choice, since the user can only log in via the social sites that the relying party has preregistered with. It gives power over the relying party to the social site, which can revoke the preregistration at its sole discretion. It also gives the social site power over users, who must get an account at the social site to be able to log in to the relying party, and can have their accounts terminated at any time at the social site’s sole discretion. And it inhibits competition, because a new social site will not be able to offer its users the convenience of social login at a large number of relying parties. OAuth also has serious security drawbacks. We have summarized all these issues in a response to the recent IETF Last Call for comments on the protocol.

There is no essential need for preregistration in social login. OAuth uses preregistration to authenticate the relying party and identify it to the user. We have designed an alternative protocol, PKAuth, where the relying party’s TLS certificate is used for authentication and identification, obviating the need for preregistration.

Public key certificates

An alternative to passwords has been available on the Web since 1995, viz. public key certificates. The SSL protocol created by Netscape, now renamed TLS by the IETF, provided for authentication of both client and server with public key certificates. Server certificates were very successful, because they were essential for ecommerce. But client certificates were not essential, because passwords provided a simpler alternative. Little effort was put into working out practical deployment issues, and deploying client certificates has remained cumbersome to this day.

The use of public key certificates for user authentication in federal agencies was mandated in 2004 by presidential directive HSPD-12. Specifically, the directive requires the use of certificates carried by PIV smartcards for authentication of federal employees to federal information systems. (This use of PIV smartcards is called “logical access”, by contrast to the use of the same cards to provide physical access to federal buildings.) But a recent GAO report shows the difficulties that agencies have been having in implementing the directive.

NSTIC

In April 2011 the White House launched the National Strategy for Trusted Identities in Cyberspace, which aims at creating an Identity Ecosystem based on identity solutions that reduce password use and improve security, while increasing privacy and user choice.

NSTIC has also subsumed the earlier Open Identity Initiative, whose goal is to use private sector identity providers to authenticate citizens who access government Web sites.

Privacy-Enhancing Technologies

NSTIC was inspired in part by the existence of credentials based on privacy-enhancing technologies such as Microsoft’s U-Prove and IBM’s Idemix.

We reviewed the pros and cons of those credentials in four blog posts

We were then asked to summarize these posts as an introduction to a panel on privacy in the identification domain at the NIST Meeting on Privacy-Enhancing Cryptography. (See also our trip report). After the workshop we discussed an additional issue of privacy-enhancing credentials in another post:

We believe that credentials based on privacy-enhancing technologies have an important role to play in the NSTIC Identity Ecosystem, but it will take time to determine what use cases they are best suited for, and to resolve technical, deployment and usability issues.

A Proposed Roadmap for NSTIC

NSTIC has come at the right time. Without it Internet identity was evolving towards a bleak future where Web authentication would have been controlled by a one or a few identity providers who would have unprecedented power over users and relying parties, and where the insecurity of passwords, instead of being eliminated, would have been augmented by a greater danger of phishing attacks.

We hope that NSTIC will take us to an identity ecosystem with more security, privacy, and user choice. Here are the features that we envision will be provided by NSTIC in the long term:

  • There will be a variety of password-free, cryptographic credentials, including credentials based on public key cryptography, such as public key certificates and attribute certificates, and credentials based on privacy-enhancing technologies. It will be possible to use multiple credentials of different kinds simultaneously.
  • Use of certificate revocation lists (CRLs) for public key certificates will be avoided by issuing short-term certificates renewable using an ad-hoc certificate renewal protocol. (The idea of an ad-hoc renewal protocol comes from Idemix, which currently provides such a protocol for anonymous credentials.) The Online Certificate Status Protocol (OCSP) will provide direct verification of validity when very timely revocation is called for.
  • Cryptographic credentials will be built into the fabric of the Web. Users will need no software other than an ordinary browser to use them. A relying party will ask for the credentials it needs using HTTP headers and those credentials will be presented by the browser to the relying party via TLS (suitably extended). There will be procedures for issuing credentials automatically after proofing, universally implemented by browsers and server-side middleware.
  • Many Web sites and applications will issue their own public key certificates when users register, to authenticate subsequent logins without involvement by a third-party identity provider. Such a certificate will not require revocation because it will be presented only to the certificate issuer.
  • Self-asserted identity data will be stored in the browser and maintained by the user as a browser preference. It will be presented by the browser to relying parties upon request (with user approval) over a TLS connection, in conjunction with the presentation of cryptographic credentials but separately from those credentials.
  • Social login will be implemented using cryptographic credentials. The social site will issue a delegatable credential to the browser, which the browser will use to delegate to the relying party partial access to the user’s account at the social site. The delegatable credential may be a public key certificate or a credential based on a privacy-enhancing technology; in either case, the social site will not be informed of the identity of the relying party unless the relying party discloses its identity with the consent of the user.

However, this vision will take years to realize, because it requires major improvements to the core Web protocols and to Web browsers. We need a shorter term interim solution if we don’t want to lose the battle before we start fighting.

A Short Term Password-Free Identity Solution

For the short term we propose an identity solution that eliminates passwords while requiring no extension to TLS and only minor browser modifications. The idea is to combine double redirection with certificate submission to the certificate issuer and with a new method of selecting an identity provider, as follows:

  1. An identity provider issues a certificate to the browser with identity data, which the browser imports automatically along with associated metadata sent by the identity provider. We propose to use an extension of the functionality of the keygen element of HTML5 to this purpose. As part of the user’s preferences the browser keeps a list of identity providers from which it has received certificates, the preferred providers. The user can designate one of the preferred providers as the default.
  2. The user elects to log in to the relying party with its default preferred provider, or chooses among its preferred providers. This can be accomplished in two different ways:
    1. The relying party’s login page presents a form containing a menu listing the preferred providers, where the default provider is preselected. The menu is generated by a new, ad-hoc HTML element. For the sake of privacy, the contents of the menu are supplied by the browser and not seen by the relying party. The user may modify the selection. When the form is submitted, the relying party receives the metadata associated with the selected provider, including the URL of a redirect endpoint of the provider. Or,
    2. The relying party’s login page contains a single-button form, which contains a new, non-visual, ad-hoc element. When the user submits the form, the non-visual element causes the browser to either send the metadata of the default preferred provider to the relying party, or present the user with a menu of preferred providers from which the user can select the one whose metadata will be sent to the relying party. In either case, the metadata includes the URL of a redirect endpoint of the provider.
  3. The relying party uses a double redirection protocol to send the browser to the preferredn identity provider’s redirect endpoint. The browser presents the certificate to authenticate the user and the identity provider redirects the browser back to the relying party, passing along the identity data contained in the certificate.

A key feature of this solution is that there is no need for certificate revocation, because the certificate is presented to the certificate issuer. The double redirection protocol that we propose to use is PKAuth which provides stronger security than OpendID and OAuth.

The main drawback of this short term solution is that the identity provider is informed of the user’s logins. To mitigate this drawback the browser may use a do-not-track header to inform the identity provider that the user does not want to be tracked. Regulations should make it compulsory to comply with the request. We have written a blog post arguing that the scope of a do-not-track header should include tracking by identity providers:

A Very Short Term Solution

An even shorter term solution is to substitute OpenID for PKAuth in the short term solution, with the new method of selecting an identity provider replacing the complex OpenID provider discovery process. The user does not have to enter an OpenID identifier before being redirected to the OpenID provider.

Comments are closed.