mirror of https://github.com/lianthony/NT4.0
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
697 lines
30 KiB
697 lines
30 KiB
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
INTERNET DRAFT Dave Raggett, HP Labs
|
|
|
|
Expires in six months 27th March 1995
|
|
|
|
|
|
|
|
Mediated Digest Authentication
|
|
|
|
|
|
|
|
<draft-ietf-http-mda-00.txt>
|
|
|
|
|
|
|
|
Status of this Memo
|
|
|
|
|
|
|
|
This document is an Internet draft. Internet drafts are working
|
|
|
|
documents of the Internet Engineering Task Force (IETF), its areas
|
|
|
|
and its working groups. Note that other groups may also distribute
|
|
|
|
working information as Internet drafts.
|
|
|
|
|
|
|
|
Internet Drafts are draft documents valid for a maximum of six
|
|
|
|
months and can be updated, replaced or obsoleted by other documents
|
|
|
|
at any time. It is inappropriate to use Internet drafts as reference
|
|
|
|
material or to cite them as other than as "work in progress".
|
|
|
|
|
|
|
|
To learn the current status of any Internet draft please check the
|
|
|
|
"lid-abstracts.txt" listing contained in the Internet drafts shadow
|
|
|
|
directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
|
|
|
|
munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or
|
|
|
|
ftp.isi.edu (US West coast). Further information about the IETF can
|
|
|
|
be found at URL: http://www.cnri.reston.va.us/
|
|
|
|
|
|
|
|
Distribution of this document is unlimited. Please send comments to
|
|
|
|
the HTTP working group of the Internet Engineering Task Force at
|
|
|
|
<[email protected]>. Discussions of the working group are
|
|
|
|
archived at: <URL:http://www.ics.uci.edu/pub/ietf/http>
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
|
|
As the number of commercial services on the world wide web increases
|
|
|
|
rapidly, the need arises for a means for these services to
|
|
|
|
authenticate clients, and vice versa. A simple scheme can be based
|
|
|
|
on keyed hash functions with a shared secret key for each
|
|
|
|
client/server pair. Key management becomes impractical for both
|
|
|
|
clients and servers when the number of participants is scaled up.
|
|
|
|
This document describes a efficient scheme for using mutually
|
|
|
|
trusted third parties to mediate authentication, as a direct
|
|
|
|
extension of the digest access authentication scheme. The scheme is
|
|
|
|
based upon public domain algorithms, and unlike encryption software,
|
|
|
|
isn't subject to export restrictions. The main benefits to users
|
|
|
|
include: avoiding having to enter separate user names and passwords
|
|
|
|
for each service, and an ability to authenticate servers. It is
|
|
|
|
proposed that the mediated digest authentication scheme be included
|
|
|
|
in the proposed HTTP/1.1 specification.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Purpose
|
|
|
|
|
|
|
|
The companion Internet Draft <draft-ietf-http-digest-aa-00.txt> sets
|
|
|
|
|
|
|
|
Dave Raggett Page 1
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
out a scheme for HTTP servers to authenticate clients using keyed
|
|
|
|
hash functions. It is based upon clients and servers sharing a
|
|
|
|
secret key. When the numbers of clients and servers increase
|
|
|
|
rapidly, the scheme becomes cumbersome for both clients and servers
|
|
|
|
to keep track of all the different secret keys needed for each
|
|
|
|
client-server pair. This can be dramatically simplified if
|
|
|
|
authentication is mediated by a relatively small number of third
|
|
|
|
party authentication servers. Clients can get by with a single key
|
|
|
|
shared with an authentication server, rather than a key for each web
|
|
|
|
server. Similarly, web servers need only a single key per
|
|
|
|
authentication server, rather than one for each client.
|
|
|
|
|
|
|
|
This document describes an extension to HTTP 1.0 for servers to list
|
|
|
|
a set of trusted third parties that can act as authentication
|
|
|
|
servers. This is combined with a secure means for clients to forward
|
|
|
|
secret session keys created by the authentication server. This is
|
|
|
|
designed to complement the digest access authentication scheme by
|
|
|
|
providing a secure means for clients and servers to establish fresh
|
|
|
|
keys for each session. It is proposed that the mediated digest
|
|
|
|
authentication scheme be included in the proposed HTTP/1.1
|
|
|
|
specification.
|
|
|
|
|
|
|
|
The proposed digest access authentication scheme allows servers to
|
|
|
|
authenticate clients, but not for clients to authenticate servers.
|
|
|
|
The mediated authentication scheme defined in this document remedies
|
|
|
|
this omission without compromising security.
|
|
|
|
|
|
|
|
This document also specifies the protocol for web clients to request
|
|
|
|
the mediation of a mutually trusted third party authentication
|
|
|
|
server. The protocol uses UDP and keyed hash functions together with
|
|
|
|
the bitwise exclusive-or operator to transfer the session key. It
|
|
|
|
uses the technique first proposed by L. Gong (see references). A
|
|
|
|
major advantage of the scheme is that it uses public domain
|
|
|
|
algorithms and more importantly, isn't subject to the export
|
|
|
|
controls associated with encryption software.
|
|
|
|
|
|
|
|
The mediated digest authentication scheme isn't a complete answer to
|
|
|
|
the need for security on the World Wide Web. This scheme doesn't
|
|
|
|
provide encryption of requests or replies. The intention is simply
|
|
|
|
to provide a means to facilitate secure access authentication, which
|
|
|
|
scales as the number of clients and servers increase rapidly.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Security Protocol Negotiation
|
|
|
|
|
|
|
|
It is useful for a web server to be able to know which security
|
|
|
|
schemes a client is capable of handling. It is recommended that the
|
|
|
|
HTTP extension mechanism proposed by Dave Kristol [2] be used. If
|
|
|
|
the client includes the following header line with the request, then
|
|
|
|
a server can safely assume that the client can handle Mediated
|
|
|
|
Digest authentication.
|
|
|
|
|
|
|
|
Extension: Security/MDA
|
|
|
|
|
|
|
|
Dave Raggett Page 2
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
|
|
|
|
If this proposal is accepted as a required part of the HTTP/1.1
|
|
|
|
specification, then a server may assume Mediated Digest
|
|
|
|
Authentication support when a client identifies itself as HTTP/1.1
|
|
|
|
compliant.
|
|
|
|
|
|
|
|
It is possible that a server may want to require Mediated Digest as
|
|
|
|
its authentication method, even if the server does not know that the
|
|
|
|
client supports it. A client is encouraged to fail gracefully if the
|
|
|
|
server specifies any authorization scheme it cannot handle.
|
|
|
|
|
|
|
|
Note: Mediated Digest Authentication is a strict superset of the
|
|
|
|
companion Digest Access Authentication scheme.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
The Mediated Digest Authentication Protocol
|
|
|
|
|
|
|
|
This protocol describes the messages sent between the HTTP client
|
|
|
|
and the trusted third party being used to mediate authentication.
|
|
|
|
The small size of the messages make it practical to use UDP. Further
|
|
|
|
work is needed to specify how authentication messages are layered on
|
|
|
|
other protocols.
|
|
|
|
|
|
|
|
URI's for Authentication Servers
|
|
|
|
|
|
|
|
This document proposes a new protocol prefix for UDP access to
|
|
|
|
authentication servers. The prefix mdap: stands for the --mediated
|
|
|
|
digest authentication protocol--. Some examples of possible URIs for
|
|
|
|
authentication servers are:
|
|
|
|
|
|
|
|
mdap://zeus.cyberbank.com:1995/retail
|
|
|
|
mdap://zeus.cyberbank.com:1995/trade
|
|
|
|
mdap://dawn.freeworld.org:2010/
|
|
|
|
|
|
|
|
The default UDP port number is yet to be assigned, so it is
|
|
|
|
important for the time being that URI's include an explicit port
|
|
|
|
number. Path names such as --retail-- and --trade-- in the examples,
|
|
|
|
may be used to partition members of an authentication service.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Overall Operation
|
|
|
|
|
|
|
|
The basic sequence of events ...
|
|
|
|
|
|
|
|
1. Client sends document request to HTTP server, attaching a client
|
|
|
|
nonce.
|
|
|
|
|
|
|
|
2. Server responds with "401 Unauthorized" and attaches
|
|
|
|
authentication information, including a list of trusted 3rd
|
|
|
|
parties, and a server nonce.
|
|
|
|
|
|
|
|
3. Client sends authentication request to selected trusted 3rd
|
|
|
|
party.
|
|
|
|
|
|
|
|
Dave Raggett Page 3
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
|
|
|
|
4. The trusted 3rd party authenticates both client and server, then
|
|
|
|
replies with a protected freshly created session key.
|
|
|
|
|
|
|
|
5. Client resends request to HTTP server attaching the protected
|
|
|
|
session key and the authentication information.
|
|
|
|
|
|
|
|
6. Server authorizes the request and returns the requested
|
|
|
|
document. It can optionally include a keyed message digest to
|
|
|
|
allow the client to check message integrity.
|
|
|
|
|
|
|
|
The following sections of this document will describe the proposed
|
|
|
|
extensions to HTTP 1.0, and the message format for the client to
|
|
|
|
communicate with the authentication server. This is followed by an
|
|
|
|
analysis of possible threats and how they are defeated.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Stage 1
|
|
|
|
|
|
|
|
For the first stage, the client generates a value for the nonce Nc
|
|
|
|
which will be used in the authentication of the web server. It is
|
|
|
|
proposed that a new field is added to HTTP to pass this nonce value
|
|
|
|
to the server:
|
|
|
|
|
|
|
|
Nonce: "<client-nonce>"
|
|
|
|
|
|
|
|
Clients may defend their ability to authenticate servers against
|
|
|
|
replay attacks by refusing to reuse nonce values. The nonce should
|
|
|
|
be considered opaque by web servers.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Stage 2
|
|
|
|
|
|
|
|
In stage 2, the web server replies "401 Unauthorized" and includes
|
|
|
|
the WWW-Authenticate header as described in the companion
|
|
|
|
specification for the Digest Access Authentication scheme. If the
|
|
|
|
client shares a secret key with the web server, then authentication
|
|
|
|
can proceed as described in that proposal.
|
|
|
|
|
|
|
|
The server can optionally include one or more Trusted-Party headers.
|
|
|
|
This header is defined by:
|
|
|
|
|
|
|
|
Trusted-Party: uri="<trusted-party>", -- required
|
|
|
|
server-name="<server>", -- required
|
|
|
|
server-mac="<mac-server>" -- required
|
|
|
|
|
|
|
|
|
|
|
|
Where the tagged fields are defined by:
|
|
|
|
|
|
|
|
<trusted-party>
|
|
|
|
This identifies a trusted third party which can be used to
|
|
|
|
mediate authentication. The form of the URI is specified later
|
|
|
|
on in this document.
|
|
|
|
|
|
|
|
Dave Raggett Page 4
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
|
|
|
|
<server-name>
|
|
|
|
This is a character string used by the trusted party to name the
|
|
|
|
web server. The trusted party acting as mediator uses this name
|
|
|
|
to look up the secret values it shares with the web server.
|
|
|
|
|
|
|
|
<server-mac>
|
|
|
|
This is a 128 bit number encoded as 32 lower case hexadecimal
|
|
|
|
digits, starting with the most significant, and ending with the
|
|
|
|
least. It is generated using the following procedure:
|
|
|
|
|
|
|
|
The web server and trusted third party share a secret octet string
|
|
|
|
Ks which can be of arbitrary length. The calculation of the
|
|
|
|
<server-mac> value also involves values supplied with the associated
|
|
|
|
WWW-Authenticate header. These are: <realm> and <nonce> (here after
|
|
|
|
refered to as --server-nonce--. The expression below uses "+" to
|
|
|
|
denote octet string concatenation. The function H is the MD5 message
|
|
|
|
digest algorithm, as specified in RFC1321. It provides a 128 bit
|
|
|
|
hash value for any sequence of octets. Source code in C for MD5
|
|
|
|
Message-Digest algorithm can be found in RFC1321, and is also
|
|
|
|
available free of charge from RSA Data Security, Inc.
|
|
|
|
|
|
|
|
<server-mac> = H(S + R + Nc + Ns + Ks)
|
|
|
|
|
|
|
|
where S = <server-name>, R = <realm>, Nc = <client-nonce>, and Ns =
|
|
|
|
<server-nonce>. The web server needs to cache the <server nonce> for
|
|
|
|
use in decoding subsequent requests from the client.
|
|
|
|
|
|
|
|
------------------------------------------------------------------------------
|
|
|
|
Stage 3
|
|
|
|
|
|
|
|
When the web client receives a "401 Unauthorized" response from a
|
|
|
|
web server, it checks the headers for WWW-Authenticate and
|
|
|
|
Trusted-Party:
|
|
|
|
|
|
|
|
1. If there isn't a WWW-Authenticate header the client should
|
|
|
|
display an appropriate error message to the effect that the user
|
|
|
|
is unauthorized to access this service.
|
|
|
|
|
|
|
|
2. The <realm> is then examined to see if the client already knows
|
|
|
|
of a secret password suitable for use with this server and
|
|
|
|
realm. If so, then authentication proceeds as described with the
|
|
|
|
Digest Access Authentication scheme.
|
|
|
|
|
|
|
|
3. If such a password is unavailable, the client examines any
|
|
|
|
Trusted-Party headers to look for mutually trusted
|
|
|
|
authentication servers. If none are found, the client can ask
|
|
|
|
the user to enter a user name and password for the web server
|
|
|
|
and realm, or for one of the authentication servers listed with
|
|
|
|
the Trusted-Party headers. If the user enters a user name and
|
|
|
|
password for the web server, then Authentication then proceeds
|
|
|
|
as described with the Digest Access Authentication scheme.
|
|
|
|
|
|
|
|
|
|
|
|
Dave Raggett Page 5
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
|
|
|
|
|
|
|
|
4. If a mutually trusted authentication server is found, or the
|
|
|
|
user has enterered a user name and password for an
|
|
|
|
authentication server in the previous step, then the client
|
|
|
|
sends a authentication request to the authentication server, as
|
|
|
|
described below.
|
|
|
|
|
|
|
|
Authentication requests take the following form:
|
|
|
|
|
|
|
|
Authentication Request ::=
|
|
|
|
method, INTEGER [8 bits]
|
|
|
|
version-major, INTEGER [8 bits]
|
|
|
|
version-minor, INTEGER [8 bits]
|
|
|
|
uri STRING [variable]
|
|
|
|
user-name, STRING [variable]
|
|
|
|
server-name, STRING [variable]
|
|
|
|
realm, STRING [variable]
|
|
|
|
client-nonce, STRING [variable]
|
|
|
|
server-nonce, STRING [variable]
|
|
|
|
server-mac, INTEGER [128 bits]
|
|
|
|
client-mac INTEGER [128 bits]
|
|
|
|
|
|
|
|
Each of the fields is defined by:
|
|
|
|
|
|
|
|
method
|
|
|
|
For authentication requests, this is equal to 1.
|
|
|
|
|
|
|
|
version-major
|
|
|
|
The initial version major number is 1.
|
|
|
|
|
|
|
|
version-minor
|
|
|
|
The initial version minor number is 0.
|
|
|
|
|
|
|
|
uri
|
|
|
|
The full URI used to access the authentication server.
|
|
|
|
|
|
|
|
user name
|
|
|
|
This is a character string that allows the authentication server
|
|
|
|
to uniquely identify the user. The client uses the URI for the
|
|
|
|
authentication server to determine which user name to provide.
|
|
|
|
|
|
|
|
server name
|
|
|
|
This is taken from the Trusted-Party header along with the URI
|
|
|
|
to send the authentication request.
|
|
|
|
|
|
|
|
realm
|
|
|
|
This is taken from the WWW-Authenticate header.
|
|
|
|
|
|
|
|
server-nonce
|
|
|
|
This is taken from the <nonce> field in the WWW-Authenticate
|
|
|
|
header.
|
|
|
|
|
|
|
|
client-nonce
|
|
|
|
The client nonce generated in stage 1.
|
|
|
|
|
|
|
|
Dave Raggett Page 6
|
|
|
|
|
|
|
|
Mediated Digest Authentication 28th March 1995
server-mac
This is taken from the <server-mac> field of the Trusted-Party
header.
client-mac
This is computed by the procedure described below.
<client-mac> = H(M + V1 + V2 + L + U + S + R + Nc + Ns + Sm + Ks)
where M = <method>, V1 = <version-major>, V2 = <version-minor>, L =
<uri>, U = <user-name>, S = <server-name>, R = <realm>, Nc =
<client-nonce>, Ns = <server-nonce>, Sm = <server-mac>, and Kc is
the secret key shared by the client and the authentication server.
INTEGERs are sent in network byte order (big-endian order). STRINGs
are sent as null terminated octet sequences.
------------------------------------------------------------------------------
Stage 4
When the authentication server receives a authentication request in
the above format. It uses <user-name> to look up the user's secret
key Kc. This is then used to check the value of <client-mac>. This
provides a check on message integrity and confirms the authenticity
of the client. If this test fails, a NAK message is sent as
response, see later for details.
The next step for the authentication server is to verify the
authenticity of the web server using the information supplied in the
authentication request. If this test fails a NAK message is sent as
a response, see later for details.
The authentication server now computes a random 128 bit unsigned
integer value Ksc for use as a session key. The authenticated
response message is then composed with the following information:
Mediation response ::=
response-code, INTEGER [8 bits]
version-major, INTEGER [8 bits]
version-minor, INTEGER [8 bits]
client-nonce, STRING [variable]
server-key, INTEGER [128 bits]
client-key, INTEGER [128 bits]
server-mac, INTEGER [128 bits]
client-mac INTEGER [128 bits]
The response code is 100. The client nonce should match that of the
request message. Sending messages via UDP reduces latency, but runs
the risk of packet loss. If a response is not received by the client
in a suitable interval, the authentication request message should be
resent. The authentication server may take advantage of a small
cache to speed handling requests, when the response packets are
Dave Raggett Page 7
Mediated Digest Authentication 28th March 1995
lost, otherwise, the server doesn't need to keep any state
information between requests.
The <server-key> is computed as follows:
<server-key> = K xor H(<user name> + <realm> + <server-nonce> + Ks)
Similarly, the <client-key> is computed as follows:
<client-key> = K xor H(<server name> + <realm> + <client-nonce> + Kc)
where Ks is the secret key shared by the web server and the
authentication server. The client reveals the session key with the
computation:
Ksc = <client-key> xor H(<server name> + <realm> + <client-nonce> + Kc)
This relies on the properties of the bitwise exclusive-or operator:
A xor B = B xor A and A xor B xor A = B
The <server-mac> is used to detect attempts to spoof the client. It
is generated by the authentication server as follows:
<server-mac> = H(<uri> + <server-name> + <server-key> + <server-nonce> + Ks + Ksc)
The <server-key> is passed to the web server unchanged in stage 5 as
part of the Session-Key header for the HTTP request message. The
client uses the session key to generate an Authorize header in the
manner specified with the Digest Access Authentication scheme.
The value of <client-mac> is used to check the integrity of the
response and to check the authenticity of the authentication server.
It is computed as follows:
<client-mac> = H(M + V1 + V2 + Nc + Ps + Pc + Sm + Kc + Ksc)
where M is the <response-code>, V1 = <version-major>, V2 =
<version-minor>, Nc = <client-nonce>, Ps = <server-key>, Pc =
<client-key>, Sm = <server-mac>, Kc is the secret key shared by
the client and the authentication server, and Ksc is the new session
key. Using Ksc in the integrity check increases the difficulty in
analysing messages for information about the keys.
Negative responses from the authentication server take the form:
Mediation Request ::=
response code, INTEGER [8 bits]
version-major, INTEGER [8 bits]
version-minor, INTEGER [8 bits]
Where the response code is 200 for the case when the authentication
request fails the integrity check or the user name is unknown. The
Dave Raggett Page 8
Mediated Digest Authentication 28th March 1995
response code is 201 for the case when the web server fails the
authentication check.
------------------------------------------------------------------------------
Stage 5
After the client has sent the authentication request to the
authentication server, and received a reply, the client resends the
document request to the web server with the authentication
information attached. This information is included in two HTTP
request headers:
* the Authorization header as defined by the Digest Access
Authentication scheme. This is generated using the session key
created by the authentication server as the password for the
computation of the <digest> and <message-digest> fields.
* the Session-Key header which is used to transfer the session key
(or password) to the server. The session key is strongly
protected against disclosure.
The Session-key takes the form:
Session-key: uri="<trusted-party>", -- required
server-name="<server-name>", -- required
session-key="<session-key>" -- required
session-mac="<session-mac>" -- required
Where the tagged fields are defined by:
<trusted-party>
This identifies a trusted third party which was used to mediate
authentication. The form of the URI is specified later on in
this document.
<server-name>
This is a character string used by the trusted party to name the
web server.
<session-key>
This is a 128 bit number encoded as 32 lower case hexadecimal
digits, starting with the least significant. It is generated by
the authentication server.
<session-mac>
This is used to check the integrity of the Session-Key header,
and is essential for detecting spoofed clients. It has the
exactly same definition as the <server-mac> field in the
response message from the authentication server.
The session key created by authentication server is a randomly
chosen 128 bit unsigned integer Ksc. The web server reveals this
Dave Raggett Page 9
Mediated Digest Authentication 28th March 1995
value by the following calculation.
Ksc = <server-key> xor H(<username> + <realm> + <server-nonce> + Ks)
Before the above calculation can be performed, the web server needs
to use <trusted-party> and <server-name> to determine which secret
octet string to use for Ks. The values of <user-name>, <realm> and
<server-nonce> are supplied with the associated Authorize header as
defined by the Digest Access Authentication scheme. The client's IP
address and the value of <server-nonce> areused by the web server to
cache the value of Ksc for use in subsequent requests by the client.
The session key Ksc is then used as the password for processing
information supplied with the associated Authorize header.
Subsequent requests by the client use the same server nonce and
session key.
After a suitable interval, the server should purge the entry from
the cache. The Digest Access Authentication scheme describes the
server response when the nonce value is stale (i.e. it is no longer
held in the cache of fresh nonce values). Web servers are
recommended to use the client's IP address together with the server
nonce value to identify cache entries.
------------------------------------------------------------------------------
Stage 6
The response sent by the web server may be optionally protected by a
keyed message digest. The format for this is defined in the
companion Digest Access Authentication scheme. It is recommended
that, where practical, the message digest is included to allow
clients to check message integrity. Clients, should provide a clear
indication to the user that the response is protected by such a
message digest.
------------------------------------------------------------------------------
Threat Analysis
Disclosure of Secret Keys
If the user is responsible for keeping track of multiple passwords,
the risk of accidental disclosure is greatly magnified - e.g. most
people will have to write the passwords down somewhere. An
additional problem is that passwords will need to be quite short in
length. This follows since otherwise people won't be able to
remember them, furthermore, long passwords are difficult to type
without errors.
The mediated digest authentication scheme circumvents these problems
by minimizing the need for user to enter passwords. There is no need
to keep track of user names and passwords for each web service that
the user subscribes to. The password of the authentication server
only needs to be entered once. It is therefore practical to use much
Dave Raggett Page 10
Mediated Digest Authentication 28th March 1995
longer password strings.
The mechanism for passing session keys provides several levels of
protection. The hash value is dependent on the web server's secret
key. The nonce and the random lower 64 bits of M combine to make it
extremely unlikely that anyone could ever deduce the server's secret
key from analysis of HTTP and MDAP messages.
The chances of being able to deduce the client's secret key are also
very remote. The nonce, and message id complicate anaylsis of these
messages.
Replay Attacks
The limited lifetime of the nonce and session key limit the
opportunity for replay attacks. Replaying an HTTP request while the
nonce is still fresh will allow the enemy to see the document again,
but what can be gained from this? If it can replay a request, it can
easily record the document the first time around. If the HTTP
transaction has important side-effects, such as placing an order,
then the web server should refuse to allow the nonce to be reused
for subsequent requests. This will force authentication on every
such request. If an authentication request to an authentication
server is replayed no new information is obtained.
Spoofing Attacks
Web clients authenticate the authentication server using the keyed
message digest for the response from the authentication server. The
authentication server directly authenticates both the web client and
the web server. The web client is therefore safe against spoofing by
one or other of the authentication server and the web server.
Similarly, the authentication server is safe against spoofing of
either the web client or the web server. If just the web client is
spoofed, it will be detected by both the authentication server and
the web server. If both the web client and the authentication server
are spoofed, what then? The web server will detect a damaged session
key and hence will refuse requests from the web client.
Denial of Service Attacks
There is not much that can be done about this, given the current
nature of the Internet. This an area that needs to be considered for
the next generation of Internet protocols.
------------------------------------------------------------------------------
Acknowledgements
I am grateful for the many supportive conversations I have had with
Wembo Mao of Hewlett Packard Laboratories. Without Wembo's support,
I would never have reached the point of being able to write this
specification.
Dave Raggett Page 11
Mediated Digest Authentication 28th March 1995
------------------------------------------------------------------------------
References
1. J. L. Hostetler, J. Franks, P. Hallam-Baker, A. Luotonen,
L. C. Stewart, Internet Draft: "A Proposed Extension to HTTP: Digest
Access Authentication", draft-ietf-http-digest-aa-00.txt, March 1995.
2. L. Gong, "Using One-way functions for authentication"
Computer Communications Review, 19(5):8-11, 1989
3. R. Rivest, "The MD5 Message-Digest Algorithm", RFC1321, April 1992.
4. T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen.
"Hypertext Transfer Protocol -- HTTP/1.0",
Internet Draft: <URL: http://ds.internic.net/internet-drafts/
draft-fielding-http-spec-01.txt>, December 1994.
5. D. Kristol. "A Proposed Extension Mechanism for HTTP"
<URL: http://www.research.att.com/~dmk/extend.txt>, December 1994.
------------------------------------------------------------------------------
Author's Address
Dave Raggett
email: <[email protected]>
<URL: http://www.hpl.hp.co.uk/people/dsr>
Hewlett Packard Laboratories,
Filton Road
Stoke Gifford,
Bristol BS12 9QZ
United Kingdom
Dave Raggett Page 12
|