[4677] in WWW Security List Archive
Re: SecureID alternatives?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Wed Mar 5 22:15:19 1997
In-Reply-To: <9703041451.AA25311@aleatory>
Date: Wed, 5 Mar 1997 19:29:44 -0500
To: dmk@research.bell-labs.com (Dave Kristol)
From: Vin McLellan <vin@shore.net>
Cc: jch@vasco.com, www-security@ns2.rutgers.edu, tel1dvw@is.ups.com,
aisecur!KClancy@bpd.treas.gov, adam@homeport.org, rgaloppini@tim.it
Errors-To: owner-www-security@ns2.rutgers.edu
Vin McLellan <vin@shore.net> asked:
> > [...]
> > Anyone know about DAA??? I'm intrigued by rfc 2069, which offers
> > Digest Access Authenticaton (DAA) to replace HTTP 1's basic authentication
> > -- particularly it's optional second digest (which would offer a
>continuous
> > authentication, protecting against session hijacking and guaranteeing the
> > integrity of a downloaded html page.)
Dave Kristol <dmk@research.bell-labs.com> responded with a caution:
>I wouldn't put *too* much trust in the second digest. Because a
>man-in-the-middle could replace the digest= field with one of its own,
>the MITM could replace the content and adjust digest=. So this digest
>provides no protection against meddling. It merely assures that the
>content matches the digest. Still, that can be useful, especially for
>PUT/POST, where (assuming *no* meddling) you want to be sure the
>content reaches the server correctly.
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.
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.
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)?
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?
Suerte,
_Vin
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
