On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote:

So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.

You only think this is bad because you believe CAs add some value.

SSH keys aren't signed and don't expire. Is that bad?

Agred - that (signing) in itself not important - however in a (large) corporate environment overall plain keys does force one to re-invent the same kind of CA and/or CRL wheel with respect to the expiring and the lack of a managed authority.

I recently came across two installations where ssh public keys where used to great avail (combined with a command="" construct which would launch various curses/IBM tn3270 user interfaces), in one case combined with a commercial product where a x509 on a chipcard would login and 'unlock' a users windows home directory/registry. This system had been going on for many, many years and had seen several OS migrations.

With the advent of faster moving windows/laptops - a lot keys had been 'lost'. Some due to real loosing of a laptop; most due to automated upgrades wiping the users transients home-directory/registry.

After a bit of scripting it seemed that for every key which had been used in the last few weeks; a little over 8 keys where 'dormant'. A manual quick sample confirmed that most of those where associated with lost/retired equipment (hire/fire was a well controlled HR process). Looking at an authorized keys file revealed little - as few, if any, comments where filled out.

Couple of things suprized me, and/or where a serious of an eye opener to me:

A       Even very experienced sysadmins can make the conceptual
        error that an old 'public key' is not 'dangerous' _because_
        it is public. Therefore you do not need to keep careful
        track of them or be 'super diligent' when managing your
        key files.

B       The very nature of the ssh public key (esp. when generated
        in an environment where the comment field is not easily
        attributed to a specific user; e.g. on windows some tools
        just put the text 'Generated by SShKey.exe' in that field)
        is very hard to manage - and really assumes a 1:1 mapping
        of a unix account to a real person.

C       The lack of expiry _combined_ with the lack of easily
        'documenting' an ssh key (i.e. the full key or even the
        fingerprint or bubblebabble of the ssh pub key is a bit
        painful when you need to cross a cut-and-paste barrier)
        easily creates and environment where the keys start to
        lag behind or where the pain combined with false security
        due to the 'A' misconception starts to conspire
        against you.

And as an aside - as one of the organisations already had a PKI rolled out into every nook and cranny - so using the Roumen Petrof patches which add x509 to openssh* - has helped solve some of the worse excesses virtually overnight.

So I'd argue that while x509, its CA's and its CRL's are a serious pain to deal** with, and seem add little value if you assume avery diligent and experienced operational team -- they do provide a useful 'procedural' framework and workflow-guide which is in itself very valuable, relatively robust and are a little bit organisationally "inherently fail-safe". The latter as you are forced to think about expiry of the assertions, what to do when a CRL is too old and so on.

Or perhaps we're comparing apples and oranges; ssh is just a pure pub/ priv key pair -- whereas x509 is a management framework in which you happen to also have embedded and manage a pub/priv key pair along with a whole lot of other things.

However - as firewalls and hardening of the far-outer perimeter is increasingly becoming ineffective, as you increasingly look at fine grained controls close to the user and (end) applications -- we do need to come to grips (much) better with the distributed management tools which let us map those controls to the desired social/ organisational model they are functioning within.



*: http://www.roumenpetrov.info/openssh/ (and I'd love those in openssh itself, and in solaris please :) **: not in the least as they force you to tackle nasty organisational questions such as who is really responsible for what; rather than let it fester it into some ops-team 'we always did it like that' fudge.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to