Delegation and Moonshot

[Nico Williams]

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.  One of the nice
things about a model like Smack is that you would be able to constrain
delegation in a simple way, requiring just one additional item
per-principal: a label (plus, when you need to create additional
labels, additional Smack rules, but hopefully you can manage to keep
those 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), impersonation
is still used, but without credential delegation: you just trust the
service 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 credential
delegation 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
--