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

>I read the paragraphs about how the server checks the validity of the
>information to mean that the server uses the header's "uri" value when
>it calculates A2.  Should the server ever compare the "uri" value
>against the URI it actually received as part of the request, too?  If
>so, does it matter whether that comparison comes before or after the
>various MD5 checks?  (I assume if there's a mismatch, the request is
>rejected.  True?)

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 

The specified URI and the digested URI need not be the same, merely 
`equivalent'. This is a hard concept to define though. 

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.


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.

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.


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 :-).


		Phill

Received on Monday, 20 March 1995 02:27:52 UTC