[16744] in Kerberos_V5_Development
Re: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Apr 4 00:44:41 2011
MIME-Version: 1.0
In-Reply-To: <87mxk6myp3.fsf@windlord.stanford.edu>
Date: Sun, 3 Apr 2011 23:44:35 -0500
Message-ID: <BANLkTimqYZg5ytKtR92rJkU4r0jkHYHg4g@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: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 delegationpolicies. Such policies might be as simple as one more bitper-principal (trusted-for-delegation), or quite complex if you wantto reduce attributes across delegation boundaries. One of the nicethings about a model like Smack is that you would be able to constraindelegation in a simple way, requiring just one additional itemper-principal: a label (plus, when you need to create additionallabels, additional Smack rules, but hopefully you can manage to keepthose to a minimum).
> The best way to see this is to consider LDAP as the final destination> service. OpenLDAP, and probably other LDAP implementations, supports> extremely complex access controls with many features, such as making> access contingent on both the authenticating identity and on the values of> other fields in the same object that one is trying to read fields from.> We use those sorts of features here to implement user-chosen visibility.> For example, may of our LDAP ACLs will release data if the corresponding> suVisib attribute is set to stanford, but not if it's set to private;> then, the data is only visible to specific privileged users or> applications.>> If you have other software that uses LDAP to present information to a> user, you now have to duplicate this extremely complex logic in every> single application that may serve users with varying degrees of authorized> access. If you want phone numbers to have user-settable privacy but> always display them to Help Desk staff, for example, everything that> displays phone numbers now has to look up the corresponding visibility> settings and confirm that the current authenticated user has access based> on those settings. If, however, you have delegated credentials, you can> set the ACLs once on the LDAP servers and then everything just inherits> them.
Oh, this is a very good example. I like it a lot, and I'll probably steal it :)
In the example I've used most often in the past (NFS), impersonationis still used, but without credential delegation: you just trust theservice to impersonate anyone. This applies to LDAP too!
> The same issues do apply to services other than LDAP, in other ways, but> they're the most obvious with LDAP.
I think it's the same problem in all cases. Not using credentialdelegation does not mean not using impersonation.
>> Right, quite simple. BTW, do we want to be able to gss_store_cred()>> impersonation credentials? I believe some will. E.g., if you need to>> use secure NFS, AFS, ... as the client, then you have no way to pass the>> desired credential handle to the NFS or AFS client. Being able to>> create a PAG or keyring, or whatever, then store the credential there,>> where the NFS or AFS client will find it, is a very good thing. Where>> the impersonation credential is a Kerberos one this is already taken>> care of. For other mechs it'll be something to think about.>> Yes. This is required to implement things like a web-based front-end to> AFS. It is one of the main places we use delegation right now.
Good to know.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
