Simple Digest Security Scheme

An improved, minimal security scheme for HTTP is proposed. This scheme does not require the use of patented or export restricted technology and is believed to provide the best effective security possible within those constraints. This scheme may be used as a direct replacement for the HTTP/1.0 Basic authentication scheme with minimal modification of clients and servers. The scheme provides for reuse of code in implementing more comprehensive security schemes such as S-HTTP.

During the course of this work I have been greatly assisted by comments from a large number of people especially Alan Schiffman of EIT, Henryk Frystyk of CERN, Dave Raggett at Hewlett Packard and Mike Harvey.

This scheme has been developed with funding from the European Union and CERN.

Goals

The implementation was designed to meet the following goals.

Require minimal implementation effort.
Preserve the major characteristics of the HTTP protocol, especially idempotence.
Must not involve the use of any patented or export restricted technology.
Should be compatible with proposed S-HTTP extensions to the maximum extent possible.
Should provide a secure form of access authentication (i.e. authentication of client by server) Authentication of server by client is not considered.
Should be to the maximum extent possible a direct replacement for the Basic authentication scheme.
The scheme should be secure enough for use communicating between a Digest capable client and a proxy server performing security enhancement. Such a server would provide the full capabilities of S-HTTP and possibly other security enhanced protocols. The Digest authentication scheme should not weaken the security provided by the S-HTTP protocol.

Protocol extensions

The protocol extensions are implemented in modules HTSecure.c and HTSig.c of the CERN library of common code version 3.0Shen1.

Common Message Format

Both requests and replies use the following format:

Method URI HTTP/1.1
Content-Privacy-Domain: Shen
Content-Type: application/http
MAC-Info: time, RSA-MD5, signature, username

Standard HTTP Headers

Standard Body [If present]

Note that there are in effect two headers, both terminated by two consecutive CRLF pairs.

NB The privacy domain Shen is defined by this document. Note that the use of the S-HTTP privacy domain (PKCS-7) is inappropriate since the message is not encapsulated. The domain could equally well be called simple (because the format of the encapsulation is simple), this might lead to confusion with the Spyglass scheme however and so was dropped. This tag might be confusing though since this proposal has little in common with the original Shen proposal.

NB Problems have arisen integrating the username parameter specified by MAC-Info header lines with the HTTP/1.0 authentication mechanism which also allows a username parameter to be specified. To avoid this problem the current software release uses the username specified as part of the authenticate header tag if specified, otherwise the username specified as part of the MAC-Info line is used. This point should be resolved by the security group.

Digest Value Calculations

Key Calculation

The following formula is used to generate the key K,where H(x) stands for the hash value of x and U, P, R stand for the username, password and realm respectively.

K = H (U + '@' + R + ':' P)

Example

The digest key for fred at w3.org using password fredpass is H("fred@w3.org:fredpass")

Message Signature Calculation

The following formula is used to generate the signature S, where H(x) stands for the Hash value of x and M, K stands for the message text

S = H (H(M) + K)

Negotiation

The digest scheme uses the same security negotiation mechanism as HTTP/1.0, i.e. a request is first sent without authentication after which a new connection must be established to communicate the authentication parameters. If the protocol version is specified as HTTP/2.0, however, full negotiation of security and other parameters may be performed according to spec [Issue SHTTP-N].

The digest security scheme is specified using the following line

WWW-Authenticate: Digest realm="realm"

Request

The request is formatted in the common message format described above. Note that the protocol version number should be specified as HTTP/1.1 since the message is not a valid HTTP/1.0 message.

If encryption of the response is to be permitted then a suitable subset of headers from S-HTTP must be found [Issue Encrypt- H]

Reply

A reply may be sent as either a standard HTTP message or as an enhanced message. At present only standard HTTP messages are used. This is because the question of format is as yet incomplete. Considerations include:

Efficency of signature digest generation: The simplest method of digest generation would simply place the message digest in the message header. This has the disadvantage that a signature must be calculated before a message is sent which is unsatisfactory for large documents stored as files since the file would have to be read twice [Option Reply-G-1]. Alternatively the digest could be placed at the very end of the message which would require only the length of the message to be known in advance, since this is already calculated this is not a significant problem. Neverthelesss this significantly deviates from the HTTP model of having all the access data in the header [OptionReply-G-2].
Choice of signature.: The simplest choice of reply signature would be to simply use the shared secret used for access [Option Reply-S-1]. Alternatively some other system might be considered.
Encrytpion: An encryption option could easily be supplied using the shared secret as the basis of a DES key. This could either be used directly [Option Encrypt-K-1] or indirectly [Option Encrypt-K-2]. The latter solution has the advantage of providing less material to allow the system to be cracked. Note however that this would mean that the security of the system would then be dependent on the security of each message, compromise of the encryption key would compromise the access method. Introduction of yet another hash level would solve this problem
Signing of PUT and POST: The current CERN httpd daemon does not support PUT and POST so this issue was not raised. A question arises of the best way to sign large messages. It is probable that these issues are best defered until the status of the HTTP-ng proposal is better known [Issue PUT/POST-Signature].
[Option Encrypt-K-3].

Prototype Implementation

