W3C

NOTE-authentform-19990203


User Agent Authentication Forms

W3C Note - 03 Feb 1999


This Version: http://www.w3.org/TR/1999/NOTE-authentform-19990203
Latest Version: http://www.w3.org/TR/NOTE-authentform
Author: Scott Lawrence, Agranat Systems, Inc.
Paul Leach, Microsoft

Status of this document

This document has been submitted to the World Wide Web Consortium (see Submission Request, W3C Team comment).

This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.

User Agent Authentication Forms

This note proposes a new HTML capability to aid in the development of authenticated web user interfaces.

The Problem

In current web applications, most user authentication is accomplished by one of three mechanisms:

HTTP Authentication

HTTP/1.x provides a mechanism whereby the server can deny access to a resource and indicate that authentication is required for a request for that resource. The usual result of this denial of access is for the user agent to challenge the user for credentials (all defined HTTP authentication schemes require credentials in the form of a user name and password), but no mechanism is provided by the protocol for controlling the presentation of this challenge other than the realm name (a non-internationalized string value).

The combination of first requiring that access be denied and the lack of any control over the form of the challenge means that the application developer cannot make the authentication an integral part of the application.

HTTP Authentication has the addition problem that there is no mechanism available to the server to cause the browser to 'logout'; that is, to discard its stored credentials for the user. This presents a problem for any web application that may be used from a shared user agent. Requests for how to force 'logout' appear almost daily in the netnews html and cgi authoring groups, and are one of the most common support questions received by Agranat Systems from their customers developing embedded systems web interfaces.

SSL Certificates

SSL (Secure Socket Layer, or its new IETF descendant, Transport Layer Security [TLS]) can be used to authenticate users by means of the public key certificates used to secure the communications channel. This can be done smoothly and in the normal context of the application, but requires the use of strong cryptography. In many contexts this is too costly and complex a mechanism, and because many countries restrict the export of cryptographic technology, it creates legal difficulties for applications that need to cross certain national boundaries.

SSL/TLS certificates have the same problem with stored credentials as HTTP authentication (there is no mechanism to instruct the user agent to discard them), and the certificates are too large to be entered by a normal user interface, so they are not in practice usable at all by sharable user agents.

Form based credentials

In order to overcome the disadvantages of each of the above, many web based applications have used HTML FORMs to request the authentication credentials. This is supported by the TYPE=PASSWORD input element (which is usually not displayed when entered). This allows the designer to present the request for credentials as a normal part of the application and with all the HTML capabilities for internationalization and accessibility.

The great disadvantage of both form based credentials and the original HTTP/1.0 'basic' authentication scheme has been that they transmit the user credentials in cleartext on the network. This exposure of the credentials is unacceptable for any application requiring real security, and is forbidden in any new protocol to be considered for the Internet Standards track.

Despite its problems, form based authentication is very widely used because of the cost and complexity of using SSL and the poor user experience of HTTP authentication.

The Opportunity

As a part of the development of HTTP/1.1, a new scheme for passing authentication information, called 'Digest', has been developed. Digest authentication can mutually authenticate the user and server without passing the actual credentials on the network in a way usable by an attacker (the details are beyond the scope of this note; see [2]). This overcomes the worst security weakness of HTTP authentication and makes it possible to meet the guidelines for an Internet Standard protocol, but does not help with its poor user interface nor the problem of discarding credentials that are no longer needed. There are mechanisms in the Digest scheme that make it easier for the server to detect how long it has been since credentials were last used and force a request for new ones, but that does not completely solve the problem.

The Proposal

This proposal suggests extensions to HTML forms to overcome their present security problems by integrating them with HTTP (or other security sublayer) mechanisms. It calls for a new type of form; the AUTHFORM and new values for the TYPE attribute of the INPUT element and SELECT block.

AUTHFORM element

The AUTHFORM element is defined to specify a specialized form for collecting authentication information. An AUTHFORM is not submitted to the server, but is used to initialize the credentials store of the user agent for subsequent requests to the server from which it was returned.

