Slashdot Mirror
Draft IETF Standard for SSH Key Management Released
A few months ago, Tatu Ylonen (creator of SSH 1.x) declared that lax key management was hazardous. Now there's work being done on a standard for automated key management. hypnosec sent in the news; quoting Parity News on the content of the draft: "It presents a process that would allow for moving of already issued keys to protected location, removal of unused keys, key rotation, providing rights of what can be done with the keys and establishing an approval process for issue of new keys."
There's a non-WG mailing list; the final version of the standard is expected in October.
Given the fact that this document is a 'best practices' sort of thing rather than actually defining some sort of protocol, I find the venue of an RFC (even TFS incorrectly marks this sort of thing as a 'standard) questionable.
If they were looking for a techncial solution to actually enforce some of what is prescribed, basically it's describing the precise sorts of things x509 has baked in. Expiration rules to force examination of things like need-to know or even continued employment. Keys having to be blessed by an organizational authority rather than empowering each indivdiual user. Certificate revocation.
Basically, ssh *should* have embraced x509 as a PKI standard. The biggest failing of x509 is the CA system lacking a facility to limit scope of particular CAs leading to implementations shipping with a default set of free-for-all CA certificates. So long as ssh infrastructure doesn't pre-ship with any CA certs until the target organization adds one, that one flaw is mitigated severely.
XML is like violence. If it doesn't solve the problem, use more.
Tatu Ylonen (creator of SSH 1.x)
Ylönen.
There is SSSD for that:
http://www.ohjeah.net/2011/06/09/linux-ssh-pam-ldap-sssd-2008-r2-ad-deployment/
The SSSD is intended to provide several key feature enhancements to Fedora. The first and most visible will be the addition of offline caching for network credentials. Authentication through the SSSD will potentially allow LDAP, NIS, and FreeIPA services to provide an offline mode, to ease the use of centrally managing laptop users.
The LDAP features will also add support for connection pooling. All communication to the ldap server will happen over a single persistent connection, reducing the overhead of opening a new socket for each request. The SSSD will also add support for multiple LDAP/NIS domains. It will be possible to connect to two or more LDAP/NIS servers acting as separate user namespaces.
It is originally a Fedora project but has been ported to most other distro's.
In combination with FreeIPA it is even better.
Why reinvent the wheel :-%
https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/user-keys.html
5.3. Managing Public SSH Keys for Users
OpenSSH uses public-private key pairs to authenticate users. A user attempts to access some network resource and presents its key pair. The first time the user authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the user's public key in an authorized_keys file. Any time that the user attempts to access the resource again, the machine simply checks its authorized_keys file and then grants access automatically to approved users.
There are a couple of problems with this system:
SSH keys have to be distributed manually and separately to all machines in an environment.
Administrators have to approve user keys to add them to the configuration, but it is difficult to verify either the user or key issuer properly, which can create security problems.
On Fedora, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys. Because SSSD can use FreeIPA as one of its identity information providers, FreeIPA provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying user SSH keys.
This is an Internet Draft. Internet Drafts are the working documents of the IETF - some become standards most don't.
The IETF allows anyone to publish an Internet Draft. This is an 'individual draft' - produced by an individual, and not an IETF working group. So it's a bit disingenuous to say that the "IETF Opens Draft Version of Updated SSH for Public Review" as the linked article does. (And as noted, in other comments, this document is more about operational best practice than changes to protocol standards anyway.)
Unless this is picked up by an IETF working group then it can't be a standard - the independent RFC submission track only allows the resultant RFCs to classed as Informational or Experimental.
I'm not sure where "final version of the standard is expected in October" comes from. It isn't what "Expires: October 06, 2013" means on the draft. (All Internet Drafts expire after 6 months.)