Delegation and Moonshot

[Nico Williams]

On Sun, Apr 3, 2011 at 11:44 PM, Nico Williams <nico at cryptonector.com> wrote:
> On Sun, Apr 3, 2011 at 11:23 PM, Russ Allbery <rra at stanford.edu> wrote:
>> Nico Williams <nico at cryptonector.com> writes:
>>> I don't mean to take anything away from this amazing work you've done,
>>> but, credential delegation writ large is simply scary.  Better to design
>>> services that don't require it.  For example, in the particular case you
>>> mention of web gateways to mail services just trust the web service
>>> fully and be done -- incredibly undesirable if the two services are not
>>> run by the same organization, but then, would you really delgate access
>>> to your mailboxes to a party other than the one that runs them?!
>>
>> Having done this for years, it does mostly work, but it has a serious
>> drawback: it requires that you do authorization control at multiple
>> levels.  Properly managed delegation systems can instead allow you to do
>> authorization control only once.
>
> In exchange you get one more thing to manage: credential delegation
> policies.  Such policies might be as simple as one more bit
> per-principal (trusted-for-delegation), or quite complex if you want
> to reduce attributes across delegation boundaries.  [...]

Hmmm, well, if the alternative to delegation is to allow impersonation
without delegation then that still requires managing who's allowed to
impersonate, which makes the above argument not a very good one!

What I want is very fine-grained control regardless of whether I were
relying on credential delegation impersonation without credential
delegation.  It's probably easier to decentralize such policy, but
only in the case of impersonation without credential delegation, since
the KDC needn't be involved in the former but must be involved in the
latter.  Imagine an authorization-data element, to be used in
Authenticators more often than in Tickets, that indicates that the
cname at crealm wants to impersonate some other principal...

Nico
--