W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Digest-MessageDigest doesn't work with proxies

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 1 Mar 96 16:15:47 PST
To: john@math.nwu.edu
Cc: hallam@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960302000833MTP[01.52.00]000000b1-125848
John says:
----------
]
] It always has to go to the origin-server.  Here is a quote from
] from section on Access Authentication from  the HTTP/1.1 spec draft at
]
] 	http://www.w3.org/pub/WWW/Protocols/HTTP/1.1/spec.html
]
]    "Proxies must be completely transparent regarding user
]    agent authentication. That is, they must forward the
]    WWW-Authenticate and Authorization headers untouched, and
]    must not cache the response to a request containing
]    Authorization."

I know that. And this is precisely the section that the caching 
subgroup asked to be modified, which is why I commented about it. 
People wanted to be able to use Basic
just for identification, and still let entities be served form the 
cache.  If Digest is to be a replacement for Basic, it needs to have 
the same capability.

So, if their request is granted, the no-cache requirement will no 
longer be there, and you'll need to at least make a specific 
Digest-related no-cache requirement, Even if it isn't granted you'll 
need to augment that statement with one about proxies not generating 
D-MD and passing D-MDs from origin servers it through untouched.

]
] The problems you are addressing are important and need to be solved.
] But Digest Authentication is not the mechanism to solve those problems.
] It is a very small step in the right direction, intended only to replace
] a misstep, viz.  Basic Authentication.

Would you please read my  whole message instead of just replying to one 
little piece of it , and then rejecting it in it's entirety? There were 
problems pointed out in it even if you didn't want to cache results, 
but just want to use Digest to replace Basic when authenticating to 
proxies or for simple identification to servers that preserves the 
ability to cache.

So: are you going to say that Digest can be used for Proxy-Auth? Basic 
can be, and the HTTP spec (I'll say again) says that challenges and 
credentials are the same for both origin-server and proxy auth.  Both 
facts argue for Digest being able to be used for both purposes.

If you say it can't be, are you going to ask for modifications to the 
HTTP 1.1 spec to eliminate that requirement? If you say it can be used 
for both purposes, then questions in my previous message remain 
unanswered, and I'll claim that what's in the Digest Auth draft is not 
adequate to tell an implementor how to implement when proxies are being 
used, or to describe the security ramifications.

By adding D-MD, Digest already goes beyond just replacing Basic, and 
leads directly to the issues with proxies. But even without D-MD, proxy 
issues still exist and need to be addressed just for Digest to be a 
replacement for Basic.

Paul
Received on Friday, 1 March 1996 16:14:49 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:47 EDT