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

Digest-MessageDigest doesn't work with proxies

From: Paul Leach <paulle@microsoft.com>
Date: Fri, 1 Mar 96 14:05:33 PST
To: john@math.nwu.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960301215917MTP[01.52.00]000000b1-125422
John said:
----------
] > The problem is, this is broken when a proxy is involved.  I don't care
] > if you enhance the section along the lines of my suggestions, but it
] > has to work when proxies are involved, otherwise huge numbers of
] > clients can't use digest auth -- perhaps even the majority of users in
] > the near future.
] >
]
] Are you saying it is broken for end-to-end transactions when the data
] passes through proxies?  If so why?  Or is it just that it doesn't
] handle proxy authentication?

It's not just that it doesn't handle proxy authentication. The most 
obvious problem is that it isn't explained how to do digest auth when 
there is a proxy in the middle.

I can't give a complete answer to the "why" question easily without
knowing whether Digest Auth can be used with Proxy-Auth* headers, but
let me see if I can at least present a convincing argument that 
operation of Digest Auth with proxies with or without Proxy-Auth* isn't 
trivial to understand from the current draft, and so needs some explicit
explanation.

Consider: if the client does a GET and the proxy serves it from the cache,
where does the "nonce" come from that is needed to compute and
check <message-digest> -- cached data, the proxy's nonce from
proxy-auth, or does the proxy have to always go to the origin-server?

Which user name, realm, and password are used to check the
<message-digest>: the one for the proxy (if Proxy-Auth* are being used)
or the one from the origin-server?  If it's the one from the origin-server,
then the proxy will have to keep some new information that it wouldn't
have had to keep if it weren't using digest auth -- that needs be be 
explained. If it's not, then it must be made clear that there is no 
guarantee that the proxy didn't munge the entity-body, only that it 
wasn't munged in between the proxy and the client.

If a proxy has a cached resource because it was fetched by user X, and 
user Y asks for the same resource, how does the proxy get a
<message-digest> computed with Y's username and password? Does it go to 
the origin-server, or does it use Y's proxy username and password to 
compute <message-digest>.

Can both oriigin-server and proxy server add Digest-MessageDigest 
headers? If so, how does the client tell which is which?

Does a proxy pass through the user identity to the origin-server, or 
authenticate itself to the origin-server, or both?  How does a client 
authenticate itself to both proxy and origin-server with Digest Auth?

The simplest fix I can think of is:
a.  to require that requests to proxies that carry digest auth in 
Authorization headers must have Pragma: no-cache or
Cache-Control: no-cache.
b. state that Proxy-Auth* is completely independent of origin-server
auth (clients can get both challenges in a single response, and need
to include both credentials in the retry of the request).
c. State that proxies only  add D-MD on responses served from the cache 
(which by rule a will never be in response to requests with 
Authorization: Digest in them).
d. State that proxy supplied D-MD only guarantees that noone munged
entirty-body between the client and proxy, but that the proxy could have
(i.e., no end-to-end guarantee).

This fix has the (big) disadvantage that it doesn't allow end-to-end 
authenticated requests to be served from cache. The caching subgroup 
made a request for a change to the HTTP spec specifically to allow it, 
so they thought it was important.  But at least if we can agree at this 
level, we can worry about making it more efficient later.  As it is, I 
don't think proxy implementors or clients would know what to do.

Paul
Received on Friday, 1 March 1996 14:05:52 EST

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