Forgot your password?
typodupeerror
Encryption Network Security

Draft IETF Standard for SSH Key Management Released 35

Posted by Unknown Lamer
from the best-practices dept.
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.
This discussion has been archived. No new comments can be posted.

Draft IETF Standard for SSH Key Management Released

Comments Filter:
  • 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.)
  • 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.

    • by Anonymous Coward

      AuthorizedKeysCommand

    • 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
  • Awkward format... (Score:4, Interesting)

    by Junta (36770) on Wednesday April 10, 2013 @09:05AM (#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.

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

      • by Junta (36770)

        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.

    • by real gumby (11516)

      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

  • by Anonymous Coward on Wednesday April 10, 2013 @09:05AM (#43411723)

    Tatu Ylonen (creator of SSH 1.x)

    Ylönen.

    • by tqk (413719)

      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.

  • 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 [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

    • by jgrahn (181062)

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

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

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

  • 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

"Our reruns are better than theirs." -- Nick at Nite

Working...