Re: Digest mess

Before I start commenting, I have to say that at this point I'm
very confused between all the proposals in flight at the same time.  So
if this doesn't make sense in some context, please forgive me.

Scott Lawrence <lawrence@agranat.com> writes:

>JF> John Mallery points out that it would be good to have the response
>JF> status code digested as well.  If it is included here that becomes
>JF> possible (which it wasn't before since proxies change it from
>JF> say 304 to 200).  This header would also eliminate problems of
>JF> proxies canonicalizing headers.
>
>  This would work in terms of preserving the computability of the
>  digest value.  The problem I see with it is that it doesn't really
>  do anything for the security but prevent a denial of service attack
>  (which is unstoppable if the attacker can modify any part of the
>  message anyway).

These two quotes and a few other recent messages imply that we are no
longer considering Digest Authentication to be "a replacement for basic
authentication and nothing more." [-00 draft, 3.1.1].  It now appears
to be targeted (at least by some) as an exportable alternative to SSL
(notwithstanding the fact that SSL can be exported).  If that's really
this group's intent, we need to look at the spec in that light.  As
Roy Fielding pointed out in another note:

>It also fixes the problem that Dave was trying to describe, namely
>that if the values are separate then the recipient would still have
>to compare the received field values against the received values
>inside dheader-content, which would still result in failure if the
>proxy changes them.  (If it didn't compare them, then an attacker
>could simply change the field values without changing the digest
>at all.)

And of course, it is perfectly reasonable for proxys to change certain
headers as they go by, and to respond with a different status code than
the origin server.  If we're going to deliver two sets of the "same"
headers that are not to be normalized into one, we also need to specify
which set of data a client should act on.  (My brain is starting to hurt
already, and I'm only considering 200->304 status code changes!)

The -00 draft acknowledges the exposure of Digest Authentication to
traditional man in the middle attacks, and adds a few interesting
possibilities of its own.  If we're going to positition this as something
more than "a replacement for basic authentication and nothing more",
I'm afraid we've got to analyze and address the whole mess.

Ross Patterson
Sterling Software, Inc.
VM Software Division

Received on Monday, 5 January 1998 11:02:56 UTC