Implementation has been developed which should be used for testing purposes only. The protocol is not fixed at this time and may change. This consists of a modified version of the CERN library of common code, and a modified version of the Daemon and LineMode browser. This implementation currently has the following limitations:

The timestamp is not currently checked.
The only digest algotithm supported is MD5.
Use through proxies has not been tested.
Replies are not signed.

Source code is avaliable from the CERN ftp site.

Daemon Setup

Considerable effort has been made to ensure that the system is as compatible with the standard CERN daemon setup. Implementation of the digest scheme requires modification of the password file format. This modification is upwards compatible with the previous format in the following respects:

An old format password file may be converted to the new format. The format of individual passwords is not modified however.
Unmodified passwords in an upgraded password file may continue to be used with the Basic scheme. Such passwords be used with old and new versions of the CERN server.
Before a password entry may be used with the new scheme it must be reentered. Such password entries may only be used in conjunction with an upgraded server but may be used for either Basic or Digest authentication methods.

To setup the CERN daemon to use the Digest method the password file should be upgraded and the method digest should be specified in the relevant protection files. Use of the basic mechanism is still supported but might be considered for withdrawl or made a compile time option only at a future date because of the security problems associated with it.

Attack Vulnerability

The following attacks have been considered:

Replay: Believed Not Significantly Vulnerable: The timestamp field allows for rejection of replay attacks outside the specified time interval. For most systems this attack does not significantly compromise the vulnerability of the system. Full security against this attack may be achieved through the use of the Anonymous session Id field.
Person-in-the-middle: Believed Not Vulnerable on Request, Vulnerable on Reply: A person inbetween the server and client cannot forge a request for another object or modify the request in any significant manner. It is currently possible for a person in the middle to modify the reply however since these are not currently signed. the protocol could be modified to provide such signatures although this might be a significant implementation overhead.
Analysis of messages: Believed Not Vulnerable: It is beleived that analysis of the messages cannot be used to reveal either the password or information allowing access security to be defeated.
Compromise of the password file by inadequate key length.: Not Vulnerable: No intrinsic limit is set on the length of the password. Thus passwords may be of a length sufficient to defeat attack by exhaustive search.
Analysis of password file leading to compromise of password: Believed Not Vulnerable: The password file does not store the passwords themselves but a site and username specific one way encrypted hash of the password. This means that analysis of the password file at one site does not compromise the password file of another site with a different realm identifier. In addition each password is stored as a function of the username it corresponds to, this provides protection analogous to the UNIX salt, attempts to obtain the password by exhaustive search must be repeated for each entry in the password file.
Compromise of one system leading to compromise of other systems: Believed Not Vulnerable: The password file is specific to a particular realm. Unless the password itself is revealed to the system administration at a site other sites are not compromised. The system does not require the password itself to be revealed, even during password entry (although implementations may do so).
Analysis of password file leading to compromise of security: Vulnerable: The security of this mechanism depends entirely on the security of the password file. If this is read by a third party then access is effectively granted even though the password itself is safe.
Communication of Password: Believed Not Vulnerable: There is no requirement for the password to be communicated by the client to the server at any time. The security of the system depends on the shared secret which is specific to a particular site. Thus there is no requirement to communicate the password which can thus be shared between different sites without the security of one system being compromised by knowledge accessible to the systems administration of another.
Communication of Access Data: System Vulnerability: Security of the system is dependent on the shared secret (key) being communicated between the participants without discovery by a third party. This security scheme does not protect against this vulnerability. Although a number of methods have been considered to avoid this problem it appears that most are reductable to a public key cipher protected by the Diffie Helleman patent. Thus there would be no advantage over the implementation of the full S-HTTP proposal in this regard.

Future Developments

Encryption

A patent restriction free but ITAR controlled variant of the protocol could be produced by employing encryption of messages and replies. Such a system would have to justify its existence as a separate entity from the publick key extensions proposed in S-HTTP. [Issue Encrypt-Viability]

S-Key

Implementation of the S-Key scheme would break the idempotence of the HTTP protocol. In addition problems arise when a client sends multiple requests to the same server which are processed out of order. Another difficulty is that the shared secret can only be used a limited number of times. In a session based protocol such as telnet this is not a problem since logins are infrequent. In the context of HTTP/1.0 this is a major disadvantage since a user may perform many hundred operations a day thus requiring key changes on a weekly or even daily basis.

Concern should also be raised about the applicability of certain hash methods with the S-Key scheme, if the hash function should contain a strange attractor to either a fixed point or a cycle of fixed points and attack might be possible. The mathematical properties of recursive application of hash functions for very high orders is not known. Such a system should certainly be considered with caution. [Issue SKEY-Security]

Despite these disadvantages S-Key has a number of uses in conjunction with hardware identification devices. In addition S-Key would be very suitable for use in conjunction with session oriented HTTP proposals such as HTTP-ng. Here the difficulty of having to regenerate a key on a regular basis would be less of a problem since key challenges would occur much less frequently, once per session rather than once per operation. [Issue SKEY-Reuse]

Dongle interface.

A popular method of providing secure remote access to a computer system involves the use of a hardware device to provide a passkey. This pass key may be a function of the time or of a challenge key sent by the server. Support for use of such devices is clearly desirable, a system necessitating repeated entry of a code for each operation is however undesirable. [Issue Dongle-Interface]