Delegation and Moonshot

[Russ Allbery]

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.

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.

The same issues do apply to services other than LDAP, in other ways, but
they're the most obvious with LDAP.

> 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.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>