[4692] in WWW Security List Archive
Re: SecureID alternatives?
daemon@ATHENA.MIT.EDU (Dave Kristol)
Thu Mar 6 13:16:08 1997
Date: Thu, 06 Mar 1997 09:55:58 -0500
From: Dave Kristol <dmk@bell-labs.com>
To: Vin McLellan <vin@shore.net>
Cc: www-security@ns2.rutgers.edu
Errors-To: owner-www-security@ns2.rutgers.edu
Vin McLellan wrote:
> [discussing Digest Authentication and MiTM attacks...]
>
> I knew there are a number of MiTM attacks possible, but I didn't
> think actually replacing the entity digest (ie, spoofing the server) is one
> of them -- at least, not if it is known that the server uses DAA. I
> thought the MiTM scams might try to erase the digest, or switch to basic,
> or screw with the headers to cause a Denial of Service, but I thought the
> message digest relatively secure.
>
> Actually, rfc 2069 seems to allow for an amazing number of
> alternative nonce and/or digest implementations (which, in any given
> environment, would have to be established by common expectations at both
> ends) so maybe I'm missing something.
It sounds like you're reading too much into the spec, or haven't read it at all.
DAA is meant to be a *more* (but certainly not *highly*) secure drop-in
replacement for Basic Authentication.
>
> In any case, if there is a prior (or out of band) distribution of,
> say, the server's secret -- which would be factored into the entity digest,
> as per 2069 -- then the digest would verify the integrity of the download
> absolutely.
The main use for the entity digest is to assure the integrity of the entity (and
remember it can be used either server->client or client->server). It was never
meant to assure authenticity of the entity. That's what SSL and S-HTTP are for.
>
> It did strike me that if the message (entity) digest had been
> designed to include the client's password (securely submitted to the server
> in the initial MD5 authentication exchange) it would be vastly more secure.
> OTOH, given that most of the implementations will require a prior agreement
> between all the participants on an acceptable format, why not just do a
> digital signature on the digest before it is transmitted from the server
> (or the client)?
Right now the degree of coordination between the client and server is a username
and password. Indeed, because of the nature of the DAA challenge/response, the
server might not actually *know* the password (secret), only a hash of it and
other things. So there might be *no* shared secret with which you can key a hash
in either direction.
>
> The content could still be read by the various national
> intelligence agencies (who now seem to determine which privacy technologies
> are accessible to everyone _except_ the crooks, the terrorists, and the
> infowar commandos) but the integrity of the "digested" message could be
> assured. Come to think of it, I don't understand why a digital sig on the
> digest isn't an option in the rfc. Anyone know?
That capability would be well beyond the intended aims of the RFC, namely drop-in
replacement for Basic. This is from the Purpose section:
The Digest Access Authentication scheme is not intended to be a
complete answer to the need for security in the World Wide Web. This
scheme provides no encryption of object content. The intent is simply
to create a weak access authentication method which avoids the most
serious flaws of Basic authentication.
Dave Kristol
