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.
I know I am extraordinarily bad at key management. I also know I have lots of company in that. I have not had much luck in finding good guidance until now. I look forward to one day understanding what the smart folks at the IETF have to say about it! (That day will not be today. It takes a while to digest an RFC, for me at least.)
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
There is some ways to recompile ssh to lookup using ldap, but I really wish that it would be baked in. I would love to just put a list of authorized keys, which host and user they go to, like we can with sudo in ldap.
What are we going to do tonight Brain?
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.
In section 2.1 there's a rare shout-out to a specific commercial product in the body of the RFC. I guess it pays to author the RFC!
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.
I BET if the mods would check the source IP of this story, it would trace to either SSH's Boston US or Helsinki FI office. Can we try to at least give impartial news, this is bordering on outright advertising, as SSH has been pushing their new "Manger" or whatever it is every time I turn around. While it is a problem, the idea of centralizing management of everything makes me really question, just how much can we trust this product, and is it really better to put all the castle's jewels in one locked room, or keep them spread out? "We never were attacked until we got these IDS systems, they are an attack magnet" might be another view, so any honest 3rd party teardown of this is welcome.
If people are lazy or stupid or both, how does some buzzwordy document help this?
I want to delete my account but Slashdot doesn't allow it.
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.)
Every time myself and most people I know use SSH they are ususally providing login/password credentials to go with.
If this is all your doing then why not expliot common credential knowledge to securely mututally authenticate to the system instead of or addition to certificates? SRP provides a zero knowledge proof no offline dictionary attacks, no "leap of faith", crypto binding of channel encryption to authentication and best of all no worrying about managing certs.
This obviously does not solve everyones problems but it does hit on the most common use cases for many of us.
As an aside who do I have to pay to get my I-D's advertised on slashdot? Does it come with an instant consensus building flash mob?