wiki:BarBofs/IETF80/http-auth/AdditionalMaterials/DraftProblemStatement

Note: Newer version available as an Internet Draft

HTTP authentication: problem statement

Yutaka OIWA, AIST (co-authors TBD)

1. Introduction

User authentication is, needless to say, one of the most important building block for the Web application 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 or IMAP) or VPN (IPsec, L2TP 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: Web authentication is 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 client certificate authentication.

The motivation of this document is to promote ideas of replacing current systems and mechanisms for authentications on the 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.

2. Existing authentication mechanisms

(to be written)

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 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, 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, 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.

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 gives servers an opportunity to authenticate users using identities provided by third parties. OAuth 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. Problem statements

4.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 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.

4.2 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.

4.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.

4.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 enables application-level delegated access authorization using credentials issued on another authentication/authorization framework. W3C 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 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>

5. More topics

<TBD>

Last modified 8 years ago Last modified on Nov 13, 2011, 6:39:06 PM