Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Draft IETF Standard for SSH Key Management Released

Unknown Lamer posted about a year and a half ago | from the best-practices dept.

Encryption 35

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.

cancel ×

35 comments

Sorry! There are no comments related to the filter you selected.

Great news (1)

SirGarlon (845873) | about a year and a half ago | (#43411663)

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

Re:Great news (-1)

Anonymous Coward | about a year and a half ago | (#43411785)

Somebody needs to mail a box full of flies and human feces to Roblimo Rosenberg.

ldap? (1)

QuantumRiff (120817) | about a year and a half ago | (#43411693)

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.

Re:ldap? (1)

Anonymous Coward | about a year and a half ago | (#43411733)

AuthorizedKeysCommand

Re:ldap? (0)

Anonymous Coward | about a year and a half ago | (#43411769)

That's great if you're on RedHat.

Re:ldap? (0)

Anonymous Coward | about a year and a half ago | (#43412321)

This has been in base OpenSSH since at least 5.1p1. So it is on SuSE and a lot of other Linuxes or anyone compiling OpenSSH.

Re:ldap? (0)

Anonymous Coward | about a year and a half ago | (#43412537)

Actually it is not - it is in base OpenSSH but only in the newest 6.2 release [openssh.org]

That means it's not on most Linux distributions unless they've applied it in a patch.

Re:ldap? (2)

PartyBoy!911 (611650) | about a year and a half ago | (#43412057)

There is SSSD for that:

http://www.ohjeah.net/2011/06/09/linux-ssh-pam-ldap-sssd-2008-r2-ad-deployment/ [ohjeah.net]

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.

Awkward format... (3, Interesting)

Junta (36770) | about a year and a half ago | (#43411719)

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.

Re:Awkward format... (1)

nine-times (778537) | about a year and a half ago | (#43412035)

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.

I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.

Re:Awkward format... (1)

Junta (36770) | about a year and a half ago | (#43412561)

I think the single biggest failing is that it uses centralized CAs which means expensive certs, which means people don't use the encryption except for specialized uses.

The RFC is heavily worded around organizational management of keys. In that context, you aren't using Verisign or Thawte (and ideally you wouldn't even trust external CAs though certain frameworks like Microsoft's make that a challenging proposition), you are using one specific to your organization.

Re:Awkward format... (0)

Anonymous Coward | about a year and a half ago | (#43412235)

I think OpenSSH avoided X.509 for its certificates since implementing a parser for ASN.1 is hard, one just have to look at the number of ASN.1 parser bugs.

Re:Awkward format... (1)

sjames (1099) | about a year and a half ago | (#43420113)

ASN.1 really does seem to be designed to be as close to impossible to implement as possible without actually getting it ignored entirely.

Re:Awkward format... (1)

real gumby (11516) | about a year and a half ago | (#43420929)

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.

The use of RFCs as ways of managing best practices not only has a long and honourable history but is codified in a series of RFCs specifically marked "BCP" (Best current practice). Check it out yourself at RFC-Editor.org

Finnish name correction (3, Informative)

Anonymous Coward | about a year and a half ago | (#43411723)

Tatu Ylonen (creator of SSH 1.x)

Ylönen.

Re:Finnish name correction (1)

tqk (413719) | about a year and a half ago | (#43414087)

Tatu Ylonen (creator of SSH 1.x)

Ylönen.

Tell that to Giovanni Caboto|Jean Cabot|John Cabot. "A rose by any other name ..." That, and many, many other characters don't exist on my keyboard, and though I've heard there are ways to produce it it'd be used so seldom it's not worth the effort. Sorry Tatu, but thanks.

Re:Finnish name correction (0)

Anonymous Coward | about a year and a half ago | (#43414963)

Isn't the accepted form "Tatu Yloenen" if you are unable to reproduce the international letter? The same way that "ß" is to be represented as "ss" if you cannot create the eszett? Some people need to broaden their horizons and be respectful of other cultures.

Re:Finnish name correction (2)

Volguus Zildrohar (1618657) | about a year and a half ago | (#43415621)

That's acceptable in some languages, but not Finnish.

This page [wikipedia.org] on Wikipedia explains.

Re:Finnish name correction (2)

Volguus Zildrohar (1618657) | about a year and a half ago | (#43415729)

Sorry, Slashdot ate the umlaut and turned it into a dash for some reason, so the link is broken. Type your own o-umlaut (alt-u, o on OS X, alt-0214 on Windows with the numeric keypad, *wave hands* on other systems).

Re:Finnish name correction (0)

Anonymous Coward | about a year and a half ago | (#43418501)

*hands a wavin*

(freebsd)

Re:Finnish name correction (1)

gay358 (770596) | about a year and a half ago | (#43420409)

In Finnish there is no tradition of replacing "Ã" with "oe" and it looks very odd. If it is too hard to write YlÃnen, I would prefer Ylonen over Yloenen.

In most cases you are able to understand/guess the Finnish words correctly even if you write "a" instead of "Ã" or "o" instead of "Ã" -- especially if they are in a sentence that has many words giving more context. However, there are (possibly dangerous) exceptions, like "ala" (= begin/start) and "ÃlÃ" (= don't).

Rare mention of commercial product in an RFC (1)

xxxJonBoyxxx (565205) | about a year and a half ago | (#43411739)

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!

Maybe they should look at FreeIPA & SSSD (2)

PartyBoy!911 (611650) | about a year and a half ago | (#43412103)

Why reinvent the wheel :-%

https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/user-keys.html [fedoraproject.org]

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.

Re:Maybe they should look at FreeIPA & SSSD (0)

Anonymous Coward | about a year and a half ago | (#43412509)

I'm prepared to be proven wrong but here are my thoughts:
1. Keys have to be distributed "manually" and separately anyway (manually includes as network bits if on an already secured connection). Which keys aren't user-specific? Is there ever any sensible case for not using individual keys?
2. Administrators not only have to approve the user keys but also create the user keys for their own servers anyway for real security. Same as above really.

I.e. your problems are not problems but requirements for using keys securely as far as I understand it.

What proper use of SSH doesn't entail the above? Access management etc. should happen by assigning users to groups on the server, not through sharing keys between different users.

Cluebats welcome.

Re:Maybe they should look at FreeIPA & SSSD (1)

xxxJonBoyxxx (565205) | about a year and a half ago | (#43413157)

>> Which keys aren't user-specific?

Here's two general use cases I've seen:

When you're using keys to authenticate from automated systems, there often isn't a well-defined user, especially if the system has been designed to dump data from multiple pre-configured endpoints. (In this case every endpoint shares a client key for the length of the deployment.)

People authenticating to multiple systems start to use the same key on multiple systems. (This isn't bad by itself - it's similar to how client certs work.) If you get enough of these you sometimes see people authenticating to the same machine with different users but the same key. (Or, you might have an admin testing different user accounts on a machine, but doesn't want to create a new client key for each, so he duplicates entries server-side.)

Re:Maybe they should look at FreeIPA & SSSD (1)

tqk (413719) | about a year and a half ago | (#43414361)

Cluebats welcome.

I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).

Re:Maybe they should look at FreeIPA & SSSD (1)

Slashdot Parent (995749) | about a year and a half ago | (#43415097)

I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).

ssh-copy-id [die.net] is what's wrong with scp. Your "solution" also copies your private key to the remote host, which is almost certainly undesired behavior.

Beyond that, your "solution" doesn't address the other issues mentioned in TFA, such as key rotation, key removal, centralized key administration, etc.

Re:Maybe they should look at FreeIPA & SSSD (1)

buchanmilne (258619) | about a year and a half ago | (#43420565)

Cluebats welcome.

I'm wondering what's wrong with "scp -rp ~/.ssh user@host:~/" (assuming pword auth can be enabled momentarily).

1)PasswordAuthentication no

(One of the reasons to use keys is to avoid password cracking, and/or enforce two-factor/multi-factor authentication/authorizaion in conjunction with sudo or a VPN or similar)

2)AuthorizedKeysFile /etc/ssh/keys/%u.pub

(Many security frameworks don't allow non-administrative users to have full control over keys, as this can lead to abuse, such as a member of the dba group, who can run certain commands as the oracle user with auditing, giving him/herself unrestricted/unaudited access to the oracle user account. Another example is if there are restrictions in the aurhorized keys entry, such as forced command, or sources that can use the key via 'from', 'no-port-forwarding', etc. etc. that should not be under the user's control )

We have historically used the LPK patch to OpenSSH, and we are transitioning to the AuthorizedKeysCommand feature, and have the two configurations above on all our production servers. Before the LPK patch, it was a non-trivial effort to add new users. I guess these days, puppet or chef would be other options too.

Re:Maybe they should look at FreeIPA & SSSD (0)

Anonymous Coward | about a year and a half ago | (#43412579)

Or, use puppet.

Re:Maybe they should look at FreeIPA & SSSD (1)

jgrahn (181062) | about a year and a half ago | (#43414949)

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.

Huh? The only "applications and services" that have a reason to be interested in my public keys are OpenSSH and malware. And OpenSSH already knows where to find its own keys. Yet another reason to stick with Debian, I guess ...

Re:Maybe they should look at FreeIPA & SSSD (1)

buchanmilne (258619) | about a year and a half ago | (#43420523)

FreeIPA and SSSD are not required.

Just OpenSSH with either the LPK patch, or the AuthorizedKeysCommand patch, or OpenSSH 6.2 or later.

I have been using ssh keys in LDAP since 2004, with OpenLDAP. FreeIPA, and its dependency on 389/RHDS (specific, non-standard features of 389/RHDS have been built into IPA, whereas many other web interfaces for LDAP have solutions to the same problems which don't rely on proprietary RHDS features) is unnecessary.

Just who got this on /. (0)

Anonymous Coward | about a year and a half ago | (#43413861)

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.

RFC for shit-togetherness ? (1)

Gothmolly (148874) | about a year and a half ago | (#43414085)

If people are lazy or stupid or both, how does some buzzwordy document help this?

Internet Draft - not a Draft Standard (2)

admcd (23824) | about a year and a half ago | (#43415005)

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

Forget the damn keys (0)

Anonymous Coward | about a year and a half ago | (#43416529)

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?

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>