[cap-talk] Confused Deputy (definitions)

[Ka-Ping Yee]

I've been reading the messages on this thread and thought perhaps
it might be useful to describe the interpretations of the "confused
deputy" concept i've seen here so far, as precisely as i can, and
see if this helps us identify and name these distinct concepts.

1.  Situation:
        At user U's request, entity D wields an authority A.  U does not
        itself have A because A is too big; D has A and wields it in a
        limited fashion upon authenticating U.  However, because the
        security architecture only allows D to make a decision based on
        U's identity, if U's authentication is persistent, D can be fooled
        into misusing A for the wrong purpose (something U didn't want).

    Countermeasure:
        Architectural change -- not a bug in D

        1a. If the architecture allows, the problem can be fixed by
            tightly binding an authenticator to each request.

    Architectural Flaw:
        Ambient authority
        Identity-based access control


2.  Situation:
        At user U's request, entity D wields an authority A.  U does not
        itself have A because A is too big; D has A and wields it in a
        limited fashion upon authenticating U.  U's request also names
        something belonging to U that D is supposed to use (in a
        different way than it uses A).  By naming A instead, U can fool
        D into misusing A (something the provider of A didn't want).

    Countermeasure:
        Architectural change -- not a bug in D

        2a. If the architecture allows, D can query the system to
            determine whether what U has named actually belongs to U
            (but this can be tricky to do reliably).

        2b. Otherwise, there is no possible way for D to make the
            required distinction.  D cannot be fixed.

    Architectural Flaw:
        Separation of designation from authority


3.  Situation:
        At user U's request, entity D wields an authority A.  U does not
        itself have A because A is too big; D has A and wields it in a
        limited fashion upon authenticating U.  However, D fails to
        implement these restrictions in an airtight way, and U can
        exploit a flaw in D to cause D to misuse A (something the
        provider of A didn't want).

    Countermeasure:
        Fix implementation vulnerability in D


Situation 1 seems to fit "Cross-Site Request Forgery" fairly closely;
Situation 2 seems to fit the classic Confused Deputy story fairly
closely; Situation 3 is my attempt to define what Jed described as
"confusion" in the more general sense.


-- ?!ng