On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote:
[EMAIL PROTECTED] 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.
Thanks,
Dw.
*: 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]
