[16750] in Kerberos_V5_Development
Re: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Apr 4 09:20:31 2011
MIME-Version: 1.0
In-Reply-To: <BANLkTimqYZg5ytKtR92rJkU4r0jkHYHg4g@mail.gmail.com>
Date: Mon, 4 Apr 2011 08:20:27 -0500
Message-ID: <BANLkTik7KC4KJ2iV8kRp=EYuXSUdqnRhww@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Russ Allbery <rra@stanford.edu>
Cc: Moonshot community list <moonshot-community@jiscmail.ac.uk>,
krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Sun, Apr 3, 2011 at 11:44 PM, Nico Williams <nico@cryptonector.com> wrote:> On Sun, Apr 3, 2011 at 11:23 PM, Russ Allbery <rra@stanford.edu> wrote:>> Nico Williams <nico@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 impersonationwithout delegation then that still requires managing who's allowed toimpersonate, which makes the above argument not a very good one!
What I want is very fine-grained control regardless of whether I wererelying on credential delegation impersonation without credentialdelegation. It's probably easier to decentralize such policy, butonly in the case of impersonation without credential delegation, sincethe KDC needn't be involved in the former but must be involved in thelatter. Imagine an authorization-data element, to be used inAuthenticators more often than in Tickets, that indicates that thecname@crealm wants to impersonate some other principal...
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
