Security Requirements for HTTP

For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport. [[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. See: http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html ]] [[ NTLM (shudder) was brought up in the WG a few times in the discussion of the -00 draft. Should we add a section on it? See.. http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html ]]

[[ JH: I am not convinced that this subsection properly belongs in this overall section in that "HTTP+HTML Form based authentication" <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> is not properly a part of HTTP itself. Rather, it is a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies (nominally )). Perhaps this section should be should be retitled "HTTP Authentication". Note: The httpstate WG was recently chartered to develop a successor to . See.. http://www.ietf.org/dyn/wg/charter/httpstate-charter.html ]] Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described loosely in section 10 of "HTTP State Management Mechanism" . The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was later updated , but the newer version is not widely implemented. Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those properties introduce serious security trade-offs. HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases user reliance on the appearance of the interface. Many users do not understand the construction of URIs , or their presentation in common clients . As a result, forms are extremely vulnerable to spoofing. HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content in all cases (credentials are not differentiated in the protocol). Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it is clear that some form creators do not use this facility when they should. The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request; this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the data. HTML forms and cookies provide flexible ways of ending a session from the client. HTML forms require an HTML rendering engine for which many protocols have no use.

HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" , which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, logout capabilities, or interoperable internationalization.

Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement, but not at all secure unless used over a secure transport. Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, but there is no standard method of doing so. Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.

In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport. Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation experience has shown that in some cases, especially those involving large requests or responses such as streams, the message integrity mode is impractical because it requires servers to analyze the full request before determining whether the client knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed. Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk consisting of a few million passwords for most users. Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string . Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common method of storing passwords for use with Forms and Cookies. Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks. Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.

Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers, TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates in TLS can be rooted in public trust anchors or can be based on local trust anchors.

There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are bound to transport layer connections.

Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO GSSAPI . In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols). In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets traveling along the network can be read, modified, and inserted at will. Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization, server sending authentication data in WWW-Authenticate) to complete. Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication service might be a barrier to deployment.

[[ See.. http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt http://www.ietf.org/id/draft-hammer-oauth-10.txt ]]

Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more than a sophisticated application of forms and cookies. All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization efforts in progress, as usual.

Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination of standard and vendor-produced specifications, some of which may be obsoleted at any time without any documented change control procedures. These protocols usually don't have much in common with the Architecture of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based application protocols. [[ This section could really use a good definition of "Web Services" to differentiate it from REST. See.. http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html ]]

In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping by TLS. It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable and does not address that weakness.