An AUTHFORM may contain INPUT elements with the special types AUTHUSER, AUTHSECRET, AUTHLOAD, and AUTHUNLOAD, and a SELECT element with the special type AUTHREALM. Each of these is described below.

Authentication INPUT text TYPEs

Two new TYPE values are defined for text type fields:
AUTHUSER
Indicates that this input element is the username component of a set of authentication credentials.
AUTHSECRET
Indicates that this input element is the secret (password) component of a set of authentication credentials; the PASSWORD value is not used to prevent ambiguity with the existing usage, but AUTHSECRET fields should share the property that values entered in them are not normally displayed (to prevent over-the-shoulder password snooping).

Realm SELECT TYPE Attribute

The SELECT element is extended to allow the attribute TYPE=AUTHREALM; when specified, this indicates that the values of the contained OPTION elements select the realm value with which credentials in the form should be associated.

Authentication INPUT action TYPEs

Two new TYPE values are defined for button type fields:
AUTHLOAD
Equivalent to SUBMIT in that it indicates that the form values are complete; the AUTHUSER, AUTHSECRET, and AUTHREALM values should be loaded into the credentials store for the user agent and associated with the server from which the form was returned.
AUTHUNLOAD
Indicates that the credentials associated with the specified AUTHUSER, AUTHREALM, and server should be removed from the user agent credentials store.

Example

The following shows an authentication form (the HTML column is as proposed, the Example column uses standard HTML to create a normal form with the appearance that approximates those expected for the new elements proposed herein):

HTML Example:
<AUTHFORM>
User Name: <INPUT TYPE=AUTHUSER><BR>
Password:  <INPUT TYPE=AUTHSECRET><BR>
Realm:     <SELECT TYPE=AUTHREALM>
             <OPTION VALUE=READONLY SELECTED>Read Only</OPTION>
             <OPTION VALUE=READWRITE>Read/Write</OPTION>
           </SELECT><BR>
<INPUT TYPE=AUTHLOAD VALUE="Log In">
<INPUT TYPE=AUTHUNLOAD  VALUE="Log Out">
</AUTHFORM>
User Name:
Password:
Realm:

Compatibility and Transition

An earlier draft of this proposal used the existing FORM element (with a new METHOD=AUTH attribute) rather than a new AUTHFORM element; this was changed to avoid the following backward compatibility problem. If a FORM was used, existing user agents rendered the authentication elements as a normal form. This left open the possibility that such a form might be sent to the server as a GET or POST, exposing the credentials. Since AUTHFORM will not be understood by existing software, the various INPUT elements should not be rendered as a form, and this problem does not occur. A similar case might be made for using new elements where this proposal uses types on INPUT elements.

This proposed mechanism could eventually completely replace the generic authentication prompts used today by user agents. In the interim, it is not required that a server know whether or not the user agent understands this new construct. The AUTHFORM can be served either in the body of the 401 Unauthorized response (which user agents should already display), or in a normal unauthenticated page before the application enters the protected realm. During the transition period, when most user agents will not be expected to support the AUTHFORM, application developers can (either conditionally based on User Agent information or not) include text to explain the feature is available only if the user agent supports it. This approach has been demonstrated with numerous new web content technologies, and users generally understand it.

Alternatives

It may well be that the HTML community will decide that the particular extensions proposed here are, for whatever reason, inappropriate. The authors acknowledge that they overload some existing elements in ways that may be seen as too different from the existing definitions. The specific syntax and rules of the approach proposed here are not as important as the quick development of a workable and deployable solution; doing so will substantially improve the security of web applications and users. With this in mind, the authors suggest that the following general characteristics be incorporated into a solution:

Acknowlegement

The authors would like to acknowlege the contributions of Jim Gettys of Compaq Computer Corp. and W3C for asking the hard questions that contributed to the development of the ideas herein.

References

[1] Hypertext Transfer Protocol -- HTTP/1.1 (latest internet draft)

[2] HTTP Authentication: Basic and Digest Access Authentication