Subject: Digest protection spaces

From: Jim Luther <[email-masked]>
Date: Tue, 6 May 2003 17:04:02 -0700

rfc2617, section 3.2.1, when describing the domain directive for a 
digest-challenge says, "The client can use this list to determine the 
set of URIs for which the same authentication information may be sent: 
any URI that has a URI in this list as a prefix (after both have been 
made absolute) may be assumed to be in the same protection space. If 
this directive is omitted or its value is empty, the client should 
assume that the protection space consists of all URIs on the responding 
server."

Does this mean that if a server has multiple protection spaces, they 
cannot be nested? For example, if a server had a hierarchy of abs_paths 
like this:

"/Users"
|_____________
|             |
"/Users/Bob"  "/Users/Public"
|
"/Users/Bob/Pictures"

Can "/Users" be in one protection space, and "/Users/Bob" be in another 
protection space?

One implementation I've seen assumes the protection space for "/Users" 
includes "/Users", "/Users/Bob", "/Users/Public" and 
"/Users/Bob/Pictures", and that accessing anything below "/Users" with 
those credentials won't generate a challenge unless the server wants to 
update the credentials for that protection space.

Another implementation I've seen assumes "/Users/Bob" can be in a 
different protection space than "/Users". For example, if 
authentication credentials are known for both "/Users" and 
"/Users/Bob", the "/Users" credentials could be used for "/Users" and 
"/Users/Public" while the "/Users/Bob" credentials must be used for 
"/Users/Bob" and "/Users/Bob/Pictures" (i.e., the "/Users" credentials 
won't work for "/Users/Bob" and "/Users/Bob/Pictures").

Which implementation is correct?

Jim Luther

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 7 May 2003 10:26:49 +0200

Am Mittwoch, 07.05.03, um 02:04 Uhr (Europe/Berlin) schrieb Jim Luther:

> assume that the protection space consists of all URIs on the 
> responding server."
>
> cannot be nested? For example, if a server had a hierarchy of 
> abs_paths like this:

IMO that does not forbid nested protection spaces. There is just a 
security implication
that "inner" spaces will see authentication header from "outer" ones, 
since clients
can be expected to send those to all descendants of the outer 
protection space.

> Can "/Users" be in one protection space, and "/Users/Bob" be in 
> another protection space?
>
> those credentials won't generate a challenge unless the server wants 
> to update the credentials for that protection space.
>

I assume the second one will use credentials from "/Users" also for 
"/Users/Bob" until it
is separately challenged there. So this seems to be the best 
implementation.

The first one, as you described it, will probably also work (it handles 
new challenges), but
alternating accesses to "/Users" and /Users/Bob" URIs will each trigger 
a new challenge.

As for existing implementations: I assume that a lot of implementations 
behave like
the first. So in case you can design your server that it avoids nested 
spaces, that seems
like a good choice. But then you probably wouldn't have send your 
questions in the first
place, I assume. ;)

Regards, Stefan