- From: Phillip M. Hallam-Baker <hallam@dxal18.cern.ch>
- Date: Mon, 20 Mar 1995 16:53:28 +0900
- To: Dave Kristol <dmk@allegra.att.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: hallam@dxal18.cern.ch
>1) Should the server use the header's "uri" value when it calculates A2?
No, the value used must be the one given in the authorisation line. The other
value may get changed by intermediate proxies.
>2) Should the server compare the header's "uri" against the URI in the
>request line?
Yes.
>3) If yes to (2), should the comparison occur before or after the various
>MD5 checks?
Dosen't matter.
> > The specified URI and the digested URI need not be the same, merely
> > `equivalent'. This is a hard concept to define though.
>But if you can't define it, I can't implement it! ("You" is meant to be
>generic, not an attack on Phill.)
It can't be defined for all sites in the RFC. An indvidual site should have no
difficulty determining what their policy is however. then it is a matter for
server designers to be smart and work out how to be very flexible.
>All of which suggests the need for some kind of canonical agreed-to
>version of a URL. Otherwise, if there are N ways to describe the
>document, there are N(N-2)/2 comparisons to do, and the server may
>not know all the mappings that produce all N versions.
No, the server simply needs a set of translation rules for the URL. This should
be the complete set of translation rules which it has knowledge of. The URL is
then translated according to these rules and compared to the cannonical form of
the header URL.
MASSIVE KLUDGE ==>>
Sounds difficult? Not really, very few people have translating proxies
and those who do can probably perform the authentication at the first proxy and
attach a secondary authentication. The sort of situations where this would be
used would be a main server with an auilliary backup such as an intelligent
search engine which is only occasionaly referred to.
In other words this is pretty much a theoretical issue at this moment.
But for a very limited number of people it is not. That is why the specification
is the way it is.
Its worth pointing out that in the original specification the URI was
not even present...
>I think I understand the threat you describe, but I'm not sure I reach
>the same conclusions. First, Alice would certainly be entitled to read
>the (mailbox) information. The real problem is that sensitive
>information, as you say, is passed en-clair.
This is true but unhelpfull...
The problem is not just that the information is passed en-clair. Mallet is able
to bypass the authentication system so that he has greater access than that of a
pure passive lisner.
Personally I would prefer to encrypt the content using the shared secret
(modified in some manner) and DES or IDEA. I did think of suggesting this at the
time but then of course we are into massive ITAR problems :-( But no patent
problems :-)
We should probably have a bridge note written since S-HTTP has lots of shared
secret mechanisms. Since we now have a shared secret we should employ it...
The simplest mode would be to take the shared secret key [MD5 (password,
domain, username)] and XOR it with some random 128 bits. Then use the first 64
bits for the key and the other 64 bits for the IV of the cipher. (PKCS #5). The
random bitstring is needed because one should attempt to limit the quantities of
ciphertext sent under the same key.
Phill.
Received on Monday, 20 March 1995 08:02:18 UTC