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

Re: More KeyedDigest... Re: another Digest Access Authentication question

From: Dave Kristol <dmk@allegra.att.com>
Date: Mon, 20 Mar 95 10:10:01 EST
Message-Id: <9503201508.AA29132@hplb.hpl.hp.com>
To: hallam@dxal18.cern.ch, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
[Has the "Digest" authentication scheme become "KeyedDigest"?]

I previously asked (less succinctly):
1) Should the server use the header's "uri" value when it calculates A2?
2) Should the server compare the header's "uri" against the URI in the
request line?
3) If yes to (2), should the comparison occur before or after the various
MD5 checks?

"Phillip M. Hallam-Baker" <hallam@dxal18.cern.ch> responded:

  > The order of performing checks is undefined. This is essential since in 
  > the ideal case the various parts of the header would be processed in
  > parallel
Fair enough, but what are the answers to (1) and (2)?
  > 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.)

  > The URI specified to the server may potentially be very different from the 
  > initial URI. The server may have caused multiple redirects en route. The initial 
  > URI may have been a URN and been resolved through a proxy resolver. Provided the 
  > server is satisfied that the names are equivalent it can release the page.

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.
  > There is a serious definciency in the security of a system using KeyedDigest 
  > without encryption. It involves use of a trojan page.
  > Alice requests a page of text from Bob, because Bob is a suspicious so and so
  > Bob requires he to identify herself.
  > Alice requests a page of text from Mallet, this has a link to Alice's email
  > stored on Bobs server hiden under the title "Secrets".
  > Alice follows the `secrets' link, the client automatically reusung the same 
  > password information as before and is suprised to discover her own email.
  > Mallet who has been tapping the link sells the information to one of the less 
  > scrupulous chat shows.
  > The problem is that anchors are not validated and suposedly confidential 
  > information is passed en-clair. A more significant problem arises if the 
  > KeyedDigest scheme is seen as an authentication service for payments.

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.  Note that Mallet is
unable to get the information himself and must set up a Trojan page to
get it.  Had Bob secured the information itself, Mallet would have
achieved nothing.  Mallet had to tap the link, and we already know if
he can do that there's lots of mischief he can make.  So I don't see the
problem with unsecured anchors.  The [Keyed]Digest authentication
successfully required Alice to identify herself, as it was supposed to.
  > There might be some milage in specifying the conditions under which a link 
  > should be followed automatically and under which it should not. In particular:
  > 1) A link from an unsecured domain to a secured domain must always result in a 
  > request for authority.
  > 2) A link from a secured domain to a different secured domain should result in a 
  > request for authority in the first instance and may result in a request for 
  > subsequent instances.
  > 3) A link from a secured domain to itself may result in a request for authority.
But a client doesn't necessarily know a priori which domains are secure
and which are not (particularly when going to a new domain).  And the
server doesn't know the predecessor link (if any!) that resulted in a
request's reaching it.  And even if it did, it wouldn't know whether
that the predecessor document was in a secured domain if that document
came from a different server.  So who's going to make the determination
that a security transition occurred?
  > In case (2) the request for authority should provide an option to grant 
  > authority for all future operations of like type.
  > Alternatively a client may permit these options to be overidden in a 
  > configuration language.
  > The word Domain is used instead of server. This is beacuse a single server may 
  > have multiple areas with different securities. Mallet and Alice may be on the 
  > same machine (In fact they are, Alice, Bob and Mallet all have accounts on
  > wit.w3.org :-).

Dave Kristol
Received on Monday, 20 March 1995 07:24:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:13 UTC