[4702] in WWW Security List Archive
Re: SecureID alternatives?
daemon@ATHENA.MIT.EDU (Vin McLellan)
Thu Mar 6 20:49:04 1997
In-Reply-To: <331EDAFE.4487EB71@bell-labs.com>
Date: Thu, 6 Mar 1997 18:13:33 -0500
To: Dave Kristol <dmk@bell-labs.com>
From: 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.
Be that as it may.
DAA is a replacement for HTTP "Basic Authentication" which was
explicitly designed to be only so strong as to not impinge on either patent
rights and export regs (ITAR/EAR, in the US.)
From the rfc: "An important design constraint is that the new
authentication scheme be free of patent and export restrictions."
rfc 2069 is designed to offer multiple authentication options to be
used where, because of political and legal considerations, encryption (SSL
and S-HTTP) devices are not available.
There _are_ a surprising variety of implementations possible under
the rfc: with or without a one-time nonces; with or without a one-time
digests; with or without time-out nonces; etc.
It is also clear that -- since the rfc does not address the
necessary assignment of passwords to the client/users -- the mechanism for
password distribution is left to the system designer. However that is
done, it does not seem unreasonable to suggest that the web server's node
secret (proposed as part of the entity digest in the rfc) might be
distributed to registered users at the same time.
The result, I think, could be a pretty solid mechanism for ongoing
authentication -- without, as I noted earlier, the transborder
complications of encryption.
With the optional second digest, I think rfc 2069 goes considerably
beyond being a mere "drop-in replacement for Basic." You do the authors an
injustice by taking their words so literally. They offer more than they
say.
Surete,
_Vin
Vin McLellan + The Privacy Guild + <vin@shore.net>
53 Nichols St., Chelsea, MA 02150 USA <617> 884-5548
