Internet DRAFT - draft-hallambaker-httpauth
draft-hallambaker-httpauth
Internet Engineering Task Force P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Standards Track October 22, 2012
Expires: April 25, 2013
HTTP Authentication Considerations
draft-hallambaker-httpauth-01
Abstract
This draft is input to the HTTP Working Group discussion of HTTP
authentication schemes.
Since the topic is one that the intended audience is more than
familiar with, the presentation style is maybe not what is usual in
such papers.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Hallam-Baker Expires April 25, 2013 [Page 1]
Internet-Draft HTTP Authentication Considerations October 2012
described in the Simplified BSD License.
Table of Contents
1. What is Wrong in Web Authentication . . . . . . . . . . . . . 3
1.1. Password Promiscuity . . . . . . . . . . . . . . . . . . . 3
1.1.1. Password Recovery Schemes . . . . . . . . . . . . . . 4
1.1.2. Phishing . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Provider Lock In . . . . . . . . . . . . . . . . . . . . . 5
1.3. Strong Credentials Compromised by Weak Binding . . . . . . 6
1.3.1. Confirmation vs Authentication . . . . . . . . . . . . 7
1.4. What passwords get right . . . . . . . . . . . . . . . . . 7
2. User Authentication is Three Separate Problems . . . . . . . . 8
2.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Credential Presentation . . . . . . . . . . . . . . . . . 8
2.3. Message Authentication . . . . . . . . . . . . . . . . . . 9
3. Deployment Approach . . . . . . . . . . . . . . . . . . . . . 10
3.1. Password Managers as Transition Path . . . . . . . . . . . 10
3.2. Non-Transferable Credentials . . . . . . . . . . . . . . . 11
4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Open Protocol for credential management . . . . . . . . . 11
4.2. HTTP Integrity Header . . . . . . . . . . . . . . . . . . 12
4.3. Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. User Lock In . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Site Lock In . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Impersonation . . . . . . . . . . . . . . . . . . . . . . 12
5.4. Credential Disclosure . . . . . . . . . . . . . . . . . . 12
5.5. Credential Oracle . . . . . . . . . . . . . . . . . . . . 12
5.6. Randomness of Secret Key . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hallam-Baker Expires April 25, 2013 [Page 2]
Internet-Draft HTTP Authentication Considerations October 2012
1. What is Wrong in Web Authentication
What is wrong with Web Authentication is that twenty years later we
still depend on passwords and what is worse, the weakest possible
password infrastructure.
Little has changed in the use of password authentication since the
publication of crack in 1990. Before crack it was a point of pride
for many Unix admins that the one way encryption used in UNIX "made
their password system more secure than VMS". It was argued that
making the one way encrypted password file public made the system
more secure than the 'security-through-insecurity' approach of VMS.
VMS also used one way encryption but the password file was only
readable with admin privileges. Endless USENET flames explained
'why' this was a terrible, terrible idea. When crack appeared these
flames were quietly forgotten and it is widely imagined that UNIX
systems have always had shadow passwords.
In the wake of crack it was discovered that most users chose terrible
passwords that could be guessed through a brute force or dictionary
attack in a few hours. The use of a salt made guessing passwords
moderately more difficult as did minimum length password requirements
and a requirement to use a non alphabetic character.
In the two decades since the standard rules for passwords were set in
scripture, computing power has increased by over a billion times and
it is now possible to buy a computer that will fit in the heel of a
shoe that is more powerful than the fastest mainframe on CERN campus
in 1992. The ad-hoc rules developed to make brute force attacks an
order of magnitude harder in 1990 have been rendered utterly
irrelevant by the six orders of magnitude improvement in available
computing power. We have arrived at a situation where we use
passwords that are maximally hard for people to remember while being
trivial for modern computers to break by brute force.
This approach to password security: complacency followed by ad hoc
patches followed by complacency has remained firmly in place since.
1.1. Password Promiscuity
Today the typical Internet user has to remember hundreds of passwords
and account names. Since this is of couse silly, most users, myself
included do no such thing. Most users have the same password for
every account. Security concious users have a different password for
every account they care about and an easy to remember password for
the rest. My New York Times account is phil@hallmabaker.com and the
password is GuessEasy. Go have a party. That information protects
an asset that the New York Times wants to protect. It is not an
Hallam-Baker Expires April 25, 2013 [Page 3]
Internet-Draft HTTP Authentication Considerations October 2012
asset that I care to spend time or effort protecting.
Password promiscuity is a natural strategy that users have adopted to
protect the asset they care about: Their time. Creating and
remembering strong passwords takes time and effort. Blaming users
for not taking time and effort to protect the assets of other people
is futile.
If Alice has shared her password at 100 sites then a single corrupt
actor who can access just one of those sites can gain access to the
other 99.
Account names pose a harder problem since most sites require that the
account name be unique for that site. So a user who finds their
preferred account name is taken has to choose another.
Expecting users to remember all this stuff is stupid, just stupid.
1.1.1. Password Recovery Schemes
Password and account name recovery schemes are necessary because
users cannot remember the hundreds of passwords or account names that
using the Web now involves.
The most common password recovery mechanism is the email callback
authentication mechanism first used by Mallery and Hurwitz on their
Open Meeting system. A challenge (usually in the form of a link) is
sent out to the user to their registered email address. The user
must respond to the challenge to reset their account.
One important consequence of the email callback scheme is that
virtually every Web site that has an accounts mechanism requests an
email address during registration. There is thus no loss of privacy
if the email address is used as the account name. Many sites have
realized this fact and avoid the need for the user to choose an
account name by allowing them to give their email address instead.
A site need not and in fact should not disclose the email address to
other users when this approach is used. Shadow account names allow
the user the courtesy of not having to remember the account name for
that site.
1.1.2. Phishing
Another circumstance that made it difficult to implement strong
security mechanisms at the time was the popular misconception that
the attackers were exclusively teenage miscreants engaged in the
cyber equivalent of joy-riding rather than criminals motivated by
Hallam-Baker Expires April 25, 2013 [Page 4]
Internet-Draft HTTP Authentication Considerations October 2012
money. People were warned that this was not the case but they did
not want to hear.
The core defect of the Web authentication mechanism is that passwords
are presented en-clair to the verifier. Thus any party who can
present a login page to the user stands a good chance of capturing
their credentials.
This problem was of course anticipated a few days after the BASIC
authentication mechanism was proposed and was the original motivation
for DIGEST authentication. But DIGEST authentication did not permit
the re-use of legacy UNIX password files and so implementation did
not take place until it was to late to deprecate BASIC.
Even today, IE7 makes no distinction between a request for
authentication using BASIC vs DIGEST. Thus an attacker can easily
capture the user's credentials through a downgrade attack. DIGEST
was intended to replace BASIC and for BASIC to be expunged from the
spec as dangerous to use.
In the event authentication moved into the HTML layer which likewise
communicated the password enclair to the verifier. Thus enabling
phishing.
1.2. Provider Lock In
Many schemes have been developed to provide the user with a portable
form of credential but all those created to date present the security
risk of lock-in to both users and relying parties.
Such schemes are often described as 'identity management' a term that
seems to hurt rather than help comprehension of the problems
involved.
Many users have found to their cost that when their FaceBook or
Twitter account is disabled, they lose access to every other Web site
linked to it.
While end users are faced with a minor inconvenience, relying party
sites are faced with the risk that the 'identity provider' will
decide to change their terms of service to their great disadvantage
with little or no notice. Essentially the relying parties have
agreed to channel all their traffic through the portal of another
without any form of contractual agreement to prevent the portal owner
setting up a toll booth.
A particular form of lock in that will doom any scheme to an
inevitable and deserved death is any attempt to tie the scheme to the
Hallam-Baker Expires April 25, 2013 [Page 5]
Internet-Draft HTTP Authentication Considerations October 2012
use of any naming registry other than the DNS.
In one recent exercise in mindboggling futility a group of otherwise
rational people spent over five years on a project where the two
identifier forms to be supported were
http://www.whowoulddothis.org/username and =username. It was rather
obviously and abundantly clear that the only rational reason for the
first choice was to corrale users to the inevitable choice of the
second. Well they didn't did they?
One of the problems with such commercial interests is that it is
often considered impolite or somehow improper to point out that they
exist. Even when it is rather clear that their presence is going to
doom the scheme to extinction.
While a naming ragistry can be profitable in theory, there have only
been four such registries established on an international scale in
the history of human civilization. Each supported a new form of
communication, these being the postal system, the telephone system,
the barcode product identifier system and the Internet. While
commercial control of such a registry would of course bring ritches
almost beyond the dreams of MBAs, the chance that such proposals
might succeed is negligible to nil.
1.3. Strong Credentials Compromised by Weak Binding
A secondary Web authentication problem is that use of strong
credentials is compromised by the inadequacy of the Web protocols.
For example, a One Time Password (OTP) token provides strong
authentication when used in the context of a VPN or other application
that can guarantee that the passcode is only presented to the
intended service. When entered into a HTML page, OTP passcodes are
as vulnerable to interception as passwords.
Use of an OTP or public key token provides strong evidence that the
hardware device concerned was in some way involved in a transaction
but not the intention of the token holder.
Consider the case where a wire transfer of $10,000 to be sent to
Nigeria is requested, the bank asks for an OTP value to be entered as
confirmation. The bank can only verify that the value entered is the
next OTP value in sequence. The bank has no means to determine
whether the token holder was looking at a Web page that asked them to
enter the value to confrim the wire transfer or whether they were
looking at a Web page asking if they would like to buy a fluffy pink
bunny for their daughter's birthday.
If an authentication system cannot tell the difference between a con
Hallam-Baker Expires April 25, 2013 [Page 6]
Internet-Draft HTTP Authentication Considerations October 2012
trick and a pink fluffy bunny, it should not be considered strong.
1.3.1. Confirmation vs Authentication
Modern smartphones are ubiquitous and relatively cheap. They provide
a computing capability, a communication capability and a display in a
single package. This is a platform that can and should be leveraged
as an authentication device that can provide proof not only that the
user was involved but that they were committed to the transaction
concerned.
This technology provides us for the first time with a technology
platform that is capable of presenting the user with the actual
transaction they are being asked to confirm and to thus provide a
strong binding between the device and the transaction.
My prefered hardware device for such a use would be a wristwatch with
an intelligent display.
1.4. What passwords get right
Overlooked in most security discussion of passwords is what they get
right, indeed it is often assumed that they have no redeeming
features. Yet if that were the case they would have been gone long
ago. The real problem of passwords is that they work just well
enough to be almost always better than the alternatives.
The biggest advantage of passwords is that every Internet device has
had to develop the affordances to support them. My Internet enabled
weighing scale has a USB socket whose sole purpose is to enable me to
plug it into a computer to set the WiFi network name and password. I
can log into my personal email account from every desktop computer,
laptop, tablet or mobile in the house. I can only acces my corporate
email from the one machine configured for the corporate VPN and smart
token.
Passwords require no dongles, tokens or cards which in turn means
that they don't require device drivers or administrator privileges.
While vendors of such systems strive to present low barriers for such
devices, low barriers can never compete with no barriers if the user
has a choice in the matter. People take effort to secure the assets
they care about which is why banks can't give authentication tokens
to customers while the same customers will go and pay for a
battle.net token to secure the assets that matter to them.
Hallam-Baker Expires April 25, 2013 [Page 7]
Internet-Draft HTTP Authentication Considerations October 2012
2. User Authentication is Three Separate Problems
The term 'authentication' tends to cause confusion due to the fact
that there are actually three separate activities that it can refer
to. When Alice establishes an account at a Web site, the site may
verify her email address is correct. When Alice presents her
username and password, the site verifies the data and if correct
issues a HTTP cookie. When Alice re-visits the same Web site to make
further requests, the cookie is verified each time. Each of these
verifications is a form of authentication but they are totally
different in character and only the last of these is a form of
authentication that is directly related to HTTP.
Attempts have been made to distinguish between these as 'initial
authentication' and 're-authentication' but this also creates
confusion as some people consider the first contact with the user as
the 'initial' authentication and others consider that to be the start
of a Web session.
2.1. Registration
Registration comprises all activities related to the establishment
and maintenance of an account. These include the initial dialogu in
which Alice picks out an account name for display on the site and her
authentication credentials and all subsequent updates including
password resets.
In a small number of circumstances, registration involves
authentication of dopcumentary evidence such as articles of
incorporation, a passport, business license or professional
qualifications. The term validation seems to have emerged as the
term of art for this activity.
Today registration is almost exclusively managed through HTML forms.
Any new system will probably have to respect this approach.
Registration establishes an account that is in almost every case to
be accessible from multiple Web browsers rather than just the browser
on which the registration process was completed.
2.2. Credential Presentation
Unlike the FTP and Telnet protocols that preceded it, HTTP Web
sessions typically span multiple TCP connections. In the typical
case the use will 'log in' to a Web site to establish a session that
then continues for several hours, days or even months.
Like the registration phase, credential presentation has largely
transitioned out of the browser to HTML. Although many users employ
Hallam-Baker Expires April 25, 2013 [Page 8]
Internet-Draft HTTP Authentication Considerations October 2012
plugins and applets that effectively reverse this, filling in the
account an password field from a password database that is stored
locally or in the cloud.
While such 'password managers' have traditionally been considered
part of the problem they are in fact a necessary part of any
solution. If we are going to improve matters we must first offer
users a solution that meets their needs better than current
solutions.
2.3. Message Authentication
Credential presentation has a necessary impact on the user. Since it
would be tedious to enter a username and password for every Web page
view, a lightweight mechanism is necessary to re-authenticate the
user and demonstrate that they are the user that authenticated
themselves when the session was created.
This is the only part of the process that is currently within the
scope of HTTP rather than HTML and probably the only part for which
it will be possible to get agreement on a better mechanism than the
existing one.
The best available mechanism is the HTTP 'cookie'. This is highly
unsatisfactory as a technical mechanism as they are weakly bound to
the HTTP transaction and disclosed to the verifier. These
circumstances in turn lead to numerous forms of cookie-stealling and
cookie-stuffing attacks.
Using cookies for authentication also involves privacy concerns. In
the context of authentication schemes, the use of cookies does not
raise new privacy concerns as the purpose of the authentication
scheme is to establish a session and uniquely identify the user.
Unfortunately the cookie spec permits sites to establish cookies for
tracking purposes without user permission or knowledge. The fact
that cookies may be used for illegitimate purposes compromises
legitimate uses and creates unnecessary transaction costs including
customer serivce calls, congressional subpoenas and accusations on
slashdot.
My proposal for fixing this part of the problem isdescribed in
[I-D.hallambaker-httpintegrity].
While there are many, many concerns that need to be considered in the
registration and credential presentation operations, the problem of
message authentication can be reduced to the problems of:
Hallam-Baker Expires April 25, 2013 [Page 9]
Internet-Draft HTTP Authentication Considerations October 2012
Identifying a security context consisting of at minimum an
authentication algorithm, key and account identifier.
Applying the security context to parts of the HTTP message.
3. Deployment Approach
Proposing a better authentication mechanism for the Web is easy. In
fact there is nobody involved in Web Security that could not develop
a better scheme given a free hand and a group of people interested in
deployment. The development of a secure scheme should be well within
the capabilities of a competent first year Computer Science
undergraduate.
The much harder problem is deployment and in particular how to deploy
a new scheme in the context of the legacy infrastructure. Here the
ease with which a proposal can be made makes deployment harder, not
easier since there are always competing proposals.
3.1. Password Managers as Transition Path
If the users are going to participate in any new scheme it must work
at least as well as the existing password scheme. In particular it
must be possible for the user to access all their accounts from their
browser in a transparent fashion with minimal hassle.
Storing passwords in the cloud is a very good way to achieve the
user's interest even if the sites whose assets may be compromised as
a result may see it as a bad thing. Let us agree for the sake of
argument that we consider passwords to be such an intrinsically
insecure form of authentication that the user choice to store them in
the cloud has negligible impact on the security of the system.
Since all the proposals to improve the Web authentication
infrastructure involve some form of 'identity provider', why not give
that provider the secondary purpose as a password manager?
If the communication between the client and the password manager was
a widely supported Internet standard, users could choose any provider
they liked as their password manager and access their credentials
from any Web browser that they might need to use.
Such a confluence could in itself improve security as once the user
is assured that every browser they need to use has access to their
password manager, there is no need for the password to be memorable.
It is thus possible for the password used for credential presentation
to the site to be long and strong.
Hallam-Baker Expires April 25, 2013 [Page 10]
Internet-Draft HTTP Authentication Considerations October 2012
Use of a standards based password management protocol permits the
user to take their security into their own hands irrespective of what
attempts the sites might attempt to prevent it. What is perhaps more
interesting is that it also sets the scene to enabling use of strong
credentials.
3.2. Non-Transferable Credentials
While Web sites concerned with the risk that their customers store
credentials in the cloud might attempt to frustrate a cloud based
password infrastructure, a much better approach is to co-opt it and
use it as a basis to build on. At the very least, a cloud based
authentication infrastructure provides a useful pre-authentication
step that could be used as a preliminary to a site specific log-in.
But just as an identity provider can also be a cloud password
manager, the converse is also true. The cloud password manager can
also support one or more existing mechanisms that enable credential
presentation authentication without disclosure of the credential
being verified. These could be based on SAML, OpenID, OAUTH or even
some new proposal.
4. Action Plan
My proposal to improve Web authentication has the following parts:
Open Protocol for credential acquisition
HTTP Integrity Header
Bindings for credential presentation employing the commonly used
federated authentication schemes, vis SAML, OAUTH, OpenID, etc.
4.1. Open Protocol for credential management
This protocol would be responsible for managing users legacy
credentials (i.e. passwords) and to support whatever strong
mechanisms for credential exchange were developed.
The protocol itself would require registration, credential
presentation and query components. Once the user had established an
account they would have to be able to bind any browser or device of
their choice to that account, possibly doing so for a very limited
time or for limited sites.
The query component would be of the form 'how do I access site X with
identity Y'. For general applications the broker might then respond
Hallam-Baker Expires April 25, 2013 [Page 11]
Internet-Draft HTTP Authentication Considerations October 2012
with a username and password or a secret to be used to respond to a
challenge. For circumstances requiring higher security the system
might support some form of key splitting or sharing or other control
limiting exposure.
4.2. HTTP Integrity Header
This is described at length in [I-D.hallambaker-httpintegrity]
The biggest challenge in the design of SAML, OAUTH and OpenID was
establishing a secure binding between the authentication token and
the HTTP messages. Using cookies and URI fragments for this purpose
is deeply unsatisfactory.
4.3. Bindings
While we might imagine that we can get by with one single protocol
that is going to solve all our authentication problems we now live in
a world where there is much legacy that demands attention. Even if
we decide that in future we are all going to use one single new
protocol, we have to find a mechanism that allows the credential
management systems to trade in their old lamps for new.
At minimum we require a mechanism that allows Web sites to specify
which forms of authentication credentials they might accept, which
mechanisms for useing them for validation and of transporting the
challenges and responses for such mechanisms within HTTP message
headers.
5. Security Considerations
Since this is a discussion document and the whole thing is talking
about security, I think I will just leave the headings here to remind
people about the security issues I think people should consider.
5.1. User Lock In
5.2. Site Lock In
5.3. Impersonation
5.4. Credential Disclosure
5.5. Credential Oracle
5.6. Randomness of Secret Key
Hallam-Baker Expires April 25, 2013 [Page 12]
Internet-Draft HTTP Authentication Considerations October 2012
6. IANA Considerations
7. Normative References
[I-D.hallambaker-httpintegrity]
Hallam-Baker, P., "HTTP Integrity Header",
draft-hallambaker-httpintegrity-01 (work in progress),
October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker Expires April 25, 2013 [Page 13]
