Reduce the effort of verification
Posted Feb 22, 2010 11:13 UTC (Mon) by dkg
In reply to: Reduce the effort of verification
Parent article: Trust, but verify
buchanmilne, the solutions you outline (LDAP, kerberos) do work well for single-authority enterprise-type situations, and it's not unreasonable to use them there, if you're willing to accept the tradeoffs associated with shared-secret schemes (e.g. suboptimal passwords, users reusing them insecurely with outside services, etc). (though as you say, LPK only identifies users to hosts, and not vice versa). But as soon as you're dealing with a distributed identity model (where no single central authority is accepted for all entities), LDAP and krb5 are less useful as authentication services.
For example, imagine company A needs to contract with company B to do some work on company A's equipment. Either each worker from company B now needs a separate authentication credential with company A (and how do you establish those credentials?) or company A's LDAP or krb5 services need to declare cross-domain trust on company B's LDAP or krb5 services (assuming that A and B both run compatible authentication services. And Company B's LDAP or krb5 services need to be offered on the public network, or at least be accessible to company A's equipment. These are do-able, but non-trivial operations.
It turns out that monkeysphere can handle all of these cases, scaling cleanly, and even works well in the sole enterprise model you describe. You wrote:
So, when a new admin joins a team, another admin has to log in to all servers and run a command to authorize the new admin as a "Identity Certifier". This is exactly the kind of work duplication I have tried to avoid by using LPK and Kerberos.
You're responding to a description of one way to use the monkeysphere (and it's a useful method in a loose confederation of affiliated machines). In the enterprise approach, you'd simply create a company OpenPGP certifying key, and add it as the identity certifier for all your hosts.
Then, you have three options for dealing with a team of admins in a larger enterprise:
- You could give each admin access to the central certifying key, and let them certify users from the trusted root,
- You could create a certification-capable subkey of the master for each member of the admin team, and let them each control their own certifying subkey, or
- You could issue trust signatures over the personal OpenPGP keys of every member of the admin team, and let them certify people individually
The latter two options give you the ability to block bad certifications if an admin turns rogue, without ever having to touch the hosts that rely on this certification.
And you don't even need to run your own authentication servers to do this -- revocation and re-keying can be handled by the existing global HKP network (though it's easy to run your own HKP server if you do want to keep things all in-house).
Given this infrastructure, how do you handle the company A/company B scenario above? Company A's OpenPGP certifying authority makes a trust signature on Company B's certifying authority, limited to only cover certifications in company B's domain. All existing infrastructure remains otherwise in place.
Note also that monkeysphere works without any patches to OpenSSH, and with any reasonably-modern version.
to post comments)