Reduce the effort of verification [LWN.net]

Reduce the effort of verification

Posted Feb 18, 2010 20:55 UTC (Thu) by buchanmilne (guest, #42315)
Parent article: Trust, but verify

For SSH, especially for sites with lots of hosts, it means that users or system administrators don't have to laboriously propagate keys into authorized_keys files on each new system.

I typically avoid this.

In some instances, by using the openssh lpk patch, which allows the user's public keys to be stored in LDAP, and have sshd find them there directly. I have also scripted retrieving the keys from LDAP to a central authorized_keys file (rather than per-user keys files, to adhere to security policies etc.), for either the case where you can't patch sshd, or if you want to provide fail- back in case of some problem reaching LDAP (e.g. failure of firewall or network or similar). In this scenario, host key verification still needs to be addressed, but there is a scalable solution - but it requires DNSSEC. Now that we are seeing DSNSEC deployments, maybe this will become more common.

In other instances, where a decent Kerberos setup is in place, you don't use public/private keys for users at all, but of course Kerberos authentication. There is also a patch in development for OpenSSH to do host verification by Kerberos, from the service principal, so host manual key verification isn't necessary.

Both of these seem to scale better than MonkeySphere, as according to the documentation:

You'll probably only set up Identity Certifiers when you set up the machine. After that, you'll only need to add or remove Identity Certifiers when the roster of admins on the machine changes, or when one of the admins switches OpenPGP keys.

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. And, if they don't know GPG/PGP, I would have to teach them that first ... and unfortunately admins who have never had a GPG/PGP key are all too common these days. In many environments, even the term "ssh public key" had to be explained many times, including to the network security team.

Now, unfortunately, AFAIK neither LPK nor the Kerberos host key verification patches are likely to be merged upstream, as the OpenSSH team doesn't seem to think they are necessary, and probably that they will introduce insecurities.

Of course, the pragmatic view that making it *easier* to implement adequate security is of value seems to have been missed.

(Log in to post comments)

Reduce the effort of verification

Posted Feb 22, 2010 11:13 UTC (Mon) by dkg (subscriber, #55359) [Link]

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.