Internet Engineering Task Force Y. Oiwa
Internet-Draft RCIS, AIST
Intended status: Informational T. Hayashi
Expires: January 6, 2012 B. Kihara
Lepidum
July 5, 2011
HTTP authentication: problem statement
draft-oiwa-http-auth-problem-statement-00
Abstract
This document discusses about existing problems in the current
authentication technologies around HTTP and some analysis of the
requirements for future authentication technologies in HTTP area.
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 January 6, 2012.
Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License.
Oiwa, et al. Expires January 6, 2012 [Page 1]
Internet-Draft HTTP auth problem statement July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Existing authentication mechanisms . . . . . . . . . . . . . . 4
3. Background: existing threats and contributing factors . . . . 4
3.1. Impersonation of server identity (Phishing) . . . . . . . 4
3.2. Impacts of server-side password database leakage . . . . . 4
3.3. Impacts of complex authentication/authorization
technologies . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicable fields for HTTP authentication . . . . . . . . . . 5
4.1. Web user authentication . . . . . . . . . . . . . . . . . 5
4.2. Web client application data accesses . . . . . . . . . . . 6
4.3. Non-Web user authentication . . . . . . . . . . . . . . . 7
5. Problem statements . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Lack of mutual authentication . . . . . . . . . . . . . . 7
5.2. Avoiding use of plain-text passwords on authentication . . 8
5.3. Functional weakness of HTTP authentication framework . . . 9
5.4. Lack of bindings between multi-layer
authentications/authorizations . . . . . . . . . . . . . . 9
6. More topics . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Oiwa, et al. Expires January 6, 2012 [Page 2]
Internet-Draft HTTP auth problem statement July 2011
1. Introduction
User authentication is, needless to say, one of the most important
building block for the Web applications and other Internet-based
systems. As social activities and commerce systems are more and more
widely spreading, the importance for the security of the
authentication also increase. Furthermore, the recent movement of
providing government services on the Web requires user authentication
as a key feature. Impersonation of client users in such systems may
cause unrecoverable damages such as loss of credits, trusts, or
social statuses.
At the same time, the authentication is currently one of the weakest
blocks in terms of security. Intrinsically, the Web system as a
whole is a multi-party system where the malicious servers cannot be
rejected from the world. Unlike other systems such as email (POP
[RFC1939] or IMAP [RFC3501]) or VPN (IPsec [RFC4301], L2TP [RFC2661]
etc.) where the communication peer is typically pre-configured in the
client software, Web clients (Web browsers) communicate with any
party which the user insists to. This property leaves malicious
servers to forge users to communicate with himself and performs a
fiddle with the victim. Once such an attack succeeds, its result is
severe: not only user's passwords to be stolen, users are often
fooled to provide more critical information such as credit card
numbers to the attackers.
On contrary to the current design, the authentication on the Web
systems should be bidirectional and mutual: not only the authenticity
of the users, but the authenticity and integrity of the servers is
really important for protecting user resource stored on the server
side. Most users assume that the successful user authentication also
implies that they are talking with the genuine server entity:
unfortunately, for almost all currently-deployed technologies on Web
authentication this is not true, even for the TLS [RFC5246] client
certificate authentication.
The motivation of this document is to promote ideas of replacing
current systems and mechanisms for authentications on the HTTP/Web
systems by more secure building blocks which are carefully designed
for both security and usability/deployability. In the following
sections, currently available methods of authentication on the Web
systems are reviewed, and existing problems are discussed. At last,
we conclude with possible action plan proposals for the community.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
Oiwa, et al. Expires January 6, 2012 [Page 3]
Internet-Draft HTTP auth problem statement July 2011
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Existing authentication mechanisms
(To be described)
3. Background: existing threats and contributing factors
3.1. Impersonation of server identity (Phishing)
The term "Phishing" here is used as a generic term of attacks
involving some kind of spoofing or impersonation used to socially/
technically fool the victim users. From the beginning of the Web
system, such "false web sites" are considered as a problem. TLS and
its predecessor, SSL, have introduced a PKI-based server identity
checking [RFC3647] using trusted certificate authorities (CAs) to
address this issue. However, more and more sensitive and valuable
information Web systems become to handle, more and more the Phishing
attacks become "useful" attack vector. Such Phishing sites typically
steal user identity and plain-text passwords from the victim user,
and use it to either access sensitive data (such as Web mail services
for critical officers), to fool users to provide more sensitive
informations to the attackers (such as credit card numbers), or to
impersonate victims with a malicious social activities (such as
selling stolen items in a net auction).
3.2. Impacts of server-side password database leakage
Technically speaking, security of the server-side data is an out-of-
scope issue for the HTTP authentication. However, we should be aware
that many real-world security bleaches actually caused (partially) by
the leakage of server-side stored information. Impact of such
server-side leakage depends on how the authentication mechanism are
designed. For Basic authentication [RFC2617], server-side credential
used for password verification is usually one-way hashed with a
random salt, which mitigates risk of server-side leakage a bit.
Public key cryptography-based authentication, if correctly managed
and deployed, can also avoid storing of sensitive client-credentials
to the server-side. On the contrary, Digest authentication and other
hash-based authentication schemes (e.g. CRAM-MD5 in SASL [RFC4422],
APOP, etc.) requires raw client-side credentials to be stored in the
server side by its nature. Of course, if all other properties are
similar, the algorithms which do not require raw client credentials
in server side is preferable as far as possible.
Oiwa, et al. Expires January 6, 2012 [Page 4]
Internet-Draft HTTP auth problem statement July 2011
3.3. Impacts of complex authentication/authorization technologies
Recently, many complex framework for authentication and
authorizations are deployed to realize multi-party authentication.
For example, OpenID and SAML [OASIS.saml-core-2.0-os] gives servers
an opportunity to authenticate users using identities provided by
third parties. OAuth [RFC5849] allows a user to delegate some access
rights to servers or other systems without giving client
authentication credential itself.
Introduction of such services can have both positive and negative
impacts on the Web security. For example, federated multi-party
authentication can reduce number of client credentials which are
required to access many services, which can reduce risk of server-
side information leakage. At the same time, it requires user to
authenticate himself in dynamically-generated web pages in the middle
of complex page redirection flows, which makes users difficult to
discriminate whether the page is a correct one to input her user name
and password, increasing risk of Phishing attacks. Detailed analysis
of its security, including user experiences in its consideration,
might be needed.
Also, in such systems single security bleach among multiple parties
involved to federated authentication may or may not impact security
of other systems and their users. There are many pitfalls in
implementation of such multi-party protocols, such as session
fixation, session hijacking and cross-site request forgeries.
Especially because most of those technologies are implemented often
in application layer, careful observation and analysis of such
bleaches caused by mis-implementation of a single party should be
performed.
4. Applicable fields for HTTP authentication
Nowadays HTTP is used as a common foundation for various systems
including Web systems and other non-Web applications. Depending on
the nature of each systems using HTTP, the required properties for
the underlying authentication/authorization mechanism may vary.
Although the comprehensive analysis of all existing applications are
impossible, this document hereby proposes categorizing use cases to
three typical groups as a starting point, for further analysis in the
sections below.
4.1. Web user authentication
The first group is to authenticate users of common Web applications,
typically using Web browsers as clients. This group is very common
Oiwa, et al. Expires January 6, 2012 [Page 5]
Internet-Draft HTTP auth problem statement July 2011
use cases which exists from very early stage of HTTP, and the ones
for which currently existing HTTP authentication mechanisms are
designed.
One of the most important security consideration in these scenarios
is complex interactions between human users, browser clients and
Websites including those of uncontrollable third-party entities.
Phishing is a very common attack vector for this scenario, and
without having some weapons against protecting authentication
credentials and integrity, it is impossible to stop malicious
phishers from deploying such attacks.
Authentication credentials used for these scenarios varies for
required authentication strength and several social factors, for
example passwords, cryptographic secret keys, smart cards, one-time
passwords, etc., but in most cases such credentials are belonging to
human entities. There is several proposals for unified and federated
authentications, but this principle does not change.
4.2. Web client application data accesses
Recently, capability of client-side data processing in Web browser
clients are greatly improved, and it introduced a new pattern of
client-server relationship in Web applications: Web-application
initiated data accesses.
In ancient Web systems, clients are only communicating with the
corresponding server providing the current Web page, and if some
external data accesses are needed, the server will perform it,
process the received data and serve the result to client as a static
data embedded in Web contents. In this scheme, the user
authentication mentioned above is only necessary, and all other
authorization managements are performed in the server-side.
However, evolution of client-side data processing changed the whole
story. Now the client-side application can request authentication of
itself as an agent of the human user, obtain authorization rights and
access several data resources in various servers. Such authorization
rights are not needed to be directly corresponding to the active
human user's rights: it can be of another user's rights delegated to
a user (like what the OAuth protocol [I-D.ietf-oauth-v2] provides),
or it can be subset of what the user has access to. In this story,
the authentication/authorization of client application are related
but not directly connected to the human user's authentication.
Some important points in this group might be flexibility:
application-level authentication can be either related or unrelated
to human entity, and same application may need to provide more than
Oiwa, et al. Expires January 6, 2012 [Page 6]
Internet-Draft HTTP auth problem statement July 2011
one methods of authentications in the same framework, possibly with
different levels of authorizations.
In this use cases, phishing is not always a key factor for threat
analysis. If Web applications are itself faked and thus provided
from phishing sites, the user cannot trust provided data regardless
of whether the data resource servers accessed are trustful or not.
On the contrary, provided Web applications are trustful, these
programs typically (but not always) "know" what server is the correct
server to interact. Some mutual and eavesdropping-safe
authentication technologies are still useful, as many applications
nowadays still need some communication in an unencrypted channels
because of overhead of secure-channel provisions.
4.3. Non-Web user authentication
The final group is use-cases for non-browser client applications.
Nowadays HTTP is becoming a common vehicle for various applications
including non-browser clients. Because of its simplicity, many
existing services are providing both Web-client and non-Web API
accesses using the same HTTP platform. We should not ignore such use
cases when considering solutions for the above two groups.
In some aspects, required features for this group of applications are
subsets of the above two use cases. Simple user authentication may
be mapped to an HTTP authentication scheme provided for the "Web user
authentication", and some detailed authorization cases may be mapped
to an access grant management used for "Web application
authentication" stories. However, because we cannot rely on any aid
from Web pages and scripts, some technologies for these groups may be
not useful for non-Web applications, or careful design consideration
may be needed for applying those to this group of use cases. For an
instance, OAuth usually relies on Web-based authentication and page
redirections, but to support non-Web application use cases it
required some additional features as well. Also, integration with
existing authentication framework such as SASL [RFC4422] or GSSAPI
[RFC2743] might be important especially in this use cases.
5. Problem statements
5.1. Lack of mutual authentication
Most authentication technologies which are currently used on Web
systems are essentially one-directional. A server always checks
authenticity of users using client authentication credential, but a
user has little control of the process and a user can not know
whether the talking peer is the intended entity, or they can not know
Oiwa, et al. Expires January 6, 2012 [Page 7]
Internet-Draft HTTP auth problem statement July 2011
whether the server is actually performing an authentication and has
knowledge of the user. This has been a cause of many Phishing attack
instances. All of HTTP Basic authentication, Digest authentication,
HTML Form authentication and even TLS client certificate
authentication fall into this category of technologies. TLS server
authentication are thought to mitigate this factor, but it was too
weak to prevent many Phishing attacks. The TLS server authentication
only certifies that the server has (in some sense) a right to
legitimately use the domain name that the client accessed, and
optionally binds the server with some real-world entity. In fact,
some phishing sites use their own domains with a valid server
certificates, or others use a cracked servers with legitimate
certificates to perform an attack. In this situation, the server
authentication does not prevent Phishing technically, instead it
relies on the careful manual investigation of domain names by an end
user.
For secure use of Web systems mutual authentication between users and
servers has critical needs. By performing mutual authentication, a
user can assure that the peer server has certainly performed an
authentication, and that the peer has a prior knowledge of the user,
eliminating possibility of man-in-the-middle attacks or false
authentications. We should investigate possibilities of performing
mutual authentication using various kinds of authentication
credentials: passwords (weak secret), strong shared key, multi-factor
credentials and even cryptographic public/private key pairs if
possible.
This requirement is mainly applicable for both Web and non-Web user
authentication. For simple access patterns (where user
authentication coincide with data access authorization), it may be
also applicable for application data accesses (both Web and non-Web).
5.2. Avoiding use of plain-text passwords on authentication
Two most widely used authentication technologies, Basic and Form-
based authentication, uses plain-text passwords as credentials and
send these directly on wire. Obviously, using those technologies
without encryption will reveal any secret credentials to all
eavesdroppers. Even if TLS encryption is used, on-wire plaintext
passwords are vulnerable for Phishing and (Web application layer)
man-in-the-middle attacks. This weakness is amplified when users are
using a single password for several independent systems. Especially,
using plaintext passwords in Form-based authentication required
handling of passwords in a Web application layer, which has caused
many password leakage accidents in many commercial websites. To
avoid these problems, we need technologies which prevents leakage of
reusable weak secret.
Oiwa, et al. Expires January 6, 2012 [Page 8]
Internet-Draft HTTP auth problem statement July 2011
This item applies to all of the previously-mentioned use cases.
Especially when applications needs use of unencrypted channels for
performance reasons, it is crucial to protect authentication
credentials and tokens.
5.3. Functional weakness of HTTP authentication framework
Current basic design of HTTP authentication framework [RFC2617] does
not sufficiently provide the features which are required by current
Web application logics. This is currently one of the biggest reason
why many Web developers prefer HTML Form-based authentication more
than HTTP Basic authentication. For example, current HTTP
authentication framework lacks support for non-mandatory
authentication (aka guest user support), and enforcement of login
session termination (log-out control). It also removes application
developers detailed control of user experiences, because most of
interactive HTTP clients (Web browsers) uses a modal, interruptive
dialog user interface for authentication. Some authentication
schemes, notably TLS client certificate authentication are further
worse, as a single server must serve a single set of authentication,
and users can not use several identities simultaneously within one
server.
However, due to the nature of HTML form and UI designs, it is almost
impossible to fundamentally improve security of Form authentication,
mainly due to the fact UI of such authentication can be always faked
and imitated. For example, if we had a secure input field for
passwords in some HTML extensions, Phishers would simply forge it
with usual password field instead to steal any passwords inputs. To
avoid this problem, the user agent (browsers) and the HTTP protocol
must serve a role of securely handling authentication and user
credentials. To make use of such agent-driven authentication in real
applications, the authentication framework should be flexible enough
so that the application developers can realize any application logics
they require for the user and session managements.
This requirement is mainly applicable for browser-based Web user
authentication. The provision of such features should be compatible
with other use cases, however.
5.4. Lack of bindings between multi-layer authentications/
authorizations
Many recent Web applications are implemented in multi-layer
technologies and each layer often has own control of authentication
and authorization. For example, OAuth [I-D.ietf-oauth-v2] enables
application-level delegated access authorization using credentials
issued on another authentication/authorization framework. W3C
Oiwa, et al. Expires January 6, 2012 [Page 9]
Internet-Draft HTTP auth problem statement July 2011
proposed WebID uses result of TLS client authentication for control
of upper-layer identification and authorization. The channel binding
is a key technology to implement such multi-layer applications.
Simply speaking, the channel binding is a technique which relates an
upper-layer authentication with a result of lower-layer
authentications/key-exchanges. By doing that, any result of upper-
layer authentication can not be separately used on any other lower-
layer channels which are not authenticated by the same way. For
example, by using TLS channel binding [RFC5929] with a signed OAuth
request, such request tokens can not be used by any other people to
access the protected resources, even if the token has been leaked in
some way. Unfortunately, current HTTP-layer authentication schemes
does not provide functionality for such channel bindings. Future
schemes should consider providing such binding functionality as its
building blocks.
(to be mentioned: OAuth HTTP MAC authentication
[I-D.ietf-oauth-v2-http-mac])
6. More topics
(TBD)
7. IANA Considerations
None.
8. Security Considerations
This document obviously deals with security technologies. However,
the purpose of this document is not to provide specific protocols or
technologies to be directly implemented, but to discuss about current
status of existing technologies and requirements for future
technologies. Therefore, there is no specific security precautions
to be mentioned here. When designing some specific technologies
mentioned in this document, we MUST have careful consideration of
security properties, because the technology area handled in this
document has very complex and legacy characteristics and limitations.
9. References
Oiwa, et al. Expires January 6, 2012 [Page 10]
Internet-Draft HTTP auth problem statement July 2011
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Protocol", draft-ietf-oauth-v2-16 (work
in progress), May 2011.
[I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP
Authentication: MAC Access Authentication",
draft-ietf-oauth-v2-http-mac-00 (work in progress),
May 2011.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
November 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Oiwa, et al. Expires January 6, 2012 [Page 11]
Internet-Draft HTTP auth problem statement July 2011
Internet Protocol", RFC 4301, December 2005.
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849,
April 2010.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
Authors' Addresses
Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology
Research Center for Information Security
AIST Tsukuba Headquarters' building
Tsukuba Central 2
1-1-1 Umezono
Tsukuba-shi, Ibaraki
JP
Phone: +81 29-861-5284
Email: mutual-auth-contact@m.aist.go.jp
Tatsuya Hayashi
Lepidum Co. Ltd.
#602, Village Sasazuka 3
1-30-3 Sasazuka
Shibuya-ku, Tokyo
JP
Boku Kihara
Lepidum Co. Ltd.
Oiwa, et al. Expires January 6, 2012 [Page 12]