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
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.
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
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.
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
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
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
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
Digest Value Calculations
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)
The digest key for fred at w3.org using password
fredpass is H("email@example.com: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
S = H (H(M) + K)
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"
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]
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.
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].
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.
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.
The following attacks have been considered:
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.
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
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
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.
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]
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]
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