delegating SSL certificates

[Dirk-Willem van Gulik]

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

> travis+ml-cryptography at subspacefield.org 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 majordomo at metzdowd.com